The CTO’s Incoming Storms

Let me name the six conversations I’m watching land on CTOs right now, and the stance I’d want you holding in each one.

I’m sitting across from a CTO at a coffee shop in Salt Lake City. He’s stirring his Americano like he’s trying to drill through the bottom of the cup. We’ve been here twenty minutes and he hasn’t taken a sip.

“They want to cut us to one engineer per product team,” he says. “One. The CEO read something on LinkedIn about AI agents and now he’s convinced we can ship the same roadmap with a third of the team.”

I ask him what he said in the meeting.

“I told him the math doesn’t work. I walked him through the velocity numbers, the on-call rotation, the knowledge concentration risk.” He finally takes a sip, grimaces. The coffee is cold. “He nodded. Then he asked me to put together a transition plan by end of quarter.”

This CTO is brilliant. He has fifteen years of scar tissue, a calm demeanor, and a genuine love for his team. And he is about to lose this fight. Not because he’s wrong. He’s right. He’s going to lose because he showed up to a strategy conversation with a defense brief.

I’ve had four conversations like this in the last three weeks. Different cities, different stages, different product categories. Same shape. The CTO knows something is coming at them, the conversation has already started, and they don’t have a stance ready. They have facts. They have logic. They have decades of experience. What they don’t have is a position they can hold under pressure when the room turns.

So let’s fix that.

The conversations already on your calendar

Here’s something true about the storms heading toward technology leaders right now: they don’t announce themselves. They show up disguised as casual questions in 1:1s, throwaway comments in board meetings, Slack messages from a CFO who “just had a quick thought.”

By the time the conversation feels like a confrontation, it’s already three weeks deep. The CEO has talked to two board members. The CFO has run the model. The COO has chatted with a peer at another company who “did the same thing and it worked great.”

You walk in thinking you’re having a discussion. They walk in having already made the decision and looking for your buy-in.

You need to know what’s actually being asked, and you need a position before you walk into the room. Let me name the six conversations I’m watching land on CTOs right now, and the stance I’d want you holding in each one.

1. “Why can’t we cut headcount now that we have AI?”

This is the conversation. Every CEO on the planet is having some version of it, even the ones who haven’t said anything to you yet. Revenue per employee is climbing across software companies, boards are pattern-matching hard, and the productivity stories about AI coding tools are everywhere.

The trap is to argue against the cut. You’ll lose. The numbers your CEO is reading are real, the productivity gains in narrow contexts are real, and your defensive posture will read as self-interested protection of your empire.

The stance to hold: AI doesn’t reduce the need for engineers, it changes what engineers are for. Your team used to produce code. Now they produce judgment about code. The bottleneck has moved from typing speed to the ability to evaluate, integrate, take responsibility for, and operate systems built faster than any human can fully review.

If you cut the team, you don’t get the same roadmap with fewer people. You get a codebase that nobody understands at depth, security posture that decays in months because nobody has time to think about it, and a production environment where every incident takes three times longer to resolve because the people who would have built the system never built it.

Don’t say “we can’t cut.” Say “here’s what we’re optimizing for now, and here’s what that team looks like to deliver it.” Bring the new shape, not the defense of the old one. If the answer involves a smaller, more senior team with different skill profiles, say that. If it involves the same headcount with a radically different mix, say that. What you can’t do is fight the premise. The premise has already won.

2. “Can we just have one developer on each product team?”

This is the same conversation in a different costume. It’s the org-design version of the headcount conversation, and it’s seductive because it sounds like alignment. One engineer, one PM, one designer, ship faster, fewer dependencies, clear ownership. It reads beautifully on a slide.

What it actually creates is the bus factor problem at industrial scale. Every product surface depends on a single person who cannot get sick, take vacation, or quit without breaking something. Every architectural decision gets made in isolation. Every cross-cutting concern — auth, observability, data contracts, security review, deployment infrastructure — becomes nobody’s job.

