I used to feel strangely relieved when delivery slipped.
Because it meant I knew what to do.
Better planning. Better estimation. Better sprint ceremonies.
Process felt like something I could get my hands around.
I realised much later that I was solving the comfortable problem rather than the important one.
I once spent three months helping build a set of OKRs I was genuinely proud of.
They were well-structured. The objectives were ambitious but achievable. The key results were measurable. We'd done the thing properly, or at least it looked that way on the slide deck.
By February, nobody was looking at them. The business was under pressure, priorities were shifting week to week, and the conversations we'd had in the planning sessions were being relitigated in response to whatever had happened that Monday.
At the time, I believed the problem was that people hadn't committed hard enough to the process. If we just trusted the framework, it would work.
Looking back, I think we'd used the OKR process to avoid a more difficult conversation about what the organisation actually prioritised when things got hard.
Frameworks amplify clarity.
They don't create it.
The version of this that has stayed with me most is engineer development, but from the other side of the table.
I've been the developer in those meetings. The one nodding along to objectives that sounded sensible enough on paper. Stretch goals. Real development areas. A plan that looked like someone had thought carefully about where I needed to grow.
Then the work would start, and the support around the plan would be thinner than the plan itself. A skill gap would appear. A decision would need talking through. I'd hit the wall and realise the objective had been set more clearly than the path to reaching it.
Six months later I'd be back in a review conversation, being measured against goals I hadn't been properly helped to achieve.
That's not a development plan. That's a standard. And setting a standard without providing the support to meet it is a leadership failure, not an engineer one.
I don't think I understood that fully until I'd been on the receiving end of it.
A development objective without the support to achieve it isn't a goal.
It's a standard.
I don't think leaders reach for frameworks because they're lazy or avoidant. I think they do it because frameworks feel objective. They come with templates, books and success stories from organisations that used them well. The conversation you're avoiding doesn't come with any of that.
That's a harder thing to schedule into a quarter.
None of this is an argument against process.
Frameworks amplify good leadership. They don't replace it.
In a healthy organisation, process gives shape to what's already working. In an unhealthy one, it can cover over what isn't, sometimes for long enough that everyone forgets what the original problem was.
Before I introduce a process now, I ask myself three questions.
What problem am I actually trying to solve?
How will I know if this process solved it?
What conversation am I avoiding by introducing it?
If the honest answer to the third question is a difficult one, I try to have that conversation first.
The process can follow. I've found it usually works much better once the difficult conversation has already happened.