Live data from Hacker News

Why I code as a CTO

assembled.com

1–10 of 304 posts

Re: Why I code as a CTO

#2
You can be the chief officer of a 1 person organization, or a 100,000 organization. Or pick another dimension such as SLOC, number of projects/products, teams, DAU, etc.

CTO has a different meaning at different levels of scale.

With a headcount of around 250 employees, you can still work directly on implementation. But with a headcount of 100,000, it doesn't make sense.

Re: Why I code as a CTO

#3
I really appreciated this blog post, John, to know that you're doing what I've been doing without a guilty conscience.

I'm a VP eng/research at a startup and also feel like one of the few people apart from the founders who can push major technical initiatives by just doing it themselves, due to: business context, technical chops, architectural judgment, grit, and seniority to pull in cross-functional stakeholders to help out.

However, I have often questioned if it is correct that so few people in the org can do this and if I shouldn't be enabling others to do it themselves instead.

How have you been able to navigate not having any direct reports? Who does your engineering org report to and how are you able to manage conflict between org builders and your technical vision?

Re: Why I code as a CTO

#4
You have no direct reports. That’s the difference. You’re effectively the solo Fellow level engineer at the company, driving the largest tech decisions based on time spent in code; and you’re doing your job well by familiarizing yourself with all parts of the code, including areas that need bug fixes.

This is not the same as an SDM or Director or people with lots of reports. It’s mostly the “having reports” part that causes devs to reduce or stop coding, since managing and project leadership are whole jobs.

Re: Why I code as a CTO

#5
Articles like these are kind of hard to parse because there's no well-defined meaning to the title of "CTO". Our "CTO" codes, probably more than anybody in the company, but that's because he's got a founder-inherited CTO title that mostly just means "he can do whatever he wants" --- we're happy with that, what he wants is practically always great.

That's one definition of a CTO. Another CTO type is the opposite: "the thing you call an engineering founder when they've done so much customer-facing work that you have to take their commit bit away from them". This is, I think, an even more common archetype than the other one.

Then you have the toxic CTO definitions --- CTO as "ultimate decision maker for engineering", or, God help you, CTO as "executive manager of all of engineering".

You'd have to be specific about what kind of CTO you are to really make the question of why you code interesting.

Re: Why I code as a CTO

#6
I think this captures the technical track dual to CEO 'founder mode'. As cringeworthy as many found that term, it captures the plain truth that there are certain types of changes that only people at the top are (or at least feel) empowered to make in an organisation's structure or processes. A CTO can choose to ship substantial, opinionated pieces of software that wouldn't (at least quickly) emerge from lower level teams. Arguably the best way to communicate a radical design is working code. That said, I do think the degree to which a company can push down this sort of constitutional power is a good measure of long term organisational health.

Re: Why I code as a CTO

#7
> I currently manage no direct reports and ship a lot of code. Not in an “I dabble when I have free time in between meetings” way, but in an “I shipped multiple substantial features last quarter” way

Very loose definition of a CTO.

Re: Why I code as a CTO

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

Re: Why I code as a CTO

#9
post #5

Articles like these are kind of hard to parse because there's no well-defined meaning to the title of "CTO". Our "CTO" codes, probably more than anybody in the company, but that's because he's got a founder-inherited CTO title that mostly just means "he can do whatever he wants" --- we're happy with that, what he wants is practically always great. That's one definition of a CTO. Another CTO type is the opposite: "the…

I found the article interesting, even given a large range of possible definitions of CTO.

I do wonder if it is possible to agree on a general definition of the CTO from the perspective of the job to be done, rather than how they do it.

For example, we could say the job of the CTO is to ensure the company remains technically competitive. If they do it by means of building an organization then so be it. If they rather do it by writing code themselves, then why not?

Re: Why I code as a CTO

#10
> I currently manage no direct reports and ship a lot of code.

This is a wildly different status than almost all other people with this title.

I’m glad this person still likes coding, and they seem to be great at it, but this role doesn’t match up to the title. This doesn’t really matter until he wants to switch jobs and realizes near zero CTO positions outside of this one company will require few meetings and zero management. He’d have to change title to principal engineer or something but an article titled “Why I code as a Principal Engineer” doesn’t quite grab attention the same way.

Post reply on HN