Part I — Discovering Flow

A Personal Journey

I wrote my first production code in 2001, for an insurance company most people have never heard of unless they’ve filed a claim through it. AFA Försäkring wasn’t glamorous. It didn’t need to be. It needed systems that worked, and for the first seven years, that was the whole of my job: writing the systems that worked.

By 2008 I’d moved from writing code to designing it — Solution Architect, a title that meant I was now responsible for how the pieces fit together, not just for building one of them. The questions got bigger. Not “does this function work” but “does this system make sense next to the other twelve it has to talk to.” I didn’t have language for it yet, but I was already doing the thing this book is about: trying to keep value moving through a growing tangle of capabilities, decisions, and dependencies.

Five years later, in 2013, the title changed again — Domain Architect — and so did the questions. Less about systems now, more about domains: what belongs together, what doesn’t, where one team’s responsibility should end and another’s should begin. I was drawing boundaries I couldn’t see, the way a gardener decides where one bed ends and the next begins, long before anything is planted.

I didn’t call it that at the time. I called it architecture, because that was the word on my business card, and because “gardening” would have gotten me strange looks in a steering committee. But the instinct was the same: some things need tending, not building. You don’t finish a domain the way you finish a feature. You keep it healthy.

By 2019 I was Chief Architect and Head of Architecture — building and leading the function itself, not just working within it. A different kind of responsibility: not “is this decision right” but “are the conditions right for other people to make good decisions without me.” That’s a harder problem, and a quieter one. Nobody thanks you for a decision that didn’t need escalating.

Looking back, the throughline across all four titles is embarrassingly simple: I kept moving further from the code and closer to the conditions the code lived in. Capability before technology, ownership before control, structure before speed — none of that was written down anywhere. It was just what worked, learned the slow way, one domain at a time.

Then, in 2016, someone asked a question that made all of it explicit.