4 ms·

Possibly unpopular, but this is an interesting topic, so I'll post my counterpoint. The question is: what are you not doing that is in the list of CTO responsi

Possibly unpopular, but this is an interesting topic, so I'll post my counterpoint. The question is: what are you not doing that is in the list of CTO responsibilities because you're coding? One of the reasons stated why you do this is "because you enjoy it", and on the list of reasons you need to do it is there are only a handful of people in the org that can ship new product surface area. That's...concerning. That seems like the kind of thing the CTO would want to fix, but I don't think having the CTO be the one to ship that surface area is highest-leverage use of time. If I'm reading this right, it's essentially that "because of the virtue of my position and autonomy, I can work on experimental projects for months at a time, but I don't empower my teams to do the same." I have direct experience with this sort of attitude at companies between 200-400 people, and the messaging from top brass was framed as "innovation cannot be democratized". After seeing it in action for several years, I think it's a poor model. CTOs are technical visionaries, but coding is not a high-leverage activity. Good startup CTOs need to change their role multiple times over the course of the life of a company, and failing to understand the profound impact you can have as a leader is a common pitfall, because it doesn't fit with what you enjoy, or often what you have experience with. In the case of Assembled, Crunchbase says between 100-250 employees. If you get more towards 500-1000, I would seriously recommend you re-evaluate your thinking on coding as CTO, at least to the degree you are today. One technical question: do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"? What happens when you don't have time to land the long-term experiment before you need to turn to the next concern? I ask these questions because they are the points where I've seen this system fail, and I'm curious if that has every been an issue for you.

tptacek 1y ago
Again, implies there is such a thing as a "list of CTO responsibilities". Companies can decide to give their CTO x or y portfolio, but by the time a company reaches the point where titles matter, it's hard to think of an intrinsically "CTO" responsibility that isn't covered by a VP/E or VP/PM. The one thing I can think of is "organization-wide architecture oversight", which is a pretty toxic role to assign. In orgs where the CTO does a bunch of stuff, I think it usually makes more sense to think of them as a VP/E with a different-shaped hat (or a VP/PM). There's definitely an interesting article to write about the VP/E who still codes!
- dnw 1y ago
  Exactly. Role and title are amorphous and depends on the industry, stage of the company, etc. Look at this CEO who codes: https://github.com/lattner https://github.com/lattner :-) (He was fund raising in July, August)
- dahart 1y ago
  > The one thing I can think of is “organization-wide architecture oversight”, which is a pretty toxic role to assign. I don’t know that I understand what you mean by toxic or why, but I’ve only ever seen the architecture overseer kind of thing in pretty small companies. In big companies, where there are multiple VPs of engineering and product management, that feels like the only time CTO even makes sense, and I expect they need to be setting vision and deciding where to invest (i.e. setting budgets) sometimes handling legal issues. In such large companies I’ve never seen a CTO providing architecture oversight, let alone coding. They might mandate the use or avoidance of some tech for reasons of corporate politics, but they are never in the trenches. Having been a founding engineer in a startup where I was called CTO and mostly wrote code, I feel like this is a ‘cute’ thing we do, using C-level role names for everyone in a 3 person company. I didn’t feel like a real CTO, or VP, and I feel like using C-level names for roles in startups and small companies is a little goofy and awkward. A lot of people seem to like inflated role titles, and VCs seem to like having someone in key roles who can both lead well and take all responsibility and blame. I feel like ideally the name CTO shouldn’t be used until it’s needed, which isn’t until there are enough devs to need managers, and enough managers to need VPs and enough VPs to need a CTO. If that were the case, then the possible things on the list of CTO responsibilities is a lot smaller and more definable than if we say CTO can be anything including the 2nd founder who’s more interested in coding than pitching or marketing.
  - tptacek 1y ago
    Think about what it says, in a larger team staffed with competent technical talent, to have a single person across all of it reconciling decisions with their own personal mental model. I think it's an attractive idea for a lot of aspirants! Who wouldn't want to be President of Code? But ambiguity is resolved by practitioners at the sharp end of the system.
emilsoman 1y ago
> do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"? I liked your take and curious to know what you think a CTO should be doing here
- rpdillon 1y ago
  Generally, I don't advocate for code getting thrown over the fence, regardless of the dynamics associated with the particular exchange. So the ideal approach here would be for the CTO to partner with a trusted engineer with some leadership capacity (tech lead, staff, etc.) and work through the architecture design and technical specifications for the project and get it off the ground and then hand that off to the tech lead that they partnered with so that they could carry it over the line, possibly with a team. Understanding the vision behind the project and why the CTO thought it was valuable is a critical aspect here. It turns what would otherwise be a low leverage project, mostly involving architecture and coding, into a much higher leverage project that's focused on educating and empowering other leaders in the organization. It also allows the CTO to stay close to the technical foundations and code so they don't lose touch with the organization that they're leading.
brabel 1y ago
So many things wrong with this sort of “CTO must not do what they enjoy but what is the list of responsibilities “ robotic thinking. So you think coding is not high leverage on a tech company. Do you even remember why your company exists anymore? Surely not to give people a living and let them be happy at work, according to you. Absolutely no, the only purpose of a company is to deliver value, but I bet you can’t even define value other than a hand wavy impact on ROI or whatever makes this quarter’s numbers look good. In any company, only a small number of developers can ship a difficult feature within a reasonable time frame, and that will almost always include the CTO if they were a founder and probably wrote half of the code. Only many years of experience working on a particular code base will give you that so no matter what you do, it may be years for someone else to get to the same level and that may never happen because the product just grew so large no one can do that anymore. If a CTO is still in the position to ship a large feature in a day , you are having an extremely hard time arguing they still should not do that. What could be more valuable use of a day in their schedule? Meeting with the CEO to discuss KPIs?? Fuck that. This hits close to home as you might have realized. But yes I am all for letting the c-level go back to the trenches once in a while to feel what the salaried guys are facing. They can’t fix things just based on third party accounts anyway.
- matwood 1y ago
  > So you think coding is not high leverage on a tech company. At the CTO level of a growing company it is one of the lower leverage things they can do. Setting technical direction, hiring the right people, and putting the right people in positions of power will all have much more impact than writing some code on the weekend.
  - brabel 1y ago
    You’re wrong man. These things you mentioned happen rarely, it’s not what you do day to day. If you don’t do some high value coding you have no clue how to steer a tech company at a technical level.
    - deleted 1y ago
      [deleted]

