4 ms·

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 bec

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.

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.