As engineering teams grow, obvious difficulties arise. It’s simple math. You can’t keep up with everyone, and everything, in the same way as you did when the team was small. To maintain the high level of impact you’ve always had, your ways of working need to change.
The good news is, there are a few principles and laws that’ve emerged from social science and project management – like Conway’s Law, Dunbar’s Number, and Brooks’ Law – that can help inform your growth. The truths revealed by these principles about team dynamics and system design point the way to better outcomes and more team satisfaction.
While applicable to any domain, these principles are especially powerful in the context of engineering teams. Use them to help you lead through scale, change, and optimal organization design.
Principle #1: Dunbar’s Number
First proposed in the 1990s, anthropologist Robin Dunbar’s research shows that the human neocortex (aka the most evolved part of the brain) can maintain a maximum social group size of about 150. In a small team, you might know everyone’s favorite lunch, or how they spend their free time. As the team grows, though, you might find yourself only knowing first names, or that someone generally sits on x team. In big companies, you might not even recognize the people in your own org!
Numerous studies and social experiments confirm Dunbar’s findings. When applied to designing engineering organizations, it’s helpful for decisions about tools, processes, and organizational structure, all of which affect velocity as teams scale. For example, applying Dunbar’s number might come into play when deciding to specialize horizontally by technology, like a specific product, or vertically by functional area, like mobile, web, or infrastructure. Or it could be applied to decisions around effective geographic footprint expansion, or how to maintain a sense of responsibility within a team for the components they own.
Though the 150 people threshold receives the most discussion, as organizations grow issues crop up at thresholds below this number as well. When a team is ten people or fewer, it’s considered to be optimized for working together. But as the team grows to more than 35 people, optimization requires system-level interfaces and roadmaps to align goals and timelines. (This includes tools like Jira.)
At 150 or more people, the system needs to be completely stand-alone. At this size, you begin to lose familiarity (like not knowing every name or role), visibility (uncertain of all the work that is happening across the organization), and communication (complexity around schedules and channels).
When we moved the Confluence Cloud team from one location to another, we adjusted team sizes to address the challenges suggested by Dunbar’s Number. First, we scaled the team down to build rapport, trust, and effective processes in the newly-formed team. Once we knew we had the systems and tools in place to help the team collaborate with more colleagues, we scaled back up. During these changes, we learned important lessons about initial team setup, what’s required over time to maintain cohesion, and aligning horizontally or vertically.
Here are a few tips to mitigate the effects of Dunbar’s Number:
- Keep team sizes small when possible. For example, for initial team set up start with 3-5 devs under a manager, co-located, so they can build rapport.
- Try monthly cross-team demos to share knowledge.
- Make time to build relationships with others as the team grows.
- From casual coffees to all-hands meetings, it’s important for everyone to feel connected not only to the work, but to their colleagues.
Principle #2: Conway’s Law
First proposed in 1967, Conway’s Law states, “Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” In practice, this boils down to “shipping your org chart,” which rarely produces awesome experiences for your users. Conway’s Law can be harnessed for impactful outcomes, or ignored for predictable results.
When designing an organization, the system architecture mirrors the chosen model. For example, if there are two sub-teams building part of a system, that system will have two components. This happens time and again in software at all levels. By applying the model of strategy –> organization –> people when creating your organization model, you can use Conway’s Law to your advantage. It can help you deliver simpler software, at lower coordination costs, with fewer duplicative efforts.
The recent emergence of the “inverse Conway maneuver” (or structuring your business organization to mirror your desired software architecture), is a tactic evolved from Conway’s Law taking it from cautionary tale to a powerful tool. For example, in a scenario where duplicative systems are being built, you could merge ownership of the two systems into a single team or organization, and the duplication will reduce rapidly by itself.
During a transition at Atlassian, we had the opportunity to structure a new team and tried the squads and tribes model. But it didn’t work. It was too randomizing for such a complex system. Turns out, it’s hard to move to any part of the squads and tribes system monthly or quarterly and ramp up on the knowledge required to be effective.
Here are a few tips to mitigate the effects of Conway’s Law:
- If two teams are building similar systems, apply the inverse Conway maneuver so they are a single team with ownership of duplicate systems.
- It’s hard to know that similar systems are being built. Sample signals are confusion from users of the system (“They seem very similar, why should I use one over the other?”) or technology debates (“We should use Tech X because it will be better than Tech Y in that system.”)
- By having the same team own the duplicative systems, they will converge into a single system.
Principle #3: Brooks’ Law
Brooks’ Law comes from the seminal Mythical Man-Month book. It states, “Adding manpower to a late software project makes it later.”
It’s regularly invoked by engineering leaders, usually when a project is running late and the team’s working on mitigation plans. This oxymoronic statement has been validated in project after project across engineering teams of all sizes, and projects of all durations. Hofstadter’s Law, “It always takes longer than you expect, even when you take into account Hofstadter’s Law,” is frequently quoted in conjunction with Mythical Man-Month. The double whammy of taking longer than you expect, compounded by delaying an already slipping project by adding people, can have a detrimental effect on a project at a time when it can least afford additional delays.
Applying lessons learned from the Mythical Man-Month helps teams predictably scope projects during times of great stress. It enables engineering managers to integrate extra capacity without overcommitting the positive schedule impact of adding more people. (Which sometimes makes a bad situation worse.) Adding people may be the right thing to do, but that decision should be informed by Mythical Man-Month insights.
We face this often at Atlassian. On large, long-running projects, if we need to tighten timelines, we try to find people who have hands-on experience with the codebase. There are often less painful options, but we accept the tradeoff. In some cases, we look at second-order effects of shuffling people across multiple teams. And sometimes we accept that the schedule is not recoverable and move dates out.
Tips for mitigating the effects of Mythical Man-Month:
- Find the true break-even point for adding people to an existing project, factoring in ramp-up time for the new people, as well as training time for the existing team. That break-even point is further out than you think.
- While the title of the law says “mythical,” we’re always dealing with real humans. Consulting with someone’s manager is key to understanding the potential upsides and risks to moving one of their teammates to another project.