For several months, I have been working as part of a very large team, bringing together three companies and spanning several time zones. There are about fifteen developers that actively contribute to our codebase — plus several more team members responsible for planning, design, or management. It’s a large group of people with wildly different experience levels, priorities, and personalities.
As you can imagine, this team dynamic makes work coordination a challenge. Our team has tried a handful of different methods for dividing up work. Here are the pros and cons we’ve noticed for each one.
The Single Team Approach
This approach encourages any team member — regardless of prior experience or familiarity with the subject matter — to pick up any story or task. Any piece of work is fair game. We used this low-structure, anything-goes approach during the earlier phases of our project.
- It encourages team members to take on whatever work is the most interesting or rewarding to them personally.
- It requires all developers to stay up to date with changes in all areas of the project.
- Individual developers can become paralyzed by uncertainty, not knowing which task they should pick up next.
- Work that had been planned/discussed by certain team members can be picked up by someone who didn’t participate in said discussions.
- It’s difficult to know whom to contact when you’re facing uncertainty.
- It requires more all-hands meetings to keep everyone on the same page, which can quickly become a time waster.
The Smaller Sub-Teams Approach
This strategy attempts to ease some of the chaos by splitting the team up into smaller sub-teams. This can limit the scope of what one needs to know, reducing the need for a broad understanding of all the moving parts.
- It creates more opportunities for people other than project leads to take on unofficial leadership roles.
- There’s less stepping on other people’s toes.
- Different teams working separately for long periods of time will lead to inconsistencies in the codebase.
- Decisions get made by people with less context than the project leads, which may cause unintended problems.
There are, of course, different ways to split a large team into smaller teams, each with their own set of benefits and drawbacks.
The Office-by-Office Sub-Team Approach
This is perhaps the easiest and most natural way to divide a large team into smaller teams. Not much thought needs to go into determining who will be working together. Developers will work with their own coworkers on closely related tasks.
- It can be helpful to work with people who share your company/office values, priorities, and work styles.
- Using the same set of communication/remote work tools makes collaboration easier.
- It requires less planning to split out separate teams.
- This creates the possibility of losing out on teach and learn opportunities between offices with different areas of expertise.
- It can potentially contribute to an us-vs.-them mentality.
The Feature Sub-Team Approach
This approach divides up the backlog into parallel streams of work. Each team member is assigned to a single feature and expected to work on that feature alone.
- Parallel lanes of work can boost the larger team’s output.
- Encouraging people to focus on a given feature allows for deeper understanding.
- More personal interaction between offices can help with easing conflict and increasing understanding.
- People may feel less accountability to folks from different offices.
- Developers may not have a broad understanding of the system as a whole.
- It creates less opportunity to build relationships with your in-office coworkers.
Ultimately, no single approach is perfect. What works well for the project is highly dependent on the particulars of what each office cares about prioritizing.
I hope our experience can help you understand the benefits and drawbacks of each approach and make a better decision.