Comparing 3 Work Coordination Techniques for Large Dev. Teams

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.