Unconventional Team Structures (Part 1) 🏰
Let's talk of hierarchies, autonomous teams, and two in-depth case studies.
A couple of weeks ago I had a chat with a VC who is also a reader of Refactoring.
We agreed that today there starts to be some consensus about how to structure engineering teams, while just 10 years ago, when I founded my first startup, things were pretty messy.
Such convergence isn’t happening only to engineering teams.
Popular business categories, like SaaS, now have playbooks where the whole organizational structure is decoded, so that, based on your company stage, you can get a pretty good ballpark of what your topology and headcount should be.
This is extremely useful to both companies and individuals.
🏢 Companies — can grow faster, share vocabulary and best practices.
🧑💻 Employees — can more easily swap roles between companies, growing their skills and career coherently.
While this incremental approach is mostly for good, it also poses risks. With too much consolidation, we may get trapped in local optima and ignore more radical, innovative approaches.
What does radical look like in this context?
There are successful companies out there that don’t fit the mold. They have unconventional configurations, including things like:
They don’t have managers
They have people holding multiple, apparently unrelated roles
They replace key roles with processes
But why is that? Is it just petty rebellion or is there substance? What can we learn from them?
This article investigates original team structures who exist successfully in the real world. We will cover some interesting tech companies — on a spectrum that goes from unusual, to outright crazy — and extract lessons for the rest of us.
The goal is to 1) understand and 2) build a bridge:
Understand — by comparing conventional and unconventional structures, we can discover general principles about building great teams.
Build a bridge — can we take single rebellious ideas and apply them to our traditional team to make it better? I bet so.
This piece is the result of tons of research and multiple interviews with people in some of such companies. To make it easier to read and digest, I will split this topic into two separate newsletter editions.
In this first one we will cover 👇
🏔️ Hierarchies — why you get bottle-necked as you scale, and why companies create hierarchical structures.
🏃♂️ Autonomous teams — the holy grail of scaling, with challenges and examples from successful companies like Amazon, Riot, Spotify, and Coinbase.
🔍 Two in-depth case studies — about Dimagi and ProntoPro: two companies who adopted innovative structures while still retaining managers and some traditional processes.
In the second part, next week, we will turn things up to eleven and cover wild companies who gave up most conventional wisdom about organizational structure. We will talk about self-organizing teams, holacracy, zero managers, and more.
Let’s dive in!
🏔️ Hierarchies
To understand what’s unusual, let’s first talk of what’s usual. Why do team topologies exist, at all?
As long as your team is small, there isn’t much need for a formal organization — 5 to 10 people can work pretty well without much structure.
The main problem, when teams grow larger, is communication. Large teams have a hard time doing things like:
Keeping people on the same page
Coordinating and allocating resources
Making good, participated decisions
When you grow your team from 5 people to, say, 15 or 20, it seems that these problems get worse — at first gradually, and then suddenly.
But why?
As by Metcalfe’s Law, the complexity of communication is proportional to the square of the number of users involved. So, while people grow linearly, complexity grows geometrically 👇
To tame communication complexity, companies usually introduce hierarchies. Hierarchies have several advantages:
They provide clear communication paths, ensuring alignment is obtained across the organization.
They reduce the number of lines each person has to manage, allowing the company to scale.
They provide a simple way for making decisions, by assigning responsibility to people up in the hierarchy.
However, they also bring drawbacks:
Overhead — communication has a longer way to travel to a destination, which makes you slower. Longer paths also create all kinds of “work’s work”, like traffic controlling, managing up, presentations, and more.
Inflexibility — once in place, it is hard to reconfigure roles and processes. This in turn reduces agility, resilience to turnover, and velocity, too.
These problems contribute to the so-called efficiency gap, as described by Eiso Kant, and experienced by most teams as they scale.
How do companies fight this?
🏃♂️ Autonomous teams
Smart tech companies invariably ask themselves the same question as they scale:
If a 5-10 people team can work efficiently without much structure, why can’t we just replicate this over and over?
Organizing a company in small teams, capable of working autonomously, is the holy grail of scaling modern product and engineering work.
While small teams work well at an operational level, though, they still pose challenges. In fact, while staying independent from one another, they also still need to:
Collaborate well when needed — because dependencies can never be entirely removed.
Preserve alignment towards wider company goals — because such independence is granted within a given, agreed scope.
Here are famous examples of big companies built around small, autonomous teams: