The CTO Journey at a Small Startup(zapier.com)
zapier.com
The CTO Journey at a Small Startup
https://zapier.com/engineering/startup-cto/
46 comments
> C suite member still doing coding 80% of the time is extremely unlikely in my experience.
That depends on what you mean by "small startup". In a VC-backed Silicon Valley startup where you're hiring fast and aiming for massive growth in as short a time as possible? You're probably right. Small startup that's self-funded or close to it with a tiny team, like what happens in most of the rest of the world? Yeah, you're probably rolling up your sleeves and getting your hands dirty for quite a while to come, because the code that you're selling has to come from somewhere.
Different startups have different constraints. It sounds like you're used to the SV-style startup where the constraint is time, rather than money. A lot of businesses have their most senior technical staff write code because they don't have the cash to hire more developers but their product still needs to be built.
That depends on what you mean by "small startup". In a VC-backed Silicon Valley startup where you're hiring fast and aiming for massive growth in as short a time as possible? You're probably right. Small startup that's self-funded or close to it with a tiny team, like what happens in most of the rest of the world? Yeah, you're probably rolling up your sleeves and getting your hands dirty for quite a while to come, because the code that you're selling has to come from somewhere.
Different startups have different constraints. It sounds like you're used to the SV-style startup where the constraint is time, rather than money. A lot of businesses have their most senior technical staff write code because they don't have the cash to hire more developers but their product still needs to be built.
Fair response. My thought of startup is definitely in the mold of rapid growth an expansion to MVP and finding product-market fit as fast as possible. I think its a safe assumption to make on HN given that it is a public facing arm of YC, but I should have qualified it for clarity.
In a small business, consultancy, or more bootstrapped world you're completely right. Theres plenty of technology businesses that I've worked with where the CTO is one of the co-owners or the engineer who's been there the longest and they'll come on site to fix equipment or get on the phone with me to walkthrough unexpected behavior/etc.
In a small business, consultancy, or more bootstrapped world you're completely right. Theres plenty of technology businesses that I've worked with where the CTO is one of the co-owners or the engineer who's been there the longest and they'll come on site to fix equipment or get on the phone with me to walkthrough unexpected behavior/etc.
It's not been the sole dominion of HN alumni for years, all sorts of businesses and coders are here.
Exactly right. For at least some of the 99% of startups that are not VC-backed, it can be the constant struggle between working /on/ the business and working /in/ the business, when resources are limited. That can mean a CTO deep in the code on a daily basis, or even the CEO taking a project from time to time. When you're small and broke, you just get what needs to be done, done, regardless of titles.
I think the confusion is semantics. Most people think of a startup as a growth business. A startup is different from a small business. Whereas a small business may aim for $10M in revenue per year in 5 years (and maintain that), a startup may aim for $1B in revenue per year in 5 years.
So, if you're the CTO in your second year of business and still writing most of the code, you're probably a small business.
That said, in my experience, if you're a CTO and not able to at least understand the source code, you're a liability. I've worked for CTOs like that, and they were unable to manage risk or estimate beyond random guesses. And, it's unlikely that such a person can forecast or expand business safely without at least some trusted advisors.
So, if you're the CTO in your second year of business and still writing most of the code, you're probably a small business.
That said, in my experience, if you're a CTO and not able to at least understand the source code, you're a liability. I've worked for CTOs like that, and they were unable to manage risk or estimate beyond random guesses. And, it's unlikely that such a person can forecast or expand business safely without at least some trusted advisors.
Do most people really think that?
I think Paul Graham uses the term "scalable". But I have seen talking points from lots of big VCs and other figures in business who seem to think it's more about age, profitability, and management structure that define a startup.
To focus on the scalability point, I tend to agree that many only think of scalable businesses as startups, but I think the predicted numbers don't have to be in the billions to be considered a scalable growth business.
If you are a one man shop building an innovative product and you raised seed money from friends and family and hire 2 employees and expect to start making $1m a year as a 3 man shop in a few years, I think most people would call that a startup.
On the other hand, if you raise funds and build just another restaurant on the corner but with no innovation in either product or scale, then I think you are a small business.
I think Paul Graham uses the term "scalable". But I have seen talking points from lots of big VCs and other figures in business who seem to think it's more about age, profitability, and management structure that define a startup.
To focus on the scalability point, I tend to agree that many only think of scalable businesses as startups, but I think the predicted numbers don't have to be in the billions to be considered a scalable growth business.
If you are a one man shop building an innovative product and you raised seed money from friends and family and hire 2 employees and expect to start making $1m a year as a 3 man shop in a few years, I think most people would call that a startup.
On the other hand, if you raise funds and build just another restaurant on the corner but with no innovation in either product or scale, then I think you are a small business.
You made me curious, so I did some quick investigation on the etymology of the word. :) (sorry, insomnia)
Using Google NGram viewer, I looked up "startup" and quickly noticed that the word (in modern usage) seemed to be short for "startup costs". Interestingly, "startup costs" seemed to only come into use after the 60s and 70s and was often connected to financial instruments. So, I also plotted the word "options" and was surprised that the shape of that curve was the same as the curve for "startup". They just had different magnitudes.
I also learned that stock options became tradable instruments in the 70s. And, also, startups began being formed in the 70s. That is, they seemed to go hand in hand. In particular "startup" was used to describe speculative research and development ventures with high capital requirements.
More recently though, the word "startup" became being associated with small teams, minimum viable products, and micro seed funding. So, that could be what you mean.
Using Google NGram viewer, I looked up "startup" and quickly noticed that the word (in modern usage) seemed to be short for "startup costs". Interestingly, "startup costs" seemed to only come into use after the 60s and 70s and was often connected to financial instruments. So, I also plotted the word "options" and was surprised that the shape of that curve was the same as the curve for "startup". They just had different magnitudes.
I also learned that stock options became tradable instruments in the 70s. And, also, startups began being formed in the 70s. That is, they seemed to go hand in hand. In particular "startup" was used to describe speculative research and development ventures with high capital requirements.
More recently though, the word "startup" became being associated with small teams, minimum viable products, and micro seed funding. So, that could be what you mean.
At the end of the day, there are no rules and YMMV. As a curiosity, I wonder how much time John Carmack spent coding as CTO of Oculus. Chances are there are very few people in the market with his coding talent, and if someone like him wants to code, you're going to make it work.
EDIT: yep, just as I suspected :D https://www.quora.com/What-will-John-Carmacks-role-be-at-Ocu...
EDIT: yep, just as I suspected :D https://www.quora.com/What-will-John-Carmacks-role-be-at-Ocu...
>>C suite member still doing coding 80% of the time is extremely unlikely in my experience.
The analogy I use is that a CTO doing coding is like a CFO doing invoice processing or a COO dealing with routine office management matters.
The analogy I use is that a CTO doing coding is like a CFO doing invoice processing or a COO dealing with routine office management matters.
I am not sure if this is a troll but this is a terrible analogy given the nature of coding and the impact a strong engineer can have on a product, team, or business just through raw programming skill.
A CTO should have at some point been a strong engineer, but IMO once you gain the title of CTO you should broaden your perspective and focus on higher impact activities (and yes, there are activities that have higher impact than raw programming skill).
true but your analogy is terrible.
on a scale of 1-10, invoice processing is like a 3 while coding is a 8.
I was a consultant for a bunch of startups for 4-5 years, selling my services as a "CTO for hire" to them, and was full-time CTO in multiple startups to boot.
I had a general line/rule of thumb. At < 6 engineers, you had to write code regularly as the team was so small it couldn't carry the weight of a member of the tech team who didn't commit regularly.
At 12+ engineers, you didn't have time to in order to do the other work (management, prioritisation, reports, strategic thinking, etc.), well enough.
At 6-12 engineers (where I spent most of my time), I didn't have time to write code, but had to in order to keep the company moving. Cue 60-100 hour weeks for 10 years. Yeah.
I went to quite a few CTO events, and in all honesty, it was a surprise to many of them that I both knew how to code and that actually spent any time doing it. I thought it was insane that there are CTOs - many of them - that aren't interested in the practice of creating technology at a hands-on level, but I could also understand how that happened: in my location (London), it's quite normal for non-tech CTOs to pick up from founding CTOs after a few years.
It's a weird situation to be in, and eventually a couple of years ago I decided to evaluate what I wanted and wrote a list of what I liked and didn't like about my job as a CTO.
I realised all the things I enjoyed were actually the responsibilities of a senior engineer, and all the things I didn't like were the management and board duties of being a CTO. Slept on it for a week, resigned, applied for senior roles, and generally am much happier (2 years on).
It's worth really thinking about what you want from the role. If you're a co-founder, you can shape it, but you have responsibilities to your investors, wider board, exec team, managers and developers. Most importantly, your have responsibilities to yourself.
Choose your own adventure when it comes to being a CTO, but choose wisely and carefully.
I had a general line/rule of thumb. At < 6 engineers, you had to write code regularly as the team was so small it couldn't carry the weight of a member of the tech team who didn't commit regularly.
At 12+ engineers, you didn't have time to in order to do the other work (management, prioritisation, reports, strategic thinking, etc.), well enough.
At 6-12 engineers (where I spent most of my time), I didn't have time to write code, but had to in order to keep the company moving. Cue 60-100 hour weeks for 10 years. Yeah.
I went to quite a few CTO events, and in all honesty, it was a surprise to many of them that I both knew how to code and that actually spent any time doing it. I thought it was insane that there are CTOs - many of them - that aren't interested in the practice of creating technology at a hands-on level, but I could also understand how that happened: in my location (London), it's quite normal for non-tech CTOs to pick up from founding CTOs after a few years.
It's a weird situation to be in, and eventually a couple of years ago I decided to evaluate what I wanted and wrote a list of what I liked and didn't like about my job as a CTO.
I realised all the things I enjoyed were actually the responsibilities of a senior engineer, and all the things I didn't like were the management and board duties of being a CTO. Slept on it for a week, resigned, applied for senior roles, and generally am much happier (2 years on).
It's worth really thinking about what you want from the role. If you're a co-founder, you can shape it, but you have responsibilities to your investors, wider board, exec team, managers and developers. Most importantly, your have responsibilities to yourself.
Choose your own adventure when it comes to being a CTO, but choose wisely and carefully.
What is a non-tech CTO?
One previous CTO of mine frequently told us he hadn't written a line of code since the late 1970s, and even then he hadn't done much. He didn't know what an SSH key was, didn't know the difference between FTP and HTTP, and hadn't heard of MySQL (this was mid 2000s).
He had two excellent abilities: convincing the board to give more money to IT, and hiring good people to spend the money wisely.
He had two excellent abilities: convincing the board to give more money to IT, and hiring good people to spend the money wisely.
That's key to mgmt though it can be hard to hire people when you don't have the skills to judge.
Its hard to hire pepple you do have the skills to judge.
Sounds more like a COO than a CTO.
Sounds like he was just a technical manager
My experience comports with the parent. Most "CTO"s or "CIO"s I've met have a weak or non-existent technical background. I worked closely with a CTO whose only direct technical experience was a couple of CAD classes he took at a community college.
Generally, a CTO's tech "qualifications" are more from having some general knowledge about the technology ecosystem (e.g., they've managed software people before, and they know what Microsoft SQL Server is) than from any hands-on experience.
They will often be the type that have always been interested in gadgetry and tech, but basically only enough to subscribe to WIRED (back when that was a thing people did) and observe the industry casually. Not enough to get involved in the process themselves.
CxO is a fundamentally non-technical job, so I don't know what people expect from "technical" occupants. Technical people do poorly because the role is almost entirely subsumed by "business" responsibilities; that is, closing sales, talking to media/making presentations at conferences, sitting in meetings with lawyers and investors, setting budgets, and so forth.
Let me ask you, what is a "technical" CTO supposed to do?
Generally, a CTO's tech "qualifications" are more from having some general knowledge about the technology ecosystem (e.g., they've managed software people before, and they know what Microsoft SQL Server is) than from any hands-on experience.
They will often be the type that have always been interested in gadgetry and tech, but basically only enough to subscribe to WIRED (back when that was a thing people did) and observe the industry casually. Not enough to get involved in the process themselves.
CxO is a fundamentally non-technical job, so I don't know what people expect from "technical" occupants. Technical people do poorly because the role is almost entirely subsumed by "business" responsibilities; that is, closing sales, talking to media/making presentations at conferences, sitting in meetings with lawyers and investors, setting budgets, and so forth.
Let me ask you, what is a "technical" CTO supposed to do?
seconded its like saying a non accountant CFO
An Oxymoron.
Back in the early 2000s I worked for a telco. Telecom was having a pretty rough time following the dot com crash. They replaced the previous CTO with a CTO that had a financial background (would have been suitable for as a CFO). This blew my mind at the time. The explanation was simply he's going to be less persuaded by seniors managers arguing for projects on technical merit and more persuaded by the dollars and cents. Rightly or wrongly, it worked, they got out of trouble early and when the economy turned around he was swiftly replaced by a hacker CTO.
Primary goal of CTO's is to make sure that the technology serves the business.
As C-suite, you are also involved in setting the company strategy and are responsible for building the technical organization to own it.
Outside of executing the core strategy you can take an opportunistic approach to:
1/ create more strategic options for the company
2/ cut costs by automating or re-engineering business processes
3/ deliver an unfair technical advantage over competitors
4/ improve reliability of service
5/ introduce more technology in the rest of the business (sales, marketing, operations, ..)
Startup CTO's tend to combine many different roles as there are more roles than people to fulfill them. Generally startup CTO's wind up also doing product management, engineering management (people, culture), recruitment, SCRUM master, IT, support, BI, architecting and programming.
What you actually wind up doing depends on the needs of the business and the available talent in the company to delegate these roles to.
Outside of executing the core strategy you can take an opportunistic approach to:
1/ create more strategic options for the company
2/ cut costs by automating or re-engineering business processes
3/ deliver an unfair technical advantage over competitors
4/ improve reliability of service
5/ introduce more technology in the rest of the business (sales, marketing, operations, ..)
Startup CTO's tend to combine many different roles as there are more roles than people to fulfill them. Generally startup CTO's wind up also doing product management, engineering management (people, culture), recruitment, SCRUM master, IT, support, BI, architecting and programming.
What you actually wind up doing depends on the needs of the business and the available talent in the company to delegate these roles to.
The split between VPE and CTO is that a VPE is operational and internal-facing whereas a CTO is strategic and external-facing. Neither role involves coding if your company has a dozen engineers; senior individual contributors usually have a title like Chief Scientist or Distinguished Engineer.
A CTO role is essentially that of a Technical Product Manager. What distinguishes it from a traditional TPM is that, to do the role well, you also take on the aspect of being the technical "moral authority" for the company, setting the de facto engineering culture, and creating a compelling vision that goes beyond product management.
A CTO role is essentially that of a Technical Product Manager. What distinguishes it from a traditional TPM is that, to do the role well, you also take on the aspect of being the technical "moral authority" for the company, setting the de facto engineering culture, and creating a compelling vision that goes beyond product management.
I've seen it where they hire almost 80% junior programmers and have the CTO set the tone and pace and learning environment. It worked pretty well actually, but the core technology wasn't groundbreaking, more of a relationship based business doing complex CRUD.
all the rules go out the window if you are just building a CRUD app. i have seen non technical founders outsource everything to third world countries and still be successful.
Nobody has the same definition for the CTO / VPE split. If I search "CTO VP Engineering" on Google the first result is https://www.ivyexec.com/executive-insights/2015/cto-versus-v... which defines the CTO as someone in charge of a small team doing "technical exploration". At other companies that role would be something like "Head of Research".
Maybe it is time we stop using those titles. I personally saw that confusion cause serious issues at at least two companies.
Maybe it is time we stop using those titles. I personally saw that confusion cause serious issues at at least two companies.
Seems like I read a different take on CTOs / VPEs every week or two. I've been a VPE several times, and as a cofounder. I, personally, think that a company should never have a CTO until you split the role into two; a CTO & a VPE working alongside each other. In that situation, the VPE manages the team, makes sure things get done, etc. While the CTO is working with other "C-staff" planning the longer (year+ out) roadmap of the company, with a focus on Engineering.
I have struggled with these roles and names, similar to Bryan Helmig, the author of this post. I have consulted with some former bosses, that now lead engineering teams at some of the larger companies here in the bay area, and have come to the conclusion that most CTOs are really VPEs, just using the wrong title, but in the end, the title does not really matter. Since it is extremely flexible in definition.
I have struggled with these roles and names, similar to Bryan Helmig, the author of this post. I have consulted with some former bosses, that now lead engineering teams at some of the larger companies here in the bay area, and have come to the conclusion that most CTOs are really VPEs, just using the wrong title, but in the end, the title does not really matter. Since it is extremely flexible in definition.
C level is more prestigious to outsiders than VPEs at the very least, so I don't have a problem with managers being CTOs. Still needs to be an architect or "owner/gardener of technology"
C-levels are, first and foremost, performers. They should not be invested with real authority; they should just be the set of pretty faces that get trotted out to the media, run conference calls, give presentations, and sit on sales meetings. They are media, PR, and sales operatives.
A position in the C-suite is a nightmare for anyone who wants to do serious work, and there is no reason that people who have a primarily external focus should be invested with the authority to destroy the internals.
A position in the C-suite is a nightmare for anyone who wants to do serious work, and there is no reason that people who have a primarily external focus should be invested with the authority to destroy the internals.
Weird, as a COO this doesn't accurately describe me or my peers in the slightest bit. Sounds like you had a bitter experience somewhere along the way with a bad team.
Nah, I disagree. I'm not really bitter and I haven't met a C-suite that openly acknowledged their role as performers (though they are probably aware of it). There are a lot of people with strong non-performance skills who wind up in these roles (and I have met several such persons) because they're recognized as the most important leadership roles, and most people aren't going to say "no" to that.
But by that same token, the super-high visibility of the C-suite comes with a lot of constraints that hinder the freedom of people who are not primarily interested in the dog and pony show, because there is an expectation that CxOs will have a presence at various functions, meetings, and events that are not really related to their ostensible job functions, and because every public action of a CxO is subject to intense external scrutiny, including social media, etc.
Could a CxO come on HN and state his true opinions about things? Of course they would say they can, because the illusion loses its power when the curtain is drawn back, and it'd be a big story that "CxO of ImportantCo admits he's a big fat phony".
If their employer is small enough that nobody cares, then I'm sure it works fine because no one really cares. But if they get bigger, then it doesn't work fine anymore, and their history will be combed through by competitors and media alike in search of ammunition/scalps.
Really just need to get actors or media personalities for those roles so that real people can continue to be real and guide things intelligently, rather than constantly maintaining their persona and having to pull away from serious matters to attend irrelevant functions and presentations (schmoozing).
You can't really give the title "CxO" to people and not expect this kind of intrusive, restrictive, and distracting load to land on them, so it's better to compartmentalize the real tasks away from such titles.
But by that same token, the super-high visibility of the C-suite comes with a lot of constraints that hinder the freedom of people who are not primarily interested in the dog and pony show, because there is an expectation that CxOs will have a presence at various functions, meetings, and events that are not really related to their ostensible job functions, and because every public action of a CxO is subject to intense external scrutiny, including social media, etc.
Could a CxO come on HN and state his true opinions about things? Of course they would say they can, because the illusion loses its power when the curtain is drawn back, and it'd be a big story that "CxO of ImportantCo admits he's a big fat phony".
If their employer is small enough that nobody cares, then I'm sure it works fine because no one really cares. But if they get bigger, then it doesn't work fine anymore, and their history will be combed through by competitors and media alike in search of ammunition/scalps.
Really just need to get actors or media personalities for those roles so that real people can continue to be real and guide things intelligently, rather than constantly maintaining their persona and having to pull away from serious matters to attend irrelevant functions and presentations (schmoozing).
You can't really give the title "CxO" to people and not expect this kind of intrusive, restrictive, and distracting load to land on them, so it's better to compartmentalize the real tasks away from such titles.
You've never noticed how presentation, perception and appearance focused many C-level positions are?
The audience is other C-level executives, the board, important customers, and of course the company employees themselves.
The audience is other C-level executives, the board, important customers, and of course the company employees themselves.
CTO as a startup cofounder and CTO of a large (100+) company are such different roles that they should really have different names.
If you're CTO because you co-founded the company or you joined at an early stage and you just happened to be the most senior engineer at the time, you really have no idea what being CTO of a large company is like.
If you're CTO because you co-founded the company or you joined at an early stage and you just happened to be the most senior engineer at the time, you really have no idea what being CTO of a large company is like.
and thr same can be said of a CEO, COO, etc. Job titles are really meaningless in startups so who cares whether someone calls themselves a CTO or not?
I view the cto as the person who makes sure the 6 developers aren't using 6 different frameworks. I've worked at places where that was the case and the CEO knew nothing about coding and didn't offer much more advice than "you guys work it out". The problem is you sometimes get a dev who wants to use "insert esoteric bleeding edge tool here" and then leaves a huge mess when they leave the company 3 months later
I am literally leaving a failed company just like that, except the CTO is sticking around, and he is the one using the bleeding edge tools without collaborating with the rest of the team.
I don't see value in this article. The author asks a bunch of other people in high tech positions what they believe CTO should be. Unfortunately the plural of anecdote is not data.
For example "Don't innovate in the management structure." Sure if you're an average person, then don't. But some companies have (Valve, young Google) and shown outstanding results.
I'm very skeptical of reducing the CTO title to rules like this. This is garbage conversation fodder, it appeals to our weaker human side to create a facade of self-improvement but none of us are gonna remember this article in 2 months.
For example "Don't innovate in the management structure." Sure if you're an average person, then don't. But some companies have (Valve, young Google) and shown outstanding results.
I'm very skeptical of reducing the CTO title to rules like this. This is garbage conversation fodder, it appeals to our weaker human side to create a facade of self-improvement but none of us are gonna remember this article in 2 months.
Hello,
I'm having the same considerations and am writing about challenges CTOs of startups of different sizes face on a daily basis on http://cto.pizza
The concept is simple: we talk about your growth, team and tech challenges over a pizza. Let me know of any of you might be interested in grabbing one.
I'm based in Paris but we could figure something out over Skype or something if you have interesting stories to share!
I'm having the same considerations and am writing about challenges CTOs of startups of different sizes face on a daily basis on http://cto.pizza
The concept is simple: we talk about your growth, team and tech challenges over a pizza. Let me know of any of you might be interested in grabbing one.
I'm based in Paris but we could figure something out over Skype or something if you have interesting stories to share!
Good article, but why people are calling Software Engineers Hackers these days?
trinit(1)
Pretty smart article, good introspection, matches my experience and observation. Thanks for this
What this seems to be calling CTO is more akin to a most senior engineer/fellow/hacker. I've seen it called Chief Engineer before. That's the person the the CTO should be able to hold their own in a conversation with but being that person would seem be unlikely for an exec team member as the business grows.
*Titles are more to less meaningless unless there is internal conflict or you're interacting with someone external, ignore that bit and think in terms of roles