Most comments here are assuming that there’s only “one, true CTO” role when in fact the role is essentially “everything that’s left over after you’ve delegated

Most comments here are assuming that there’s only “one, true CTO” role when in fact the role is essentially “everything that’s left over after you’ve delegated to others”. > 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.