8 ms·
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 mom
by system16 4y ago
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 spending all of their time in the code, they are not doing the tasks of a CTO. If that doesn't matter and doesn't cause issues, you probably don't need a CTO.
I've worked at a company with a CTO who was an extremely talented developer but really that's all he wanted to do. He'd avoid meetings like the plague, never managed anyone despite have several senior direct reports, and would only really engage with others when technical issues came up where he could jump into the weeds in and help solve the problem. Essentially he had the title "CTO" but in reality all that meant was he was a superadmin developer who could work on whatever technical problem he wanted with nobody to report to.
- mchusma 4y agoAgree, 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.
- ForHackernews 4y agoDropbox also completely lost the market they invented to Box, largely because of nontechnical considerations.
- scarface74 4y agoAs 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.
- dilyevsky 4y agoImo 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?
- scarface74 4y agoI think it makes more sense when it comes to Microsoft Office365. I wouldn’t use Google anything for something I depend on.
- 1123581321 4y agoDropbox 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.
- dilyevsky 4y agoWhen 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
- daveslash 4y agoYes. 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.
- pvorb 4y ago> 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.
- scarface74 4y agoI’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.
- pvorb 4y agoThanks 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.
- scarface74 4y agoIf 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.
- walrus01 4y ago> 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.
- roughfalls 4y agoI'm reminded of a blog post (https://rc3.org/2015/12/29/answering-the-question-should-managers-code/ 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.
- insane_dreamer 4y agoHe 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.
- kyawzazaw 4y agoCounterpoint example: Evan Wallace