Skip to content
All posts

The Three Types of CTO. One of Them Will Destroy Your Engineering Team.

May 4, 2026·Read on Medium·

A framework I heard from my boss that I haven’t been able to stop thinking about.

TLDR;
There are three kinds of CTO in tech. The Politician got the title through politics and has neither vision nor technical depth. The Visionary sees the big picture but cannot validate what engineers tell them. The Builder has shipped code, cannot be fooled on estimates, and earns respect without asking for it. Most engineering pain traces back to which type is sitting in the chair.

My boss said something to me once that I wrote down immediately and have been turning over ever since.

He said there are three types of CTO in tech. Not seven. Not a spectrum. Not a “it depends on company stage” nuance. Three. And one of them should never have been given the title in the first place.

I have been a Technical Lead long enough to have worked under or alongside all three. The more I tested this framework against my own experience, the more it held up.

So here it is, with my own observations layered in.

Type 1: The Politician

This is the worst one.

They got the title through tenure, through internal politics, or because they were the safest choice in the room when someone needed a name on an org chart.

Not technically deep. Not visionary. What they are is comfortable.

They have survived many reorganisations by being agreeable. They know which meetings to be seen in. They know how to make the right people feel heard. The engineering team does not respect them. More importantly, the team has figured out how to work around them.

The decision problem

Under a Politician, decisions get made not because they are right but because no one pushed back hard enough.

A senior engineer says the codebase needs to be rewritten. The Politician cannot evaluate whether this is true, necessary, or a six-month yak shave that benefits the engineer’s CV more than the product. So they approve it. Or they feel threatened and reject it entirely.

Either way, the decision has nothing to do with what is actually correct.

The real danger

The danger is not malice. Most Politicians are not malicious.

The danger is that they are a vacuum. Strategy does not come from them. Technical standards do not come from them. What fills that vacuum is whoever shouts the loudest, which is not always the person you want driving your architecture.

Under a Politician, an engineering team is often demoralized, fragmented and building on top of decisions that no one fully owns.

The tell

Ask them to explain, in plain language, why the last major architectural decision was made.

Watch them reach for buzzwords. “We needed to modernize.” “We were moving toward a more scalable posture.” When you peel back the language, there is nothing underneath it.

The decision was not made. It was allowed to happen.

Type 2: The Visionary

The most interesting one. Also the most dangerous when the team is wrong.

A Visionary CTO cannot code. Or if they once could, they have been away from it long enough that it no longer informs how they think about technical problems.

What they can do is see where technology is going before most people do. They are sharp in investor meetings. They understand the business problem at a level that many engineering leaders do not. They can translate between the product, the commercial team and the technical team in ways that create real alignment.

This is not a small thing. Many technical leaders cannot do this. They get lost in implementation details, present architecture diagrams to stakeholders who needed a direction and struggle to connect engineering output to business outcomes. The Visionary does not have that problem.

The structural vulnerability

The vulnerability is that they have to trust their engineers completely.

And their engineers know it.

When a team lead says a project will take four months, the Visionary has no independent frame of reference. When a principal engineer says the current architecture cannot scale, they cannot walk through the code and check. When a vendor brings in a demo and the team says “this is the right tool,” the Visionary relies entirely on the team’s judgment, not their own.

Good team vs. bad team

Good engineers respect this and work within it honestly. They give accurate estimates, escalate genuine technical risks and flag when a recommendation benefits them professionally more than it benefits the product.

Under a good team, a Visionary CTO can be extraordinary.

Bad-faith engineers exploit it. Not always consciously. Sometimes it is just that engineers, like all humans, optimise for what is interesting and technically elegant rather than what is most valuable. Without a CTO who can push back on the technical layer, that drift goes unchecked.

What it looks like in practice

I have seen Visionary CTOs greenlight complete platform rewrites because the team said the old system “doesn’t scale,” when in reality it served the current load comfortably and would have for years.

