Hacker News Reader

> Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming? Absolutely not.

The point was that a CTO should be able to do this in theory. Of course they won't ever actually do this unless there's no other way.

If your CTO can actually relate to the problems of their staff, they'll be able to make better decisions which also see more acceptance.

I’ve had two jobs where I reported directly to the CTO - the first as Dev lead with people management responsibilities and the second as the de facto “cloud architect” that was responsible for the “application modernization” initiatives.

My second CTO was very technical and up to date the first wasn’t. The only difference between the two day to day was with the second one, I could use terms without defining them first. They both deferred to my technical judgement and I worked with the understanding of how to align my initiatives with the company’s.

I work with CxOs all the time in consulting now. I have no problem getting my ideas through CxOs or architecture review boards.

Thanks for the insight.

I'm wondering what the devs at both companies were thinking about their CTOs. My point wasn't that much about direct reports to the CTO, who might already be used to talking in management terms, but rather the developers who are directly affected by the CTO's decisions.

If the devs are reporting directly to the CTO, the CTO should be technical. If not, the CTO should delegate dev leadership to someone who is both technical and business oriented.

As my last company grew, the CTO just didn’t have the bandwidth to be technical at work and delegated different responsibilities to the people who could wear both the technical hat and had the soft skills needed. He would just dabble in things on the weekend. His entire family was technical. His wife was a lead data analyst for a telecom and his daughter got an internship as an SWE at BigTech.

> My second CTO was very technical an up to date the first wasn’t. The only difference between the two day to day was with the second one , I could use terms without defining them first. They both deferred to my technical judgement and I worked with the understanding of how to align my initiatives with the company’s.

> I work with CxOs all the time in consulting now. I have no problem getting my ideas through CxOs or architecture review boards.

Something to consider: there is probably not much difference between technical and non-technical when their reports are good.

But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

> But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

Very true. GP probably had good tech judgement which is why their technical CTO was following their judgement.

I had never logged into AWS when I was hired. I just had theoretical knowledge. In the land of the blind, the one eyed man is king, I’m amazed to this day that the CTO trusted me knowing that in advance. Don’t get me wrong, he didn’t blindly trust me. He pushed me harder than any other manager ever had to do things correctly and to think deeply and to write well reasoned documentation and presentations.

I told myself that there were only two positions at two companies that could have convinced me to leave. I got hired by one of those companies. He left less than a year later after the company was acquired for 10x revenue. He’s working somewhere else now. I would work for him again in a heartbeat if I were working anywhere else besides where I work now.

> whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

I am genuinely wondering if I need some jiffy lube for flushing those fluids of mine.

It... sounds like... a thing... that people... do?

>But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

The non-technical CTOs "defense" is having found which reports they can trust and support to make the correct tradeoffs. Then they do that. More broadly if your reports aren't competent or trusted enough to make the right decisions then find new reports.

The job of the CTO isn't to argue some stupid architectural point with people for hours. It's also not to blindly overrule them. Their job is to hire people that know more than them and can be trusted. Then it's to setup the processes within which those people can thrive.

In fact the problem with technical CTOs is that they can rely too much on their own technical knowledge versus fixing the damn organization. It's basically a bunch of band aids being put on a gushing wound.

You are right; you have to relate to the problems to value your people more I find. I used to jump into code as cto and I lost good people because of it as they felt it was lack of trust (it was I think but I did not realise that back then). When understanding how things work and giving the team the means to get it done by supporting them instead of trying to do their job is something I see go wrong in many cto’s, including my former self. I still like coding more than managing but I realise that there are other people so much better at the code part and I need to hire and guide them.

I'm reminded of a blog post (https://rc3.org/2015/12/29/answering-the-question-should-man... , focused on software engineering managers rather than CTOs), which posited this guideline:

"A manager actively avoids creating situations where their coding is necessary for the success of the project."

I agree with Aditya's article. A CTO must be technical for all the reasons stated. I would add another reason to his list: a CTO must be able to challenge the assumptions, plans, and estimates presented to him/her by the engineering team. Doing so requires technical acumen.

> Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming?

In the roles they worked at immediately before becoming CTO they certainly should have had the technical capability and knowledge to do so, yes. Maybe not directly as CTO anymore but they need the grounding and experience to understand what the various tiers of engineers underneath them are grappling with.

Agree, also his example of the CTO was "Dropbox". Dropbox is/was basically only a "folder that syncs reliably". For that role, this is deeply technical low-level work and yeah, that CTO probably should be very technical.

The CTO (once the team is >10 or so) really only needs to be "as technical as needed to make smart decisions". This will vary a lot by company.

Dropbox also completely lost the market they invented to Box, largely because of nontechnical considerations.

As Steve Jobs said, DropBox was always going to end up being a feature not a product.

For the same price you pay for DropBox, you can get the complete Office 365 with 5 TB of storage for five people or GSuite with storage.

Imo that quote only ever made sense when you add "[compared to apple]" which was likely how he meant it. Also have you tried actually using gsuite storage?

I think it makes more sense when it comes to Microsoft Office365. I wouldn’t use Google anything for something I depend on.

Dropbox has about twice the revenue of Box. Box was founded a couple of years before Dropbox. However, both only have a small share of the value of consumer and commercial cloud storage at this point.

When i talked to dropbox folks like 5 years ago they scoffed at box only being a third of their revenue. Sounds like they’re closing the gap

Yes. This. I agree with you and the parent comment.

I was "CTO" of my very small startup with < 10 people and 3 total engineers. I was extremely technical and hands-on in that role. I've worked at a mid-sized business that didn't even have a CTO, despite having 4 FTE software engineers and a network infrastructure team.

I now work for a globally distributed Fortune 500 company with nearly 100,000 employees working on hundreds of technical projects using all sorts of tech stacks and code from Embedded C to serverless SaaS offerings. The notion that my CTO should be able to "jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming" is absurd. It might be nice to have a CTO that's been in that role at some point, but no way should I expect them to be able to tomorrow.

He probably wasn't the right person for the CTO job. But that doesn't mean that the CTO shouldn't be as much of a technical expert as that person is. It's just that that person didn't know how to switch to using his expertise at a leadership level rather than at the engineering level.

Counterpoint example: Evan Wallace