How to design workflows that eliminate bottlenecks

The Real Problem Behind Bottleneck Issues

Your workflow has a bottleneck. You know it exists because work piles up somewhere in the system. Tasks sit waiting. People get frustrated. Deadlines slip.

But here's what most founders miss: the bottleneck you see isn't the real bottleneck. It's usually just where the constraint becomes visible. Like water backing up behind a dam — the dam isn't the problem, it's just where the problem shows up.

Take a typical sales workflow. Deals pile up in the proposal stage. Everyone assumes the bottleneck is proposal creation. So you hire more proposal writers, build templates, add automation. But nothing improves.

The real constraint? Your head of sales is the only person who can approve deal terms. Every proposal sits on their desk for 3-4 days. All your optimization efforts were downstream of the actual constraint.

The bottleneck isn't where work accumulates — it's where decisions get stuck.

Why Most Approaches Fail

Most workflow optimization falls into what I call the Complexity Trap. You see a problem and add more steps, more tools, more people. The system gets more complicated but not more effective.

The typical approach: map every step, identify "inefficiencies," then optimize each piece. This creates three problems. First, you're optimizing parts instead of the whole system. Second, you're adding complexity that creates new bottlenecks. Third, you're treating symptoms instead of the root constraint.

I worked with a founder whose customer onboarding took 6 weeks. They had mapped 47 steps across 8 departments. Every step was "necessary." They wanted to optimize each one.

But when we applied constraint theory, we found something different. Only 3 of those 47 steps actually determined the timeline. Everything else was just busy work that had accumulated over time. We eliminated 80% of the process and cut onboarding to 10 days.

The First Principles Approach

Start with a simple question: what determines the speed at which work moves through your system? Not the individual steps — the rate-limiting factor.

In any workflow, there's always one constraint that determines throughput. Everything else is either feeding that constraint or waiting for it. Your job is to find that constraint and design everything around it.

Here's the process. First, map the flow of decisions, not tasks. Every workflow is really a series of decisions wrapped in execution. The bottleneck is almost always a decision point, not an execution step.

Second, identify where queues form. Work doesn't pile up randomly — it accumulates just before the constraint. Look for the consistent backlog, the place where things always seem to get stuck.

Third, trace the constraint to its source. The visible bottleneck might be proposal reviews, but the real constraint is that only one person can approve pricing. The visible bottleneck might be customer support tickets, but the real constraint is that engineering has to validate every product issue.

Most workflows are 80% waste wrapped around 20% constraint. Design for the constraint.

The System That Actually Works

Once you've identified the true constraint, you have three options. Eliminate it, elevate it, or exploit it. Most constraints can't be eliminated — they exist for good reasons. But you can always elevate or exploit them.

Elevating the constraint means giving it more capacity. If your head of sales is the pricing bottleneck, create clear pricing guidelines so account managers can approve standard deals. If engineering review is the constraint, build a decision framework so support can handle common issues.

Exploiting the constraint means optimizing everything around it. If you can't add capacity to the constraint, make sure it never waits for anything else. This usually means working backward from the constraint to redesign upstream processes.

I worked with a SaaS company where feature requests died in engineering review. Their constraint was the CTO's time for technical validation. We couldn't clone the CTO, so we redesigned everything upstream. Product created technical specs before requests entered the queue. Customer success gathered detailed requirements upfront. The CTO went from spending 30 minutes per request to 5 minutes, tripling throughput.

The key insight: don't optimize the constraint itself — optimize everything around it. Make sure the constraint gets perfect inputs and never waits for anything downstream.

Common Mistakes to Avoid

The biggest mistake is treating every slowdown as a bottleneck. Workflows have natural variability. Sometimes the legal review takes longer. Sometimes customers are slow to respond. These aren't constraints — they're noise in the system.

A true constraint is consistent and predictable. Work always piles up in the same place. The same person or process always determines the timeline. If it's intermittent, it's not your constraint.

Second mistake: assuming the constraint is a person. Sometimes it is — often the founder themselves. But frequently the constraint is a policy, a tool limitation, or a communication breakdown. I've seen workflows where the bottleneck was a weekly meeting that delayed all decisions by 3-4 days on average.

Third mistake: solving constraints with more complexity. You can't automate your way around a decision-making bottleneck. You can't hire your way around a knowledge constraint. The solution is usually simpler processes, not more sophisticated ones.

Finally, avoid the temptation to optimize non-constraints. It doesn't matter if your proposal creation is 50% faster if proposals sit waiting for approval for days. Focus all optimization effort on the true constraint. Everything else is a distraction.