tptacek 1y ago

Again, implies there is such a thing as a "list of CTO responsibilities". Companies can decide to give their CTO x or y portfolio, but by the time a company reaches the point where titles matter, it's hard to think of an intrinsically "CTO" responsibility that isn't covered by a VP/E or VP/PM. The one thing I can think of is "organization-wide architecture oversight", which is a pretty toxic role to assign. In orgs where the CTO does a bunch of stuff, I think it usually makes more sense to think of them as a VP/E with a different-shaped hat (or a VP/PM). There's definitely an interesting article to write about the VP/E who still codes!

dnw 1y ago
Exactly. Role and title are amorphous and depends on the industry, stage of the company, etc. Look at this CEO who codes: https://github.com/lattner https://github.com/lattner :-) (He was fund raising in July, August)
dahart 1y ago
> The one thing I can think of is “organization-wide architecture oversight”, which is a pretty toxic role to assign. I don’t know that I understand what you mean by toxic or why, but I’ve only ever seen the architecture overseer kind of thing in pretty small companies. In big companies, where there are multiple VPs of engineering and product management, that feels like the only time CTO even makes sense, and I expect they need to be setting vision and deciding where to invest (i.e. setting budgets) sometimes handling legal issues. In such large companies I’ve never seen a CTO providing architecture oversight, let alone coding. They might mandate the use or avoidance of some tech for reasons of corporate politics, but they are never in the trenches. Having been a founding engineer in a startup where I was called CTO and mostly wrote code, I feel like this is a ‘cute’ thing we do, using C-level role names for everyone in a 3 person company. I didn’t feel like a real CTO, or VP, and I feel like using C-level names for roles in startups and small companies is a little goofy and awkward. A lot of people seem to like inflated role titles, and VCs seem to like having someone in key roles who can both lead well and take all responsibility and blame. I feel like ideally the name CTO shouldn’t be used until it’s needed, which isn’t until there are enough devs to need managers, and enough managers to need VPs and enough VPs to need a CTO. If that were the case, then the possible things on the list of CTO responsibilities is a lot smaller and more definable than if we say CTO can be anything including the 2nd founder who’s more interested in coding than pitching or marketing.
- tptacek 1y ago
  Think about what it says, in a larger team staffed with competent technical talent, to have a single person across all of it reconciling decisions with their own personal mental model. I think it's an attractive idea for a lot of aspirants! Who wouldn't want to be President of Code? But ambiguity is resolved by practitioners at the sharp end of the system.

emilsoman 1y ago

> do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"? I liked your take and curious to know what you think a CTO should be doing here

rpdillon 1y ago
Generally, I don't advocate for code getting thrown over the fence, regardless of the dynamics associated with the particular exchange. So the ideal approach here would be for the CTO to partner with a trusted engineer with some leadership capacity (tech lead, staff, etc.) and work through the architecture design and technical specifications for the project and get it off the ground and then hand that off to the tech lead that they partnered with so that they could carry it over the line, possibly with a team. Understanding the vision behind the project and why the CTO thought it was valuable is a critical aspect here. It turns what would otherwise be a low leverage project, mostly involving architecture and coding, into a much higher leverage project that's focused on educating and empowering other leaders in the organization. It also allows the CTO to stay close to the technical foundations and code so they don't lose touch with the organization that they're leading.

brabel 1y ago

So many things wrong with this sort of “CTO must not do what they enjoy but what is the list of responsibilities “ robotic thinking. So you think coding is not high leverage on a tech company. Do you even remember why your company exists anymore? Surely not to give people a living and let them be happy at work, according to you. Absolutely no, the only purpose of a company is to deliver value, but I bet you can’t even define value other than a hand wavy impact on ROI or whatever makes this quarter’s numbers look good. In any company, only a small number of developers can ship a difficult feature within a reasonable time frame, and that will almost always include the CTO if they were a founder and probably wrote half of the code. Only many years of experience working on a particular code base will give you that so no matter what you do, it may be years for someone else to get to the same level and that may never happen because the product just grew so large no one can do that anymore. If a CTO is still in the position to ship a large feature in a day , you are having an extremely hard time arguing they still should not do that. What could be more valuable use of a day in their schedule? Meeting with the CEO to discuss KPIs?? Fuck that. This hits close to home as you might have realized. But yes I am all for letting the c-level go back to the trenches once in a while to feel what the salaried guys are facing. They can’t fix things just based on third party accounts anyway.

matwood 1y ago
> So you think coding is not high leverage on a tech company. At the CTO level of a growing company it is one of the lower leverage things they can do. Setting technical direction, hiring the right people, and putting the right people in positions of power will all have much more impact than writing some code on the weekend.
- brabel 1y ago
  You’re wrong man. These things you mentioned happen rarely, it’s not what you do day to day. If you don’t do some high value coding you have no clue how to steer a tech company at a technical level.
  - deleted 1y ago
    [deleted]