Org Design for Growing Engineering Teams

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

In what actually breaks as you scale, I described the walls an engineering org hits as it grows — including the dependency gridlock where Team A is blocked on Team B, blocked on Team C. This post is the other half of that: how you design the structure so those walls don't take you down.

The principle underneath everything I'm about to say is one most founders underestimate: how you structure the humans dictates what the code will ultimately become. So I treat org design not as an HR exercise but as an architectural one. Here's how I do it.

Draw boundaries around outcomes, not layers — the Inverse Conway Maneuver

I draw team boundaries strictly around business domains and customer outcomes — never around technical architecture, and never around the existing org chart.

And I use Conway's Law aggressively, on purpose. Conway's Law says your software architecture will inevitably mirror your communication structure. Most leaders treat that as a warning; I treat it as a lever. It's the Inverse Conway Maneuver: if you want a decoupled, independent architecture, you first build decoupled, independent teams, and the architecture follows. Put 50 engineers in one giant department and tell them to build microservices, and they'll build a distributed monolith instead — because they still talk to each other every day, and the code mirrors the conversation. So I design the org chart to force the architecture I want. (It's the flip side of the modularity I wrote about here — clean seams in the code start as clean seams between teams.)

Make teams autonomous — the ship-it test

My test for whether a team is structured right is one question: can this team push a feature to production, monitor it, and roll it back without asking permission or opening a ticket with another department?

To pass, a team has to own its work end to end — its roadmap, its codebase, its database schema (no central "DBA gatekeeper" every team has to queue behind), its deployment cadence, and its own on-call rotation. You build it, you run it. That last part matters: a team that owns its own pager writes more reliable code, because they're the ones who get woken up.

Now, the obvious objection: doesn't total autonomy become chaos? Yes — if you stop there. The line between autonomy and chaos is drawn by platform engineering and golden paths.

• Autonomy means the team decides when to ship and what logic to write.
• Chaos means every team invents its own deployment script, picks a different monitoring tool, and grabs a random programming language.

I prevent the second one by providing a centrally supported golden path — standard CI/CD, standardized logging, a blessed default stack. Stay on the path and you get full autonomy for free. Want to run some rogue database off the path? Fine — but then you build and maintain that infrastructure yourself. The golden path makes the right way the easy way, without a governance committee forcing it.

Split on cognitive load, not headcount

Everyone reaches for the two-pizza rule, but headcount is a lagging indicator. The real trigger to split a team is cognitive load — when the domain a team owns has grown so large that the engineers can no longer hold the whole system in their heads.

The tell is unmistakable once you know it: sprint planning drags to three hours because half the team mentally checks out while the other half discusses tickets they don't understand. Or the team starts shipping regressions because they've forgotten how one of their own legacy modules works. That's not a discipline problem; it's a load problem, and no amount of process fixes it.

When I split, I never split by technical function — I don't peel the front-end developers off into their own team. I split the business domain vertically. If the Checkout team is overwhelmed, I split it into a Cart Experience team and a Payment Processing team. Slicing vertically means nobody loses context; their context just gets narrower and deeper. That's deliberate, because the opposite — losing context in a reorg — is exactly the context dilution that quietly wrecks scaling teams.

The most common mistake: horizontal slicing

The single most common — and most fatal — structural mistake I find walking into growth-stage companies is teams organized by technical layer. A "Frontend team," a "Backend team," a "QA team."

It feels tidy, and it guarantees paralysis. Shipping a single button now requires three different teams, three different backlogs, and three different sprint cycles to align. Every feature becomes a cross-team dependency — precisely the gridlock from the scaling post — and velocity drops toward zero.

The fix is to dismantle the layer-based teams and rebuild as stream-aligned teams. Every team gets a product manager, a designer, front-end engineers, and back-end engineers — a cross-functional vertical slice focused entirely on one customer journey, like User Onboarding. Now that team can ship the whole button, end to end, by itself. This is almost always the highest-leverage change I make in the first ninety days of an engagement, because it unblocks everything downstream of it.

The honest goal

That's the whole discipline: design the humans and you design the architecture. Draw boundaries around outcomes, make each team able to ship on its own, split on cognitive load before it seizes up, and never organize by technical layer. Get it right and your teams ship independently and the code stays clean. Get it wrong and every feature needs three teams and a miracle.

If your engineering org feels gridlocked — features crawling because everything needs three teams to align — that's usually an org-design problem wearing a technical costume, and it's exactly what I untangle. Book a call and we'll look at how your teams are actually drawn.