A CTO should be technical

Being a CTO means you are constantly switching hats. At the core you are defining the technical direction and strategy of a company. This obviously needs to be business aligned; so a lot of CTOs are all over that as well. And it touches on product as well. So a lot of CTOs are also head of product. And in smaller startups, anything vaguely technical is the CTOs job; as well as anything else that needs doing. I currently do this.

In some companies the CTO role is more important than others. If you are a tech startup, the CTO is likely a founder if not the main founder. However, there are also a lot of non-technical companies where the strategy is simply to build tech stuff as cheap and efficiently as possible while not getting in the way of the founders who tend to be non technical types running a company where tech is just a means to an end rather than core to what they do. Just because you have an app or a website does not mean you need a CTO. You might just outsource that to an agency even.

I've seen this a lot in the Berlin scene where a non technical founder team starts looking for a non founding CTO to build their thing and they end up with some engineer getting the label slapped on them. My advice to companies like that is that they should be looking for a VP of engineering instead and not slap CTO role on the relatively inexperienced early engineers they'll manage to attract to their company. More often than not this ends in tears; especially when equity is involved.

Often the roles of VP of Engineering and CTO are confused. They can be separate roles. Not all CTOs are good at managing large teams. And some engineering managers know a thing or two about tech. However, a VP of Engineering can be very hands off when it comes to tech. Building stuff is not their function. Managing the people that do is.

Lots of scale ups need one and the role is about nurturing and growing the tech team, not necessarily about having a lot of opinions on what the tech should be (other than be boring, low risk, predictable type stuff). Another difference is that a VP of engineering is not a C level executive and also not a founder. They are there to grow the business and make sure the tech team delivers whatever product needs delivering and that the right people are in place to make that happen. IMHO VP of Engineering is closer to and HR role than a tech role actually. You wouldn't expect them to write a single line of code. Lots of companies end up having both roles. Especially those with founding CTOs that turn out to not be ideal at managing their tech team.

The CTO should be able to liaise with employees, customers, and upper core management.

While some technical understanding is needed to contextualize operational costs, it is hardly a primary skill requirement.

Some may find it convenient to overburden employees with 6 roles in a small firm, it is often not a wise decision. Ignoring burnout factors, a company could end up with a very cool looking toy infrastructure, that essentially misses the subtle long-term stakeholder requirements.

Also, who hires an external employee for a CTO role… that sounds insanely risky. =)

https://www.youtube.com/watch?v=0D7hFHfLEyk

>employees as mindless drones ... very toxic management style.

I agree.

back when the word CTO was invented it had a different meaning than it does now. It used to mean the person in charge of the technology for a non-technology company. So for instance, a Wall Street firm would have a CTO in charge of their computer systems, critical infrastructure for their business, key technology trends to anticipate, etc., needed visibility in the C suite, but it's not their main business, it's not a profit center.

A technology company would have a VP of Engineering, because that's what the company does as a core business. A company like Boeing could have a VP of Engineering wrt the airplanes they build, and a CTO wrt their CAD systems. (I just made that up to try to give some flavor, not saying that's literally true)

I've been on the reverse side, where it was obvious the CTO and CEO were hiding things. It's annoying for a while and then eventually there's some proverbial straw that breaks the camels back.

Word spread pretty quickly through various cliques in the company. Some teams had no idea what was happening, other teams lost literally all their developers and and couple managers over the course of 30 days.

During my exit interview I mentioned the dishonesty and they just doubled down that I was imagining it.