Running a Successful Working Group

Giving structure to an agile engineering team is hard. You want people to work on the things that they are most interested in without losing focus on the main goal of building a great product. No matter how you split your organization into teams, you will miss covering certain areas of interest. This is where working groups can come into play.

We are a diverse group of people at Causes. People with different backgrounds, knowledge and interests make up the engineering team. Even though product teams collaborate on a daily basis, we’ve noticed that members with shared interests wanted to get together in a slightly more formal way than over a cup of imported, light roast, deliciously smooth pour-over coffee (@dgouldin can tell you more about that…). This is where working groups come into play.

Running a working group is a great way to gather people with shared interests and allow people to strengthen skills within a certain area. Our working groups are made up of individuals with a self-identified interest that they share with others. We currently run four working groups that cover Front-end Technologies, System Architecture, Testing, and Security. Anyone is welcome to join the groups, even people outside the engineering team.


We believe the main goal of a working group is to come up with practices and tools that the rest of the organization can benefit from. In our company, we often talk about force multipliers. By influencing others, you multiply your force. A good working group is a force multiplier. This is what we think is part of that mission:

Export knowledge to the rest of the team

Members of the working group should strive to have a shared understanding about what to use, when to use it, and how to use it. At Causes, this knowledge spreads throughout the organization through tech talks, code inspections, blog posts, emails, pair programming, and other means of collaboration.

Resolve controversial decisions

Let’s face it — building a product inevitably includes having to make decisions. These decisions can often be controversial. A working group can help you resolve the tension by structuring the decisions that need to be made.

Identify areas for future research and experimentation

A working group is a great place for discussing how different practices, processes and framework/tools could be used to solve problems. We always produce action items at our meeting, and these often aim at investigating some area and coming up with a concrete plan to be shared at the next meeting.

Getting the most out of a working group

Even though groups are self-organized and voluntary, we have found that some structure is important to be successful.

Meet regularly

We meet every other week for 30-60 minutes. This should be enough for most working groups, but situations may arise that call for more attention, and a tighter meeting schedule.

Stick to an agenda

Preferably, circulate a meeting agenda ahead of time so that people can prepare for the meeting. If you find yourself without having a meeting agenda (we all know this can happen…), spend the first few minutes of the meeting collaboratively creating one.

Keep track of action items

The first item on the agenda should be following up on action items from the previous meeting. During the meeting, take notes on all the action items that are decided. Follow up by publishing the meeting notes in written form. This can be an email, a document, a wiki article or any other searchable form of documentation.

Use a mailing list

This is great for circulating meeting notes and action items from the meeting. And it’s ideal for discussions that may arise in between meetings. We use Google Groups to create and manage our lists.

When expertise is spread out across a product-oriented team, you want the subject experts to get together and make decisions. These subject experts can then take the decisions out to their respective teams to share the knowledge. Working groups help enable this and are a valuable practice for any organization that needs to share knowledge that cross-cuts the formal team structure.

Henric Trotzig