Bo FreseEverything connects.
That's where I start.
Most approaches to fixing software organisations pick one dimension and optimise it. The process. The technology. The org structure. AI. Each fix creates new friction somewhere else — because the parts were never the problem. What moves the needle is quality culture and close collaboration — together, not in sequence.
The dead cat problem
Russell Ackoff, one of the founders of systems thinking, put it bluntly: "If you try to understand a cat by taking it apart, the first thing you will find is a dead cat."
Software organisations are the same. You can examine every component in isolation. The structure. The ceremonies. The backlog. The codebase. The deployment pipeline. The team topology. Each analysis will be locally correct — and the people doing it are usually right about what they see from where they sit. The problem is that the most persistent issues tend to live in the connections between the parts, not within them. And those connections are exactly what specialisation, division of labour, and siloed measurement make hardest to see.
How an organisation structures itself shapes what people can see and communicate. That shapes the architecture of the software they build. The architecture shapes what's possible to change. What's possible to change shapes how the organisation responds to users and markets. Pull one thread and you find the others.
What this looks like in practice
When you look at a software organisation as a system, certain things become visible that aren't visible from inside any one part.
A team that can't deliver is often constrained by architectural decisions made years ago by people who have since left — decisions now invisible except in how slowly everything moves. The team didn't make the architecture. The architecture makes the team's reality.
A product that misses the mark often misses because the people closest to users — developers, support, frontline — aren't in the room when decisions get made. Not because anyone chose to exclude them. Because the structure makes it hard to include them.
AI makes both of these patterns harder to ignore. It starts every session as a new developer on day one — no memory of last week's decisions, no feel for your conventions, no understanding of why the product exists. That exposes every gap in shared understanding and quality culture.
But AI also offers something most organisations haven't fully grasped: the ability to prototype fast enough to bring users and business into the loop in ways that were previously too slow to be practical. Real feedback. Real validation before you've committed.
The condition is the same in both directions. Users, business, and developers need to be close enough that knowledge flows between them. Without that closeness, AI generates debt faster than you can manage it. With it, AI compresses exactly the feedback loops that make you build the right thing.
None of this is visible from inside one part of the system. It's only visible from across it.
My priority is not that you are happy I am there. My priority is that you are happy when I have left.
— Bo Frese
The goal is to make myself unnecessary
Most consultants measure success by how much the client needs them. I measure it the other way around.
My priority is not that you are happy I am there — though that matters too. My priority is that you are happy when I have left. That the code your developers are maintaining six months later is something they can stand behind. That the habits and conversations your organisation started having are still happening after I am gone. That the AI discipline your teams built stays embedded in how they work, not in how often they call me.
That shapes how I work from day one. I don't hold the solution and hand it over when I leave. I work alongside the people who will own it — developers, leads, the people closest to the problem — so that ownership is never mine to transfer. It was theirs from the start.
The engagement succeeds when you no longer need me in the room to keep the value alive. That's not just the exit condition. That's the goal. It's commercially counterintuitive for a consultant to say out loud — which is exactly why I say it.
Who this works for
The entry point varies — the organisation, AI adoption, or hands-on development. What doesn't vary is the approach: understand the whole before touching any part, and say honestly what the whole picture shows.
For advisory work, that means direct access to the people with the authority to act. Not filtered. Not a steering committee that reports upward. The leaders I work best with have already decided they'd rather know.
For AI and development work, that means teams with enough craft and autonomy to do it properly — not looking for a shortcut around the hard parts.
In all cases, I won't tell you what you want to hear. If you're not ready for an honest picture, we'll both know quickly.