Six months in you have twelve product surfaces, twelve different ways of doing the same thing, twelve people who’ve each painted themselves into a corner, and a platform team that doesn’t exist because you couldn’t justify the headcount when you were “moving fast.”

Your stance: pods of one are not teams, they are single points of failure dressed up in a process diagram. Engineering work is collaborative because the work itself is collaborative. The code one person writes today will be read by four people next quarter and modified by twelve people next year. The decisions one person makes about how to structure data will constrain every team that touches that data for years.

Counter-propose. If they want surface area and ownership, give them small persistent teams of three to five with clear product alignment and shared platform infrastructure underneath. That’s the structure that scales. That’s the structure that survives someone quitting. That’s the structure that lets you actually move fast in year two, not just year one.

3. “The board wants to know our AI strategy”

Translation: someone on the board read an article, talked to a portfolio company CEO, and now you have a homework assignment due Friday.

The wrong move is to produce a deck full of tools you’re “evaluating.” Every CTO is evaluating Cursor, Claude Code, Aider, a handful of MCP servers, and whatever launched on Product Hunt last Tuesday. That’s not strategy, that’s shopping. Boards smell shopping immediately.

The stance: your AI strategy is your engineering strategy. They’re not separate documents anymore. It’s how your team writes code, reviews code, handles incidents, makes architectural decisions, and develops junior engineers in a world where the easy work is done by machines. It includes what you’re building with AI for customers, but the harder and more important half is how AI changes the way your team operates internally — and what that means for hiring, leveling, performance, and risk.

Bring three things to the board.

1. Where AI is creating leverage in your engineering org today, with numbers you trust. Not vendor numbers. Your numbers.

2. Where you’re investing for the next two quarters and what you expect to learn.

3. What you’re explicitly not doing and why. The “not doing” list is what separates strategy from a wish list. Boards have seen enough wish lists. They want to see judgment.

If you can’t fill in that third bucket, you don’t have a strategy yet. You have a backlog.

4. “We need to move faster”

You will hear this every quarter for the rest of your career. It’s the background radiation of being a CTO. But right now it has a new edge to it, because everyone in the building believes AI should have already made you faster. The question is no longer “can we go faster” — it’s “why aren’t we faster yet.”

The bad response is to promise more velocity. The worse response is to explain why velocity is hard. Both lose you credibility.

Your stance: speed is a function of what you’re willing to stop doing. The team’s capacity hasn’t suddenly tripled because an LLM can write a function. The team’s capacity to ship features is gated by code review, testing, deployment safety, on-call burden, security review, customer support escalations, and the cognitive load of maintaining everything you’ve already shipped. AI helps with one slice of that pipeline. The rest is unchanged or, in some cases, worse — because faster code generation means more code to review, integrate, and operate.

If you want speed, we make trade-offs. Here are three things we could stop investing in to free up capacity for the new priority. Here’s what we’d accept in terms of risk or quality. Here’s what would break.

Make the trade-off visible. Make the CEO choose. The conversation shifts from “the CTO is slow” to “the executive team made a prioritization decision together.” That’s where it should have been all along. That’s also where you stop being the person who says no and start being the person who frames the choice.

5. “Are we sure all this AI-generated code is safe?”

This one usually comes from the CFO or General Counsel, and it usually arrives about a quarter after your team has gone all-in on AI coding tools. Sometimes it arrives the morning after a security incident at a peer company makes the news.

The honest answer is: probably not entirely, and neither is anyone else’s. Recent research on AI-generated code has found meaningful rates of vulnerable patterns, license contamination, and subtle logic errors that pass code review because they look right. The code is plausible. Plausible is the enemy of secure.

The stance: AI-generated code needs the same scrutiny as code from a brand new engineer on day one — which means it needs more scrutiny, not less, even though it arrives faster. Our review practices, our test coverage requirements, our security scanning, our dependency analysis — none of that gets relaxed because the author is a model. If anything, it gets tightened, because the volume of code is going up.

