How design an org structure for growth

The Real Problem Behind Org Issues

Your org structure isn't broken because you hired the wrong people or picked the wrong framework. It's broken because you're solving the wrong problem.

Most founders think org design is about boxes and lines — who reports to whom, how many layers you have, whether you're functional or divisional. But that's like optimizing the seating chart on a sinking ship. The real problem is constraint propagation.

Every organization has exactly one constraint that determines its maximum throughput. Maybe it's your lead qualification process. Maybe it's your engineering deployment pipeline. Maybe it's the founder who insists on approving every hire. Whatever it is, your org structure should be designed around identifying and eliminating that constraint — not around making everyone feel important.

When you optimize for politics instead of throughput, you get what most companies have: beautiful org charts that don't actually work. People spending more time in alignment meetings than creating value. Multiple handoffs where one would do. Decisions that take weeks because nobody knows who owns what.

Why Most Approaches Fail

The advice you'll find online falls into three categories, and they're all wrong for growing companies.

First is the copy-paste approach. Someone reads about how Netflix or Amazon structures their teams and tries to implement the same thing. But Netflix's structure optimized for different constraints than yours. They had different bottlenecks, different markets, different talent pools. Copying their solution gives you their overhead without their advantages.

Second is the theoretical framework approach. Holacracy, Spotify model, matrix organizations — these look elegant in consulting decks but collapse under real-world pressure. They assume perfect information flow and rational actors. Most ignore the human reality that people need clear ownership and decision rights to move fast.

The best org structure is the one that removes friction from your specific constraint, not the one that looks good in a Harvard Business Review case study.

Third is the growth-stage template approach. "At 50 people you need this, at 100 people you need that." But company maturity isn't determined by headcount. A 30-person team doing $50M ARR has different structural needs than a 30-person team doing $5M ARR. Stage-based templates ignore the actual work that needs to get done.

The First Principles Approach

Start with constraint identification. Map your entire value creation process from lead generation to customer success. Find the single step that limits your overall throughput. This is your system constraint.

Everything else is non-constraint. And here's what most people get wrong: optimizing non-constraints doesn't improve system performance. It just creates local efficiencies that pile up inventory at the constraint.

Let's say your constraint is lead qualification. Your sales team can only qualify 100 leads per week, but marketing generates 300. You could hire more marketers, build better lead scoring, optimize your website conversion. None of that matters. You're just creating a bigger pile of unqualified leads.

The constraint-based approach says: design your org structure to maximize flow through lead qualification. Maybe that means embedding marketing people directly with sales. Maybe it means giving your best qualifier more junior people to train. Maybe it means eliminating handoffs between marketing and sales entirely.

Your org structure should make it impossible for the constraint to be starved of inputs or blocked by outputs. Everyone else exists to subordinate to the constraint — to ensure it never has to wait and its output immediately flows to the next step.

The System That Actually Works

Here's the framework I use with clients to design constraint-focused org structures.

Step one: Constraint identification. Run a value stream map. Track every handoff, every approval, every queue. Time how long work sits between steps. The constraint is usually where you see the biggest queues or the longest cycle times.

Step two: Constraint elevation. Give your constraint team the best people, the best tools, the most attention. If engineering deployment is your constraint, your best engineers should be on the platform team, not the feature teams. If customer success is your constraint, hire a world-class CS leader before you hire more salespeople.

Step three: Subordination design. Everyone else's job is to feed the constraint or consume its output. Marketing feeds sales. Sales feeds customer success. Customer success feeds expansion revenue. No department optimizes for local metrics that suboptimize the global system.

Step four: Exploit the constraint. Make sure your constraint operates at maximum efficiency. No context switching. No meetings that don't directly improve throughput. No bureaucracy. If your constraint team spends 30% of their time in cross-functional alignment meetings, you're burning 30% of your company's capacity.

The goal isn't to eliminate the constraint — it's to systematically move it until it's no longer inside your organization.

Step five: Continuous iteration. As you improve the constraint, it will move somewhere else. Your new org structure should make the next constraint visible quickly. Design for rapid reorganization, not permanence.

Common Mistakes to Avoid

The biggest mistake is premature optimization of non-constraints. I see founders restructuring their marketing team when the real bottleneck is in product delivery. They're solving yesterday's problem while today's constraint strangles their growth.

Second biggest mistake: designing for perfect load balancing instead of constraint optimization. You don't want everyone equally busy. You want your constraint at 100% utilization and everyone else with slack capacity. If your best salesperson is at 100% and your best engineer is at 60%, that might be exactly right.

Third mistake: creating coordination overhead in the name of "alignment." Every cross-functional meeting, every approval layer, every handoff adds latency. Sometimes you need them, but each one should justify its existence by improving constraint throughput.

Fourth mistake: ignoring information flow. Your constraint needs perfect information to make good decisions. If your product team doesn't know which features drive revenue because there's no direct line to sales, you've created an artificial constraint in information processing.

The final mistake is optimizing for organisational stability instead of market response. Your org structure should change as your constraints change. If you're still using the same structure you had six months ago, you're probably optimizing around an old constraint.