The CTO's Real Job in a Digital Transformation

The most common misunderstanding about the CTO's role in a digital transformation is that it is a technology job. It is not. It is a translation job.

The business has ambitions it cannot articulate in technical terms. The technology teams have constraints the business does not understand. The CTO sits between them and translates in both directions. When the translation works, the transformation delivers. When it fails, the organisation spends two years and a large budget building something the business did not ask for.

This piece is for CTOs, CIOs and technology leaders in the middle of a transformation programme who feel the gap between what the business wants and what the technology teams are building.

The short version

The CTO's job in a digital transformation is to translate between business intent and technical reality. This means making trade-offs visible, killing projects that will not deliver, and protecting the teams from scope that changes every board meeting.

• The CTO translates business goals into technical decisions and technical constraints into business language.
• The most valuable skill is saying no to work that sounds important but will not deliver.
• Protect your teams from shifting priorities by agreeing on outcomes, not features.
• Measure transformation progress in business outcomes, not technical outputs.
• The transformation will take longer than the board expects. Say so early.

This article sits inside the digital transformation advisory cluster, where the wider argument is set out in full.

What translation actually looks like

The CEO says: we need to be more customer-centric. The CTO has to figure out what that means in practice. Does it mean a new customer portal? A unified customer view across systems? Faster response times? All of the above?

The translation job is to take a vague strategic direction and turn it into specific, measurable technical decisions. "Customer-centric" might translate to: build a single customer record that combines data from the CRM, the support system and the billing platform, accessible through a single API, within twelve months.

That translation makes the goal testable. Either the single customer record exists at the end of twelve months or it does not. Either the API works or it does not. The business can see what they asked for; the technology team can see what they need to build.

The reverse translation is equally important. When the integration team discovers that the billing platform has no API and the data model is incompatible with the CRM, the CTO has to explain this to the business without using the words "API" or "data model." The translation might be: connecting the billing system will take six additional months because the billing system was never designed to share data with other systems, and we need to build that capability first. Do you want to wait, or do you want a partial customer view sooner that excludes billing data?

That is a business decision, not a technical one. The CTO's job is to frame it as a business decision.

Should your organisation do this now?

• Yes, if your transformation programme has a technology roadmap but no clear mapping to business outcomes.
• Not yet, if you have not agreed on the three business outcomes the transformation must deliver.
• Instead, first: get the business to commit to three measurable outcomes.
• Measure it by: whether every technical workstream can trace back to a business outcome.

The art of saying no

The highest-value activity a CTO performs in a transformation is stopping work that will not deliver.

Every transformation accumulates scope. A board member sees something at a conference. A business unit wants their pet project included. A vendor presents a solution to a problem nobody has. Each addition seems reasonable in isolation. Together, they dilute focus, stretch teams and extend timelines.

The CTO is usually the only person in the room who can evaluate whether a proposed addition is technically feasible within the current timeline and budget, and whether it serves the agreed business outcomes. That evaluation often results in a no, and delivering that no in a way that is heard rather than resented is a core skill.

Three principles for saying no productively:

1. Reference the agreed outcomes. "Does this serve one of our three agreed outcomes? If not, it belongs in a future phase." 2. Show the trade-off. "We can add this, but it delays the customer portal by three months. Which do you prefer?" 3. Offer the minimum viable version. "The full version takes six months. A version that covers eighty per cent of the value takes six weeks. Shall we start there?"

The worst thing a CTO can do is say yes to everything and let the timeline slip silently. That is how transformations fail — not with a dramatic failure but with a slow, quiet erosion of focus.

Protect your teams from the board calendar

Transformation programmes are typically governed by quarterly board reviews. This creates a cadence problem: the board wants visible progress every three months, but meaningful technical work does not always produce visible results on that schedule.

A data migration, a system integration or a security overhaul might take six months with nothing to show after three. If the CTO does not manage expectations, the board loses confidence, and the programme gets restructured, rescoped or cancelled.

Two strategies I use:

Decompose work into demonstrable increments. Even a six-month data migration can be broken into: month two, sample data migrated and validated in the new system; month four, full data migrated in a test environment; month six, production migration complete. Each milestone is demonstrable even if the final result is not.

Separate the progress narrative from the feature list. Boards think in features: can I see the new portal? But progress is often in capabilities: we now have a single customer record. Frame updates in terms of capabilities delivered, not features launched.

Should your organisation do this now?

