Having a CTO is not the same as having technical leadership

A portfolio CEO called me at 9pm on a Tuesday last quarter. The kind of call you take.

“My CTO just told me about an architecture decision. It got made last week. I’m finding out tonight because the bill came in.”

That’s the difference between having a CTO and having technical leadership, compressed into one phone call. Having a CTO means there’s a name on an org chart and a person you can call when something breaks. Having technical leadership means there’s someone in the room when business decisions get made who can articulate the technical implications in language the operating partner understands, before the bill arrives instead of after.

This wasn’t a bad CTO

The CEO on that call had a CTO. Smart engineer. Hard worker. Loyal. He was in the trenches with the team, which is exactly why he wasn’t in the room when the architecture decision should have been a board-level conversation. He didn’t think it needed to be. By the time the invoice surfaced it, the company had already eaten three weeks of opportunity cost they didn’t know they were paying.

I want to be careful here, because the easy reading is “replace the CTO,” and that’s usually wrong. If your CTO is doing the work of three engineers, they don’t have time to do the leadership. The judgment that should be applied to vendor proposals, build-versus-buy calls, and spend trajectory is being spent on shipping. That’s not a personnel problem. It’s a structural one, and firing the person in the seat just restarts the clock on the same structure.

The test

I see this gap in roughly half the portfolio companies I get asked to assess, and there’s a quick way to check for it in yours. Look at the last three significant technology decisions: a contract over six figures, a platform choice, a rebuild approved or killed. For each one, ask who in the room could independently evaluate it, and when the CEO or the board found out.

If decisions are getting made and then announced, you have a reporting function, not a leadership function. The technology org can ship, it can fix, but it can’t influence Monday’s decisions on Friday. It’s a more specific version of the question I keep coming back to with owner-led companies: when your team brings you a technology decision, who’s checking the work?

Adding the layer without the headcount

For most companies in this range, the fix is not a second executive hire. It’s putting qualified leadership capacity next to the CTO you already have: someone who’s held the seat, sits in the business conversations every week, and translates in both directions. The CTO keeps building. The board gets the technical implications while they’re still cheap to act on. We run this as a player-coach model, and when the existing CTO is good, it makes them better instead of threatening them. (Six questions to gauge whether the model fits, if you want the short version.)

The CEO from the 9pm call has this in place now. The decisions didn’t get easier. They just stopped arriving as invoices.

If your CTO is heads-down shipping and nobody is in the room doing the translation, the next 9pm call will not be the last one. The structure makes that a promise.