5 ms·

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 o

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.

spaetzleesser 4y ago
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 very strong technically and have a good bullshit detector.
- SkipperCat 4y ago
  100% agree. Any decent CTO will have tech in their roots, but if you're coding all day, you're missing out on what's truly important about the CTO role - building teams, assigning resources to problems and steering the company in the right technical direction.
- beachy 4y ago
  > 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!".
  - scarface74 4y ago
    You realize that is the very edict that basically started at Amazon and came straight from Jeff Bezos in 2001? I think it worked out okay there (here).
    - beachy 4y ago
      I wasn't saying microservices are bad (personally I love them, maybe too much:). Just that making technology decisions based on someone's else's anecdotes, in the absence of any technical understanding, is a bad way to go.
    - Denzel 4y ago
      Not quite. Jeff’s “edict” came via a lot of analysis, trial-and-error, and information gathering throughout the entire Amazon organization over the course of many years. Amazon had huge dependency problem, both technical and organizational. Technically, the effort to work in their monolith scaled superlinear with respect to the CL size due to coordination and review with other teams. Organizationally, teams were dependent on an ever growing set of centralized, global processes that further slowed their ability to make progress. Jeff (and S-team) saw these issues and worked to solve them through a series of experiments. Specifically, Jeff tasked his then CIO with finding a solution. This CIO worked throughout the organization to gather on-the-ground feedback around what was and wasn’t working; built a model for how Amazon _should_ work based upon that sense making; and then tested, iterated, and refined that model into what we’ve come to know as Single-Threaded Leaders and Two-Pizza teams, etc., today. In parallel, a couple Amazon business units were experimenting with exposing their data via textual (XML) APIs like the Amazon Associates API which went on to become the Amazon Product Listings API. These early APIs were sort of the POCs that allowed Amazon to see early validation around the concept of web services. Synthesizing all these different streams of information, ideas, and actions lead to Jeff’s “edict” around building standalone web services (which eventually led to what we know as AWS today). In short, Jeff is the exact antithesis of GP’s straw CTO. He speaks from data, facts, and information gathered from a myriad of internal and external sources, not merely anecdotes of success from a CEO buddy. :) Source: Working Backwards has a lot of information on Jeff (and Amazon’s) decision making.
- jjav 4y ago
  > I saw terrible decisions made by CTO and CIO While a CTO needs to have grown up in the technical trenches to have credibility, a CTO should not be making any technical decisions anymore. If they are, that's a red flag for a CTO who can't let go and keeps micromanaging.
  - sercand 4y ago
    It depends on the company size. On a small startup with 10 people and a company with 1000 people have different CTO definitions and roles.
    - jjav 4y ago
      Yes, certainly. In a tiny startup the CTO is just a lead developer with more stock options than the others.
  - spaetzleesser 4y ago
    A CTO often will be the referee for making big technical decisions. If that CTO doesn’t have a good bullshit detector then bad decisions will be made.
PragmaticPulp 4y ago
> 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.
tluyben2 4y ago
Having been a cto for decades I can agree; the things that are part of the job that are not technical, are the parts I find boring and don’t like. I am good at them by now, but I don’t like doing them. They are needed and indeed not many people who can do them actually like them.
allisdust 4y ago
Some CTOs who have seen their companies going from 10-1000 don't seem to grow up in their role. They don't learn delegation or trusting others with making decisions. They end up becoming a glorified architect instead of an actual leader. Meanwhile since no one takes the lead in setting up processes and keeping an ear to the ground on quality, velocity etc and things go bad quickly. This article reads like something a startup CTO would do or expected to do. Frankly companies below 100 shouldn't have this role. Someone leading a 10 person tech team isn't really a CTO because the work and decisions involved are totally different from someone leading a larger tech organisation. They should just mark such roles as what it is: a senior architect.

spaetzleesser 4y ago

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 very strong technically and have a good bullshit detector.

SkipperCat 4y ago
100% agree. Any decent CTO will have tech in their roots, but if you're coding all day, you're missing out on what's truly important about the CTO role - building teams, assigning resources to problems and steering the company in the right technical direction.
beachy 4y ago
> 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!".
- scarface74 4y ago
  You realize that is the very edict that basically started at Amazon and came straight from Jeff Bezos in 2001? I think it worked out okay there (here).
  - beachy 4y ago
    I wasn't saying microservices are bad (personally I love them, maybe too much:). Just that making technology decisions based on someone's else's anecdotes, in the absence of any technical understanding, is a bad way to go.
  - Denzel 4y ago
    Not quite. Jeff’s “edict” came via a lot of analysis, trial-and-error, and information gathering throughout the entire Amazon organization over the course of many years. Amazon had huge dependency problem, both technical and organizational. Technically, the effort to work in their monolith scaled superlinear with respect to the CL size due to coordination and review with other teams. Organizationally, teams were dependent on an ever growing set of centralized, global processes that further slowed their ability to make progress. Jeff (and S-team) saw these issues and worked to solve them through a series of experiments. Specifically, Jeff tasked his then CIO with finding a solution. This CIO worked throughout the organization to gather on-the-ground feedback around what was and wasn’t working; built a model for how Amazon _should_ work based upon that sense making; and then tested, iterated, and refined that model into what we’ve come to know as Single-Threaded Leaders and Two-Pizza teams, etc., today. In parallel, a couple Amazon business units were experimenting with exposing their data via textual (XML) APIs like the Amazon Associates API which went on to become the Amazon Product Listings API. These early APIs were sort of the POCs that allowed Amazon to see early validation around the concept of web services. Synthesizing all these different streams of information, ideas, and actions lead to Jeff’s “edict” around building standalone web services (which eventually led to what we know as AWS today). In short, Jeff is the exact antithesis of GP’s straw CTO. He speaks from data, facts, and information gathered from a myriad of internal and external sources, not merely anecdotes of success from a CEO buddy. :) Source: Working Backwards has a lot of information on Jeff (and Amazon’s) decision making.
jjav 4y ago
> I saw terrible decisions made by CTO and CIO While a CTO needs to have grown up in the technical trenches to have credibility, a CTO should not be making any technical decisions anymore. If they are, that's a red flag for a CTO who can't let go and keeps micromanaging.
- sercand 4y ago
  It depends on the company size. On a small startup with 10 people and a company with 1000 people have different CTO definitions and roles.
  - jjav 4y ago
    Yes, certainly. In a tiny startup the CTO is just a lead developer with more stock options than the others.
- spaetzleesser 4y ago
  A CTO often will be the referee for making big technical decisions. If that CTO doesn’t have a good bullshit detector then bad decisions will be made.

PragmaticPulp 4y ago

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

tluyben2 4y ago

Having been a cto for decades I can agree; the things that are part of the job that are not technical, are the parts I find boring and don’t like. I am good at them by now, but I don’t like doing them. They are needed and indeed not many people who can do them actually like them.

allisdust 4y ago

Some CTOs who have seen their companies going from 10-1000 don't seem to grow up in their role. They don't learn delegation or trusting others with making decisions. They end up becoming a glorified architect instead of an actual leader. Meanwhile since no one takes the lead in setting up processes and keeping an ear to the ground on quality, velocity etc and things go bad quickly. This article reads like something a startup CTO would do or expected to do. Frankly companies below 100 shouldn't have this role. Someone leading a 10 person tech team isn't really a CTO because the work and decisions involved are totally different from someone leading a larger tech organisation. They should just mark such roles as what it is: a senior architect.