Why I code as a CTO

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.

> When I was figuring out my role as CTO, I read Greg Brockman’s blog post about defining the CTO role at Stripe. He talked to a bunch of other CTOs and realized there’s enormous variance in what the role looks like. Some CTOs are technical visionaries, some are org builders, some are infrastructure-focused. The commonality is that great CTOs figure out where they can create the most value given their particular skills, interests, and company context.

> For me, that’s meant writing a lot of code. It works because of my particular context: I enjoy building software more than org design, I have deep customer and codebase knowledge that makes me particularly effective, and we’ve hired strong engineering managers.

It appears like you became a CTO, because you co-founded the company, not because you rose to the rank.

If you were to join a different company with this approach you are taking, I doubt if you would even reach Staff level.