Valueless CTO: High Salary, No Return

👋 Hey, everyone, thanks for reading this issue. For everyone who joined recently: this is my highly subjective newsletter about all things surrounding software development/engineering management/CTO daily life. I hope you enjoy your stay here

Here are some updates from my life over the last two weeks:
* Recorded a video about Fake Interviews in Software Engineering
* I'm planning on moving out from Switzerland, going traveling for a year so. In the process of selling my stuff and giving up my apartment. Hopefully will be finished until June. If you have any experience being a digital Nomad - hit me up.
* I'm thinking about creating a private community on Telegram or Discord. Like a a support group for CTOs, wdyt?
* Roasted 2 CVs from Software Engineers. If you're looking for a job, highly recommend.

As always, I hope you enjoy the article. Share it with your friends, here's a link.

So, I’ve been called a bad CTO a few times, and people even told me they wouldn’t work for me even if I were the last CTO on earth. Quite a statement, right? Thank god that’s just Reddit talking, and I usually don’t expect any good comments whenever I get traffic from Reddit. But this whole hate made me think.

What’s the value of a CTO? Can a CTO be worthless to a company? While everyone loves to read HN Stories about the rockstar CTOs who perform magic while programming in all the languages at once, that doesn’t represent the real world. I’ve talked with companies that fired their CTO because they’ve gotten way too comfortable and haven’t done much in terms of moving the company forward. So, do you ever wonder what happens to a company if the CTO doesn’t really know what they’re doing?

I thought long and hard about what kind of CTOs are valueless to startups; I was mostly thinking about what I should and shouldn’t be doing for the board to vote me out. I ended up with four main archetypes and their missing values that I want to go deeper into:

1. Non-technical CTO — missing value is expertise.
2. Invisible / Absent CTO — missing value is role model.
3. Misaligned CTO — missing value is shared goal.
4. Asshole CTO — missing value is people skills.

As you can see, there’s always some value that is missing from each of these; we’re taking a fully functioning, average CTO and subtracting a quality from them and trying to figure out what goes wrong and how long we can wing it.

You might counter, “I know plenty of companies that thrive with bad CTOs that bring no value.” But, my friend, they’re thriving despite the CTO. Can you imagine how much better they would do if they had a good one? Also, maybe that statement holds true in the short term, but the cracks will begin to show over time, just wait.

The bigger the company, the slower the downfall, but the smaller the company, the more visible the CTO’s negative impact is. If they're out of their depth, everyone feels it, especially other software developers.

If you’re reading this, don't be the CTO who's just another suit. Be the CTO who knows their stuff and isn’t afraid to lead, learn, and be the most valuable CTO ever, even if it’s just for this company.

Let’s dive in.

Non-Technical CTO

I have a big issue where non-technical people lead technical companies. I agree that if you’re a Fortune 500, you’re big enough not to care if you have technical leadership. But I think they should care; I believe it is essential. Having someone who knows how the engine runs, how the factories work, or, in our case, how a digital SaaS works is a tremendous value proposition for a CTO.

Imagine a CTO who cannot articulate how the software works in layman’s terms for the board of directors. Such a leader might excel in managerial skills or business development, but without technical expertise, they are often unable to contribute effectively to the discussion. What’s the point of a CTO if they have the same knowledge as the other 5 Board Members with an MBA? This knowledge/understanding gap can lead to strategic technology misalignment that will eventually bleed to every level of your organization.

I’d also like to state that there are numerous pitfalls to having a non-technical CTO. For starters, they will struggle to gain the respect of their engineering teams. Software developers expect leadership to at least understand on some high level the complex technical challenges they face daily. When the CTO lacks this ability, it can lead to dissatisfaction and erosion of trust within tech teams. I wouldn't trust my CTO if they don't know the ins and out of the product that we're building, would you?

Moreover, a CTO who is out of touch with the latest technology may make decisions that compromise the company. We have enough CEOs who are super excited about all the LLMs they’re going to integrate into all the processes; someone needs to step up and say that’s bullshit, articulate the known limitations, and why that idea is not going to work. There needs to be a balance between what the CEO envisions and what CTO says is doable at the moment, for that we need the technical expertise to judge if the technology is feasible or not.

A Non-Technical CTO brings no value in terms of choosing technologies. Moreover, they have negative value, they will select inappropriate technologies because they do not fully understand the associated options or risks. I have seen some startups suffer due to this issue. One case involved a promising tech company that aligned much of its strategy around leveraging a single vendor that sounded cool and had a great Landing Page. No due diligence was performed, nor an in-depth evaluation. The result was a costly overhaul of their systems when that vendor went out of business a year later. Totally CTOs fault.

The value that CTOs bring with their expertise is enormous. If you take that away, you have another CEO — they can lead, inspire, and motivate people — but they’re not a good technical sparring partner to bounce ideas off, nor can they understand the engineering teams that work for them.

My advice, and a highly subjective opinion, is to always ensure that the role of the CTO is filled by someone who not only understands the tech stack in-depth but can also adapt to future technology trends. Sadly, just having an MBA is not enough, and having great people skills is also not enough.

Invisible / Absent CTO


This one is relevant only for companies with < 300 engineers. After that number, the CTO becomes invisible, not because they’re not involved but because they’re busy in other areas that are not visible specifically to you.

The Absentee Syndrome occurs when a Chief Technology Officer lacks the role model value. Because they lack this characteristic, they disengage from daily operations and the direct development process.

