Strategy

The multi-generational roadmap: why one-year technology plans fail

David ClinganJul 28, 20264 min read

Every January, technology organizations publish a twelve-month plan. By April it is fiction. Not because the teams are weak, but because the plan was built on three assumptions that never hold: that the estate is understood, that funding arrives on schedule, and that operations will politely pause while you modernize underneath them.

Technical debt breaks the first assumption. Debt is invisible in planning documents and very visible in delivery, and it compounds quietly until it decides your schedule for you. Funding cycles break the second: transformation spend rarely fits a single fiscal year, so annual plans quietly optimize for what can be finished by Q4 rather than what the business needs. And the third assumption fails hardest in environments that cannot stop - the engagement told in full on this site ran across hospitals, critical care, emergency care, and clinics, where "pause the systems while we upgrade" was never on the table.

Plan in generations, not quarters

A generation is a coherent state of the estate with its own purpose, not a time box. In practice I use three. The first exists to recover and stabilize: contain risk, restore trust in the platform, and stop the bleeding - without breaking the operation that pays for everything. The second exists to modernize: retire the debt deliberately, close compliance exposure, and sequence deployment so each move is reversible. The third exists to scale: lower the operating cost, and let the business grow on top of what is now solid.

"A roadmap is not a promise of features. It is a risk instrument the board can govern."

What makes it governable

Generations only work with governance attached: a small set of KPIs that describe posture rather than activity, executive reporting that says what moved and in which direction, and decision rights that are written down before they are needed. When the board can see risk falling, cost falling, and capability rising across generations, funding conversations change character - you are no longer defending a project, you are steering an instrument.

The test of a good roadmap is not whether it survives the year. It is whether, when something breaks - and something will - the plan tells you what to protect first. Annual plans rarely answer that. Generational ones are built around it.

AI

From AI pilots to production: the business-case discipline

David ClinganJul 14, 20264 min read

Ask an enterprise how many AI pilots it has run and you get a proud number. Ask how many are in production, owned by a named executive, with a measured effect on a P&L line - and the room goes quiet. Pilot purgatory is not a technology problem. It is a discipline problem, and it has three usual causes.

First, no one owns the number. A pilot with an enthusiastic sponsor but no owner accountable for a business outcome is a demo, whatever it costs. Second, demo-grade data: pilots run on curated extracts, then meet production data - late, inconsistent, and governed by systems nobody consulted - and die on contact. Third, governance arrives last. Access, auditability, and failure handling get designed after the pilot succeeds, which is exactly when nobody wants to slow down.

The business-case test

Before I fund any AI initiative, it has to answer three questions in one page. Which P&L line moves, and who owns it? What is the baseline today, measured, not remembered? And who has the right to kill it, at which checkpoint? If those answers do not exist, the initiative is research - which is fine, as long as it is funded and judged as research.

"A pilot you kill on evidence is a success. A pilot that lingers unowned is a tax."

What production actually requires

Getting from a working demo to production impact means four unglamorous things: a data contract with the systems the model depends on, an evaluation harness that runs continuously rather than once, a human override path that operations trusts, and unit economics that survive scale - because inference that is cheap at pilot volume can be ruinous at production volume.

Agentic AI raises the bar again. When systems take actions rather than produce answers, the governance questions stop being theoretical: what may it do, what must it never do, who is notified, and how is it stopped. I build the go-to-market for agentic offerings as well as the architecture, and the pattern holds on both sides of the table - the buyers who move fastest are the ones whose governance answers already exist.

Run fewer pilots. Own each one. And retire them proudly when the evidence says so - the portfolio gets stronger every time you do.

Security

Security is a plane, not a padlock

David ClinganJun 30, 20263 min read

The padlock model of security is easy to recognize: the work gets designed, then security is bolted on at the end - a gate, a review, a scan before release. It satisfies nobody. Delivery teams experience security as friction, security teams experience delivery as risk, and the audit still finds the gaps, because gaps live in the architecture, not at the gate.

The alternative is to treat security as a plane - a layer that crosses everything, the way it is drawn in the operating architecture on this site. It touches the growth motion, because enterprise buyers audit you before they trust you. It touches strategy, because risk posture is a board topic. It touches the application layer, where AI systems create new classes of exposure. And it touches the platform, where identity and segmentation actually live.

Zero-trust is an architecture, not a purchase

Zero-trust fails when it is bought as a product category and succeeds when it is designed as a posture: verify explicitly, grant least privilege, assume breach, and make the blast radius of any single failure small. None of that arrives in a box. It arrives through architecture decisions made early, which is why security has to sit inside the design conversation rather than at its exit.

"Security that is architected in closes deals. Security that is bolted on delays them."

Compliance as an operating rhythm

The same logic applies to compliance. ISO 27001 readiness treated as an annual scramble produces binders. Treated as an operating rhythm - controls owned by named people, evidence produced by the systems themselves, exceptions visible weekly - it produces something more valuable: a security story you can tell a customer's auditors without rehearsal. In enterprise sales, that story is worth real pipeline. I have watched security move from the objection list to the differentiation list in a single procurement cycle, purely because the posture was real and legible.

Draw security as a plane, fund it as a plane, and staff it as a plane. The padlock never protected much anyway.

