As an early-stage CTO, I really appreciated this insight-from-the-future about how my role might change over time if we're ultimately successful.
One interesting difference with our company is that I hit the bottleneck of "I need to be doing more spec work and less engineering work" more quickly - possibly because we were relying on contractors who couldn't (or wouldn't) take on as much of that spec work themselves. I started to really feel this pain point at 3-4 other full-time engineers, where I was sort of trying to stay ahead of them and make sure that upcoming features were fully specc'ed and met the business needs as opposed to chipping in and coding myself.
I'm definitely tinted by my own experience, but it seems like 8-10 other engineers is a really late point to hit this bottleneck - did you have a PM that was also working to help plan the features to reduce this burden on you?
I was a CTO for a little more than two years. When I joined we had 3 people as direct reports which grew to around 12 when I left. Besides hiring people, all I felt like I was doing was product manager work with talking to clients about their requirements and putting those into stories, tasks etc. Additionally I would pull together discussions on the evolution of our stack and handle the finances around the cloud implementations of our technology (on Azure). What else does a CTO do? I deeply disliked it because I was working for 14 hours a day most of which was dead time but communication was frequent enough that I couldn’t do anything else.
Hi, author here. I would probably agree with that. We only managed to go that far because the first engineers were quite experienced and super proactive. We also had a PM (essentially part time, since he was in charge of other areas too) and the CEO giving a lot of product direction.
It would have been really hard to do with more junior people (or contractors) without process. We are in a better place now, and planning to start hiring more junior people next year. I think without the correct support structure and process in place, we would have done a disservice to jr engineers. It's part of my focus now, though.
My suggestion would be no one should be CTO at the beginning. Limit titles at the start since it gives you flexibility. Lee Holloway wasn't "CTO" or "VP of Engineering" when Cloudflare started; I was "Programmer".
Agreed on having the flexibility. I think that's the key, the self awareness and ability to adapt. I don't think having CEO/CTO/CMO for founders is a bad idea though. Even at Cloudflare, CEO and COO were co-founders. I am more curious about what it takes to grow from a founder CTO to a public company CTO, same way than other founder roles can. Or maybe it's just too hard.
Anyway, I am flexible John! Totally onboard to give up my title if you are interested to come over and help us RevenueCat go public ;)
Same could be said for CEO, you aren't really acting in the capacity as would be described by a guidance counselor. However, it is a nice signifier as to who "the boss" is. Same for CTO, it tells people, "this person owns the technical stuff", which at a software company is super important IMO.
In my first startup (circa 2000 or so), no one had a title except the CEO (because ... someone needed to be a CEO, as you mention in another reply).
However, when I was on a roadshow through Silicon Valley, almost everyone I met (a few tens of people over a month) kept asking "so, what's your title" and writing it on the title-free business card I just gave them. One of the conclusions of that roadshow was that business cards HAD to have a title; I added "CTO", one of my co-founders had 2 stacks ("VP Product" and "VP R&D") which he used depending on who they were meeting. We both did the same kind of work.
My conclusion would be "don't have titles internally - but have some consistent externally visible titles for those people you meet who need them".
I haven't needed to do a roadshow since then, I don't know if that's still common in the valley - but that ritual of asking for my title and writing it on the just-received title-free business card was so prevalent, that I assume some people would still look for that.
Well a big reason I took the CTO promotion at my company was because I wanted to get out of programming and overhaul our stack and overly expensive implementation (which we were hugely successful at, dropping costs by more than 60%). Is a CTO required to code?
> Simplifying, we could say that the CTO role is closer to architecture and code; whereas the VPE would be in charge of processes and management.
Hmm, not sure I fully agree with this separation between CTO and VPE (Engineering).
At large companies, the CTO is more of a public-facing technical person (e.g. Amazon's Werner Vogels), who doesn't necessarily have a team under him/her; or, if it does, it's a team of other CTOs (e.g. Google's Will Grannis, or VMware's Chris Wolf), as part of an "office of the CTO".
My sense is that, for startups, the CTO role is usually interchangeable with VP of Engineering; but most people prefer the former because it almost implies "founder" too.
It's a pity that there's confusion around these roles, especially if applied to different type of companies, or stage of companies (early stage vs late stage vs public).
Great article. I'm curious about one thing, if Miguel happens to read this - it seems like early engineering hires are primarily located abroad. Was that strategic - and does it help/hurt with building the engineering culture? Or were they purely financial decisions?
Hi! I could tell you that we were visionaries and we knew a pandemic was going to come, so we were super prepared, but that would not be true.
In the early days, Jacob and I discussed a lot whether we wanted to be a remote company or not. We were very attracted to the idea, and firmly believed it was the future. But as you mentioned, we were concerned about the ability to move fast and setting the culture. The first employees we hired from our network were actually based in SF, so it was not a problem.
One of the early employees wanted to move back to his hometown, and we started to move to a more remote first environment (eg more async comms, everyone using their own cam for meetings even if they were in the office, etc). We hired our first engineer remotely (who we had the pleasure to work with in the past) and we never looked back.
It's been challenging (communication, compliance,...). But overall, we are super happy. I have a strong network in Spain and the UK, and we have access to world class talent that do not necessarily want/can live in the Bay Area. Also no immigration issues!
Even Jacob, my co-founder and CEO left the Bay Area. Being prepared was extremely helpful when the pandemic hit, since most processes were already in place.
Important note, we DID NOT do it for financial reasons. We pay same salary (based on SF) no matter where you live in the world.
One interesting difference with our company is that I hit the bottleneck of "I need to be doing more spec work and less engineering work" more quickly - possibly because we were relying on contractors who couldn't (or wouldn't) take on as much of that spec work themselves. I started to really feel this pain point at 3-4 other full-time engineers, where I was sort of trying to stay ahead of them and make sure that upcoming features were fully specc'ed and met the business needs as opposed to chipping in and coding myself.
I'm definitely tinted by my own experience, but it seems like 8-10 other engineers is a really late point to hit this bottleneck - did you have a PM that was also working to help plan the features to reduce this burden on you?