The Stampede

The program had forty engineers and was shipping slower than when it had five.

I joined the weekly program sync expecting the usual status updates. Instead, I walked into a call with thirty-two people, most of them on mute, half of them multitasking. The program manager asked a simple question: “Which team owns the customer onboarding flow?”

Silence. Then three people spoke at once. Then an argument about whether “owns” meant “wrote it originally” or “is currently changing it.” The meeting ran forty minutes over. Nothing was decided.

This was a large European bank, midway through a monolith-to-microservices rewrite of their core platform. They had budget, executive sponsorship, and smart engineers. What they didn’t have was a way for forty people to work together without stepping on each other. The trail of ownership had vanished somewhere between the fifth and the fortieth hire.

I’d been brought in to lead the golden path team, the group responsible for building the standards and tooling that other teams would follow. What I found was an organization that had scaled its headcount without scaling its structure. The result was a kind of organizational entropy: more people, more motion, less progress.

This is the story of what went wrong, and what we did about it. It’s not about technology. It’s about people.

The Rewrite That Ate the Org

The rewrite started small. Five engineers who knew the monolith inside out. They’d maintained it for years, understood its quirks, knew which parts were load-bearing and which were dead code. Those five shipped fast. They had a shared mental model of the system and could make decisions over coffee.

Leadership saw the early velocity and did the natural thing: they scaled up. Ten engineers became twenty. Twenty became forty. The program got squads and streams and a coordination layer of program managers and delivery leads.

The original five stopped coding. They became full-time tour guides, explaining the legacy system to newcomers, reviewing PRs from people who didn’t understand the domain, sitting in meetings to provide context that only they had. Their deep knowledge, the very thing that made the project viable, was now consumed entirely by the overhead of transferring it.

Every engineer we added made the remaining engineers less productive. Adding more dogs to the hunt didn’t help. They just circled each other.

Banking made this worse. This wasn’t a startup where you could hand someone a laptop and expect useful commits by Friday. PCI-DSS training took weeks. SOC2 processes had to be understood before anyone could touch production systems. The regulatory context (anti-money laundering rules, data residency requirements, audit trail obligations) took months to absorb. A new engineer at a fintech startup might be productive in four weeks. Here, three to four months was realistic.

So leadership had forty engineers on the books, but the effective capacity was closer to twenty. And those twenty were spending half their time coordinating with each other.

When Everyone Owns Everything, Nobody Owns Anything

The ownership problem was the quiet killer.

There were no formal service boundaries. In theory, squads had areas of responsibility. In practice, services were worked on by whoever was available. A squad focused on payments might fix a bug in the account service because they needed it unblocked. Another squad might refactor the same service’s API a week later without knowing about the first change.

The result was predictable: duplicate work, conflicting patterns, and broken contracts. One team added retry logic with exponential backoff. Another team, working on the same service from a different branch, added retry logic with a fixed delay. Both merged. The service now had two retry mechanisms fighting each other in production.

Decision-making collapsed into meetings. Without clear ownership, every change required consensus. Consensus required coordination. Coordination required meetings. By the time I joined, the average engineer spent twelve hours a week in meetings, most of them about who should decide things, not actually deciding them.

There’s a threshold I’ve seen repeatedly. I think of it as the fifteen-engineer wall. Below fifteen, informal communication works. People bump into each other, overhear conversations, absorb context through proximity. Decisions happen in hallways and Slack threads.

Above fifteen, that breaks down. Hallway decisions become blocked calendars. Slack threads become hundred-message debates. The information that used to flow naturally now has to be explicitly routed, and nobody has built the routing infrastructure. This bank had blown past fifteen without noticing, and by the time they hit forty, the informal communication patterns hadn’t just degraded. They’d become actively harmful, creating an illusion of coordination where none existed.

Before the next hire: Pick a service and ask who owns its API, data model, and deployment decisions. If the answers conflict, resolve the ownership gap before expecting more engineers to increase delivery capacity.

This is technical leadership work as much as architecture work: making decision rights explicit, helping teams agree on boundaries, and backing those agreements when delivery pressure tests them.

Building a Trail Others Could Follow

My team’s mandate was to build the golden path: the reference architecture, the templates, the tooling that other teams would use. We were four engineers, embedded within the program but not assigned to any product stream. Our job was to make everyone else faster.

The golden path itself was a service template with health checks, structured logging, and contract tests baked in, plus a reference architecture showing how services should communicate, handle failures, and expose APIs. But the technical artifacts were secondary. The real job was organizational.

