Years ago, my friend Greg wrote about his progression from one of Stripe's first hires to its CTO.

The post resonated with me a lot. It was the first honest perspective I'd seen that shared the 'guts' of the CTO role.

You start off writing a bunch of code and knowing how all the systems work. You're on-call 24/7. You're the go-to person when there's a big production issue. Over time, you start giving away your Legos.

And as the team grows, there's this big existential question that starts to pop up: What should a CTO even do?

Most corporate roles are relatively well defined. The CEO fundraises and hires the exec team. The CFO manages the cash balance of the company and sets the budgets. The COO ensures the processes at the company work effectively. The CRO owns a sales number.

But the CTO role is more nebulous. In the early days, CTO is more or less equivalent to "the most technical co-founder" (that's how we decided the title, anyway). But as the org grows, the role has to change.

I've talked with a bunch of early-stage founders about the 'technical founder' role. Most of them seem to have the same dilemma that I had when we hired our VP of Engineering; they aren't sure what to do!

Here's the framework I wish I'd had during my own journey.

The CTO Archetypes

Although there's no set role for a CTO, there are a few different archetypes that a CTO might fall into. These are the most common 'shapes' that need filling as a company scales.

For each one, I've included a few examples of different leaders to help give you an idea of what they look like. If you want to get better, start reading their writing.

People leader

Some CTOs are what you would call a VP of Engineering. They're responsible for growing the engineering org, and making sure it is working effectively.

They probably own things like recruiting, the engineering ladder, and headcount allocations. They have a deep understanding of what a high-functioning organization looks like.

I haven't met him, but I'd say that Will Larson at Calm falls into this camp. He's a fantastic people manager and literally wrote the book on staffing and leading eng teams. If you read a number of his blog posts, you'll notice that he's an expert in thinking systematically about building an organization.

At Segment, Tido Carriero very successfully filled this role. He started as our VPE, and went on to build these processes across product and design as well. He set the blueprint for company-wide recruiting and leveling (in addition to many many other things, Tido is wildly good).

Architect

Some CTOs love to think about what the next version of a system might do.

They are technology experts, and spend a lot of time thinking about the primitives that can unlock big wins in engineering efficiency.

At Segment, I'd say a combination of Rick Branson, Albert Strasheim, Achille Roussel, and Daniel St. Jules, filled the architecture role (though many others contributed as well). They built many of the building blocks that allowed us to scale our pipeline to each next step: Dedupe, Centrifuge, the split between Ctlplane and Dataplane, and our new APIs. I found these folks (particularly Albert) also tended to be quite good at vendor evaluation and negotiation.

To be honest, I'd wished we'd formalized this role a bit more, just because of the outsized impact it can really have. Whenever we'd have a building block that was 'platform-worthy', it'd inevitably serve us for years.

I'd say Armon and Mitchell of Hashicorp fall into this camp. Jeff Dean doesn't officially have the title of CTO, but my impression is that he also has a role like this as well.

R&D

Some CTOs love to push the org towards the next big product opportunity.

It's hard to find people who have the urge to push the company in a new direction for months without much progress.

Yet these R&D types are essential. A company needs these individuals if it wants to reinvent itself.

At Segment, I'd say this was the role that my co-founder Ilya and I took most often (as well as early PMs like Kevin, Alex, and Sperandio). That R&D led to the launches of Cloud Sources, Personas, Functions, and our Dev Center.

I've worked with a bunch of ex-Cloudflare folks, and they all mention that John Graham-Cumming fits into this camp too.

At Cloudflare, a small set of engineering teams that live outside of the main "Engineering Org". They build interesting new prototypes of products to an MVP level, and then see if the main org was excited about picking it up and taking it over. Apparently this is how Cloudflare Workers was incubated, amongst other products.

Marketing / Customer-facing

The last archetype of CTOs focuses on marketing and interacting with customers.

If you market to developers, your customers will want to hear from someone who is both senior and very technical. These CTOs often find themselves on the conference circuit, meeting with large clients, and writing blog posts or doing other forms of thought leadership.

Werner Vogels at AWS is probably the best example of a marketing and customer-facing CTO. No doubt there are others like him.

When it wasn't R&D, this was also the role I stepped into more often than not.

Being a founder helped give me historical + global context for Segment. A long practice of writing technical posts helped me write for our blog in a way that was authentic and resonated with our users and potential hires.

The secret superpower of these CTOs is that they will get an overwhelming flood of customer feedback. One of the most valuable things you can do in this role is synthesize it and make sure that feedback makes its way back to the product teams.

What's in a name

A quick word on the CTO title...

Most of the founders I talk with fixate on the title of CTO, and don't think from first principles about why it should exist in the first place.

There are certainly good reasons to bestow a CTO title. In my mind, there are three reasons why companies might do this.

Public facing engagements – it can be much easier to speak at conferences or on a panel with a 'bigger' title. If you are doing a lot of this, the CTO title can legitimately be helpful.

Hiring – candidates are always more excited to talk to folks who are perceived as leaders. If you are a candidate, you don't have a lot of signal about how things work in a company, so the title is a proxy.

Engineering authority – The extra authority that comes with a title can help companies make changes they might not make otherwise. This one is a bit silly in my opinion, because most CTOs stop writing code. Nonetheless, I've heard of some CTOs enforcing engineering norms by fiat.

Whatever it is, try to worry less about the title as possession, and think more about the title as a tool. It's a tool that should serve you, not the other way around!

There were numerous times in my own journey that I talked with Tido about giving up the CTO title. By the end of my time at Segment, there were other people in the org who I think could've benefitted more from it.

My own path

To make this more concrete, I can give you a flavor of my path after Tido joined. It's a little bit of a mishmash, so I'm categorizing projects by their broad strokes.

• brand (eng blogging): we had to hire great engineers really quickly, and we were having trouble attracting them. I started putting out content to build Segment as a 'world-class brand', which also doubled as internal documentation. Later, Rick picked this up and started our popular "Segfault" talk series.
• arch rewrite (warehouses): we had a large-ish infra project to re-write our warehouses pipeline. I helped work with the team to limit the scope and nail down some of the goals (not-coding). Most of the hard work came from the warehouses team.
• arch rewrite (centrifuge): similar story here, we had a big re-write in the works. I worked with a small team to get it landed and spread the work spread between more of the team (again, the engineers on the team did the heavy lifting).
• new feature R&D (event delivery): we had a problem going back to the beginning of Segment that we couldn't tell people what was happening to their API calls. I worked with the team to help refine the requirements and give feedback on the architecture + featureset to solve the customer problem.
• eng management (destinations / platform): I did some eng management and leading a few small teams, mostly spending time on things like goal setting, metrics reviews, some hiring, career development, and narrowing requirements.
• new feature R&D (dev center): pushed for the 0 > 1 version of our developer center. It was a bit hacky, but also helped prove out the demand for becoming more of a platform and unlocked a number of sales objections.
• new feature R&D (functions): based upon the work we did building out our Developer Center, pushed to get a new product delivered (Functions) which was supposed to unlock custom use cases and professional services.
• cross-functional work (digital): Ilya and I teamed up with a very fun cross-functional team to build a bridge between sales, marketing, and EPDS. It was particularly helpful having founders who would work across the different parts of the org for this.

Spread across all of that, there were a decent number of public presentations, blog posts, bits of data analysis, sales calls, and talking with customers.

If this seems a little bit random, well, it is. [1] It's sort of akin to Reid Hoffman's role as the "firefighter in chief at Paypal". I've seen a lot of founders who constantly embrace important (but perhaps unexciting) problems at the company and run towards the fire.

Deciding where you want to be

If it wasn't clear already, building a startup requires a lot of different skills! And the CTO title can give you a lot of flexibility to lean into your strengths.

But here's my advice: think of yourself as a founder first, and CTO second. Stay humble and don't let the title of CTO get in the way of what's best for the company.

If there's one thing that most successful founders have in common: they tend to be good at picking up new skills on the job. The best founders I know don't run away from this constant "series of mini-games", they embrace it. So if you can, lean into each new problem the company faces.

Remember, you can always hire someone to fill any one of these archetypes. But you can't hire more founders.

---

Thanks to Victor Pontis, Kevin Niparko, and Gordon Wintrob for giving feedback on drafts of this post.

[1]: Part of it also came down to knowing nothing about management at the age of 24. I'd like to think I've learned a lot in this dimension since!