Most problems in software product development are visible long before anyone understands them. That's where I start.
Before I suggest anything, I need to understand what's actually going on — not just what looks like it's going on from the outside.
That means talking to people. A lot of people. Not just the managers who hired me, but the architects, the developers, the testers, the UX designers, the people in ops who keep things running. Anyone close enough to the product to have a real opinion about what's working and what isn't.
I can have these conversations the way I do because I'm not an outsider to the work. I've been a developer, an architect, a team lead. I still write code. I still build products — because I genuinely love it, and because staying close to the craft is what keeps my advice grounded in reality rather than theory. When I sit down with a senior developer or an architect, they know I understand their world. Not in the abstract. In the specific, daily, frustrating, satisfying reality of actually building something.
What I'm looking for isn't opinions about what to fix. It's signals — different kinds of insight about the same system. I seek out three groups in particular:
The experienced, outspoken people who have strong views and aren't afraid to say so. They've often identified something real and can articulate it clearly. What they sometimes can't see is whether their diagnosis is a root cause or a symptom of something deeper.
The ones the organisation has learned to tune out. They raise concerns in meetings, resist changes, get quietly labelled as difficult or negative. They're not always right about the solution — but their frustration is almost never random. Something generated it. That something is usually worth finding.
People who have been in the organisation for a long time, rarely speak up in group settings, but carry more institutional knowledge than almost anyone else. They've watched the same problems resurface in different forms over the years. If you create the right conditions, they'll tell you things nobody else will.
I do most of this in one-on-one conversations. The real story rarely comes out in a group.
I'm not collecting opinions. I'm trying to map the system that's generating the current results.
Here's the thing about organisational problems: the organisation is not broken. It is, in fact, perfectly built to produce exactly the results it gets now — including the problems. That's not cynicism. It's the most useful frame I know for finding root causes instead of chasing symptoms.
If you treat a symptom without understanding what's generating it, the problem comes back. Sometimes in the same form. Sometimes in a different one. But the system keeps doing what it's designed to do.
The other thing about root causes: there is rarely just one. There are several, and they are connected — they reinforce each other in ways that aren't obvious until you've seen the whole picture. The team structure that makes certain conversations impossible is directly connected to the architecture that makes certain changes expensive, which is connected to decisions made years ago when nobody was looking at the whole chain. Pull one thread and you find the others.
My job is to find what's underneath. The problems being described are rarely the real problems — they're symptoms. The real issues tend to live in the friction between business goals, organisational structure, and technical reality: how those three connect (or don't), where decisions get made and by whom, what the codebase actually reveals about the choices people have been making, and where the people doing the work feel helped or hindered by the organisation around them.
The engagement follows the diagnosis. I don't arrive with a solution.
— Bo Frese
When I have enough of a picture, I bring it back to the people who hired me. Not a slide deck full of recommendations — an honest account of what I found, including the parts that are uncomfortable.
Then I stay.
That's the part most consultants skip. A diagnosis is only useful if something actually changes. And change in an organisation doesn't flow from a plan handed down from the top and implemented at the bottom. It's a constant back and forth — between the doing and the deciding, between what was intended and what actually happened, adjusting and trying again. That loop needs someone to keep it alive.
Which means I need to be on-site. The conversations that matter rarely happen in scheduled meetings. They happen at the coffee machine, at the end of a retrospective when most people have left, when a developer pulls up a piece of code and says "this is where it actually breaks down." I can have those conversations because I can work at every level — sit with an architect on a system design, pair with a developer on real code, join a planning session and notice where the disconnect between business intent and technical reality is happening in real time. I've done all of those jobs. I still do.
From the beginning, I work closely with people inside the organisation who will carry this process when I'm not there. Ideally a small cross-functional group that collectively covers the breadth of what we're trying to change. Leave out the people with the right competencies and changes will be mandated but nobody will know how to implement them. Leave out the people with real authority and nothing will stick. This isn't a handover at the end. It starts from day one.
Organisations don't change in a workshop. What works is small, incremental experiments in different parts of the system — changes that are safe enough to try, visible enough to learn from, and honest enough to stop when they're not working. All of this while the business keeps running.
There's no long-term contract. No minimum commitment. You decide how much presence makes sense at any point. Typically it starts intensively and gradually tapers as internal capacity grows.
Because the goal is to make myself unnecessary.
Culture doesn't come from an external consultant. It comes from the people inside the organisation. The engagement succeeds when the capacity for honest, iterative improvement no longer depends on me being in the room.
Before we start, we agree on what "better" actually looks like — not in the abstract, but concretely: what you'll see, hear, feel, or measure as evidence that things have changed. That becomes the shared picture we work toward, and the feedback loop we use to learn from what happens.