At Invoca, our engineering team has worked hard to transition to a decentralized service ownership structure. Each team has services and features that they own, from ideation all the way to deployment and monitoring. The autonomy of the teams to define and prioritize their respective roadmaps has been effective at ensuring reliability and stability while continuing to deliver new features. This structure gets difficult, however, when there are efforts that span multiple teams and require tight coordination. We use working groups as a tool when working on cross team initiatives that are otherwise having difficulty gaining momentum.
Wikipedia defines a working group as:
A working group, or working party, is a group of experts working together to achieve specified goals. The groups are domain-specific and focus on discussion or activity around a specific subject area. The term can sometimes refer to an interdisciplinary collaboration of researchers working on new activities that would be difficult to sustain under traditional funding mechanisms.
We have defined the term as simply: a group of people that spans teams or departments who meet regularly to discuss and coordinate domain-specific work.
When should you form a working group?
As a last resort!
Even though this post is about working groups, we actually do our best to avoid them if we can. If possible, we strive to find a single team that can be responsible for the technology or the desired result. This team will be far more productive than a cross-team initiative, as coordinating cross-team efforts is hard and prioritizing it against all the other work on those teams is even more difficult.
Sometimes though, the above isn’t possible. For example, we found that database improvements (such as upgrading versions, adding visibility tools like PMM to production databases, migrating to UTF-8 4 byte support) were not happening, or happening too slowly, because no single team was owning our database layer. We considered creating a formal database team, but there was not enough consistent work to keep an entire team busy in the long term. Database experts already existed on various application and infrastructure teams. Forming a working group that created and maintains a roadmap for database improvements was incredibly helpful. The group gets together periodically, reviews progress and farms out work to various teams to get on their prioritized roadmaps.
It is important to note that working groups are most successful when the need is already prioritized at the department level, and often times even a rough plan or timeline has already been agreed upon as well.
For discussing work that is not yet prioritized, or to just get together with other peers across teams to discuss interesting technologies or topics, consider a guild, as introduced by Spotify.
Getting work done: The working group is only identifying work for teams. The teams represented by the working group need to understand the work and fit it in with their priorities. If a working group is advocating for work that is important but not urgent it may be a long time before a team can pick it up.
Communication: Documenting and communicating decisions and roadmaps becomes more difficult as the working group falls outside the normal team level processes that handle these things.
Excessive Ambition: It is very easy for the working group to identify cool ideas that are not worth the extra effort. Resist. Stay focused on value.
Focus: Members of the working group already have a lot on their plates. Strive to make the working group a good use of their time and cancel it if that is no longer true (see “Running a working group meeting” below).
Mechanics of a working group
Create a Slack channel (or your organization’s equivalent) for the topic project or goal and invite the group members.
Create a shared document to act as minutes for the meeting:
- Use for the agenda of upcoming meetings
- Initial meeting agenda should include deciding on a cadence for the meeting and making sure you have all of the right members
- Pin this document to the slack channel
Schedule a recurring meeting with suggested members
- Include a link to the tracking document in the meeting request
- Allow all members to edit the calendar item
Running a working group meeting
- Every meeting should have a new section in the tracking document
- Keep notes of decisions and action items from this meeting in this section
- We use Google documents, and take advantage of the comments and the “assign” feature within a comment as a light-weight way to track action items
2. Review the agenda for that week and any open action items
- If any action item has not been addressed, carry it forward to the next meeting
3. All action items should have an owner who is a member of the group and attended the meeting
- If someone outside the meeting will work on something, an attendee should still be the one to own and track that item until it’s complete
4. End the meeting with a section for the time and agenda of the next meeting in the tracking document — this will allow the agenda to be updated between meetings
Stay focused & time-boxed
- Use the meeting time for information sharing, tracking progress and highlighting any decisions that need to be made
- Don’t digress to unrelated items
- Decisions do not need to be made in the meeting — instead, assign an action item and an owner
- The owner will coordinate the discussion elsewhere and report the results in the next meeting
- Keep the meeting as short as possible and end early if there is nothing more to discuss, don’t feel the need to fill the time!
After a few meetings, be sure that you find the right cadence. If there is little to coordinate you can meet less often. This can change so reassess often.
Who does the work?
- The members of a working group are not usually working 100% of the time on the working group project.
- Team members that are NOT members of the working group may work on the project if needed.
- It is up to the members of the working group, and their respective teams to prioritize and staff the work. The teams should avoid taking on work that is part of a service they are not responsible for maintaining going forward.
Working groups can be a great tool for organizing an effort that is spanning teams, or has shared ownership across teams. Be careful not to have too many working groups running concurrently, and be aware that the time spent on working group activities will take away focus from the product roadmap and technical initiatives owned by each member’s team. As with many things in software development, it is all about making the right tradeoffs.