Organizational Flow · Front matter · 2 min read · First Public Draft
A Personal Journey
How I moved from writing code to paying attention to the conditions around it.
Jump to a chapter
Narrated with Microsoft's neural voice, not me — a recording.
This is where I come from: technology, and the architecture trade. The part I have enjoyed most, though, has always been where business, people and technology meet. To make sense of the rest of this, it probably helps to know how I got there.
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 and didn’t need to be. It needed systems that worked, and for seven years that was the whole of my job.
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 rather than for building one of them. The questions got bigger. Whether a particular function worked mattered rather less than whether the system made sense next to the other twelve it had to talk to.
Five years later 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 begin. I was drawing boundaries I couldn’t see, and I called it architecture, because that was the word on my business card.
By 2019 I was Chief Architect and Head of Architecture, leading the function, sitting on the management team, and still working hands-on as an architect. My perspective had shifted. I was no longer responsible only for making good decisions myself, but for creating the conditions in which good decisions could be made throughout the organization.
The throughline across those four titles is simple enough in hindsight. I kept moving further from the code and closer to the conditions the code lived in. What an organization needed to be able to do turned out to matter more than which tools it happened to use, and clear ownership did more good than another layer of governance ever did. None of it was written down anywhere. It was just what seemed to work, learned slowly and one domain at a time.
I had the vocabulary by then. Solution, domain, architecture. What I didn’t have was a name for what all four of those jobs had actually been chasing. That came later, and not from anyone in the architecture trade.