The CTO Journey at a Small Startup
zapier.com
zapier.com
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
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.
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.
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.
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.
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.
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.
EDIT: yep, just as I suspected :D https://www.quora.com/What-will-John-Carmacks-role-be-at-Ocu...
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.
He had two excellent abilities: convincing the board to give more money to IT, and hiring good people to spend the money wisely.
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?
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.
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.
Maybe it is time we stop using those titles. I personally saw that confusion cause serious issues at at least two companies.
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.
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.
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.
The audience is other C-level executives, the board, important customers, and of course the company employees themselves.
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.
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.
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!