Building software since 1987.
Still at it today.

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 saw what a genuinely high-performing team looks like from the inside. 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 as a consultant. I watched 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 through practice and from the people who first defined it. 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. 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.