Teams Without Managers
Minimal management overhead as a path to high performance
Originally published on The Engineering Org.
Management overhead is minimal in tech teams with the right mixture of processes, competence, and personalities. These teams move fast, solve challenging problems, and produce phenomenal work. Rules like "one manager can have a maximum of 6-8 reports" don't apply. I have had the fortune to be a part of such teams multiple times in my career. In this post, I break it down into 3 parts:
Traits of high-performing teams with minimal management overhead
Antipatterns preventing teams from achieving this
Path to building an efficient team
Traits of high-performing teams
Picture this:
Inherited "legacy" codebase, zero tests, unfamiliar tech stack
Systems periodically crashing + "bad data" issues every few weeks
No monitoring or observability
Product in pre-PMF stage, so constant "idea churn"
Imminent burnout because too few members
And then, 12 months later:
The heaviest-used system has been rewritten into a familiar tech stack with 100% test coverage
30 members in the team, with a healthy on-call rotation
All servers are humming like a well-oiled machine making the right noises #iywim
Mixpanel dashboards are looking great; the next round of fund-raise looks like a foregone conclusion
No burnout, no boredom
During these 12 months, one team changed managers thrice; one had 14 direct reports at peak, and we rolled out three out-of-turn promotions and raises.
So, what did the managers do during this? You could say they were more leaders than managers, but that's a very combative dichotomy — and false, too.
A manager's job in such cases is limited to providing the vision, keeping their head up, and ensuring direction so others can go heads down. Focus, by its nature, is narrow and makes you miss out on the peripherals. And so, in such teams, providing leadership means more spotting problems and opportunities and less dealing with personal issues.
Perhaps you're tempted to call this "zen mode" or an "ideal state" and dismiss it as unachievable because it's seemingly far from reality. But that would be a mistake; achieving this state with some training is straightforward. Moreover, such teams can be found in both big and small companies in the tech industry.
But dude, this is not what I have experienced! Not at all.
No? Well, I bet you have. Here are the salient traits of such teams; I am sure you've encountered them.
Unambiguous in action
Each member clearly understands how work happens in your team. This can be done two ways: One, through cults, where everyone depends on a robust shared understanding, or two, through documentation, where you have playbooks, documents, and policies that outline this clarity. I rely more on the latter, but I've experienced both, and I can tell you from personal experience that unless you intend to scale the team rapidly, both methods are effective. Some examples of this unambiguity:
Git Playbook: How you use Git in your org
Developer Day One Document: What does an engineer do on their first day in the org?
Policies associated with software legacy, like "We favor PostgreSQL over MySQL, and here's why."
Architectural decision records: Nobody remembers why a decision was taken six months later. So you have records of the whys. Such as "Change the refresh policy of materialized view X from scheduled to on-demand."
To nobody's surprise, clarity is one of the biggest drivers of success and outcomes.
Early in my career, about 15-ish years ago, I worked on a heavily multi-tenanted architecture. These weren't your Terraform/CDK days — you deployed code using Capistrano and managed servers using Chef. Whenever we had to deploy or set up a new customer, we went through an arduous decision-making process of MySQL server configuration. We had Chef for provisioning, but many actual values had to be chosen each time. Installations varied from 100 users to 100k users. Sizes mattered.
After we had done it enough times, the team decided we had it with that system. Our manager at that time was a bonafide MySQL expert. We came down with a simple number-driven decision matrix, ran a few tests over the weekend, and created a script to take these values and spit out the config. Voila, time saved and toil reduced by a large margin!
But that wasn't the end of it; it was a start. This work set a precedent for the excellent work that followed later. Win-win all around.
Anyway, back to traits.
Self-managed teams set people up for success.
Everyone should know how they will add value to the team, the department, the company, the industry, and perhaps even the world. But good processes don't stop there; they actively make avenues for people to contribute this value. Examples:
Clear priorities on the team's work management system (Jira board, if I may)
Open and clear roadmap and each roadmap item's estimated impact on its objective.
A shared understanding of currently unsolved problems
They trust and verify
You've hired professionals; now trust them. But make it easy to verify or demonstrate so that people can do it for themselves, their teammates, their managers, and so on.
We take inspiration from other engineering disciplines here. Verification is a core engineering discipline. A crucial part of your work personality should be "How do I know if my work is working?" That might translate to better tests, TDD, Type-DD, instrumentation, dashboards, TLA+ (!), alerts, visual cues, etc. Development time and runtime, both.
Teams that consciously train this muscle are naturally more effective than teams that don't and by a large margin. The best-tested software in the world is not covered 100% by tests; it's used worldwide.
No information silos. Explore over ask.
A symptom of a poorly cataloged store is people constantly asking where something is. Akin to an untidy house. Conversely, a well-formed system can be explored for patterns and prodded for problems and opportunities. Wanting to improve something you're part of is the hallmark of high agency, instead of just accepting "this is how it is" and working around that. Information silos kill this spirit of exploration and agency.
Some other self-explanatory traits are listed below:
They are more tolerant of near-misses and non-malicious mistakes
Psychological safety
Ownership <> Responsibility Equilibrium
"Show, don't tell.”
Antipatterns
So if the traits are so common, why don't I see teams without managers so often?
I've seen three clear antipatterns that prevent teams from operating in this mode.
1. Getting drawn into people issues.
In other words, "too much parenting, too little adulting." When engineering managers spend most of their time on people issues, you can be confident that significant problems are lurking. This happens when you try to "optimize resources" and treat people as a Pareto efficient graph solely to drive business value. People issues also arise from the lack of the positive traits mentioned earlier.
There is trust but no verification -> erosion of trust
Information silos -> politics arising out of who knows what or inefficiencies arising out of coordination
Ambiguity acts as an impediment, and so on.
2. Lack of organizational intent.
Organizations often do not care enough about processes from a people angle. Such as copying "big company" processes but not having "big company" advantages. No, it will not work for you just because it worked for Google. They are 24 years old and earned $257.63 Billion in 2021 — you are nowhere close. When a not-so-mega-corp does not do enough for its people, it stifles excellence. And excellence is your only capital, unlike MegaCorp, where you can access actual capital.
3. Carryover trauma from social structures.
No team is diverse enough to absorb and negate social problems. Parenting styles, social hierarchies, and problems from schooling systems all bleed into work life. Hierarchical societies work by enforcing a top-down doctrine, and team members from such structures always want to be told what to do. Schooling systems in developing parts of the world suffer from a follow-the-syllabus problem, so people struggle to go down a less traversed path.
Is it all hopeless, then? Or is there a solution?
The path to an efficient system
First, tackle organizational intent:
This is the easiest to address. Leaders aren't fools; they're interested in improving things for everyone. More than interested, they're invested in making it a success. Playbooks, cadence meetings, budgets, and retrospectives are the four most important tools for getting movement in the leadership layer.
Next, address the process:
Pairing, Observability, TDD, Kanban, whatever floats your boat. A drafted process is necessary for a sound process. This also helps unite teams under a cause—any cause. This initial groundwork will also allow you to surface the causes people care about. Having a cause is more important than what the cause is—as long as the reason isn't, you know, vile.
Solve social debt on a small scale:
Large-scale social changes are impossible and never the goal in a business context. But on a team and org level, it's much simpler to address motivation, growth, habits, etc. There is no need to scale the trust to 500 people, ensure it is in smaller pockets, and depend on the natural hierarchy of the org for the trust to steep through. Yet another solution to a myriad of these problems is exposure. How do you develop good taste in music for a 10-year-old? Not by telling them what good music is but by enjoying it with them. Good parents don't tell their kids how to live a good life; they live a life that the kids observe and absorb.
Putting it all together
"Teams without managers" is a proxy for being sorted. If Quicksort and Mergesort taught us anything, it's the lesson that it’s far easier to take two sorted arrays and produce a single sorted array than to sort a single giant array.
Unsurprisingly, it takes big and small changes to make this happen.
In a future post, we will dive deeper into the solution.
Happy hacking!