Once upon a time, there was a Product Owner who had done everything right.
Every day, she watched her organisation absorb unnecessary bureaucracy — small frictions, repeated workarounds, the kind of overhead that nobody had officially decided to create but that had accumulated anyway. Until one day, she decided to do something about it. She mapped the problem, reached out to the development team, and between them they sketched a lightweight, practical solution — well within the team’s capability to build. She was energised by it. The kind of energy you notice in someone who has found a real problem and genuinely wants to fix it.
Because of that, she expected things to move. But nothing happened.
A few weeks later we were talking, and she described the situation the way people do when they can’t quite make sense of it — as a question. Why wasn’t the organisation moving on something so obviously useful?
I asked her one thing: was her organisation structured to receive ideas that came from the bottom up, or did change typically come from the top down?
She paused.
I explained the distinction — not as a criticism of her organisation, but as a description of how most organisations actually function. In a push system, change is initiated and authorised at the top and flows down. A pull system creates mechanisms for good ideas to surface from anywhere and be acted on regardless of where they originated. Most organisations, I find, are predominantly push systems — even ones that talk about empowerment, even ones that genuinely believe they value initiative.
In a push organisation, a grassroots initiative — however sound — is structurally out of place. The system has no established path for it to travel. It sits there, waiting for someone with sufficient authority to adopt it as their own idea and push it downward. Until that happens, it doesn’t move.
She recognised it immediately. And then came the harder part.
Because of that structural mismatch, even if her initiative found its sponsor, there was a second problem: the saving her solution would generate was bureaucracy reduction — time recovered, friction removed, cognitive load lifted. Real value. But unless that value appeared in the spreadsheet the organisation used to make decisions, it would remain invisible. Organisations tend to act on costs they can see. The cost of bureaucracy is usually absorbed silently, distributed across dozens of people’s days in ways that never aggregate into a line item. Her solution would save something the organisation hadn’t officially noticed losing.
Until finally, the picture became clear — not as a solution, but as a diagnosis. The problem wasn’t her idea, or her approach, or the team’s willingness. It was a structural mismatch between how the organisation processed change and what she was trying to do, compounded by a measurement system that made the benefit of her initiative genuinely hard to argue for in the language the organisation spoke.
Ever since then, I find myself returning to this pattern. Good ideas, capable people, real problems — and a system that wasn’t designed to receive what they’re offering. Sometimes the most useful thing a conversation can do is name the wall clearly enough that the person on the other side of it can decide what to do next.
She’s still thinking about it.
If this resonates and you want to understand the framework underneath it, the Introduction to Agile and Scrum workshop is a practical starting point — covering the values and principles that make pull-based thinking possible, and how to implement them in a real development process.
💬 Want more conversations like this one? Conversations lands once a month, straight from the room. Real client and prospect exchanges, anonymised, each built around a moment where listening changed the outcome.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
