Your Engineers Didn't Need an AI Strategy. They Needed You to Have One.

From the Desk of Suman

The hardest thing about being a CTO in the AI era isn’t the technology.

I’ve run engineering organizations at Reliance scale. I’ve done the cloud migrations, the platform rebuilds, the microservices transformations. I’ve managed through the mobile revolution, the data platform era, and now AI. And I can tell you with certainty: the technology is never the hard part.

The hard part is leading the humans through the change — while the lights stay on, the business keeps moving, and the board keeps asking questions you don’t have clean answers to yet.

This playbook is for CTOs who are in the middle of that reality. Not the ones writing Medium posts about their AI transformation. The ones running it, at 11pm, wondering if they’re moving fast enough and whether their team is going to make it through.

I’ve been that CTO. This is what I wish I’d had.

THIS ISSUE

When I talk to CTOs about AI, the conversation always has the same shape. They’ve got the tools conversation sorted — or at least they think they do. They’ve got GitHub Copilot rolling out, they’ve got some LLM experiments in the pipeline, they’ve got a generative AI working group.

What they don’t have is clarity on the other two layers. And those are the ones that determine whether their AI initiative becomes a transformation or a very expensive proof of concept.

Layer 1 — Tools: Which AI tools do we adopt, how fast, and how do we govern them? (Most CTOs are working this layer. It’s the easiest one.)

Layer 2 — Architecture: How do we rebuild our systems to be AI-native without breaking what’s running? (Most CTOs are uncomfortable here. This is where real technical leadership lives.)

Layer 3 — Organization: How do we transform the team’s capabilities, culture, and ways of working — while retaining the people we need? (Almost no CTOs are working this layer systematically. This is where transformations succeed or fail.)

The CTO who only works Layer 1 is a tool evaluator. The CTO who works Layers 1 and 2 is a systems architect. The CTO who works all three is a transformation leader.

The market pays those three CTOs very differently. And more importantly — their companies transform very differently.

Let me be direct about something that doesn’t get said enough in CTO conversations about AI.

Most enterprise systems were not built for AI. They were built for transaction processing, structured data, and deterministic outputs. AI systems are probabilistic, unstructured, and emergent. Bolting AI onto a legacy architecture is like fitting an electric motor to a petrol car — it works, but you’re leaving 80% of the value on the table.

The architecture question every CTO needs to answer in the next 12 months is not “how do we add AI to our systems?” It is “which of our systems need to be rebuilt from scratch to be AI-native, and which just need AI augmentation?”

That’s a portfolio decision. And it requires a framework.

At Tata, we applied this framework across our digital estate — stores, multiple customer touchpoints, online, hyperlocal, a complex omni-channel inventory and fulfilment layer. The clarity it created was immediate. We stopped having the “should we rebuild or augment?” debate for every system and started having the right debate: which quadrant does this system sit in, and are we resourcing accordingly?

I’m going to say something uncomfortable.

Your senior engineers are the most at risk in the AI transition — not from AI replacing them, but from AI making their seniority invisible.

For 20 years, seniority in engineering meant you carried more context in your head. You knew where the bodies were buried in the codebase. You knew which architectural decisions were made for good reasons that nobody documented. That tacit knowledge was the moat.

AI democratizes that knowledge. A junior engineer with Claude and good prompting can navigate an unfamiliar codebase, generate tests, and ship a feature that would have required 3 years of context 2 years ago.

This creates a real organizational risk that nobody talks about: your senior engineers may feel — correctly — that their advantage is eroding. And if they feel that, the good ones will leave.

1. “Your value isn’t in the code you write anymore. It’s in the architecture decisions AI can’t make without human judgment. We’re going to create more space for that.”

2. “I need you to become the AI system designers, not just the code writers. Your domain knowledge is the most valuable input an AI model can have. Let’s build that into how we work.”

3. “I’m not going to pretend this transition is easy. But I’m going to be honest with you about what’s changing and give you the tools to lead through it — not just survive it.”

These conversations are hard. They’re harder than evaluating AI tools. They’re harder than making architecture decisions. But they’re the ones that determine whether your organization comes out of this transition stronger or hollowed out.

The Reliance Lesson: Moving Fast Without Breaking Trust

At Reliance, I learned something about organizational transformation that I’ve carried into every CTO role since. The technology is never the constraint. The trust is.

When you’re transforming a large engineering organization, your engineers will go at the speed at which they trust your vision. Not the speed at which you fund the program, not the speed at which you mandate the tools — the speed at which they believe you know where you’re going and that you’ll protect them on the way there.

The CTOs I’ve seen fail at AI transformation are almost always technically competent people who underestimated the trust deficit. They announced the AI strategy, rolled out the tools, set the OKRs — and then watched adoption plateau at 20% while the rest of the organization quietly continued working the way it always had.

The CTOs who succeeded built the trust first. They ran small, visible wins. They promoted the engineers who embraced the change. They were honest about what they didn’t know. And they created psychological safety for the engineers who were struggling with the transition.

Trust is your AI strategy’s rate limiter. Most CTO playbooks don’t mention it. This one does.

Every CTO I know is getting some version of the same board question: “What is our AI strategy and when will we see ROI?”

Most CTOs answer the wrong question. They explain the technology. They show the roadmap. They present the use cases. And the board nods politely and asks the same question again next quarter.

Here’s what the board is actually asking: “Are we going to be disrupted, or are we going to do the disrupting? And how do I know we’re on the right side of that line?”

The board doesn’t need more technical detail. They need a CTO who can translate technical reality into business risk and business opportunity. That translation is a leadership skill. It’s also one that AI can help you practice — but it has to come from your judgment, not from a generated slide deck.

Stop planning. Start doing. Here is a concrete 90-day framework that I’ve used and refined across multiple transformation programs.

We go deep on building the AI-native engineering team — what roles are changing, what to hire for in 2025, and how to restructure your engineering org chart without destroying the culture that made it work.

Plus: the exact governance framework I use for AI tool adoption at Croma — covering security, data residency, and the questions every CTO should be asking vendors before signing.

Share recodeai

If this issue gave you one thing to think about differently, forward it to one CTO or engineering leader you respect.

The recodeai CTO Playbook grows through practitioners sharing with practitioners.

No algorithm. No ads. Just signal.

I’m building recodeai.co to give builders mental models for the AI decade. If this resonated, subscribe to stay in the loop. And if you want the code, it’s open. DM me.