Transformation Leadership: PMO, CTO, and Chief Transformation Officer Roles
Avery Brooks
May 27, 2026
Most transformation programs have clear leadership at the top and clear accountability at the project level. What they don't have is someone who owns what happens to knowledge in between.
The project management office tracks timelines and budgets. The executive sponsor sets strategy and clears roadblocks. The Chief Transformation Officer - when one exists - orchestrates across functions. But none of these roles owns the question that determines whether transformations succeed or fail: does operational knowledge flow from one phase to the next?
The "Transformation Knowledge Gap" - the failure of knowledge to move from discovery to design to delivery to adoption - is fundamentally a leadership accountability problem. It's not that teams don't generate knowledge. It's that nobody is accountable for ensuring that knowledge survives the handoffs between phases and between teams.
This article maps the three leadership roles that transformation programs depend on, explains how each one typically operates, and describes what transformation leadership needs to look like when knowledge continuity is treated as a first-class accountability.
Organizations don't fail to create transformation knowledge. They fail to protect it.
The traditional project management office was designed to solve the problems of the 1990s: cost overruns, missed deadlines, scope creep. It is exceptionally good at tracking milestones, enforcing governance, and reporting status upward. What it is not designed for is the messy, contextual, informal work of preserving how operational knowledge flows between teams.
PMOs operate through structured reporting, stage gates, and status updates. Knowledge continuity doesn't live in status updates. It lives in the informal conversations that discovery teams had with frontline staff, the constraints that delivery teams discovered but didn't document, the workarounds that adoption teams are unaware of because nobody told them.
A PMO can tell you a phase is complete. It cannot tell you whether the knowledge from that phase transferred meaningfully to the next one.
The Chief Transformation Officer (CTO) role has grown significantly in the past decade. Organizations that deploy a dedicated CTO achieve an average of 24% more of their planned transformation value compared to programs without one. The CTO coordinates across functions, maintains strategic direction, and ensures that individual initiatives connect to overall business objectives.
But the CTO typically operates at the executive and cross-functional level. The operational reality - the informal workflows, the undocumented dependencies, the frontline constraints that shape whether a transformation will actually work - lives four or five layers below where the CTO sits.
The CTO knows the strategy. They often do not know that three teams in one region have developed a workaround that the new system cannot replicate, or that a key integration assumption made during design was wrong, and delivery discovered this six weeks ago without flagging it.
Many organizations have established transformation management offices (TMOs) alongside or in place of traditional PMOs. But the TMO is frequently treated as an upgraded PMO - more strategic, more cross-functional, but still fundamentally focused on delivery tracking and governance rather than knowledge continuity.
The organizations that get the most from their TMO treat it differently. They treat it as what Grant Thornton has called "corporate memory" - an institutional function that maintains the intelligence gathered across all phases of a transformation, not just the status of its milestones.
Discovery teams own discovery. Design teams own design. Delivery teams own delivery. Adoption teams own adoption. But nobody explicitly owns the transitions between them. Nobody is accountable for the question: "What did discovery know that design needs to know?" or "What did delivery discover that adoption is depending on being true?"
This accountability gap is where most knowledge loss happens. Not because teams are careless, but because nobody's job description includes protecting knowledge across phase transitions.
The organizations that consistently deliver transformation value - the ones that move from the industry average of 30% success to 70% and above - have restructured their leadership around three distinct functions that work in coordination.
The CTO role is not primarily an execution role. It is a continuity role. The CTO ensures that the transformation program stays connected to its strategic intent as it moves through phases, that business priorities are reflected in delivery decisions, and that the organization doesn't drift from its original objectives when facing delivery pressure.
What distinguishes high-performing CTOs from average ones is not their authority - it's their visibility into operational reality. Effective CTOs maintain direct lines into discovery findings, delivery blockers, and adoption signals. They are not surprised by what frontline teams are encountering, because they have structured mechanisms to surface that information.
The CTO is not an upgraded project manager. They are a bridge between strategic intent and operational truth.
The TMO is not a governance function. It is a knowledge architecture function. Its job is to ensure that the knowledge generated at each phase of a transformation is captured, contextualized, and transferred to the next phase.
In practice, this means the TMO maintains the institutional memory of the transformation: why decisions were made, what evidence informed them, what constraints were discovered, and what assumptions turned out to be right or wrong. As outlined in "Building a Living Transformation System," this requires more than documentation - it requires a deliberate system that makes knowledge navigable and actionable at each phase.
The TMO that only tracks deliverables is not serving the transformation. The TMO that tracks knowledge - what was learned, what was captured, what was transferred - is what the transformation actually needs.
Between the strategic CTO and the institutional TMO, there needs to be a role that operates at the operational level: the Knowledge Steward. This is not necessarily a new headcount; it is an accountable role within the transformation program.
The Knowledge Steward's mandate is narrow and specific: ensure that knowledge does not get lost at phase transitions. In practice:
The Knowledge Steward role can be held by a senior business analyst, a program manager with deep operational context, or a dedicated transformation knowledge lead. What matters is not the title - it is the accountability.
Transformation leadership works when three layers are operating in coordination, each owning a distinct function.
Step 1: Establish Strategic Continuity at the C-Suite Level
Appoint or designate a CTO (or equivalent) with explicit accountability for maintaining the connection between transformation strategy and operational reality. This person needs regular structured access to discovery findings, delivery signals, and adoption metrics - not filtered through status reports, but through direct operational visibility.
Step 2: Structure the TMO as a Knowledge Architecture Function
Reposition the TMO from a delivery governance function to a knowledge architecture function. The TMO maintains the transformation's institutional memory: decisions made, evidence gathered, assumptions logged, constraints documented. This is not a documentation library. It is an active function that identifies when knowledge is at risk of being lost and intervenes before phase transitions.
Step 3: Appoint Knowledge Stewards for Each Phase Transition
For each major phase boundary - discovery-to-design, design-to-delivery, delivery-to-adoption - designate a Knowledge Steward accountable for the handoff. The steward prepares a structured handoff document, briefs the incoming team, and remains available for questions during the first four weeks of the next phase. Once the knowledge is confirmed as transferred, the steward's mandate for that transition ends.
Step 4: Build Governance Around Knowledge Transfer, Not Just Deliverables
Stage gates should include knowledge transfer checkpoints. Before a project moves from discovery to design, governance should require a confirmed knowledge transfer: what did discovery find, and does design acknowledge it? Before delivery begins, governance should require confirmation that design assumptions are understood and accepted by delivery leads. These aren't bureaucratic additions. They are the specific checkpoints that prevent knowledge loss at phase boundaries.
For organizations launching or restructuring transformation programs, the sequence matters.
In the first 30 days, focus on establishing accountability. Designate a CTO or transformation sponsor with explicit knowledge continuity accountability. Assess the current TMO mandate - if it is primarily tracking delivery, add a formal knowledge architecture function alongside it. Identify the Knowledge Steward candidates for the first phase transition.
In days 30 to 60, build the infrastructure. Establish the knowledge capture templates and governance checkpoints. Build the phase-transition briefing process. Ensure the CTO has direct visibility into operational discovery findings - not filtered status updates, but the actual evidence from frontline interviews and discovery activities.
In days 60 to 90, run the first knowledge transfer and measure it. At the end of the first major phase, execute the Knowledge Steward-led handoff. Ask the incoming team: what did you learn from the previous phase that changed your assumptions? If the answer is "nothing," the handoff didn't work. If the answer reveals new information and recalibrated decisions, the transfer worked.
The business case for restructuring transformation leadership around knowledge continuity is direct.
Fewer late-stage surprises. When knowledge flows from discovery through design and delivery, the constraints and dependencies that would otherwise surface as late-stage surprises are known early. Late-stage risk discovery forces organizations to choose between rework, scope cuts, or accepting quality compromises. Early knowledge transfer gives organizations options.
Reduced rework costs. Industry data shows that failed lift-and-shift implementations require 60-80% rework when underlying process logic isn't understood. Organizations that structure handoffs around knowledge transfer dramatically reduce this rework because delivery teams understand what they're building before they build it.
Faster adoption. Adoption teams that know what was actually built - including the workarounds, constraints, and exceptions discovered during delivery - can develop realistic training, support, and change management plans. Adoption teams that learn this information after go-live are always reacting.
24% more planned value. Organizations that deploy a dedicated, empowered CTO with structural knowledge continuity accountability achieve measurably better transformation outcomes - not because the CTO is smarter, but because they maintain the connection between strategic intent and operational reality throughout execution.
The leadership model described above requires one thing to function: visibility into operational reality. PMOs, CTOs, and Knowledge Stewards can build governance structures and phase-transition checkpoints, but those structures only work if they're fed with accurate, granular knowledge about how the organization actually operates.
This is where ClearWork supports the transformation leadership function. ClearWork uses AI-driven asynchronous interviews to surface operational reality - the informal workflows, undocumented dependencies, informal constraints, and exception-handling steps that frontline staff know but that formal discovery rarely captures.
For CTOs, ClearWork provides structured operational intelligence that keeps strategic decisions grounded in what's actually happening. For TMOs, it provides the evidence layer that makes institutional memory reliable rather than anecdotal. For Knowledge Stewards, it provides a systematic mechanism to capture and transfer what teams know without requiring dedicated interview hours or workshop sessions.
The result is that the leadership structures this article describes - CTO, TMO, Knowledge Steward - become operational rather than aspirational. Governance checkpoints have something to check against. Phase-transition briefings are grounded in evidence rather than assumptions. Knowledge transfer is verifiable, not merely hoped for.
Treating the PMO as the transformation management function. PMOs are excellent at delivery tracking. They are not designed for knowledge architecture. Expecting a traditional PMO to manage knowledge continuity is like expecting a project tracker to function as a knowledge management system.
Positioning the CTO only at the executive layer. A CTO who operates only at the board and executive committee level loses visibility into operational reality. Without structured mechanisms to surface what's actually happening at the operational level, strategic continuity decisions are made on filtered information.
Assigning the Knowledge Steward role without clear accountability. Naming someone as a knowledge steward without defining what they're accountable for produces documentation, not transfer. The Knowledge Steward mandate must be specific: confirm that the incoming phase team understands what the previous phase found, and flag discrepancies before design or delivery decisions are locked.
Running stage gates that check deliverables but not knowledge. A phase gate that confirms "discovery is complete" without confirming "design knows what discovery found" is measuring the wrong thing. Add knowledge transfer checkpoints to your governance gates.
Assuming that knowledge will flow naturally between teams. It doesn't. The evidence is overwhelming: knowledge generated in one phase of a transformation does not naturally migrate to the next team. Knowledge continuity requires active management and explicit accountability.
A: The function of a CTO - maintaining strategic continuity and knowledge visibility across phases - is necessary in any transformation that spans more than one phase and involves more than one team. Whether that function is held by a dedicated C-suite CTO, a senior program director, or an empowered transformation sponsor depends on the scale and complexity of the program. Large enterprise transformations genuinely benefit from a dedicated CTO; mid-size transformations can achieve the same outcomes by clearly assigning the CTO function to an existing senior leader, provided that leader has both the authority and the structured visibility into operational reality to do the job.
A: A PMO is designed for delivery governance: timelines, budgets, scope management, and status reporting. A Transformation Management Office is designed for program continuity: ensuring that the knowledge, decisions, and institutional memory generated across all phases of a transformation survive phase boundaries and inform each successive phase. TMOs include delivery governance, but they go further - they own the knowledge architecture that makes phase transitions coherent rather than chaotic. Many organizations label their function a "TMO" but operate it as an upgraded PMO. The distinction is not the name but the accountability: does the function own knowledge continuity or just delivery tracking?
A: Team transitions are the highest-risk knowledge continuity events in any transformation. When discovery teams hand off to design teams, or delivery teams rotate before adoption, structured knowledge transfer becomes essential rather than optional. The Knowledge Steward role is specifically designed for this. Before any significant team transition, the outgoing team should produce a structured brief covering: what was found, what decisions were made and why, what assumptions are baked into the current state, what constraints are real vs. assumed, and what the incoming team should validate immediately. The briefing should be followed by a structured Q&A session, not just document review.
A: The CTO role should last as long as the transformation program. For multi-year transformations, this means the CTO is a sustained role, not a launch-phase appointment. Many organizations appoint a CTO at the start of a major initiative and then wind down the role once the "big bang" delivery is complete - but this often coincides with the adoption phase, which is precisely when strategic continuity is most at risk. The CTO or equivalent should remain accountable until the new operating model has been validated in production and adoption metrics confirm that the transformation has actually changed how the organization works.
A: The Knowledge Steward is accountable for one thing: ensuring that knowledge generated in the current phase is understood, documented, and confirmed as transferred to the next phase team before that team's work is locked. This means the Knowledge Steward must actively engage with both the outgoing team (to extract and document what was learned) and the incoming team (to confirm they understand and have incorporated that learning). The steward's accountability is complete only when the incoming team can demonstrate - through their decisions, assumptions, and plans - that they understand what the previous phase found. Documentation alone is not sufficient. Active transfer confirmation is the standard.
Transformation programs don't fail because leaders lack ambition or intelligence. They fail because nobody is explicitly accountable for ensuring that what discovery knew becomes what design used, what design assumed becomes what delivery validated, and what delivery built becomes what adoption understands. Assign that accountability deliberately - to a CTO with operational visibility, a TMO with knowledge architecture mandate, and Knowledge Stewards at each phase transition - and transformations stop losing knowledge at the moments it matters most.
Most transformation programs have clear leadership for strategy and delivery, but a critical accountability gap exists at the phase transitions where operational knowledge either survives to inform the next team or disappears into documents nobody reads. The organizations that close this gap do so by restructuring transformation leadership around three coordinated roles: a CTO who maintains strategic continuity with direct operational visibility, a TMO that operates as a knowledge architecture function rather than a delivery tracker, and Knowledge Stewards who are explicitly accountable for phase-to-phase knowledge transfer. When these three functions work in coordination, the 70% failure rate in enterprise transformations begins to look like a fixable problem rather than an inevitable industry reality.