Bo FreseThe diagnosis comes first.
Always.
Most attempts to move faster fix one piece in isolation — the process, the structure, the technology. The underlying pattern stays. Before anything can actually change, you need an honest picture of what's generating the current results. That's where this starts.
Image created with AI - obviously :-)
I listen first
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 product owners, the business people closest to the market — 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 still write code, 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:
Thought leaders
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 sceptics
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.
The quiet ones
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.
What I'm looking for
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.
Not a plan handed down. A direction owned from within.
— Bo Frese
What comes next
When I have enough of a picture, I bring it back to the people who hired me. Not a slide deck — an honest account of what I found, including the uncomfortable parts.
Then I stay — but not the way most consultants do. Not full-time, not indefinitely. What the work looks like depends on what the diagnosis surfaces. Organisations don't change in a workshop. What works is small, incremental experiments — changes safe enough to try, visible enough to learn from, honest enough to stop when they're not working. All while the business keeps running.
From the start, I work alongside people inside the organisation who will carry it forward — the right competencies and the right authority in the room from day one. Not a handover at the end.
The full philosophy behind this — making myself unnecessary by design — is on the How I Work page.
What this will surface
The conversations I have inside an organisation will surface things that haven't made it to the top. Some will be uncomfortable. A partial diagnosis is worse than no diagnosis — so I won't give you one.
What I won't do is create unnecessary disruption or hand over a report that sits in a drawer. We work out together what can be changed, what has to be changed, and in what order. If the diagnosis points somewhere you're not ready to act on, that's important to know before we start — not after.
I only take engagements where I have direct access to the people who can act on what I find. Not because I'm precious about hierarchy — because without it, I'm providing cover for staying the same, not help.
The engagement works when the people who commissioned it genuinely want to know what I find. The leaders I work best with have already decided they'd rather know.