We started with ownership. Every service got assigned to exactly one team. That team made decisions about their service: API contracts, data models, deployment schedules. No committees, no cross-team approval workflows. If you owned the service, you decided. If another team needed something from your service, they asked, and you could say no.

This was harder to enforce than it sounds. Engineers had been trained by months of ambiguity to work on whatever seemed most urgent, regardless of boundaries. Managers resisted giving up influence over services their teams had contributed to. “But we wrote half of that code” was a common objection. It didn’t matter. Shared ownership is no ownership.

We gave teams a two-week grace period to adjust. After that, pull requests that crossed ownership boundaries required explicit sign-off from both team leads. The friction was intentional; it made the cost of coupling visible. There were escalations, especially in the first month, but every escalation became a conversation about drawing better boundaries rather than removing them. Within six weeks, most teams had stopped crossing lines altogether.

Next, we standardized onboarding. Beyond “here’s how to set up your laptop,” this was organizational onboarding. Every new team got a decision tree: here’s your domain, here are your neighbors, here are the contracts between you and them, here’s how to change those contracts. New engineers could understand the landscape in days instead of months.

The coordination reduction was the biggest win. Forty engineers operating as one amorphous group meant n-squared communication paths, everyone potentially needing to talk to everyone. Eight teams with defined interfaces meant linear communication: you only talked to your neighbors, and only through agreed-upon contracts.

Forty engineers hunting without a trail isn’t a hunt — it’s a stampede. The golden path gave them a trail.

The hardest part wasn’t designing these structures. It was getting people to follow them. We couldn’t mandate adoption; we had to demonstrate it. My team adopted the standards first. We published our service contracts. We followed the onboarding decision tree for our own new hires. We tracked our delivery metrics and shared them openly.

When other teams saw that our squad was shipping predictably while they were still stuck in coordination meetings, they started asking questions. Adoption spread team by team over months.

By the time I moved on, the numbers told the story. Average meeting hours per engineer dropped from twelve per week to under five. Deployment frequency across the program roughly doubled. New engineers were shipping meaningful work within weeks of completing compliance onboarding, not months. I can’t share the exact client metrics, but the trajectory was unmistakable: not as fast as the original five, but far faster than the forty-person crawl we’d started with.

What the Trail Taught Me

“More engineers, slower delivery” isn’t a paradox if you look at it through the right lens. It’s the predictable outcome of scaling headcount without scaling organizational structure. You can’t solve a coordination problem by adding more people to coordinate.

The technical problems at the bank (the microservices architecture, the deployment pipelines, the testing strategies) were real, but they weren’t the root cause. The root cause was that forty people didn’t have a shared understanding of who owned what, who decided what, and how to work together without constant synchronization.

Every engagement since, I track the people trail first. Before I look at the architecture, before I open the codebase, I ask: who owns what? How are decisions made? Where does coordination happen, and how much of it is necessary versus habitual? The answers tell me more about delivery speed than any architecture diagram.

The org chart is the first system to debug.

Key Takeaways

The scaling paradox: Adding engineers to a program without adding organizational structure will slow delivery. Every new hire adds coordination overhead. Past fifteen engineers, informal communication breaks down entirely.

The organizational fix: Clear ownership (one team per service), standardized onboarding (decision trees, not tribal knowledge), and reduced coordination (defined interfaces between teams, not open-ended meetings).

The compliance multiplier: In regulated industries, onboarding takes three to four months instead of one. This means every scaling mistake is three to four times more expensive: you’re paying for unproductive engineers longer.

The leading indicators: Watch for these before velocity collapses: engineers spending more than 30% of time in meetings, services with no clear single owner, decision-making that requires cross-team consensus for routine changes, and new hires who can’t ship meaningful work for months.

The people cost: The engineers most at risk are your best ones. They absorb the coordination load and stop doing the work that attracted them in the first place. Watch for your senior ICs quietly disengaging. Coordination overhead doesn’t just slow delivery; it drives attrition of the people you can least afford to lose.

For engineering leaders: The instinct to hire your way out of slow delivery is almost always wrong. Before adding headcount, audit your organizational structure. Do teams have clear boundaries? Are decisions made by owners, not committees? Can a new engineer understand the landscape in days, not months? If not, more people will make it worse, not better.

Scaling your engineering organization and feeling the drag? The Pointer Assessment is our diagnostic phase; its “Run with the Pack” trail reviews onboarding, knowledge distribution, and ownership to identify structural risks and priorities. Let’s talk about what the org chart is telling you.