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 structural, technical, and human dynamics generating the symptoms everyone can see. That means looking at how product, engineering, and business connect (or don't), where decisions get made and by whom, what the technical reality of the codebase actually is, 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 first. Not a slide deck full of recommendations — an honest account of what I found, including the parts that are uncomfortable.
From there, we figure out together what to do.
What I can't do is fix it for you. And I wouldn't want to — because no outsider can. Systemic problems are solved by the people inside the system, not by someone parachuting in with a plan.
What I can do is work through it with you.
That usually means bringing together a cross-functional group — the people with the relevant competencies, and the people with the authority to make decisions that actually stick. If you leave either out, you end up with solutions that are technically right but organisationally impossible to move, or with mandated changes that nobody knows how to implement.
What an outsider can do is ask the questions people inside have stopped asking. See the shape of the system from the outside. Notice what everyone has learned to treat as fixed when it isn't.
But the actual work of changing things — trying new approaches, finding out what works, adjusting, trying again — that has to come from people who are embedded in the organisation. It's not a handover. It's a collaboration.
And it won't be quick. 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.
I don't know in advance which changes will land. Neither will you. I've seen what happens when people pretend they do.
I don't run framework certification programmes. I don't fix surface problems without addressing what's generating them. And I don't tell you what you want to hear.
I'll tell you what I found, including the parts that are uncomfortable to name. What you do with that is your decision. My job is to make sure you're making it with a clear picture.