Resilience

Ransomware: the first 72 hours, and the year after

David ClinganJun 16, 20264 min read

I have led an organization through ransomware recovery - the engagement is told in full on this site - and the clearest lesson is uncomfortable: the outcome is mostly decided before the attack, by choices leadership either made in advance or left for the worst possible moment.

The first 72 hours

Declare early. The organizations that fare worst are the ones that spend day one debating whether this is "really" an incident. Declaring costs little; delay costs options. Isolate what must be isolated, and accept the operational pain - half-measures preserve the attacker's position, not the business. Move leadership communication to channels you do not currently trust less, and assume the primary ones are read. Bring counsel and your insurer in immediately, because notification clocks and coverage conditions start running whether you acknowledge them or not. Preserve evidence even while restoring, or the questions you face later become unanswerable.

And the hardest one: know your position on payment before you are asked. That decision, made calmly in a boardroom months earlier - with counsel, with the insurer, with the board - is a policy. Made at 3 a.m. under threat, it is a coin flip.

"The 3 a.m. decisions should all have been made months earlier, in daylight."

The year after

Recovery is not the end state; it is the first generation of a longer plan. What follows, in order: rebuild identity as if it is compromised, because it probably is. Retire the technical debt the incident illuminated - the attack path almost always ran through systems everyone already knew were fragile. Close the compliance exposure while regulators are watching, not after they leave. Then sequence modernization so the estate that emerges is one you would defend by design, not by luck.

Two leadership behaviors matter throughout. Tell the truth inside the company early and often - rumor does more damage than fact. And run the exercise again next year, as a tabletop, with the executives in the room. An organization that has rehearsed its worst day is a different organization on that day.

Leadership

The fractional executive: when a full-time hire is the wrong answer

David ClinganJun 02, 20263 min read

There are gaps that need a permanent chair, and there are gaps that need eighteen months of executive-grade ownership. Confusing the two is expensive in both directions. A full-time hire made for a transformation window leaves you carrying a senior cost long after the window closes - or worse, leaves you, once the interesting work is done. A gap left open because "we are still searching" costs a year of drift at exactly the moment drift is most dangerous.

What fractional is, and is not

The fractional model exists for the second kind of gap. But the word has been diluted, so let me be precise about what I mean by it. A fractional executive is not an advisor who visits monthly and leaves a deck. The test is ownership: the fractional CTO owns the roadmap, the architecture decisions, and the board reporting. The fractional CGO owns the number, the pipeline, and the room. If the person in the seat cannot be held accountable the way an employee would be, you have bought consulting, not leadership.

"The test is simple: can you hold them accountable the way you would an employee?"

The exit is part of the job

A fractional engagement done well is self-terminating. From the first month, part of the mandate is building what makes the fraction unnecessary: the operating rhythm, the governance, the team - and eventually the successor. I consider hiring my own replacement a deliverable, not a threat. The organizations that get burned are the ones whose fractional leaders quietly become permanent dependencies at premium rates.

One more pattern worth naming: technology and growth gaps often arrive together, because they share a root - the company has outgrown its operating model. That is why I work both mandates. Whether one operator should hold both chairs depends on the company; that the two conversations must happen together is close to universal.

Hire full-time for the destination. Hire fractional for the crossing. And insist, either way, on someone who owns outcomes rather than opinions.

Innovation

Adopt, watch, ignore: a working filter for emerging technology

David ClinganMay 19, 20264 min read

The list of technologies you are told you cannot ignore never gets shorter. Quantum, edge, blockchain, agentic AI - each arrives with a conference circuit and a deadline. Most executive teams respond in one of two bad ways: adopt everything a little, which produces a museum of pilots, or ignore everything defensively, which works until the one that mattered ships in a competitor's product.

The working alternative is a filter, applied on a rhythm. I classify by maturity first - the bands on this site's technologies page: early research at five-plus years out, rapid growth at two to five, mainstream now, and the rare breakthrough that resets an industry's assumptions. The band sets the posture. You do not pilot five-year technology; you assign someone to watch it well. You do not "watch" mainstream technology; you are simply late.

Four questions before any adoption

Within the posture, four questions decide the money. Maturity: is this real outside its vendor's demos? Business fit: which of our problems does it solve better than what we run today? ROI: what is the measured case, against a baseline we trust? And reversibility: if we are wrong, what does unwinding cost? That last question is the one most teams skip, and it is the one that separates a bet from a trap.

"Ignoring well is a competency. It frees the capacity that adoption requires."

The filter, applied

Run today's list through it and the postures fall out cleanly. Quantum computing broadly: watch - but post-quantum cryptography is an adopt, because the migration is long and the deadline is not yours to set. Edge computing: adopt narrowly, wherever latency or bandwidth is already costing you money - real-time inspection, industrial IoT - and nowhere else. Blockchain: adopt in the thin slice where shared, tamper-evident records between parties who do not trust each other is genuinely the problem - traceability is the honest case - and ignore the rest without apology.

Then run the survivors through the same four steps every time: assess, pilot with a kill switch, scale with risk mitigation, optimize. The framework is boring by design. Boring is what discipline looks like from the outside - and discipline, not enthusiasm, is what turns emerging technology into advantage.