Scaling distributed teams

The idea of distributed teams is nothing new. Over the past decade, having remote workers has become commonplace. While it used to be a co-located team with a couple of remote team members, it’s now common to find entire teams being distributed.

Often organizations manage distributed teams in the same way they manage co-located teams. They pick a development model that fits with their organization, substitute a work tracking tool for face-to-face accountability, and hit the ground running.

For a small team, this works fine. They’re self-organized enough that inefficiencies bubble up and just a little bit of process and organization smooths out the rough edges. The problem comes when you try to scale.


Even though an organization may be fine with distributed teams, they typically try to scale just like they would if the team were co-located. This usually involves:
  • Generating documentation around the project for new team members to read
  • Establishing an on-boarding plan that involves a number of steps and progressions until the new hire is part of the team
  • Segmenting off the new hire into low risk work until they learn the ropes and are ready to integrate with the team
This works well until the size of your team reaches around seven engineers. When you hit that number you have something that’s really hard to penetrate. The members have reached the effective limit of being able to keep track of what’s going in the team. That leads to boundaries around the team making it hard to grow and hard to coordinate with others. At that point, change is often disruptive.


At this point if you focus on the team you’re only going to make incremental progress. You can add an engineer, put them through the on-boarding process and hope they integrate well. What you can often end up with is the same core team you had and a handful of fringe engineers that inadvertently get less critical work. Depending on the hire, you can also end up with a “rock star” that again doesn’t integrate, they just get the tough “lone ranger” work.

The environment of the team — the organization, the attitude, and the culture — can have a tremendous impact. Focus on the environment and you’ll be able to add twice as many people, twice as fast, with less risk.

Agile (buzz word alert)

By definition, you have to exercise whatever it is you want to be agile. Do you want a team to handle change well? Make sure a new hire joining isn’t the only change that ever happens. Do you want to hire more than one engineer? Make sure there’s more than one entry point in the team. You want the team to be flexible about work? Make sure the same people don’t work on the same things. It sounds simple but it requires organization and a culture designed to leverage the agility.


Organization is critical. It’s wise to break up large teams into squads. This provides a whole host of benefits when scaling. It gives you the opportunity to take advantage of agile practices that are hard to do with a large team: iteration planning and decomposition, daily stand-ups, team accountability, and self-organizing. Having a squad work on a specific initiative helps them stay connected, focused, and motivated.

Perhaps more important than that is the ecosystem it creates. You can let squads remain the same for a while, learn to work well with each other, and then change them up. They learn to leverage each other’s strengths, adapt, and it keeps squad barriers from creeping up. Make sure squads rotate around subject areas and you end up with knowledge sharing and lessen the risk of burnout. A side effect is when you hire someone new, instead of them having to figure out how to join a big team that’s been the same forever — there are several squads that they can join that are all used to change. With a dozen engineers, Instead of struggling to add one to the team, you can add three.

What happens is with a squad as an entry point, the new hire gets more attention, feels more connected, and learns faster. You still have the resources listed above like project documentation and a body of work with a smaller learning curve — but that’s not the focus, the squad is. A new team member can feel effective in a couple of days (sometimes hours) rather than weeks. They’re not off “learning” by themselves. They do something simple to learn the process and then work directly with their squad.


Culture is just as important as organization. If you organize but don’t create or maintain the right culture, instead of having one team that’s hard to integrate with, you’ll have three. You have to actively avoid barriers around the squads just like you work to avoid them with a large team. The key is balance. You want to do enough with the whole team to keep boundaries low and interaction high without wasting everyone’s time. A few key things that can help:
  • Rotate squads so there are different team members on different squads. It keeps barriers down and avoids a super squad.
  • Have squad based stand-ups. You want everyone to interact everyday but not feel like they’re wasting 12 people’s time. A squad based stand-up gives that opportunity for help, interaction, and accountability. In a distributed team, hearing each other’s voices helps everyone.
  • Have whole team retrospectives. Don’t make a daily stand-up take half an hour by including everyone but it’s fine to have a weekly or bi-weekly retrospective take that long. It lets the whole team identify what’s working and what isn’t and interact.
  • Make iteration planning required for the squad but optional for everyone. It encourages participation in planning whether you’re on the squad in question or not.
  • Make sure peer (or code) reviews are not locked to squad. You want that cross-squad interaction. It may take longer for the review but the end result is better software, more knowledge shared across the project and therefore less risk.


Last but not least is management. An excellent benefit of small, agile teams over a large project team is that just like in development, you can fail fast. Organizations love agile development because you make progress faster and therefore can react to mistakes faster. Not only do you get quicker results, but also less waste. A well-organized agile team lets you do that with people. When you have a squad giving a lot of attention to a new hire and they can get up to speed in days, you don’t have to wait months before you know if they’re going to work out or are a good fit for the organization.

That immediate feedback loop from multiple sources is as if you spent the first couple of weeks with each new hire individually. As a manager, it’s a tremendous advantage to know you have solid people and whether or not your new hire(s) is going to be a good fit within weeks instead of months or years. The health of your team is more important than the individual skills of your people. A healthy team of quality people can ship quality software in way less time than a few rock stars that aren’t motivated and can’t get along.

Ship quality software

There’s a difference between hacking up a solution with an ad-hoc team and shipping quality software that can be developed in a cadence that can be dependable if not predictable. (when is software development predictable?)

Distributed teams can ship that quality software in a dependable way with the right tools, organization, culture, and attitude.


Popular posts from this blog

Engineering teams: what and how