Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

41–50 of 367 posts

Re: A CTO should be technical

#41
post #36
post #34

Is this what passes for management advice these days? > CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality. This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of prac…

What do you mean, the way to get quality isn't to frown while you say "more quality"?

No, no, no. That gives entirely the wrong association. You have to smile while saying "more quality".

Re: A CTO should be technical

#42
post #37
post #23

I just became a CTO. So, let me bear my thoughts. Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope. I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year. I'm terrified. I'm terrified because I feel like I will let my reports down. I'm terrified because a lot…

> but I fear what will replace me if I leave So you'll never retire or die?

I’m not very old, healthy enough and if I die then there’s not much more I can do, can I?

Re: A CTO should be technical

#43
post #23

I just became a CTO. So, let me bear my thoughts. Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope. I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year. I'm terrified. I'm terrified because I feel like I will let my reports down. I'm terrified because a lot…

I've reported directly to good CTOs and really bad ones.

The shitty ones:

- Either never built trust or broke trust.

- Were impulsive and reactionary.

- Didn't rely on the expertise and skills of their reports as much as they told them what to do because they already knew everything. Didn't ask questions. Gave orders.

- Literally used the words, "because I said so".

- Believed that they were the only one doing any real work. Used the words, "easy" to describe work that was assigned to their reports.

- Were very insecure - questions were often received as challenges to authority.

- Set in place policies which they were the first to violate.

- Their actions and their words disagreed.

- Lost their best people within a year.

Re: A CTO should be technical

#45

I'd say it's important for a CTO to be a CTO. I've been at too many places where the CTO only wanted to be a software developer/architect and would not focus on process, cost, employees, etc. CTO is a leadership role, and leadership means you have to take care of all the responsibilities under your authority, not just the interesting ones. IMHO, too many people chase the CTO title but few really want the actual job.

> I've been at too many places where the CTO only wanted to be a software developer/architect and would not focus on process, cost, employees, etc. CTO is a leadership role, and leadership means you have to take care of all the responsibilities under your authority, not just the interesting ones

A common pitfall among startups is to give the CTO title to whichever cofounder is leading the development when the team formalizes titles. Some times this person doesn't even have previous engineering manager (EM) experience at all, but as the most technically oriented person of the time they receive the CTO role by default.

Some times these people can grow into the necessary delegation, recruiting, hiring, performance review, people management, communication, and meeting skills necessary to be a CTO. Other times, they cling to what they know (coding) and turn into a micromanaging CTO who won't cede control of the things they want to do (code) while avoiding the things they have to do (managing).

This is one of many reasons why I advocate for avoiding C-level titles as long as possible at a startup. You can always promote someone up to CTO unceremoniously when the company actually needs defined C-level executives and they've been excelling at the role already, but it's much more problematic to ask someone to give up the CTO title and step aside to bring in an experienced CTO when necessary. Nobody likes being demoted, even if it's only a formality because they weren't actually doing the full management role. Any title demotion at startups is likely to lead to conflict and departures.

Re: A CTO should be technical

#46
post #23

I just became a CTO. So, let me bear my thoughts. Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope. I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year. I'm terrified. I'm terrified because I feel like I will let my reports down. I'm terrified because a lot…

I was a CTO once.

Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on. This could actually be the difference between what makes things fail or succeed. You're job is not to be transparent or honest. Its to make sure everyone stays productive and on track. This will 100% require lying or being non-transparent at some point.

>My most frequently accessed cloud console pages are the billing sections.

Lol yep.

Eventually some of those reports will hate you as well even if you do everything perfectly. Its inevitable from being in charge. You may not find out till running into them years later and they just shrug you off when you try to say hi.

I think I was good at the job, though of course I'm biased but even looking back there are very few things I would change. I really did try and will never feel like I was inadequate even though the company eventually did go under due to bad investments the owner made.

Re: A CTO should be technical

#47
post #34

Is this what passes for management advice these days? > CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality. This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of prac…

I don't see the problem. Part of a CTO's role is to set the tone for planning and direction, including priorities.

The CTO of a large company shouldn't be jumping in and managing Jira backlogs to move bugs around in a list, but they should be providing direction to teams and managers about expectations and how to set priorities within their teams.

Re: A CTO should be technical

#48
My last CTO of a 70 person company was in his 50s and while he did everything that I would expect a CTO to do - manage vendor relationships, deal with pre-sales when trying to get new customers (B2B), and define a vision, there were a number of times he would throw together a quick non production ready piece of code in Python or C# to prove out a concept and share it with me in Dropbox to make it production ready. I greatly appreciated it. That was part of his role with strategy. He understood technology well, played with Docker on the weekend and analyzed data using Athena (serverless AWS Apache Presto).

But I knew when I spoke to him about a proposal, I needed to start off speaking non technical and talk about business value and business impact (when I got to technical he would say he “doesn’t have time to listen that shit” - we had a very good working relationship and we didn’t waste time with niceties when we were trying to get a point across to each other. When he had time though, we would need out.

On the other hand, the CTO I had before that hadn’t been hands on technical at all for over a decade. When I spoke to him, I spoke only in terms of the business value and the holy Trinity (on time, on budget, meets requirements).

In both cases, they hired me so they wouldn’t have to deal with those details and it was my responsibility to explain trade offs.

Post reply on HN