Unconventional Team Structures (Part 1) 🏰
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!
Hey 👋 this is Luca! Welcome to a new 🔒 weekly edition 🔒 of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