Starting a new team is an exciting but challenging endeavor, with lots of variables to consider. Splitting teams by fission is the smoothest, optimal way to grow your organization and tackle new problems, and provides a way to create new ownership and growth opportunities. However, creating teams is a delicate art and requires careful balancing of risks to get to an optimal outcome.
Here we’ll discuss several principals to make sure you start teams in ways that help drive towards long term success. These principles are:
- Make sure teams have clearly defined areas of ownership
- No grab bag teams
- Teams need engineering anchors
- No mini teams
Clear Areas Of Ownership
One of the most important things to consider when starting a new team is to establish clear areas of ownership. Without clear areas of ownership, teams will struggle to prioritize their tasks and end up competing with one another for the most attractive projects. This leads to conflict and infighting within the organization, especially as you pass Dunbar’s number – the cognitive limit to the number of people with whom one can maintain stable social relationships, which occurs at a group size of roughly 150 individuals.
When you have multiple teams with vague missions, patterns of organizational friction occur. If you’ve seen it happen more than once, it can be like having nightmarish deja vu:
- You have two teams that have vague missions, and the org is big enough that they’re not regularly interacting.
- In that gray area, both teams simultaneously see important projects and focus-areas the org needs to get done, and both start planning to do them.
- When it’s clear both teams are working on the same high-value projects or focus-areas, pandemonium ensues:
- Both teams now have a vested interest in their projects, and reverting that focus will be seen as a mess
- Both teams will start to claim the other is incompetent over trivial disagreements in approach
- Someone might suggest that the teams just work on the project together, but that papers over a huge amount of problems that would then ensue, particularly who maintains the project after it’s done.
This might sound dramatic, but the reliability and severity of this pattern is real.
To prevent this from happening, it’s important to make sure that each team has a clear definition of what they should be focusing on. This will help to ensure that there is no duplication, overlap, or dependency sharing between teams. By doing so, you can prevent teams from stepping on each other’s toes and help them to work more effectively together.
In software organizations, good fences really do make good neighbors. Some organizations try to fashion elaborate checks and balances to avoid duplication of work; it’s best to avoid duplication by designing an organization with clear and disjoint areas of ownership.
No Grab Bag Teams
A problematic subset of the vague team is the “grab bag” team. Software organizations often have a bunch of extra stuff sitting around that nobody really wants to own. These often include things like: login flows, settings pages, credit card processing, internal automation. Those organizations sometimes try to build teams that are grab-bag teams that handle all of that extra stuff. This is often a mistake.
The logic that leads to a grab-bag team is simple:
- We have a lot of extra stuff and don’t want to dilute other team’s missions
- We can make a team that owns all of this, because it’s a manageable scope
- The team will have high value because they’ll prioritize the highest value stuff in the grab-bag.
As much as leaders may believe in the total opportunity of these teams, they often staff the team and partner with the team based on average priority of the pieces - medium priority grab bag items - instead of the priority of the total opportunity. These teams often end up in one of two states: struggling or pivoting.
The default lifecycle of these teams is to struggle: their mission is never quite clear, the team is never quite motivated, the resourcing is never quite good enough. It ends up being a place-to-leave for anyone ambitious, and a place-to-go for people who are on slow paths out of the company. Instead of making hard decisions, leadership lives with this simmering pot of medium-ness because it solves having to figure out where all the stuff goes, and having an ok team is seen as better than dealing with the alternative exercise of finding owners for everything.
The other outcome is pivoting. If the team gets people with ambition who don’t ask to leave, they end up wanting to focus on more clear, high value projects. These can often be things that are problematic in various ways: duplicative of other teams’ work, high effort but not actually high value, and more. The worst version of this style of progression is when the team is staffed for the one style work they were incepted for, but then allowed to pivot to a high-difficulty, business-critical effort. This creates a situation bound for failure.
Instead of making grab bag teams, add ownership to existing teams and ask them to manage it until we grow large enough to have fit-for-purpose teams own it. This is a harder play for leadership to facilitate, but it’s the better move in almost any timescale.
Engineering Anchors
For engineering teams in particular, it’s important to have a high-context anchor who can make sure the team builds properly.
If you’re building in a way where people can build from scratch, can just use things like cloud services, and there’s not deep context needed on product or engineering decisions, that can just be someone you hire, or just anyone who is really good - here’s an AWS account, go crazy. This is not frequently the case.
However, if you’re building in an existing system, especially with high coupling and tech debt, you need to make sure you have someone who knows that system. Otherwise, you’ll create a team that either 1) has a dependency on other teams to know how to build anything efficiently or 2) slows down more and more over time under the weight of their tech debt and not-quite-right builds.
In any case, the impact of having expert over the long run is absolutely staggering. Engineering anchors can be a huge multiplier on the impact of a team over a long enough timeframe:
- Architecture decisions compound over time. Without a team anchor, you run the risk of taking on crippling debt for any new project you want to do.
- The most common example of compounding anchors are founding CTOs - the best ones are the engine for generational companies and often are the reason tech-enabled companies can turn into tech-driven companies over time.
No Mini Teams
Avoid cross-functional teams with less than 4 engineers - they are fragile and prone to failure.
Cross-functional teams with less than 4 engineers live in a forever state of precarious fragility. Attrition and leave all threaten the goals of non-robust teams in meaningful and existential ways, and engineers are the core branching factor.
For example, your average cross-functional team has 1 PM, 1 designer, and maybe 6 engineers. The ratio of the PM and Designer is 1:6, and even with half the team out of office for any reason, you can still get work done. With 3 engineers, it only takes a wedding, an illness, and a bad bug to grind your forward progress entirely to a halt.
If you’re starting a new cross-functional team, get to 4 engineers within 6 months. If you don’t have a plan for that, don’t start the team.
Further, avoid breaking a larger two-pizza team (7-8 engineers) into two fragile teams, especially if there’s no plan to get those teams to 4+ engineers in the very near-term future. People often want to break teams into two to solve focus and prioritization issues - this team has two areas of focus, let’s split and avoid being split-brain. However, if you split into two small teams, you turn a prioritization annoyance into an existential risk of instability. You also increase the likelihood one of the two sub-teams doesn’t have an engineering anchor and you risk creating unsustainable on-calls. You’d rather have to spend a bit more time in sprint planning with a large two-pizza team than a team with no anchor or extremely volatile resourcing.
Summary
In summary: give teams clear missions that aren’t grab bags, and make sure they have an engineering anchor and enough people to keep going in the face of inevitable challenges.