Large organisations often wear complexity like a mark of seriousness. Managing hundreds of developers and sprawling architectures feels like real engineering. It isn't.
Read35 years inside the machine
I help organisations build better products — and fix what's in the way.
How I work
The Treasure Map of Software Development
The same pattern. Every time.
Everybody doing their job. Nobody looking at the whole.
Most software organisations are full of talented, hard-working people. The developers care about the code. The product managers care about the roadmap. The architects care about the system. Leadership cares about delivery.
And yet — products ship late, miss the mark, or quietly accumulate the kind of technical debt that makes every future feature slower and more expensive than the last. Not because of bad intentions. Because nobody is looking at the whole chain.
The people who understand what users need can't talk effectively to the people who build the product. The people who build it don't have the full picture of why. Decisions get made in silos, each one locally reasonable, collectively damaging. The organisation is optimised for process, not for the product it's supposed to be delivering.
Your current organisation is perfectly built to create the results it gets now — problems included.
— Bo Frese
Featured article
You can't force a team to become high-performing. But you can absolutely prevent it from happening. Here are the 13 most reliable ways organisations do exactly that — mostly through well-intentioned management decisions.
Read the articleLarge organisations often wear complexity like a mark of seriousness. Managing hundreds of developers and sprawling architectures feels like real engineering. It isn't.
ReadMost organisations aren't getting the value they expected from agile. Not because agile doesn't work — but because they implemented everything except the parts that matter.
ReadProduct development comes down to two things. I've known this for 35 years. So have you. The problem is everything we build around those two things.
Read
About Bo
I come in, I listen, I diagnose. I talk to the people closest to the product — managers, architects, developers, testers — and I look for what's underneath the symptoms. Then I tell you what I found, honestly, including the parts that are uncomfortable.
I've seen what right looks like from inside a small team. I've seen what wrong looks like at scale. The gap between the two is what I diagnose.