• Yes, if your transformation board reviews focus on feature demonstrations rather than capability milestones.
• Not yet, if your programme is less than three months old and still defining scope.
• Instead, first: define the milestone map that shows demonstrable progress at each review.
• Measure it by: whether the board can describe what the transformation has delivered without mentioning a feature.

Outcomes, not features

The single biggest mistake I see in transformation programmes is measuring progress in features delivered rather than business outcomes achieved.

Features delivered is a technology metric. It tells you the team is busy. It does not tell you the transformation is working.

Business outcomes are what the transformation was funded to achieve: revenue growth from a new channel, cost reduction from automated processes, customer retention improvement from better service, regulatory compliance from better data management.

Every technical workstream should trace back to one of these outcomes. If a workstream cannot trace back, it is either unnecessary or its connection to business value has not been made explicit.

I require every workstream lead to complete a one-sentence outcome statement: "This workstream will [outcome] by [mechanism] and we will know it worked because [measure]." If they cannot complete the sentence, the workstream needs to be re-examined.

The timeline conversation

Digital transformations take longer than boards expect. There are two approaches to this reality: absorb the pressure and adjust quietly, or have the conversation early.

I recommend the conversation. A CTO who says "this will take three years, and here is why" in month three is more credible than a CTO who says "we need another year" every year for three years.

The timeline conversation should cover:

• What the transformation actually involves. Not the vision — the work. How many systems are being replaced. How much data is being migrated. How many processes are changing. How many people need to be trained.
• Where the dependencies are. Which workstreams depend on others. Where external vendors control the schedule. Where regulatory approvals are needed.
• What the realistic risks are. Not hypothetical risks — the specific things that have already slowed similar programmes in this organisation.
• What the phased delivery looks like. Business value delivered in phases, so the organisation gets returns before the full programme is complete.

Before you start translating

Checklist:

• Three business outcomes agreed with the CEO and the board, stated in measurable terms.
• Outcome statement completed for every technical workstream.
• Milestone map showing demonstrable progress at each board review.
• Scope management process with clear criteria for adding or removing work.
• Realistic timeline shared with the board, including dependencies and risks.
• Named CTO or technology lead with authority to prioritise and deprioritise workstreams.

Questions to ask:

• Your CEO: if the transformation delivers only one thing, what must it be?
• Your board: what does success look like in twelve months, not three years?
• Your workstream leads: can you state your workstream's business outcome in one sentence?
• Your programme manager: which workstreams are on the critical path, and which have slack?
• Your teams: what is slowing you down that leadership does not know about?

How to measure it

• Outcome delivery. Progress toward each of the three agreed business outcomes. Baseline: pre-transformation. Owner: business outcome sponsors. Review: quarterly. Leading.
• Scope stability. Number of scope changes per quarter. Baseline: first quarter. Owner: programme manager. Review: quarterly. Leading.
• Workstream traceability. Percentage of active workstreams with a clear outcome statement. Baseline: first audit. Owner: CTO. Review: quarterly. Leading.
• Timeline accuracy. Actual milestone delivery versus planned. Baseline: original plan. Owner: programme manager. Review: quarterly. Lagging.
• Business value delivered. Cumulative value from completed phases. Baseline: zero. Owner: finance with CTO. Review: semi-annual. Lagging.

Mistakes that cost the most

Letting the business define the solution

The business says "we need Salesforce" when they mean "we need better customer visibility."

• Why it happens: the business picks the tool because they saw a demo.
• Prevention: translate the request into an outcome and evaluate options.
• Early warning: the RFP is for a specific product, not a capability.

Saying yes to everything

Scope grows because the CTO does not want to be the obstacle.

• Why it happens: saying no feels like blocking the business.
• Prevention: frame every no as a trade-off, not a refusal.
• Early warning: the programme roadmap has grown by more than twenty per cent since approval.

Hiding the real timeline

The CTO knows the timeline is unrealistic but adjusts quietly.

• Why it happens: delivering bad news feels career-threatening.
• Prevention: present the realistic timeline early with evidence.
• Early warning: milestones are being redefined rather than met.

What to do next

Write down the three business outcomes your transformation is supposed to deliver. Then check whether every active workstream can trace back to one of them. Kill or pause any that cannot. Then read the related piece on measuring digital transformation metrics and the digital transformation advisory topic page.

Last reviewed: 14 October 2026.

Views are my own and do not represent my employer.