Every single person has different opinions about how technical a non-IC should be (manager, director, CTO, VPE, etc). There's really nothing to argue here - it's not one way or the other. It all depends on the maturity level and size of the company and also an individual's personal interests. Moreover, in our industry where job roles/responsibilities are not uniform or standard, it's not surprising to come up with your own versions of each role. It's no surprise why a Principal Engineer from one company may or may not stand a chance to make a lateral move to another. These kinds of articles come up every day and I strongly feel that they are an utter waste of time. Stop generalizing. Talk about what the CTO is expected to do at "your company" only.
A CTO should be technical
31–40 of 367 posts
Re: A CTO should be technical
#32Strongly 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…
> 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.
Re: A CTO should be technical
#33The only competent CTOs I have seen in the telecom and network engineering business are ones who came up through the ranks either from field technician, or junior NOC desk person, to network engineer and onwards through 10, 15, 20 years of career progression. Everyone who did not take this path was missing critical information that should be used in network architecture decision making.
Re: A CTO should be technical
#34Is 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 practices. I also think the right choices are local and particular, so pausing all sorts of teams because of quality issues is inevitably going to waste a lot of time.
A real head-shaker for me.
Re: A CTO should be technical
#35Strongly 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…
> 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.
Re: A CTO should be technical
#36Is 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"?
Re: A CTO should be technical
#37I 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?
Re: A CTO should be technical
#38I 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 fear what will replace me if I leave.
Right? I've had this conversation with so many techies-turned-leaders. The way I look at it, managing means I've given up my chance at doing the fun work so I can create a context where other people can get shit done in a way that's effective and rewarding.
That does require being very technical, because you have to have a feel for the work and the issues. But it also requires giving up being very technical, because you just don't have the time or the headspace to get lost in a good problem.
It's a conundrum, and it's why Charity Majors' "Engineer/Manager Pendulum" resonates for me: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
Re: A CTO should be technical
#39Is 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"?
Of course not! You also have to mutter, "but hurry up" whenever people do something that might actually improve quality.
Re: A CTO should be technical
#40I'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 personally believe it's easier for a technical person to become reasonably competent at process, cost and other management stuff vs a management person to become reasonably competent at technical things. When I was contractor I saw terrible decisions made by CTO and CIO in several companies because they didn't have any technical taste and ran everything by numbers and processes. I definitely believe a CTO should be…
> When I was contractor I saw terrible decisions made by CTO and CIO in several companies because they didn't have any technical taste and ran everything by numbers and processes.
So true. CTO being so far upstream, mistakes made here through disconnection between the rubber and the road have compound effects downstream. It's the sort of role where bad decisions have huge, company-ending ramifications.
"I talked to my buddy at [FAANG] and he said microservices are the way to go. His team achieved awesome velocity by switching to microservices. Let's do it guys!".