11–20 of 367 posts
author doesn't understand management at all, nor silicon valley / tech company org structure model. ok sure, in a top down company, CTO better be uber technical. remind me not to apply to any SPC companies, nor use their products
(disclaimer: I know him personally and his credentials aside, think he's extremely knowledgeable about engineering leadership and company building in general)
Being "technical" is a full time job. The idea that anyone "above" you should be able to do your job is not only ridiculous, it's insulting to the engineers. The CTO should be able to have an informed and intelligent conversation about technical issues at a high level, but expecting them to be able to write code is not realistic.
Being "technical" is a full time job. The idea that anyone "above" you should be able to do your job is not only ridiculous, it's insulting to the engineers. The CTO should be able to have an informed and intelligent conversation about technical issues at a high level, but expecting them to be able to write code is not realistic.
Earlier quoted context omitted.
I think it still matters because of hiring. The type of people rewarded with promotion at the top tend to promote those people and so on down the levels. A nontechnical CTO will start promoting nontechnical people managers and eventually you will have an org run by MBAs.
Yes for sure. But those non-technical, big company CTOs are going to be hiring people who need to be good at hiring people. Those are going to be your VPs of engineering types. THOSE people will be 'more technical' at that point. Those VPs of engineering are going to hire directors and so on down the chain. As you descend - it matters more and more that they are good technically. So if you're at a 50k size company, t…
The question is: what tech? I worked at software companies, where the CTO was equivalent to the CIO, and I worked at classical engineering companies where they had both, because their tech had nothing to to with IT.
As a software engineer, I've worked at companies where the both the CTO and one of the VPs were what I would call CIOs -- they were networking/infrastructure people.
Writing software in an org like that is often an exercise in insanity. To many infrastructure people, the software itself (and related topics like developer experience/productivity) are barely even things they can wrap their heads around much less care about.
I am sure that the inverse is true. Trying to do infrastructure work in an org run by software-brained people is probably equally difficult.
Being "technical" is a full time job. The idea that anyone "above" you should be able to do your job is not only ridiculous, it's insulting to the engineers. The CTO should be able to have an informed and intelligent conversation about technical issues at a high level, but expecting them to be able to write code is not realistic.
Amongst other necessary leadership skills, I do agree with the author that CTOs should be:
1. Good judges of quality.
2. Able to make good tradeoff decisions.
3. Able to earn respect.
4. Able to inspire teams to greatness.
5. Able to recruit top talent.
However, it isn't necessary for a CTO to be able to do everyone else's job to have these skills and be a great CTO.
Being "technical" is a full time job. The idea that anyone "above" you should be able to do your job is not only ridiculous, it's insulting to the engineers. The CTO should be able to have an informed and intelligent conversation about technical issues at a high level, but expecting them to be able to write code is not realistic.
> One of the key roles of your company’s engineering leadership is to balance working on new features versus maintaining quality and squashing bugs.
Even at companies with 100 engineers, if the CTO is focused on software bugs, there are larger issues at play (i.e., talent density is too low, poor prioritization by product, etc.).
Aditya[0] seems has experience here, but he's likely addressing the market of early-stage startups where he advises.