From flow point of view, one of the worst statements you can make is “at least everything is being progressed”, yet I’ve heard that so many times from both inexperienced delivery leads and product people alike.

In my previous article, I explored feature ageing and discussed why it can be a useful signal for product managers. When you observe the ageing of features over time, you may notice a strange phenomenon with some late deliveries.

In the previous article, I argued that product managers are often the last to know when something starts going wrong. And just to be clear, I’d much prefer if this wasn’t the case but my experience and recent conversations with a dozen or so product managers confirm that it most certainly is.

If you work in software product delivery I think you might recognise this slightly uncomfortable situation I’ve noticed.

A simple story about why work gets stuck in organisations

There’s a particular kind of frustration that appears in organisations once they become even moderately complex.

Everyone seems busy as if to demonstrate their worth, teams are working hard and the number of meetings steadily increases.

There are some unspoken thoughts creeping into many delivery conversations lately.

If developers can generate code faster, test faster, produce documentation faster, then surely delivery becomes more predictable as a result?

And forecasting becomes … easier? Surely flow improves automatically?

If there is one habit that software organisations cling to longer than any other, it is starting work to feel in control. As if making the decision gives people some sort of satisfaction or power.

Roadmaps get refined, plans get approved, quarters get kicked off. Then work starts because it’s “time” and not because the system is ready.

As humans we often fail to be rational but excel at “rationalising". Our brains prioritise metabolic efficiency and social survival over objective truth. To conserve energy, the brain uses confirmation bias to filter new data through existing neural frameworks rather than performing the more "expensive" work of updating these neural pathways.

Most delivery issues seem obvious in hindsight.

After the fact, it is easy to point at the moment when things went wrong, whether it was a late dependency, a missed review, or a piece of work that was “almost done”.

The action taken or not taken at the time is always easy to justify - business pressure, higher priority elsewhere or someone accepting the risk, etc.

The uncomfortable part is that in almost every case, the warning signs were visible long before the risk became an issue.

Most delivery teams are stuck in a horrible reality of being pushed to provide estimates which are then turned into commitments. The estimates are an expression of confidence at best.

Dates are chosen because they feel reasonable, or because someone senior is comfortable with them, or because a plan demands certainty. The organisation then rallies around that date, progress is reported optimistically, and reality is politely ignored until the moment it can no longer be hidden.

Many delivery teams focus on what's in progress and what’s left to do.
Very few actively manage what's blocked. In fact, I’ve known a fair few over the years who actively skipped over the blocked items.
That's not just a minor oversight, it's one of the most expensive blind spots in modern delivery systems.

It bothers me. A lot. I used to go on LinkedIn to learn something. Now all I learn is that more and more of the content is AI generated. For instance, I’ve never known humans use this symbol “—“ so much. Have 90% of the people suddenly started doing that or are all these posts I am seeing generated by the same bot?

If your board says To Do / Doing / Done, your metrics are already compromised.
They are not just slightly off, and "good enough for now” is not good enough at all. Your metrics are actively misleading you.
And before you blame your tools, this isn't a tooling problem, it's a thinking problem.

Most delivery organisations don’t lack data. In fact they swim in data.

What they lack is understanding what to do with the data. To quote Douglas Hubbard "we should care about a measurement because it informs key decisions”​

But it is rare to come across an organisation that understands well why they measure in the first place.

If there is one Kanban idea that organisations love to talk about and hate to actually practice, it’s this one.

Pull-based WIP control. Everyone you meet who knows Kanban is also an expert in WIP.

The most common question delivery teams are typically asked is also the most damaging one:


“When will it be done?”


Not because the question is unreasonable, customers are absolutely entitled to ask, but because most organisations answer it in a way that guarantees disappointment. Dates get guessed, confidence gets projected, risks get accepted and uncertainty gets quietly ignored until it turns into high profile failure. Yes, an estimate is better than no estimate but estimates turn into commitments and that only leads to problems.