After ten years shipping technology inside reinsurers, energy companies, and industrial conglomerates — organisations where a wrong decision costs seven figures before lunch — I've built a personal operating system that I now apply in every engagement. It is not a framework with a name. It is a set of principles, sequenced, that took me a decade of expensive mistakes to distil.
The central discovery: enterprise organisations don't fail to ship because their engineers can't code. They fail to ship because the human and political infrastructure around the engineering is broken. Fix the infrastructure. The code takes care of itself.
The Context That Shapes Everything
I want to be honest about what "enterprise" means in this context, because it affects everything that follows. I'm not talking about a 200-person SaaS company that calls itself enterprise because it sells to procurement teams. I'm talking about:
- A global reinsurer where a miscalculated risk model affects balance sheets across three continents.
- An energy grid operator where software failure has physical safety consequences.
- An automotive manufacturer where a platform decision locks in a supply chain for seven years.
In these environments, the cost of a mistake is not a sprint retrospective and a changed user story. It is a regulatory investigation, a board conversation, sometimes a headline. The incentive system is therefore heavily weighted toward caution. Moving fast breaks things that cannot be easily fixed. The political cost of a visible failure exceeds the political cost of slow delivery by a wide margin.
Understanding this is Principle Zero — the one that makes all the others make sense. You are not trying to make enterprise organisations think like startups. You are trying to help them move at the maximum safe velocity given their actual risk profile. Those are very different ambitions.
Principle 1: Alignment First, Architecture Second
Every failed enterprise technology programme I've been called in to rescue had a technical diagnosis offered first: the wrong stack, the wrong vendor, the wrong architecture pattern. In almost every case, the technical diagnosis was wrong. The real problem was misalignment — between business and technology on what success looked like, between the programme sponsor and the programme team on scope, or between senior stakeholders who each believed they were the decision-maker.
Technical problems in enterprises are almost always political problems in disguise.
The first thing I do in any new engagement — before looking at a line of code, before reviewing the architecture, before meeting the engineering team — is map the stakeholder landscape. Who has approval authority? Who has blocking authority even without formal approval? Who is invested in the status quo? Who has tried to change this before and failed, and what did that failure teach them?
I use a simple two-axis map: influence on the x-axis, alignment on the y-axis. The stakeholders in the high-influence, low-alignment quadrant are the engagement. Everything else is execution.
| Quadrant | Stakeholder Posture | Your First Move |
|---|---|---|
| High influence, high alignment | Champions — protect and leverage them | Give them visibility into progress; let them carry the message |
| High influence, low alignment | Blockers — your primary focus | Understand the objection; address the concern, not the position |
| Low influence, high alignment | Supporters — useful but not decisive | Keep them informed; use them as social proof with blockers |
| Low influence, low alignment | Noise — manage minimally | Don't invest disproportionate time; don't antagonise |
The instinct of most technology leaders entering a new enterprise context is to demonstrate technical competence immediately — to show the architecture diagram, propose the roadmap, explain the delivery methodology. Resist this. The technical credibility comes from showing you understand the political landscape before proposing solutions to it. People trust the person who saw the real problem, not the person who had the fastest answer.
Principle 2: Ship Something in 90 Days or You Won't Ship Anything
Enterprise programmes have a consistent failure mode I call "the long runway." The team spends 6 to 18 months in design, procurement, governance, and planning. By the time any code reaches production, the business context has shifted, the stakeholders who commissioned the work have changed roles, and the programme has no remaining political capital to absorb normal delivery bumps.
The 90-day rule is not about shipping the final product. It is about shipping something real — something that runs in production, touches real data, and produces a result someone outside the engineering team can observe and validate. The goal is to produce evidence before the organisation loses patience.
In practice, this means aggressive scope reduction at the start of every engagement. I almost always fight for a smaller first delivery than the one the business has in mind. The typical negotiation sounds like this:
"You want to deliver the full underwriting platform in 18 months. I want to deliver the pricing module in 90 days. Not because the full platform isn't the goal — it is — but because in 18 months the budget will be under pressure, three of your sponsors will have different jobs, and the vendor you're betting on will have pivoted twice. In 90 days, you'll have something in production. That changes every subsequent conversation."
The political value of a production deployment
A working deployment is a political asset in enterprise organisations, not just a technical milestone. It proves that the team can ship. It proves that the architecture works. It creates a real artefact that stakeholders can interact with, which is infinitely more persuasive than a slide deck. I've used early production deployments to unlock budget, to neutralise sceptical stakeholders, and to reset a programme's credibility after a rocky start. The code almost doesn't matter — the fact of production is what matters.
Principle 3: The Architecture Must Fit the Organisation, Not the Textbook
Enterprise organisations are not greenfield projects. They have existing systems — some of them decades old — that cannot be replaced on any timeline relevant to the current programme. They have vendor contracts, technology standards committees, security and compliance requirements, and infrastructure teams that move at their own pace.
The architecture that looks elegant on a whiteboard is worthless if it requires integration with a system the organisation isn't ready to touch, or depends on a cloud capability that's not yet approved in the security framework, or needs deployment velocity that the current CI/CD pipeline cannot support.
I've learned to design for the organisation as it is, with a migration path to where it should be. Not as a compromise of quality — as a recognition that software architecture exists inside a sociotechnical system, and ignoring the "socio" part produces beautiful designs that never run in production.
The questions I ask before finalising any enterprise architecture:
- What systems does this touch that I cannot change in this programme's lifetime?
- What security and compliance reviews does each architectural decision require, and how long do those reviews take?
- Which team will own this in production after I leave, and can they operate the architecture I'm proposing?
- What happens when the person who designed this system leaves? Is the knowledge transferable?
The last question is the one most architects skip. In enterprise organisations, knowledge transfer failure is a first-order risk. Systems that require a specific expert to operate are systems that produce incidents at the worst possible moments.
Principle 4: Write the Boring Post-Mortem Before the Incident
High-stakes environments punish reactive operations. An incident at a reinsurer during peak renewal season, at an energy company during grid stress, or at an automotive manufacturer during a product launch is not a technical problem — it is a business crisis, sometimes a regulatory one. The difference between a bad incident and a catastrophic one is almost always preparation.
I establish three things in the first month of every engagement, before any production deployment:
A defined incident response process. Named roles. A communication channel. An escalation path. A template for what gets communicated to whom, and when. This is not complex. It is one document. But it needs to exist before the incident, not during it.
Runbooks for the five most likely failure scenarios. Not comprehensive runbooks. Five good ones. The scenarios come from the architecture — where are the single points of failure, the external dependencies, the data paths most likely to produce unexpected load? Write the runbook for each. Test it in a simulated incident before you need it for a real one.
A post-incident review culture that produces written output. The review is not a blame session. It is a structured analysis: what happened, what was the impact, what immediate action stopped it, what systemic change prevents recurrence. The written output is the point — Slack threads decay, written reviews accumulate into institutional knowledge.
In ten years I have never had a client say "we did too many runbooks." I have had dozens say "we wish we'd done the runbooks before that incident."
Principle 5: Protect Engineering from the Organisation
This sounds paradoxical in an essay about enterprise technology leadership. It is the most important principle.
Large organisations generate enormous demand for engineering attention. Stakeholders want demo environments, custom reports, integrations with tools they just bought, fixes for problems that aren't the programme's remit, and input on decisions that don't need engineering input. A team that responds to all of this demand produces none of the work the programme was commissioned to deliver.
The CTO or engineering lead's job is to be the membrane between the organisation's demand and the team's capacity. Not to block legitimate business requests — to filter, sequence, and buffer them so that engineers can work at the depth that complex software requires.
In practice, this means:
- A single intake channel for requests. Not email to individual engineers. One place, one person reviewing it, one decision about priority.
- A protected block of engineering time — I typically aim for 70% — that is not accessible to ad hoc requests regardless of stakeholder seniority.
- A bias toward saying "not in this sprint" rather than "never." The answer "that's not on the current roadmap, and here's when we can discuss it" is more useful than a full stop.
The always-available engineer is always behind
There is an enterprise management pattern where availability is treated as professionalism and deep work is treated as anti-social. Engineers who respond immediately to every Slack message, attend every meeting they're invited to, and help with every ad hoc request look like strong performers to non-technical managers. They are, in fact, the least productive people on the team — and they're the pattern that senior engineers notice, and leave to avoid.
Principle 6: Build for the Day You Leave
In fractional and interim work, the end is always visible from the beginning. The question is not "what do I build?" but "what does the organisation need to be able to do without me in 6, 12, or 18 months?" Every decision should be legible to that future state.
This changes how I make decisions. I over-document not because I'm building a bureaucracy, but because the person who inherits this needs to understand it without a call to me. I write Architecture Decision Records for every consequential choice — not as a process artefact, but as a letter to the team that comes after. I build practices that require no individual to maintain, because individual-dependent practices are time-bombs.
The test I apply to every decision: if I'm hit by the proverbial bus tomorrow, what happens to this? If the answer is "the team is stuck," the decision is wrong regardless of its technical merit.
| Decision Type | Question I Ask | Red Flag |
|---|---|---|
| Architecture choice | Can the team that will own this operate it without me? | Only I understand why this was chosen |
| Process design | Does this survive a 50% team turnover? | The process requires specific people to function |
| Tooling selection | Is the documentation sufficient for a new hire to use this? | The tool is only usable because I configured it |
| Vendor relationship | Does the contract reflect terms the organisation understands? | The relationship is informal and person-dependent |
| Roadmap planning | Does the next CTO have enough context to continue or change direction? | The roadmap exists only in my head |
What This Adds Up To
The operating system is simpler than it sounds:
- Align the humans before touching the architecture.
- Ship something real within 90 days, always.
- Design for the organisation as it is, not as it should be.
- Prepare for incidents before they happen.
- Protect the team from the organisation's demand.
- Build for the day you leave.
None of these are technically sophisticated. Every one of them took me years of expensive, painful experience to internalise. The organisations that operate closest to this system — whether by design or cultural evolution — ship more, operate more reliably, and retain their best engineers longer. The ones that don't are the ones I get called in to help.
The last thing I'll say: every principle on this list is a generalisation. The specific application requires reading the specific organisation — its history, its politics, its failure modes, its tolerance for change. That reading is the work. The principles are the scaffold. What you build on the scaffold is always, ultimately, particular.
If you're leading technology in a large organisation and recognise any of this — either because you've lived the failure modes or because you're trying to build something different — let's talk. I work with CTOs, engineering VPs, and boards as a fractional or interim partner, and this operating system is what I bring to every engagement. Book a 30-minute discovery call.