The Developer Built It While I Was Still Reading The Docs

The developer finished building it before I'd gotten through the approval documentation.

Sprint planning. High-performing team. I'm walking through the requirements for a button colour change. He looks at me, looks at the 8-page approval doc, and says: "This is dumb."

He was right.

That button had been in approval for a month. Business signed off. Design signed off, Accessibility signed off. Compliance signed off. Legal signed off. Product signed off. Then when any question was raised, it looped back through all of them again.

The actual work? Ten minutes. If that.

That's when I realised most organisations aren't just inefficient - they're layering process on top of process, and no one's questioning whether any of it should exist. And now with AI, many are about to make it exponentially worse.

Everyone's Automating The Bloat

Here's what I see happening right now: companies are building AI workflows on top of processes that were never questioned in the first place.

They take a 20-step approval chain that exists because someone added a safeguard in 2014 after an incident no one remembers, and they say "let's make this faster with AI."

You haven't made it better. You've made the bloat faster and more expensive.

The real work isn't automation. It's interrogation.

Before you build the AI workflow, strip the process down to what actually moves the needle. Everything else is just expensive theatre.

The Framework I Use Before Touching AI

Here's what I do when I walk into a new team or assess a business:

1. Define the Raw Outcome Ignore the current process entirely. What's the actual result you need? For that button change, the outcome was: "User sees updated button colour in production." That's it.

2. Audit for "Scars" Most process steps exist because something went wrong once. Every time I see a 20-step approval chain, I think about that developer's face - the look that said "you're wasting my time and you know it." Ask: "Are we spending $10,000 of collective time every month to prevent a $500 mistake that happens once a year?" If yes, cut it.

3. Build the Critical Path What's the absolute minimum required to get from start to outcome? If it feels uncomfortably bare, you're doing it right. For that button: developer changes it, QA checks it works, deploy. Three steps, not thirty.

4. Automate the Remnant Only now - after you've stripped it down - do you bring in AI or automation tools. You're automating the lean process, not the legacy one.

The Real Barrier Isn't Technical

When I started cutting approval layers, the pushback wasn't "we need this for compliance." It was "we've always done it this way."

People weren't protecting the process. They were protecting their role in it.

Here's the shift that works: change what leaders are afraid of.

Most leaders fear singular mistakes - the audit finding, the public scandal. They aren't scared of the invisible, constant drain of a slow process.

So I started making the waste visible. That button sat in limbo for a month while we pretended the process was protecting us. I put the numbers in front of leadership: "We're spending 5 days of wait time on a task that takes 10 minutes of actual work. That's 5 extra days where this value could have been realised and we could have been working on other priorities. Is the safeguard worth more than the delay?"

Make the waste visible. Suddenly the "safety check" looks like the liability it actually is.

Then I built a small team empowered to prove the lean process worked - people who could bypass the blockers without waiting for everyone's permission. The full story of how that team operated and got leadership buy-in is worth its own post. But the short version: we proved it worked, and others came on board.

You don't need everyone's permission to start stripping bloat. You need results and a few leaders who see the value.

The Cultural Shift That Actually Works

Stop rewarding people for adding safeguards. Start celebrating people who kill unnecessary steps.

Reward the process kill, not the process add.

What You Can Do This Week

Pick one process your team follows right now. Ask these three questions:

1. What's the raw outcome we actually need?
2. Which steps exist because of a one-off incident that's never happened again?
3. If we removed this step and it broke something, could we add it back in 24 hours?

If the answer to question 3 is yes, remove it. See what happens.

You're not being disrespectful by questioning the process. You're respecting people's time.

What's one step you can cut this week?