It happens around twenty-two people. Before that, you could still hold the entire system architecture in your head and keep the status of every major feature transition in your peripheral vision. You knew who was working on the legacy database migration, why the caching layer was acting up, and exactly which senior engineer to pull into a room to unblock a junior.
Then you pass thirty. Suddenly the "room" no longer exists. Your team is spread across time zones, Slack channels are a cacophony of overlapping contexts, and for the first time you realize people are making architectural decisions you never authorized. They are not trying to be "cowboy coders"; they are simply operating in the vacuum of your silence.
This is the tension of scale. Your primary job is no longer to solve technical problems, it is to stop the "technical telephone" game from destroying delivery. At thirty people the bottleneck is never talent or technical debt. The bottleneck is clarity.
For the last six years I have worked as Head of Engineering at SEFE: from 16 to 32 people across three countries, with development and QA in different locations. Below is what that taught me, and the eight questions I have used since as a filter for every new initiative.
The main claim: clarity as the scalable currency
In an engineering organization of thirty or more, exactly one thing scales: clarity. You can hire faster, buy better tools and implement the most rigid processes — but if your engineers lack a clear understanding of what they are doing and why, part of their working time goes into fighting ambiguity.
Ambiguity is the quiet killer of enterprise software. It shows up as redundant services, "integration weeks" that stretch into months, and the dreaded "I thought they were handling that" during an outage. To lead at this scale you have to turn from problem solver into context provider. You define the "what" and the "why" precisely enough that the "how" can be safely distributed across four or five autonomous sub-teams.
Every bit of uncertainty acts as friction. If a developer has to stop and ask "where does this data come from?" or "is this service deprecated?", you are not just losing minutes — you are losing momentum. At scale, momentum is the only hedge against complexity.
Section 1: the invisible wall at thirty
The jump from fifteen to thirty engineers is different in kind from the jump from five to fifteen. At fifteen you are still a "team of teams". At thirty you are an organization. You cross the line beyond which not every person can maintain a close working relationship with every other person.
The math of communication is brutal. A team of five has ten pairs between whom a conversation is possible. A team of thirty has 435. It is physically impossible to be the hub for all of those connections. And if you try, you become the critical point of failure for the entire company. The only way out is to make sure the "source of truth" is not a person, but an accessible technical standard.
In a distributed team the effect is amplified. You cannot rely on ambient knowledge, or on someone overhearing a conversation in a corridor. Everything has to be intentional: if a decision is not written down, it did not happen; if a protocol is not documented, it does not exist.
What it actually cost
By the time I arrived at SEFE, the landscape was 32 active enterprise applications, partly on ASP.NET/WebForms and partly on .NET Core, with teams across Central and Eastern Europe. Over one year we brought 32 applications down to 18, recovering the documentation GAP for every application we migrated, and completed vendor consolidation with €500K+ saved in the first year alone. The same year brought unified code quality and delivery standards to teams in three countries, and 100% SLA compliance.
"We solved the documentation problem" sounds dull until you look at the mechanics. To get from 32 applications to 18, deciding which ones to close is not enough. Every team has to be able to answer the questions that only the system's owner used to be able to answer. That is clarity itself: not "we will figure it out", but "here is where it is written what happens on failure, and here is who fixes it".
A separate lesson about boundaries. Over the same period we built applications from modular monoliths to microservices with event-driven interaction — 15+ enterprise applications, including Private Room, a modular monolith assembled in 18 hours for exchanging confidential documents between the UK and Germany. The choice of shape turned out to be secondary to the boundaries. More on that in «From Monolith to Modular Platform: Modernisation Without the Rewrite Trap».
Section 2: from "working code" to managed systems
When you lead thirty people, you stop worrying about whether the code works in isolation. You start worrying about how the system is managed. A senior engineer thinks about the logic of a function; a leader of thirty thinks about the lifecycle of a service.
Technical clarity at scale means moving toward documentation-as-code. At that size, READMEs, Architecture Decision Records and API specifications matter as much as the logic itself. The logic is only useful if somebody else can integrate with it without a three-hour call to synchronize. How to write ADRs so that decisions do not drift away from the code is a topic I covered separately: «The Architecture Decision Record That Prevents Accidental Microservices».
Managed systems require explicit interfaces. I often tell my leads: "If I have to read your source code to figure out how to use your API, your API is broken." Clarity is the lubricant that lets components slide together with minimal friction.
Managed systems also mean observability. Clarity extends to how a service reports its health. At scale, a service without standardized dashboards and a clear set of SLIs is a black box — and in a distributed team, black boxes are where engineering morale goes to die.
Section 3: the 8-question technical clarity checklist
To maintain clarity across a distributed team of thirty, I put together a checklist. If an EM or a Lead could not answer these eight questions about a new initiative, the project was not considered ready to be built.
-
Ownership. Who is the specific person who gets paged at 3 AM if this breaks? "Team ownership" is often a euphemism for no ownership. In a crisis you need a name.
-
The "why". Can the most junior developer on the project explain the business value of the work to a non-technical stakeholder? Clarity of purpose prevents wasted effort. Without context, developers make local optimizations that damage the overall goal.
-
Interface integrity. Is the API or contract documented before implementation starts? Define the handshake first; implementation is secondary. This prevents integration hell.
-
Dependency mapping. Which two teams are most likely to block this, and have they agreed to the timeline? Dependency management is most of the work at scale. Without it the roadmap stays a work of fiction.
-
Failure strategy. What is the graceful-degradation plan? If this service dies, what stays alive? Architectural clarity means knowing exactly how the system breaks before it breaks.
-
Data sovereignty. Who owns the schema, and what is the process for a breaking change? Database collisions are the most expensive kind of technical debt. Clarity about data ownership prevents the sprawl that slows an organization down.
-
Definition of done. Beyond "it works", what are the performance and security requirements for a "Ready" state? You need a shared quality floor, so that one team is not shipping dirty code while another over-engineers.
-
Onboarding. Can a new joiner from another department understand the architecture of this feature in 15 minutes without asking a human? Documentation is how you scale. Human-to-human knowledge transfer is the most expensive and least scalable process there is.
Section 4: distributing quality — QA ownership at scale
Quality is usually the first thing to break when you scale. At thirty people, especially in a distributed setup, you can no longer afford a centralized bottleneck in the form of a QA department.
Distributed engineering requires distributed quality. If every release has to pass through one central QA team, you create a line of frustrated engineers and a backlog of stale code. The central QA team becomes the scapegoat for production problems, which is a direct route to a toxic "us versus them" culture.
The key in my experience was moving the quality gates as far left as possible. We stopped thinking of QA as a phase and started thinking of it as infrastructure. The goal was to make it impossible to ship low-quality code, because the environment itself would not allow it: automated tests, coverage (xUnit, NUnit, Postman Pipeline, Selenium), release processes and a shared Definition of Done work as constraints rather than as a final check.
The result is measurable: production errors −60%, and release frequency went from one or two per month to weekly. That is not "it got better" — those are concrete numbers you can see in the release.
Separately, there is what makes the ambiguity itself visible. We built an internal tool, Team Heartbeat, that monitors task status: blockers surface in real time, and routine work is automated with AI. It is applied across all development and testing units and delivered +25% in team cohesion. Clarity about a blocked task is not reporting overhead — it is saved time.
Ownership of quality still sits with the people writing the code, with quality engineers working as coaches rather than manual testers. At thirty people across multiple geographies you need a QA strategy that works while you sleep.
Section 5: scaling your own leadership — what to stop doing
As you move past the 15–20 person mark, your habits have to change. What made you an excellent lead of a small team will actively work against you at thirty.
The hardest thing for me was giving up the final say. At thirty people you cannot be the final reviewer on every PR and the final architect on every design document. If you try, you become a bottleneck. You have to move from making decisions to creating the frameworks inside which others make them.
The second thing I had to give up was being the technical safety net. I used to be able to jump in and fix a bug or a deployment script at 10 PM. As the team grew, I realized that every time I did, I robbed my leads of the chance to build their own resilience. I had to let teams make mistakes — small enough to learn from, real enough to feel.
The third was delegating by context rather than by job title. The toolkit I assembled (1:1, PDP, OKR, DoD, MoSCoW) only works when a person has both the authority and enough information to decide for themselves. If I keep making decisions because "that is faster", the team does not grow: it just services my pace.
It took me time to rebuild that way. Three things helped: three teams built from scratch, five-plus engineers mentored up to senior, and the year-long SEFE Activate Leadership Development Program (RHR Partners, 2024–2025) — Fundamentals of Leadership, Emotional Intelligence, Situational Leadership, Coaching, Resilience, Facilitation Skills. Leadership at scale turns out to be a craft you train, not only a temperament you are born with.
Section 6: the true cost of ambiguity
In a team of thirty, ambiguity does not just slow down code — it burns out your best people. High performers live on influence and results. When they are stuck in endless meetings trying to find out which database they are allowed to use, they lose interest.
Technical clarity is for the sake of the culture. A clear organization is a calm organization. In a calm organization senior engineers work on complex problems rather than political ones. Clarity reduces cognitive load for everyone and lets people spend mental energy on code instead of bureaucracy.
Conclusion — the long game of clarity
Leading thirty people is about building a machine that builds the product. The output of that machine is a direct reflection of the clarity of its instructions.
If you are struggling with delivery speed, do not go looking for more developers. Adding people to a foggy project makes the fog denser. Look for the places where your team is forced to guess. Look for the "hidden conversations" that should have been public documents. Technical clarity is not a one-off project; it is a daily discipline.
Scaling is a process of letting go of control and holding on to context. When the path is clear, thirty people can move mountains. When it is foggy, they just trip over each other.
Related reading
- From monolith to modular platform: modernisation without the rewrite trap — boundaries before shape
- The Architecture Decision Record That Prevents Accidental Microservices — how to record decisions so they do not drift from the code
- Where the Bottleneck Moved: Code Review After Coding Agents — a constraint you cannot hire your way out of
Sources
- Team Topologies: Key Concepts — the stream-aligned and platform team model, and how cognitive load is distributed
- Camille Fournier, The Manager's Path — Tech Lead as the entry point into management, and hybrid roles
- SEFE experience: Head of Engineering, 16–32 people across three countries, 32 → 18 applications in a year with documentation recovered, production errors −60%, 100% SLA compliance, Team Heartbeat +25% cohesion
If you are scaling a team and keep hitting "everyone has a different understanding of the task", start with the eight questions above — it is cheaper than a new tool or another hire. Discuss engineering leadership → techbuzzz.ru
