That's not a nostalgic detail. It's the reason I can do what I do.
The product is the point.
Not the process, not the methodology, not the roadmap — the thing that ends up in the hands of real people, solving a real problem. Everything else is in service of that.
Speed and quality are not in opposition.
I've been saying this for decades, and I've seen it proved and disproved enough times to be certain: the teams that sustain pace over years are the ones that treat engineering craft as a competitive advantage. Technical debt doesn't announce itself. It accumulates quietly, one shortcut at a time, until the codebase that was your advantage becomes the thing holding you back.
You can't fix what you don't understand.
Diagnosing before prescribing isn't a methodology — it's basic respect for the complexity of the system you're looking at.
I started as a developer. Then architect. Then team lead. In the mid-nineties I became a partner and CTO at Bass Consulting — a small startup where we built a complete web-EDI system for Danish pension companies from the ground up and sold it to PFA and others. The company was later acquired by Aston IT Group, where I led the development team through the transition. That experience — being accountable for users, business, and code at the same time — changed how I think about building software. When you own the whole thing, you stop seeing the parts as separate.
After the acquisition I moved into larger organisations. The contrast was immediate: handoffs replacing conversations, good developers working hard toward results nobody was quite satisfied with. Not because of bad intentions. Because nobody owned the whole chain.
Then Nordija — a twenty-person consulting company that worked the way software teams are supposed to work. Small, focused, technically excellent, everyone close to the product. This is where I first worked seriously with agile practices — and where I met Jim Coplien, whose organisational patterns work directly shaped both Scrum and XP. Seeing what a genuinely high-performing team looks like from the inside, and understanding the structural theory that explained why it worked — at the same time, from someone who had helped define the field — was formative. It is the clearest reference point I have for what right actually looks like.
I spent the following years coaching and advising teams inside large organisations — first at Valtech, then independently. Along the way I had the unusual opportunity to learn directly from the people who built these practices — first at CampScrum, a week-long residential course where Jeff Sutherland and Jim Coplien both taught. The learning didn't stop when the day did. What gets shared late at night over a glass of wine is different from what goes into any course curriculum — the doubts, the edge cases, what actually made it succeed and what didn't, all the things that never made it into the Scrum Guide. A year or two later came the early sessions that became the Scrum patterns: a week-long off-site where Jeff shared what he had learned from years of real implementations, Jim captured it as patterns, and a small group of us were there to ask questions, push back when a pattern wasn't clear, and help work out whether the formulation held. That matters because it means I understand what these practices actually were before the consulting industry packaged and sold them.
What I watched during this period was agile transform from a grassroots engineering movement into something organisations buy and install. The teams I worked with were talented and well-intentioned. But in many of them — especially those deep into large-scale agile frameworks — what I encountered bore almost no resemblance to the agile I had come to know. The ceremonies were there. The structural conditions that make them work were not.
I believe in what agile and lean were designed to do. I still do. The whole point of what Coplien, Sutherland and the original practitioners built was to get closer to the product — shorter feedback loops, decisions made near the work, real ownership. That's what gets designed out when it's packaged as a methodology and sold as a transformation. I've never tried to sell one. What I stopped believing in is treating process as separable from technical excellence, or organisational structure as separable from software architecture. The people making decisions about how teams are structured often lack the engineering understanding to see what those decisions do to the systems being built. The people building the systems rarely have the authority to say so. These things reinforce each other — and they can only be addressed together.
I've been at every point in the chain. That's what lets me see where it breaks. Working independently has meant I can do both — advise on the system and still write the code. I don't think you can do one well without staying close to the other.
Bo is one of the clearest Agile thinkers in Denmark and one of the most well-rounded and practical folks I have worked with in decades. Few who use the title "architect" really deserve it: Bo is one of those rare individuals who rises to the task.
— Jim Coplien, organisational patterns author, lean/agile coach
Over 35 years I've designed and built systems across finance, telecom, digital TV, transportation, and medical — payment systems, fault-tolerant job schedulers, set-top-box platforms, mobile apps, and large-scale web systems. That work hasn't stopped. In recent years I've been embedded in financial services, energy, and life sciences organisations — building DevOps pipelines, writing production code in Java, Ruby, and Python, working alongside the teams doing the daily work. I don't advise from a distance.
Early in my career I built WDB — a web/database toolkit developed while providing internet access to astronomical data from the Hubble Space Telescope and ESO telescopes in Chile. Open-sourced, it spread further than I expected: Stanford, Harvard, Yale, Berkeley, NASA's JPL, CNES, Ericsson, the Human Genome Project, and others. It was written about in books and referenced in publications and software patents. It also became the technical foundation for Bass Consulting. Well-built software has a long life.
I also build for myself — not because I'm between clients, but because end-to-end ownership is where I started and I've never let go of it. Glysimi is an iOS app for diabetes management I built because the apps that existed didn't meet my needs. GlysimiCMS powers the platform. Bob is an open-source plugin for Claude Code — my way of sharing what I've learned about AI-assisted development. These aren't client work — and nowhere near the scale of what I build with clients. But they're proof that I still think in terms of shipping real things to real people.
Without technical excellence, the rest is just meetings.
— Bo Frese
Organisational change is genuinely hard. I know this not from theory but from years of working inside teams in large organisations — close enough to see exactly what's broken, too far from the levers to fix it.
Most organisations that want to improve how they build products end up adding more process, more oversight, more middle management. The opposite of what actually works. I've seen it happen over and over — and I've seen how little impact you can have on it from inside a single team, however good your intentions.
The first fifteen years of my career I worked in small, lean setups where developers, users, and the business were in the same room. We were agile before it had a name. I know it works. I also know that recreating those conditions inside a large organisation requires changes that can only be made from the top.
What was possible from inside a team was still real. At Novo Nordisk, two teams I worked with took genuine ownership of their process and roughly doubled their velocity within months — not by working harder, but by creating the conditions for experienced developers to self-organise and own their outcomes. At DSB, a shift from "my code" to "our code" took the better part of a year of careful work but changed how an entire team could function. At Alcatel-Lucent, I worked across France, Spain, and China to get functions that had never collaborated to actually start working together — inside a structure that made cross-team conversation genuinely difficult.
These were real changes. None of them touched the decisions that were generating the underlying problems: the incentive structures, the product-engineering relationship, the organisational design that made those problems inevitable. That's the ceiling of team-level change. It's lower than most people think.
That's why I only take engagements where I have access to the people with real authority. Honest diagnosis is only as useful as the decisions it enables. If the people who commissioned the work can't act on what I find, I'm not helping — I'm providing expensive cover for staying the same.