Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

Post reply on HN
Print view View original

61–70 of 367 posts

Re: A CTO should be technical

#61

Post by wpietri »

PragmaticPulp wrote: post #47
wpietri wrote: 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.

I believe you don't see the problem. How can I help you see it?

Re: A CTO should be technical

#62

Post by nordsieck »

scarface74 wrote: post #52
pvorb wrote: post #32

Earlier quoted context omitted.

> 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 als…

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 firs…

> 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.

Re: A CTO should be technical

#63

Post by FpUser »

I was CTO long time ago. Rose to position from being a programmer in small company. As the company grew bigger I kept moving up. Was still pretty technical though. I still coded a little in order not to loose sanity but most of my time was spent doing high level design, architecture, getting into some strategic technical partnerships and so on for some giant projects in telecom and other enterprise software areas and making sure it was correctly interpreted down the line.

Then one day new owners came and after talking to them a little I said fuck it and went on my own. Consequence of being close to burnout. Now 20+ years later even though I did not become rich I have my own one company where I design and create products. Some I own, some are done for numerous clients. I mostly work alone but hire subcontractors on on need basis and am happy like a clam.

Re: A CTO should be technical

#64

Post by scarface74 »

pvorb wrote: post #59
scarface74 wrote: post #52

Earlier quoted context omitted.

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 firs…

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.

Re: A CTO should be technical

#65

Post by roughfalls »

system16 wrote: post #22

Strongly disagree with the scope of this. Should a CTO be technical? Absolutely. 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. As others have said, development is a full time job. It requires focused time and you need to remain current and have context for the state of the project. If a CTO is sp…

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.

Re: A CTO should be technical

#66

Post by yowlingcat »

What's incredible (and frankly horrifying) in this blog post is the complete lack of anything pertaining to what /kind/ of company the CTO works at. Surely, that must be important; a large company that sells a non technical product may need a very different CTO from an enterprise software company, who may need a very different one from a quantitative trading find.

Along those lines, I find the lack of connection to anything pertaining to product market fit equally horrifying. Sure, you might say, that's the job of the head of product.

But if you're the CTO, you are going to struggle to prioritize your engineering roadmap without very strong product chops, and moreover, you will struggle to "skate ahead of the puck" and ruthlessly cut out infrastructural nice-to-haves versus necessities. You may also blunder into architectural traps that come about from insufficient awareness of product risks.

It is a real cop out, and a vague one, in my opinion, to say that a CTO "should be technical." The big question is "what kind of technical."

In contrast to this blog post (which I find a little empty, sadly), I'd recommend one of my perennials favorites: Werner Vogels post about the 4 different kinds of CTO:

https://www.allthingsdistributed.com/2007/07/the_different_c...

What I like about the quadrant is that it maps the four kinds into rate of business change on one axis, and information as percentage of products/services on another axis. This is really useful because it lets you stratify what kind of CTO you'll probably be looking for based on what kind of business you're looking at, which is very important because the world of business needs for CTOs are /vast/ and heterogenous. CTO could mean many different things at many different companies.

A good framework for whether a CTO should be at X should also account for "at Y kind of company."

Re: A CTO should be technical

#67

Post by sponaugle »

I am a CTO, and have been for 20 years. 20 years ago I was co-founding a company, so that kind of CTO was very different than the CTO I am today. Starting a company meant I was the technical part of the company. Raising money, talking to VCs, customers, hiring, and all of the other usual growth stuff. Of course I developed code, architectures, plans, deployments. I deployed, installed network switching gear, configured BGP peering, and debugged database problems. As the company grew, the role changed.

I'm now CTO of the larger company that acquired me and the role is different in almost every way. The role is to lead a path to technology changes, but much of that is technology coming from the technology staff itself. The most valuable learning happens by listening to my team and the teams around us. There is as much business as there is technology, as much future guessing as there is past evaluation.

Through all of these changes, day 1 to today, the most important skill has been a desire to be technical. I still write code for my own projects, develop my own projects, design microprocessors, hardware, software, sensors, and everything in between. If someone asks me a question, I want to understand how to get to the answer, not just get the answer.

Of course I have to understand the fundamentals of the business, and of business. Of course I have to convince non technical people why we need to do things. None of that is easier done by being non-technical, and much of it is done wrong by being non-technical. Stay frosty.

(Funny side note.. in the beginning, I often said during a 'introduce yourself' part of a meeting "I'm Jeff, the Chief Technical Officer" by mistake. )

Re: A CTO should be technical

#68

Post by pvorb »

citizenpaul wrote: post #46
dijit wrote: 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…

> 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.

Maybe they simply found out that you kept lying to them?

Re: A CTO should be technical

#69

Post by daveslash »

mchusma wrote: post #25
system16 wrote: post #22

Strongly disagree with the scope of this. Should a CTO be technical? Absolutely. 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. As others have said, development is a full time job. It requires focused time and you need to remain current and have context for the state of the project. If a CTO is sp…

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.

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

I was "CTO" of my very small startup with 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.

Re: A CTO should be technical

#70

Post by yowlingcat »

wpietri wrote: 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 would fire any CTO (or engineer) that took this kind of absolutist approach. I find this kind of extremism associated with mediocre engineers and engineering leaders who cannot weigh competing priorities without a black and white answer key which doesn't map onto reality.
Post reply on HN