For a decade, we optimised the wrong constraint
Building software used to be slow and expensive. Entire operating models were designed to widen that bottleneck — Agile, DevOps, platform engineering. All of it aimed at the same choke point, and all of it was worth doing.
That constraint is dissolving. When implementation becomes nearly free, the scarce resource moves upstream: not how fast can we build it, but what should exist, why, and is the intent precise enough that humans and agents can execute it without loss.
This publication is about what that does to the way organisations decide, build and learn.
What Intent Architecture means
Intent Architecture is the discipline of describing problems and designing systems so that intent translates into outcome without loss — through people, through agents, through the platform underneath.
It is not a tool and not an AI feature. It sits in the same category as Domain-Driven Design, Team Topologies or platform engineering: an approach, not a technology. And it deliberately spans three things that are usually treated separately — product, organisation and architecture.
An intent, in this sense, is more than a requirement. It states what outcome should be achieved, in which context, under which constraints, with which authority to act — and how we will know whether the outcome was actually achieved. Drop any one of those five and you have a ticket, not an intent.
What you’ll find here
Long-form pieces, roughly every other week, on the parts of this that are actually load-bearing:
Where the bottleneck went. Why velocity without clarity costs more than slowness, and what that means for how work gets scoped.
How intent comes into being. Signals arrive from the whole value stream — the sales engineer watching a deal stall, the support analyst sending the same workaround for the fiftieth time. Turning that into a decision is a process, and most organisations don’t have one.
How far an agent may go. Role-based access says who may act. It doesn’t say how far. The answer isn’t a policy engine — it’s reversibility.
What compounds. Why the shared context an organisation builds is a more durable asset than the software it ships.
Each piece stands on its own. Together they add up to a book I’m writing under the same name.
Who writes this
Product Manager at Red Hat, EMEA organisation builder at Palo Alto Networks, leader of specialist solution architecture teams at AWS. That’s the short version, and it’s the least interesting part.
Twenty-five years ago I had a job standing between two groups who couldn’t hear each other: users describing what they needed, engineers describing what was buildable. I was the translation layer. I’ve been in some version of that position ever since. The altitude changed. The problem didn’t.
At Red Hat I first translated customer demand into architecture, then spent years as a product manager driving adoption of containers and Kubernetes. That’s where the pattern became visible: the technology was never the blocker. Organisations adopted Kubernetes and got slower, because the structure around it still had the shape of the thing it replaced. Technology adoption work turned into DevOps, then DevSecOps, then Team Topologies work — not by design, but because that’s where the actual problem sat.
At Palo Alto Networks I helped define a market category that didn’t exist yet and built the EMEA organisation behind it — a systems engineering team, solution architects as the title later became, grown several times over inside a year and in the middle of a pandemic. That’s where I learned what it costs to make a new idea legible to a market. Mostly it costs repetition.
At AWS I led specialist solution architects across cloud migration, architecture modernisation, data and AI. Each of them arrived at a customer’s problem from a different starting point — and that produced something no single domain view does: the same blockers, in the same places, regardless of which technology was on the table. Working directly with CTOs, I took those generic patterns and ground them against specific constraints, then carried back out whatever survived, sharper, and applied it to the next organisation. The frameworks are what accumulated in that loop.
Somewhere in there the work changed shape. Leading in a large matrix organisation means most of what you do isn’t deciding — it’s aligning. Getting leaders with genuinely conflicting incentives to commit to the same outcome, and discovering that the quality of that commitment depends almost entirely on how precisely the intent was expressed in the first place. It also changed the conversations I have with other leaders. The blocker in front of a CTO is rarely a technology question. It’s usually a decision nobody has made, an accountability nobody has placed, or an organisation still shaped for a problem it no longer has. Being able to say that in the room, without dressing it up as a technical finding, is most of the job.
I’ve never been good at adopting things whole. Every organisation has a canon — mechanisms that worked somewhere else, imported and applied as written. Amazon’s are among the best in the industry, which is exactly what makes them instructive: spend five years working with them and you learn to see which part of a mechanism is load-bearing, which part carries its culture with it, and which part quietly assumes a room that doesn’t exist everywhere else. The 2x2 prioritisation process is sound, and it still needed substantial extension before it worked in organisations without that data discipline behind it. The PRFAQ is a genuinely good artifact, and it presumes a reading ritual most companies don’t have — where that ritual is missing, I’ve had better results with Steve Pereira’s Outcome Map, which reaches alignment with less setup.
None of that is a verdict on the mechanisms. It’s the observation underneath all of my work: mechanisms don’t travel. Only the reasoning behind them does. Reconstructing that reasoning, for every framework worth taking seriously, is the habit this publication is made of. It hasn’t always been good for my career. It’s also the only reason I have anything of my own to publish.
So the reading list matters less than the verdicts. Marty Cagan, Mik Kersten, Skelton and Pais, Gregor Hohpe, Nicole Forsgren, Gene Kim, Steve Pereira, the Amazon mechanisms — I’ve taken something from each and left more behind. What’s here is what survived the cross-examination. The full list, with the verdicts attached, is on What This Is Built On.
North Star Architecture describes how platform and product architecture hold together. ACE explains why identical inputs produce opposite outcomes in two organisations. The Intent Lifecycle describes the operating loop underneath both. They were built for different questions and turned out to be about the same one: what happens to intent on the way to execution, and where it gets lost. Intent Architecture is the roof over them.
I got a lot of it wrong on the way. For most of a decade I treated organisational change as a downstream consequence of technology adoption — get the platform right and the org follows. It runs the other way, and the cost of that mistake is most of what I now write about. Some of what’s here will be wrong too. I’d rather publish an argument that can be corrected than a framework that can’t.
None of this is theory that later found an application. It’s the opposite: the same problem for twenty-five years, described a little more precisely each time.
Who this is for
Written for people who decide what gets built: CTOs, VPs of product and engineering, platform leaders, and the product people who find themselves responsible for outcomes rather than tickets.
It assumes you’ve run something real. There is no introduction to what an AI agent is.
Cadence
Roughly every other week, when a piece is finished. No weekly quota, no news roundups, no tool reviews. If a month is quiet, it means I’m writing something longer.
Everything is free. Subscribe and it arrives by email; the archive stays open either way.
Elsewhere
I also work with a small number of organisations on exactly these questions — operating models for product, platform and agentic delivery. If that’s relevant, reply to any post and it reaches me directly.