I have seen them accept six-month estimates for features that a more experienced leader would have negotiated to six weeks. Not because the engineers were lying but because no one in the decision chain had the context to have that conversation.

The Visionary’s success depends almost entirely on the integrity of the team around them.

That is a significant structural risk.

Type 3: The Builder

The hardest one to manipulate. That is not an accident.

The Builder has been an engineer. They have shipped production code. They have debugged problems at 2am. That history does not disappear when they move into leadership. It sits in every conversation they have about timelines, architecture and technical risk.

Why estimates become honest

When an engineer tells a Builder CTO that something will take three months, they can engage at the level of the actual work.

“Walk me through what that includes. What are the main unknowns? What would need to be true for this to be six weeks instead?”

This is not micromanagement. It is calibration. It pushes estimates toward reality in a way that benefits everyone, including the engineers who would otherwise be held to a commitment made on guesswork.

Why respect happens organically

Engineers want to be led by someone who understands what they do.

Not someone who codes alongside them every day, but someone who has done the work and knows what it feels like. When a Builder says “I know this is hard, but I think it can be done in these constraints,” the team believes them. Because they have the credibility to hold that opinion.

The failure mode

The Builder’s risk is not being misled from below. It is over-engaging with implementation details.

Some never fully make the transition from engineer to leader. They pull back into the code when things get stressful. They have opinions about naming conventions when they should be focused on roadmap and org alignment.

But here is the thing: this failure mode is correctable.

A Builder who is self-aware, or who has good people around them, can learn to stay at the right altitude. The manipulation vulnerability of the Visionary, and the strategic vacuum left by the Politician, are much harder problems to solve.

What Each One Looks Like When Things Go Wrong

Understanding the archetype matters most when a project is actively failing.

The Politician in a crisis will look for someone to blame first. They schedule retrospectives, ask for status reports and escalate to leadership. What they will not do is make a clear technical call, because they cannot. The crisis drags on while everyone waits for a decision that never arrives with enough force to resolve anything.

The Visionary in a crisis will call their most trusted engineer and ask for an honest assessment. If that engineer is well-aligned, they will get one. If that engineer is overwhelmed, or part of the problem, the Visionary will not know the difference until much later. Decisions get made based on the information provided, and if that information has been shaped by the people providing it, the decisions will be shaped by them too.

The Builder in a crisis will roll up their sleeves. Not to take over the codebase, but to get close enough to understand the actual problem rather than the described problem. They ask questions that only someone with a technical background can ask. They cut through noise faster. The risk is staying too close to the ground for too long and losing sight of the business-level consequences.

Three crises. Three completely different failure modes.

Only one of them fundamentally depends on receiving accurate information from the people below them.

Why This Still Matters

Politicians exist in large numbers because many companies are not sure what they are hiring for when they hire a CTO. They want someone technical enough to talk to engineers and commercial enough to talk to the board. In that ambiguity they sometimes end up with someone who is neither. Just someone who performs both roles adequately enough that the gap is never obvious until it is very obvious.

Visionaries are common in companies where founders came from business or product backgrounds and needed a technical figurehead rather than a technical decision-maker. They can work well. They often do not, because the talent density required to support them is rarely consistent across an entire engineering organisation.

Builders are what most engineering teams actually want, even if they would not always articulate it that way. Someone who has been where they are. Who can be levelled with. Who cannot be sold a fantasy.

The next time someone asks what makes a great CTO, skip the competency frameworks and the leadership models.

Ask one question: can they tell when their team is bullshitting them?

If the answer is yes, you are probably in good hands.

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community. Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community.

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter. And before you go, don’t forget to clap and follow the writer️!

Found this helpful?

If this article saved you time or solved a problem, consider supporting — it helps keep the writing going.

Originally published on Medium.

View on Medium
The Three Types of CTO. One of Them Will Destroy Your Engineering Team. — Hafiq Iqmal — Hafiq Iqmal