From founder to technical director. What lessons have I learned? Who can we take an example from?
Originally published January 12, 2022
Calvin French-Owen is the co-founder and CTO of Segment and is primarily focused on building Segment's backend infrastructure and data processing pipeline.
Content
Many years ago my friend Greg wrote about how he went from being one of Stripe's first employees to its CTO.
This post piqued my interest. This was the first honest look I've seen showing the “guts” of the CTO role.
You start by writing a bunch of code and knowing how all the systems work. You are in touch 24 hours a day, 7 days a week. You are the main assistant when serious production problems arise. Over time you start donate your Lego pieces teammates.
And as the team grows, a big existential question arises: What should a technical director do anyway?
Most corporate roles are relatively well defined. The CEO raises funds and hires a management team. The financial director manages the company's cash balance and creates budgets. The COO ensures the efficient operation of processes in the company. CRO is responsible for the number of sales…
But the role of the CTO is more nebulous. In the early stages, CTO is more or less equivalent to “to the technical co-founder himself” (at least that's how we defined the name). But as the organization grows, the role must change.
I've talked to a bunch of early stage founders about the “CTO” role. Most of them seem to be facing the same dilemma I faced when we hired the VP of Engineering: they don't know what to do!
Here is the diagram I would like to have during my journey.
CTO Archetypes
While there is no specific role for a CTO, there are several different archetypes they can fall into. These are the most common”figures” that need to be filled in as the company grows.
For each of them, I've given a few examples of different leaders so you can get an idea of what they look like. If you want to improve, start reading their blog/twitter.
People's Leader
Some CTOs might be called VPs of Engineering. They are responsible for developing the engineering organization and ensuring that it operates efficiently.
They are likely responsible for things like staffing, engineering ladders, and staff allocation. They have a deep understanding of what a well-functioning organization looks like.
I don't know him, but I can say that Will Larson from Calm falls into this camp. He is a fantastic people manager and literally wrote the book about recruiting and managing teams of engineers. If you read some of his blog postsyou will notice that he is an expert in a systems approach to building an organization.
In Segment Tido Carriero coped with this role very successfully. He started as our vice president and then built those processes into product and design. He developed a company-wide recruiting and alignment plan (among many other things, Tido is wildly good).
Architect
Some CTOs like to speculate about what the next version of a system might do.
They are technology experts and spend a lot of time thinking about technical solutions that can provide great opportunities to improve the efficiency of engineering solutions.
At Segment, the role of the architect was played by Rick Branson, Albert Strasheim, Achille Roussel And Daniel Saint-Jules (although many others contributed as well). They created many of the building blocks that allowed us to scale our pipeline to each next step: Dedupe, Centrifugedivision between Ctlplane and Dataplane, as well as our new APIs. I have found that these people (especially Albert) are also very good at evaluating suppliers and negotiating.
Frankly, I wish we could formalize this role more, simply because it can have such a huge impact. Whenever we have a building block worthy of our service, it will inevitably serve us for many years to come.
I would say that Armon And Mitchell from Hashicorp fall into this camp. Jeff Dean does not officially hold the title of CTO, but it seems to me that he also plays a similar role.
R&D engineer (research engineer)
Some CTOs like to push the company to create the next big thing.
It's hard to find people who have the desire to push a company in a new direction for months without making much progress.
However, such employees are necessary. The company needs such people if it wants to reinvent itself.
At Segment, I would say that this was the role that my co-founder and I filled most often Ilya (and also early PM Kevin, Alex And Sperandio). This research and development led to the launch of several major areas such as Cloud Sources, Functions and our Dev Center.
I've worked with many former Cloudflare employees and they all mention that John Graham-Cumming falls into this camp as well.
Cloudflare has a small set of engineering teams that live outside of the core team. They create interesting new product prototypes to the MVP level, and then see if some division is interested in picking them up and adopting them. Apparently this is how it was created Cloudflare Workersas well as other products.
Marketing/Customer Relations
The final CTO archetype focuses on marketing and customer experience.
If you're marketing to developers, your clients will want to hear from someone who is both senior and very technical. These CTOs often attend conferences, meet with major clients, write blog posts, and engage in other forms of thought leadership.
Werner Vogels from AWS, is probably the best example of a CTO working in marketing and customer success. No doubt there are others like him.
When I wasn't doing R&D, I mostly stepped into that role.
Status founder helped me gain historical and global context for Segment. My years of technical writing experience have helped me write for our blog in a way that is authentic and resonates with our users and potential collaborators.
The secret superpower of these CTOs is that they receive a huge amount of feedback from customers. One of the most valuable things you can do in this role is synthesize it and make sure that feedback reaches the product teams.
What's behind the name?
A few words about the position of technical director…
Most founders I talk to get hung up on the CTO title and don't think about why it even exists.
Of course, there are good reasons for giving the title of CTO. In my opinion, there are three reasons why companies might do this.
Participation in public events – speaking at conferences or discussions with a “big” title can be much easier. If you give these kinds of presentations frequently, the CTO title may be helpful.
Simplify the hiring process – candidates are always more willing to communicate with people whom they perceive as leaders. If you are a candidate, you don't have much information about how things work in the company, so the title is an indirect confirmation.
Engineer's authority – The additional authority that a title provides can help companies make changes that they might not otherwise make. In my opinion, this point is a little silly because most CTOs stop writing code. However, I have heard of some CTOs enforcing engineering standards by fiat.
Whatever the case may be, try to worry less about the title as a property and think more about the title as a tool. This is a tool that should serve you, not the other way around!
Along the way, I repeatedly discussed with Tido the possibility of resigning from the position of technical director. Towards the end of my time at Segment, there were other people in the organization who I thought could benefit more from it.
My own way
To make this more concrete, I can tell you about my journey after joining Tido. It's a bit of a hodgepodge, so I categorize the projects based on what they have in common.
Brand (blogging): We needed to hire great engineers very quickly and were having trouble attracting them. I started publishing content to create Segment as “world class brand“, which was also used as internal documentation. Rick later picked it up and started our popular “Segfault” conversation series.
Recycling domain warehouses: We had a large project to recycle a warehouse conveyor. I helped the team limit the scope and define some goals (not coding). Much of the heavy lifting fell on the warehouse team.
Recycling domain centrifuge: similar story, we had a lot of rework in the process. I worked with a small team to polish it up and distribute the work among a large number of team members (again, the engineers on the team did most of the work).
Development of a new feature (event delivery): Back in the early days of Segment, we had a problem where we couldn't tell people what was happening with their API calls. I worked with the team to help clarify requirements and provide feedback on the architecture + feature set to solve the client's problem.
engineering management: I've managed and led several small teams, mostly spending time setting goals, analyzing metrics, hiring, career development, and narrowing requirements.
R&D of new features (developer center): promoted version 0 > 1 of our developer center. It was a bit of a hack, but it helped prove that we wanted to be a platform and alleviated a number of sales objections.
Development of new functions (features): Based on the work we had done to build the Developer Center, we were promoting a new product(s) that would unlock custom use cases and professional services.
cross-functional work (digital): Ilya and I teamed up with a very interesting cross-functional team to build a bridge between sales, marketing and EPDS. It was especially helpful to have founders who could work in different parts of the company.
Among all this was a decent amount of public presentations, blog posts, data analyses, sales calls and conversations with clients.
If this all seems a little random, that's because it is. It's like a role Reed Hoffman as “Chief Fireman at Paypal”. I've seen a lot of founders who constantly jump at the important (but perhaps uninteresting) problems of the company and running towards the fire.
Decide where you want to be
If you haven't figured it out yet, building a startup requires a lot of different skills! And being a CTO can give you more leeway to play to your strengths.
But here's my advice: think of yourself as a founder first and CTO second. Stay humble and don't let the CTO title stop you from doing what's best for the company.
There is one thing most successful founders have in common: they tend to are able to acquire new skills in the process of work. The best founders I know don't run from this constant “series of mini-games” but embrace it. Therefore, if possible, delve into every new problem the company faces.
Remember, you can always hire someone who fits any of these archetypes. But you can't hire more founders.
Other translations by the author
Since you have read to the end, I will be glad to see you in my tg channel. Now I’m actively writing excerpts on essay by Paul Graham. 1-2 daily. Posts on this topic can be found under the tag #pg. I don't force anyone 🙂
