Fast Work, Slow Decisions

A lot of organizations have been relying on slow work to stay coordinated.

Not intentionally. Nobody designed it this way. But when work takes weeks or months to complete, something useful happens in the background. Questions surface gradually. Managers course-correct in small increments. Adjacent teams notice conflicts before they become catastrophes. Priorities have time to clarify themselves.

The weeks it takes someone to finish a project aren’t just production time. They’re also coordination time. Slow execution creates a natural buffer for alignment.

AI is compressing production time. But it’s not compressing coordination time. And that mismatch is creating problems that look like AI problems but are actually organizational design problems.

The Flood vs. The Trickle

In the old world, a manager could handle ambiguous direction because feedback came in slowly. You’d assign a project, get a few questions over the first week, clarify some things, get a draft, provide input, iterate. The pace of work created a manageable trickle of decisions.

Now imagine that same project completed in two days instead of two weeks. The questions don’t come as a trickle—they come as a flood. Or worse, they don’t come at all because the work is already done by the time anyone thinks to ask.

The symptoms show up everywhere:

• Work sitting idle waiting for feedback that can’t come fast enough
• Competing efforts across teams because there wasn’t time to notice the overlap
• Managers becoming bottlenecks, not because they’re slow, but because they’re suddenly the constraint
• People doing the wrong work faster, which is worse than doing the wrong work slowly

Eliyahu Goldratt would call this a constraint shift. The bottleneck used to be execution capacity. Now it’s decision-making and alignment capacity. If you don’t address it, you’re just creating expensive inventory—completed work sitting idle, conflicting work products piling up.

The cost of misalignment used to be measured in days of wasted effort. Now it’s measured in hours. The margin for error got a lot smaller.

The Tempting Fix (And Why It Fails)

The instinctive response is to double down on project management. Create detailed plans. Break everything into tasks. Specify exactly what needs to happen before anyone starts working.

I get the appeal. If the problem is coordination, and coordination used to happen during slow execution, then let’s just front-load all that coordination into planning. Pre-solve the alignment problem.

But this runs into a fundamental issue: plans are guesses. Detailed plans are detailed guesses. The moment work begins, you learn things you couldn’t have known during planning. Requirements shift. Technical constraints emerge. The market changes. Someone has a better idea.

“No plan survives contact with the enemy.” The more detailed your plan, the more brittle it becomes. You’ve traded one problem (coordination during execution) for another (rigidity during execution).

This approach—trying to eliminate the coordination constraint by pre-solving it—works for predictable, well-understood work. It fails badly for anything complex or creative.

The Better Fix: Distributed Coordination

Instead of front-loading coordination, you can distribute it. Give more people the authority and context to coordinate locally, in real-time, as the work happens.

But this only works if you build the right foundation. Think of it as a stack—each layer enabling the one above it.

Trust comes first. Nothing else works without it. If people don’t feel safe raising concerns, if they’re protecting turf instead of solving problems, no amount of process will save you. Psychological safety is the single strongest predictor of team performance.

In a fast-work world, trust becomes even more critical. There’s no time for political maneuvering when decisions need to happen in hours instead of weeks. You either trust your people or you become the bottleneck.

Then ownership. Once you have trust, you can distribute authority. This means clear lanes—people know what they own, what decisions they can make without escalating, and where their domain ends and someone else’s begins. Clear ownership isn’t about isolation. It’s about knowing who’s accountable so that coordination can happen at the right level. When ownership is ambiguous, every decision escalates. When ownership is clear, most decisions don’t need to.

This is also where you define “what we owe one another”—the interfaces between teams. What can you expect from me? What do I need from you? How do we handle conflicts?

Then feedback without authority. Pixar’s Braintrust model nails this. Directors own their movies, but they’re required to get candid feedback from a group of peers who watch rough cuts and offer perspective. The crucial thing: the Braintrust has no authority. They can’t overrule the director. They can’t demand changes. They offer perspective, and the director decides what to do with it.

This solves the ownership-vs-input dilemma. You don’t have to choose between clear authority and collective wisdom. You can have both—if you design the feedback mechanism correctly.

Finally, measurement for alignment. You need a way to ensure all this autonomous work is pointed in the same direction. The key distinction: measurement for alignment vs. measurement for control. Measurement for control is about catching people doing things wrong. Measurement for alignment is about helping people self-correct before things go wrong.

Good OKRs let individuals and teams assess their own progress against shared outcomes. They reduce the need for check-ins and status updates because everyone can see whether they’re on track. Without the layers below it, measurement becomes either useless (people gaming the metrics) or oppressive (micromanagement with numbers). With the right foundation, it’s liberating.

Smaller Batches, Faster Loops

Gene Kim’s research on DevOps points to something similar: small batches with fast feedback loops outperform large batches with delayed feedback. The answer to faster work isn’t less feedback, it’s faster feedback. But the feedback needs to inform decisions, not make them.

Goldratt would say: subordinate everything to the constraint. If decision-making is now the bottleneck, you need to dramatically increase throughput at the coordination layer. That means reducing “batch sizes” of decisions—instead of big approval cycles, create mechanisms for continuous small alignments.

This is closer to how high-performing teams already work. Less waterfall, more continuous integration—not just for code, but for decisions.

What This Asks of Leaders

If you buy this framing, the implication is uncomfortable: you can’t solve AI coordination problems by slapping AI on them. You solve them with organizational fundamentals that many companies have been neglecting for years.

Trust takes time to build. Clear ownership means making hard calls about who’s accountable for what. Feedback mechanisms require design and practice. Measurement requires discipline.

None of this is easy. But the alternative—becoming a permanent bottleneck while your team’s production capacity outpaces your coordination capacity—is worse.

The companies that thrive in the AI era won’t be the ones that adopt AI fastest. They’ll be the ones that adapt their coordination models to match. The technology is the easy part. The organization is the hard part.

I’d love to hear how you’re navigating this—what’s working, what’s breaking. Reach out if you want to swap notes on LinkedIn or Bluesky.