I spent a good part of my career as an Enterprise Architect before moving into practice leadership, and people occasionally ask what actually changes when you make that move — beyond the obvious title and scope. It’s a fair question, and it took me longer than I’d like to admit to answer it honestly, because the shift is less about skills and more about what you’re optimizing for.
From the right answer to the right outcome
As an architect, your job is fundamentally about correctness: the right pattern, the right platform choice, the right tradeoff between cost and scalability, defensible against scrutiny. It’s intellectually satisfying work, and I don’t think you can lead a technology practice well without having done it. But a Practice Head isn’t graded on whether an individual architecture decision was correct — they’re graded on whether a few thousand people, across dozens of client engagements, are consistently delivering outcomes clients are willing to pay for again. That’s a different optimization target, and it took me a while to stop reflexively reaching for the architect’s toolkit when the actual problem was organizational, not technical.
Your best technical instinct becomes a liability if you don’t manage it
The hardest habit to unlearn was the urge to personally solve the hard technical problem in front of me. Scaling a practice to 1,200, then 2,500 consultants meant the honest answer to “can I just fix this myself” became “yes, and that’s exactly the wrong move.” Every hour I spent personally solving one client’s architecture problem was an hour not spent building the process, the talent pipeline, or the delivery standard that would let 50 other engagements solve their own version of that problem without me. Letting go of that instinct — not the skill, the instinct to personally intervene — was the single biggest unlock in that transition.
RFPs teach you what architecture reviews don’t
Running through enough competitive RFPs (a 45% win ratio across a large volume of enterprise bids will teach you this whether you want it to or not) exposes a pattern architecture work rarely does: clients rarely buy the technically superior proposal. They buy the proposal from the team they believe will actually deliver, communicate honestly when something goes wrong, and still be there in year three. Technical credibility gets you into the room. It’s rarely what wins the deal once you’re in it.
What actually transfers
The architecture discipline doesn’t disappear — it becomes the thing that lets you ask sharper questions of the people now doing that work for you, and to smell a bad technical decision three levels down before it becomes a client escalation. That’s the real throughline from Enterprise Architect to Practice Head: you stop being the one who finds the right answer, and you spend your time building the conditions where more people can find it themselves, faster, and at a scale one person never could.