I have a strong opinion about this as well. A CTO should be more than just a figurehead; they should be a driving force and role model within the company. When a CTO steps back from the operational aspects of their role, it often leads to poor morale among the engineering team. Engineers tend to perform best when they feel leadership sees and understands their work. A CTO disconnected from what the tech team is doing fails to provide this validation. And fails to be a good role model.

A few examples of an absentee CTO — are missed meetings, late arrivals, no praise, infinitely postponed meetings, promises that always get pushed back, and not even talking with the engineers. This distance can foster an environment where technical teams feel unsupported and undirected.

Teams look to their leaders for more than direction — they seek inspiration and recognition. A CTO who is not actively involved in the projects can inadvertently send a message that the work they’re doing, often boring and not fulfilling, is unimportant. Moreover, when a CTO is detached, miscommunications become more frequent, and people start to replicate this behavior — others begin to be late, become disengaged, and postpone things. It can lead to a spiral that’s hard to get out of.

Now, contrast this with the benefits of a hands-on CTO or at least someone actively participating as a role model for the company. This leader sets the vision and rolls up their sleeves to help achieve it. They are seen working alongside their team, troubleshooting problems, and brainstorming new ideas. They might not be solving the same coding problems as the engineers, but they are solving their own for the benefit of the whole company, and they are seen side by side with engineers. Their presence can be incredibly motivating and can foster a sense of teamwork and purpose.

A hands-on approach allows you, as a CTO, to spot issues quickly and intervene earlier, especially in startups with highly limited resources.

Reflect on this as you continue to shape your leadership style and consider your startup’s long-term health and success.

Misaligned CTO

Having deep trust and disagreements with your CEO are good things. Healthy debate is the foundation of good decisions and something you should strive for. It’s even better if there are multiple shareholders/founders, not just the two of you.

In my case, I have two partners, and we run our holding company and the development agency in consensus, and we vote on any significant decision. We have an agreement that whatever we decide, we trust each other. Two members vote for one thing, and the third (if he’s against the decision) trusts the other two that it’s right.

It’s all great when multiple people are involved, not just a single CEO who decides that they want to move in a completely different direction than what you wanted, and it stops resonating with you. As you remember, the primary role of a CTO involves overseeing the development and operational technology as well as driving the company’s technological vision. You must ensure that every tech initiative supports the broader vision. The question is, how do you support it if it goes against your ideals and feels wrong?

In a situation where the company ideals change, or the company wants to pursue a direction that I’m not comfortable with, there are two ways I would act:

1. Trust the CEO and try to see it through their eyes (and hopefully see results eventually). Adapt your opinion.
2. Leave. This is the simplest solution, the goals are no longer aligned with your, and you shouldn't invest resources in something you don't wholeheartedly believe in.

If you stay, it’s your responsibility to ensure that your non-beliefs do not impact the culture/environment. I encourage you to cultivate a deep dialogue with other C-suite members to ensure that decisions are made with a clear understanding of how they impact the company and the future.

Asshole CTO

I first wanted to call this “Inadequate CTO,” but then I figured there’s nothing inadequate about being an asshole; it’s a personality trait that focuses exclusively on the person’s inability to work with others.

Let’s look at a CTO who’s a genius at coding. Their value is extreme expertise, but there’s a catch: sadly, they don’t have much people skills.

You can see this very often, even on Hackernews, stories about people leaving the company because the CTO is an asshole. It’s not a new thing. I think this is one of the oldest issues in tech leadership — people being asshole geniuses. There's quite a few that come to mind, the most prominent of those — Linus Torvalds and Steve Jobs. Are they geniuses yes? Is it enough to be great? In their case yes, on average no.

I’d like to remind you that a single person can only do so much. They become sick, and they take vacations. You need to cultivate teams, teams, teams. Cultivate supportive environments that nurture great coders AS PART OF A TEAM. Being technically proficient is just one part of the job; equally important are people skills, communication skills, articulation skills, writing skills, and the ability to translate complex into simple without sounding condescending.

Remember, a CTO’s impact goes beyond code. They can be writing code with their eyes closed directly in Assembly, for all you care, but it’s irrelevant. They are crucial in shaping the culture. They risk alienating the whole team if they lack empathy, communication skills, or the ability to handle interpersonal dynamics gracefully. Especially in smaller companies, a CTO who can't or won't mentor their team is failing a crucial part of their role.

Your values as a CTO should be about building up people while fully understanding the technology. Your time is limited. You cannot be cloned. So nurturing people who you can delegate to is your number one job when you’re growing.

In the first section, we discussed a CTO who doesn’t have any technical knowledge, which leads to a disaster. Now we’re on the other end of the spectrum — pure technical genius but no empathy or understanding of leadership. The truth is in between. Strive to be the CTO who not only excels in technology but also in building a happy, productive, and cohesive team. That’s the kind of leadership that genuinely drives a company forward.

Conclusion

The absence of a competent CTO, or the presence of one lacking the necessary qualities, can render them worthless to a startup or scale-up. I hope it’s evident that the value of a CTO extends far beyond a single quality; you need to have them all. You’re basically acting as a bridge between the product, the technical team, and the business, combining all of these elements in yourself.

As a closing thought, I pose a direct and potentially controversial question: As a CTO or VP of Engineering, are you a liability or a positive influence on your company? Are you driving change or merely reacting to it?

Cheers,
Vadim