Then bring the actual plan. What scanning tools you’re running. What review standards you’ve updated. What you’re tracking. What you’re going to know in 90 days that you don’t know today. The CFO doesn’t need you to promise zero risk. They need to see that someone is actually thinking about this with rigor, not just enthusiasm.

If you don’t have that plan, build it this month. This conversation is coming whether you’re ready or not, and “we trust our engineers” is not an answer that survives a board-level question about AI risk.

6. “I don’t think anyone is listening to me”

This isn’t a conversation with the C-suite. This is the conversation you’re having with yourself at 11pm on a Tuesday, and it’s the most dangerous one on this list.

I wrote a while back about how being technically correct isn’t enough. That hasn’t changed. What’s changed is the stakes. When the rest of the C-suite is making decisions about AI, headcount, and organizational structure based on incomplete mental models, your inability to make them feel what you see isn’t a communication problem anymore. It’s a survival problem. For you and for the company.

There’s a particular flavor of isolation that hits CTOs right now. Your CEO is reading the same five Substacks as every other CEO. Your CFO is running models built on industry benchmarks that are six months out of date by the time they’re published. Your peers in the C-suite are pattern-matching against what they’re hearing at their own peer dinners. And you, the only person in the room who actually understands what the technology can and can’t do, are increasingly being treated as the resistant one. The cautious one. The one who doesn’t get it.

You start to wonder if you don’t get it.

The stance to hold with yourself: if they’re not hearing you, that’s data about how you’re showing up, not data about their intelligence. The work is to translate. Not dumb it down — translate. Find the version of your concern that lives in their language. Revenue, risk, retention, runway, customer trust, regulatory exposure. Pick the frame they already think in and put your concern inside it.

And get out of the building. Talk to other CTOs. Not to vent — to calibrate. The version of reality you’re living in inside your company is one data point. You need others. You need to know whether your CEO’s expectations are reasonable, aggressive, or unhinged compared to what’s actually happening at companies of your size and stage. Without that calibration, you’ll either capitulate when you should hold, or hold when you should adapt. Both are fatal.

The CTOs I see weathering this period well all have the same thing in common: they have somewhere to take the hard questions before they have to answer them in front of their CEO. A coach, a peer group, a mentor, a community. Somewhere they can be uncertain out loud and come back with a stance.

If you don’t have that, build it this month. It’s not a luxury anymore.

What to do this week

Pull out your calendar. Find the next executive meeting on it. Before you walk in, write down two things on a notecard.

The first is the strongest argument against your current position. Not a strawman — the real one, the one your smartest skeptic would make. If you can’t articulate it cleanly, you’re not ready to defend your position. You’re ready to be surprised by it.

The second is the trade-off you’re asking the team to make. Not a recommendation, a trade-off. “If we do A, we don’t get B. Here’s why I think A is right anyway.” This forces you out of advocacy mode and into the executive frame, where everything is a choice between imperfect options and the job is to make the choice cleanly.

Then in your next 1:1 with your CEO, ask one question: “What’s the conversation about engineering you’re having that I’m not part of?” Sit with the silence. Let them answer. The answers will tell you which storm is closest, and how much warning you actually have.

You’re not going to stop the storms. They’re coming. Boards are going to ask hard questions about AI. CFOs are going to push on headcount and security. CEOs are going to want more velocity with fewer people. Product is going to want autonomous pods. That’s the job now.

What you can control is whether you walk into those rooms with a stance or with a defense. The CTOs I see thriving right now aren’t the ones with the best technology opinions or the deepest technical chops. They’re the ones who’ve already done the work to know where they stand before the conversation starts. They’ve stress-tested their position with peers. They’ve translated it into the language of the room. They’ve identified the trade-offs they’re willing to make and the ones they aren’t.

Get your stance ready. The meeting is already on your calendar.