Book Joelle

If You’re the Smartest Person in Every Decision, You’ve Built the Wrong Company

by | Jun 24, 2026

I caught myself doing it at Larridin.

I was running marketing on an interim basis, and somewhere in month five or six I noticed the pattern: I was reviewing every piece of content. Editing the headlines. Checking the copy. Approving the publish button. The team was sharp, fast, and waiting on me. And I was the slowest part of the system.

It didn't feel like control. It felt like quality. Like care. Like protecting the brand. Which is exactly how bottleneck leadership disguises itself — as the thing a good leader would do.

The Cost of Bottleneck Leadership

Cheryl Robinson wrote a sharp piece in Forbes this week about context engineering — the leadership shift from making the call to designing the conditions where good calls get made. She's right about the cost. Three in four leaders say their organizations lose up to 5% of annual revenue to decision delay. And she's right that the leader-as-final-decider model doesn't scale to the speed AI is forcing on us.

But context engineering isn't a new leadership style. It's the leadership style we've always known we should be running. We just have new vocabulary for it now because AI made the cost of bottleneck leadership impossible to hide.

The Five Pillars of Context Engineering

The architecture underneath context engineering — the actual mechanism that makes it work — is five pillars I've used across five CMO and CRO seats:

  • Clarity of goal. Everyone knows what we're trying to achieve and why it matters. Not the slogan version. The version where someone closest to the customer can make a tradeoff at 4:47 on a Thursday without escalating.
  • Clarity of role. Everyone knows what's theirs to decide and what isn't. Ambiguity here is what sends decisions up the chain. People escalate when they don't trust they have the right to call it.
  • Autonomy of execution. Once the goal and role are clear, people get to make the call. Not "run it by me first." Make the call.
  • Accountability. They own the outcome. If the call works, great. If it doesn't, they fix it. Your job isn't to take the bat back. It's to ask the right questions while they figure out the next swing.
  • Transparency. Everyone can see what's happening — the goal, the progress, the obstacles, the calls being made. Visibility replaces approval as the trust mechanism.

Without those five, "context engineering" is just a new wrapper on the same dependency. You can talk about designing conditions all you want, but if your team still funnels every meaningful decision to your inbox, you haven't engineered context. You've engineered a queue.

OKRs and The Top Three

This is also where most organizations break their OKRs. OKRs done badly are a reporting ritual — quarterly theater where people list what they did, not what matters. OKRs done well are the context, engineered. They define the big goal and the milestones precisely enough that anyone on the team can prioritize without asking permission.

The Top Three is the daily expression of the same discipline. In the Curveball Method, the Top Three is the focus tool: the three things — and only three — that you must move forward this week to meet your milestone. Anything else is noise to push back, delegate, or kill. But here's where most leaders get it wrong: the Top Three isn't just the leader's focus list. Every person on the team has a Top Three. And every person's Top Three connects visibly to the milestone that connects to the goal.

That's what makes decision-making distributable. When everyone knows their Top Three, and everyone can see how their Top Three ladders up, you don't need to be in the room. The context is engineered. The decisions get made.

Lessons from Larridin

Back at Larridin: once I caught myself, the fix wasn't a new system. It was getting out of the way. We aligned the team on voice — what we sounded like and what we wouldn't talk about. I gave editing and publishing rights to the people doing the work. Output went up tenfold. Visibility in AI search and answer engines climbed dramatically. The bottleneck was me. The minute I stopped being the bottleneck, the team became the engine.

So how do you start engineering context tomorrow? Five small moves, each tied to something I've written about before:

  1. Stop answering the question. Ask them what they'd do. The single most common bottleneck is the leader who answers too fast. Pause. Ask. Let them call it.
  2. Make your Top Three visible — and ask each person on your team for theirs. If you can't see how their Top Three connects to the milestone, you don't have alignment. You have hope.
  3. Write OKRs that let people prioritize without you. If your OKRs aren't sharp enough to resolve a tradeoff at 4:47 on a Thursday, they're not OKRs. They're a status report.
  4. Use AI as a lighthouse, not a watchtower. AI should illuminate the landscape so your team can navigate. The minute you turn it on your people instead of the problem, you've eliminated the very thing AI was supposed to free up: their judgment.
  5. When something breaks, ask them to fix it. Resist the urge to take the bat back. Accountability is built in the at-bat after the strikeout, not the one before.

Here's the question I'd ask you to sit with: How many decisions waited on you this week? And what did your team learn from that?

If the answer is "they learned to wait," you don't have a leadership style. You have a dependency.

Context engineering doesn't replace leadership. It exposes whether you've actually been doing it.

Related reading on gtmflow.com:

Terms and Conditions - Privacy Policy