Studying how the world’s top executives make decisions, you start to notice patterns that have very little to do with industry, company size, or technology stack. What stands out is the rigour they apply to their own decision-making, the same rigour most enterprise architects reserve exclusively for the systems they design. EA work sits at a strange intersection. We’re technical enough to understand the systems, commercial enough to translate them into business value, and senior enough to influence strategy, yet the craft of deciding well rarely gets the same attention as the craft of designing well. Here’s what we can borrow from the executives who’ve made it their discipline.
The best CEOs invest heavily in what might be called the “North Star”, a compelling answer to the question: what are we actually for? Not a mission statement crafted by committee, but a genuine narrative that reframes how success is measured, influences every resource decision, and gives people a reason to behave differently. Nelson Mandela and François Pienaar didn’t coach South Africa’s rugby team to win a World Cup. They gave them a reason to play that made winning feel secondary to something larger. The team played differently as a result.
Enterprise architects face a version of this problem every time we present a target state architecture. We often lead with the technology, the Kubernetes cluster, the event-driven backbone, the API gateway layer, and leave the “why this, why now, why should anyone care” for slide 14. That’s backwards. Before presenting any architecture proposal, write one paragraph, not a slide, that answers: what does success look like for the business in three years, and why does this architecture enable it specifically? If you can’t write that paragraph, the proposal isn’t ready.
The CEOs who build durable change do so because they connect the technical to the meaningful. They find the intersection between organisational capability and a future the organisation actually wants to inhabit. Our job, as architects, is to do the same: translate systems thinking into a story with genuine stakes.
DuPont’s CEO Ed Breen has a habit that every architect should steal. Before committing to any major decision, he asks one question obsessively: what does the downside look like, and can I live with it? Not the expected outcome. Not the best case. The downside. Jamie Dimon at JPMorgan goes further, describing decision-making as toppling dominoes, the first is easy to push, but you need to trace every subsequent one before you commit. If any downstream outcome is company-threatening, regardless of its probability, you choose a different path. Full stop.
This is, in essence, risk architecture applied to strategy. And it’s something we rarely do systematically in EA work. We model the happy path. We document the target state. We sometimes note risks in a RAID log. But we seldom sit down and ask: if this migration goes badly, which scenario would we actually be unable to recover from? And are we designing for that scenario, or just hoping it doesn’t happen? For every major architecture initiative, it’s worth running a “reverse architecture review”: map the failure modes first, not the capabilities. Define which failure mode is unacceptable, and make that the constraint your design must satisfy before you optimise for performance, scalability, or cost.
Adobe’s shift to cloud subscriptions is the canonical example of this discipline executed well. Shantanu Narayen’s team spent hours in the boardroom stress-testing pricing models, unit economics, and the rate at which perpetual license revenue would decline. They weren’t confident, they were prepared. There’s a significant difference, and it shows in the outcome.
Among the most underappreciated habits of elite executives is how they manage investment portfolios. They don’t release budgets on an annual calendar cycle. They release them against performance milestones: prior investment must produce demonstrable results before the next tranche is unlocked. This sounds obvious. In practice, it is routinely ignored in large technology programmes. Platform teams get multi-year budgets approved upfront. Workstreams are funded annually regardless of delivery evidence. Architecture decisions made in year one persist into year three because no one built in a formal checkpoint to ask: is this still the right call?
The discipline here is separating “continue” from “complete.” At each milestone, the question isn’t whether the programme is done, but whether it should continue. The bar is different, and it keeps teams honest about value delivery. DuPont reviews major programmes one year after completion, something EA teams almost never do. Without retrospectives, patterns of poor decision-making compound silently across initiatives.
Danaher’s Larry Culp offers the sharpest framing: he consistently asked what a new CEO with no emotional attachment to the portfolio would do. EAs should ask the same of their architecture. Is this still the right platform, or are we maintaining it because we built it? Thinking like an outside investor, rather than an internal custodian with sunk costs to defend, is one of the harder mental shifts in the discipline, and one of the most valuable.
Research consistently shows that only one in three strategies is successfully implemented, and that 72% of the obstacles are human and cultural, not technical. Peter Drucker put it plainly: “Culture eats strategy for breakfast.” Enterprise architects tend to believe that if the architecture is sound, adoption will follow. It won’t. The most technically elegant architecture I’ve seen fail did so not because of a bad design choice, but because the teams on the receiving end didn’t trust the process, didn’t understand the rationale, and didn’t feel ownership over the outcome.
Satya Nadella’s transformation of Microsoft is instructive here. He didn’t lead with the technology strategy. He led with a cultural reframe, “Growth Mindset,” rooted in Carol Dweck’s research, which gave the organisation a way to think about failure, learning, and collaboration that made the technical changes feel coherent rather than imposed. The cultural shift was designed before the technical one was deployed, not as an afterthought.
For EAs, this means the real deliverable of any major architecture initiative isn’t the target state diagram. It’s the shared understanding, across engineering, product, operations, and leadership, of why the architecture makes sense and what it enables. Culture put in place through genuine consultation, not broadcast from above, is what makes technical transformation durable. If that shared understanding doesn’t exist, no amount of documentation will substitute for it.
The most effective executives share a consistent discipline: tracking technological and market shifts early enough to invest before they become conventional wisdom. DSM’s Feike Sijbesma describes a practice of reading across disciplines, including subjects apparently unrelated to his industry, and building networks across business, science, and society, specifically to surface insight that siloed thinking would miss. Netflix’s trajectory makes the same point structurally. The DVD-by-mail service was never the end state; it was the cash-generating beachhead that funded the bet on streaming. Reed Hastings didn’t wait for streaming to be proven. He invested into uncertainty, absorbed the short-term criticism, and held the position.
Enterprise architects are increasingly expected to play this role, not just designing for current requirements, but anticipating the architectural implications of AI adoption, regulatory change, data sovereignty shifts, and the ongoing fragmentation of the vendor landscape. The temptation is to anchor too close to present-state thinking: what does the organisation need today? That question is necessary but not sufficient. A better question is: what is becoming true in the industry that our architecture is not yet positioned for?
The goal isn’t prediction, it’s positioning. An architecture that can absorb an AI-native workflow, a new data residency requirement, or a major vendor consolidation without requiring a full re-platform is one that has done this work. Building a deliberate horizon-scanning practice into your working rhythm doesn’t require a formal framework. It requires the discipline of reading outside your stack, maintaining networks outside your organisation, and setting aside time each quarter to surface what’s changing before it becomes obvious.
The thread connecting all of these behaviours is a single disposition: acting like an owner. It means making decisions as though you are the full proprietor of the enterprise, unbounded by political constraints, undistracted by short-term optics, accountable to the long-term value of the whole. Enterprise architects rarely think of themselves this way. We think of ourselves as advisors, as enablers, as the people who make the technical trains run on time. That framing keeps us safe, but it also keeps us peripheral. The executives who drive lasting change refuse to be peripheral to their own organisations.
The architecture function is most powerful when it occupies the same posture: opinionated about outcomes, not just about designs. Willing to say “this is the wrong direction” and defend it with evidence. Accountable for what gets built, not just for the blueprint that preceded it. The lesson from the best executives isn’t a set of techniques, it’s a stance. And it’s one worth consciously adopting.