View Source

Date

20 Jul 2017

Attendees

Goals

Rethink the meeting structure

Discussion items

Time	Item	Who	Notes
60 mins	Rethink the FedX group	EdwardF (Deactivated)	Part two of our retro (see the mute mapping results here: 2017-07-06 Meeting notes) Eddie will lead a discussion where we brainstorm how the FedX group should work going forward Eddie will be the executive sponsor for the group Need a single decision maker who can report to Eddie and others Is this a working group, a chapter, an architecture meeting, something else? Decide upon a meeting cadence What is the typical agenda for the meeting? How do we track the success of the team? What are the team's outputs? Consider how often to do retros (once a quarter?)

Notes

Architecture team discussed four key tenets
- autonomy
- efficiency
- context
  - industry experience and expertise in the team. Know where the industry is going
- design
  - making sure that we're driving towards a high quality implementation
Other teams are similar
- architecture, security, performance, FedX, DevOps, platform
- all (other than FedX) are driven out of the Core team
- Educator, Learner, Open Source are key stakeholders
  - Their OKRs are not around improving the platform or technologies
- Core is the decider, drives and project manages the efforts
- Eddie would like to see FedX move to this model
- Who holds these groups accountable?
  - Eddie should be the executive sponsor of all teams, including FedX
  - Can go to Eddie to help drive adoption
- Have similar challenges
  - How does the security team move things forward?
  - Performance team is a dedicated Core team so it is their job to work this
    - This approach tends to be more successful
  - Docker project is interesting
    - It started with a number of passionate individuals
    - It eventually transitioned to the Core team as an actual project
    - The end result may not be an ideal Docker implementation due to the way it was developed
What makes FedX different from other teams?
What should we do with FedX
- Ari will lead the team as the Core representative
  - She is the decision maker for the team
- FedX team members are active practitioners
- Need to define who are the stakeholders for this group
  - Product delivery teams
  - Open Source team
- Who are our customers
  - Product delivery teams
  - Open Source community
- All decisions made by this group should be focused on serving developers
  - Secondary benefits: time to value
- This team should propose organizational changes too
  - This team should be the ones to propose that we need a core FedX team
  - Push for more autonomy
    - Release pipeline team was doing everyone's pipelines, training everyone
    - Had to push to give them the team's the ability to do things themselves
    - This is the only way to get the product delivery teams to scale
    - e.g. doesn't make sense that Ari has to fix all Webpack issues
    - How do we make sure that teams do follow the best practices?
- Does this roll up to architecture group?
  - Not clear yet. FedX will be a guinea pig
  - Eddie will meet regularly with Ari as the executive sponsor for the team
- Communication
  - Regularly share with lunch & learns, emails, engineering all hands
- FedX is in a great position to address time-to-value for FY18
Concerns
- How do we drive things forward?
  - Resourcing is still a challenge
- Business team does not have a representative on FedX
  - Their concerns like multisite don't necessarily get heard
  - Can we find someone to become a stakeholder and attend meetings
- Issues we need to tackle
  - Bootstrap
  - Paragon
  - Asset pipeline
- How do we use the FedX board?
  - How do product delivery teams pick them up? How do we justify them over product features?
  - We need to make sure tickets have clear value on time-to-value
- How will bigger questions be addressed?
  - e.g. do we want to completely separate front end from back end?
  - server-side vs client-side
    - Andy Armstrong (Deactivated) to share the learner discussions on this topic
  - how does this fit with full stack engineers?
  - FedX group should not be deciding these things in a vacuum
- How can we get more help from the Open Source community?
  - They are very excited to contribute but find our stack very confusing
- Talent acquisition and retention
  - Need to be adopting modern front end practices
- Core team should be the center of excellence to provide best practices
- For long running, cross-functional projects
  - e.g. fixing the asset pipeline
  - how do we resource this? Not enough resourcing within the Core team today
  - do we need a core FedX team?
  - can we spin up a short-lived team to solve big problems
    - again FedX needs to advocate for this
Actions
- Are there articles that would help us?
  - Look at how a chief security officer tries to affect change within their organization
  - Doesn't fit with "move fast and break things"
  - Maybe there are articles about driving front end technology change

Action items

Ari Rizzitano (Deactivated) - write up a page describing how the group is going to work moving forwards
- develop a fuller charter for the group
- decide how often to meet
- consider having office hours