I've worked in organisations that had excellent processes.

Beautifully documented. Thoughtfully introduced. Enthusiastically adopted.

And I've watched those same organisations struggle with the same problems they had before the process arrived.

There's a pattern I've noticed in struggling engineering organisations.

When something isn't working, the instinct is to introduce a framework.

Delivery is slow. Introduce Agile. Teams aren't aligned. Introduce OKRs. Engineers aren't growing. Introduce performance objectives.

The frameworks aren't wrong. Most of them are genuinely well-designed, built on real experience from organisations that used them well.

But frameworks don't remove the need for judgement.

A framework is a tool.
And tools take the shape of the hands holding them.

OKRs were designed for a specific kind of organisation. One with clear direction, stable enough to hold a meaningful objective for ninety days without the ground shifting underneath it. One where leadership could translate a company goal into something that meant something to an individual engineer on a Tuesday afternoon.

Most organisations that introduce OKRs have none of those conditions in place. Priorities are shifting. Leadership is still working out what actually matters. The gap between a company objective and a developer's daily work remains unbridged.

So the OKRs arrive — and too often the framework becomes a substitute for the harder conversation about priorities, trade-offs and direction. The spreadsheet gets filled in. The quarterly review happens. And six months later someone asks why nothing has changed.

I've also seen OKRs transform organisations. But in every case, the leadership team had already done the difficult work of agreeing what mattered. The framework amplified clarity. It didn't create it.

Agile has the same problem, dressed differently.

The pitch is almost always speed. Faster delivery. Shorter cycles. More frequent releases.

But speed is rarely the real constraint.

The team that's shipping every two weeks but building the wrong thing isn't suffering from slow delivery. It's suffering from unclear direction. And Agile, introduced into that environment, doesn't fix unclear direction.

It accelerates it.

I've watched organisations introduce Agile and immediately feel more productive. Standups. Sprints. Retrospectives. Velocity charts. All the motion of progress. Not always the direction of it.

When Agile works, it's because the team already shares a clear picture of where they're going. The framework gives that clarity structure and rhythm. When it doesn't work, the ceremony remains long after the usefulness has gone.

The personal development version of this failure is the one I find hardest to watch.

A leader sits down with an engineer. Together they write objectives. Stretch goals. Development areas. Things to work toward over the next six months. The engineer leaves the room motivated.

Then they hit a wall. A skill they don't have. A question they can't answer alone. A decision they need help navigating. They raise it. Nothing comes back.

The next review arrives. The objective remains. The wall remains. What started as a development conversation becomes a performance conversation. The engineer who asked for help and didn't receive it is now being evaluated on the outcome.

This is the version of process failure that damages people rather than just wasting time.

The onus on the individual to grow is real. But so is the onus on the leader to lead.

A development objective without the support to achieve it isn't a goal.
It's a standard.

And most people already knew they weren't meeting it.

None of this is an argument against process.

Good process, in the right organisation, is genuinely powerful. The difference is always the same: the organisations where these frameworks work have done the harder work first. They've agreed on what matters. They've built the trust and communication that makes alignment possible. The framework then gives that foundation structure.

In a healthy organisation, process amplifies what's already working.

In an unhealthy one, it papers over what isn't — sometimes for long enough that everyone forgets the original problem.

Before introducing a new process, I've started asking three questions.

If the honest answer to the third question is "quite a difficult one" — it's usually worth having that conversation first.

The process can follow. It tends to work better that way.