One job, many roles: The different skills needed to be a successful CTO
madewithlove.be
madewithlove.be
The CTO role is a visionary one. You're responsible for looking outside the organization at new technological developments and deciding how they may impact the organization's strategy; identifying new technical areas that warrant some exploratory investment; prototyping new systems, sometimes with the help of a small team of engineers who enjoy that stuff; and advocating for innovation within the organization.
Think of the role of Larry & Sergey (technically Presidents of Product/Technology, respectively) vs. Urs Hoelzle (VP Eng) at early Google. Larry & Sergey were responsible for making sure that things like GMail, Google Maps, 20% time, Chrome, etc. got funded and Keyhole, Android, Blogger, Writely, etc. got bought. Urs instituted the engineering culture, made sure the right engineers got into the right roles and were able to be productive, technical debt got paid down (slowly), new systems were written as necessary to scale, etc.
The CTO role, properly defined, is the perfect place to kick a technical founder upstairs and yet still retain their expertise in innovation. The problem is that many CEOs conflate the two roles, assign VP responsibilities to a CTO with a personality type more suited for the CTO role, never hire a real VP, and then wonder why the organization devolves into chaos. If you're doing it right the bulk of the engineering organization should report up through the VP of Engineering and the CTO should have only a small number of special-projects reports.
Obviously a President is "higher" than a Vice President, but most companies have a VP Eng/Product, but not a President of Eng/Prod
The etymology, I think, is specific to some quirks in corporate law, which still has some anachronisms from the 1600s. When you form a new organization, there are 3 positions that are assumed to exist: President (overall leader), Treasurer (responsible for keeping the books & finances), and Secretary (responsible for writing down meeting minutes). These are enshrined in corporate law, so when you form a new corporation, the bylaws need to specify holders for these offices (it's common for the founder to hold all 3, or to split them up among founders). The idea of a corporation in the 1600s didn't really envision today's massive multinational tech companies, so the actual org structure departs fairly significantly from these "official" offices.
There's a rough correspondence that's developed though: President = CEO, and Treasurer = CFO, and Secretary = whoever's keeping the minutes. Sometimes you'll see this in official titles, as "President and CEO of X". Sometimes - particularly when you have a visionary CEO who needs a strong operational COO - the President title will be assigned to the COO. This is Gwynne Shotwell's title at SpaceX, and is a strong indication that actual operational leadership of the organization rests with the COO. A "Vice President", by analogy, is someone who helps out the President with the details of their duties. In the U.S. government there's only one Vice President, but many corporations have dozens.
Google's tripartite leadership, with Eric as President & CEO, Larry as President of Product, and Sergey as President of Technology, was a way of showing that all 3 of them were in charge, and actual leadership rested with the triumvirate. If Larry had been VP of Product (a title actually held by Jonathan Rosenberg), it would've put him subservient to Eric, which is not how Google's leadership was actually structured.
The reason most companies don't do this is that it's usually a really bad idea: having multiple bosses typically results in the destruction of the organization. Google could get away with it because they were so far ahead of the competitors and so profitable that having Larry & Sergey running around sponsoring crazy innovative products did not seriously impede the running of its normal business. It also speaks extremely well to the working relationship among the triumvirate, and Eric's humility in leadership.
Thank you for providing historical context in explaining these roles and how they worked at Google.
> the working relationship among the triumvirate, and Eric's humility in leadership
Respect!
The full-stack hacker building the MVP is the lead technical guy in the first stage of the company when formal titles have yet to be defined.
That person should probably become CTO in the next stage, unless he/she is just plain lacking/disinterested on the vision front and wants to remain involved in the minute details of the product (which is not uncommon in my experience).
When they become CTO, a VP Eng should be hired to take the MVP to the next level in terms of process, security, and scalability.
Assuming they remain an individual contributor (the "not uncommon" scenario I refer to above)... well that means the organization might have two vacancies going forward to fill instead of one.
Using Google as an example for how things should work is generally a poor idea due to the huge outlier nature of the company.
I've worked in a startup (about 30 ppl) where the CTO was one of the founders and he was doing nothing but holding the company back with his decisions and his 0-architecture-spaghetti code. My first day, when I saw all the trash going on I thought "ok I can't really quit my first day so they'll have to fire me".
Decided to take ownership and start treating him like any other team member, reviewing and declining his merge requests (those weren't use before I came, they just commited all over the place), refactoring, planning ahead because otherwise we would have never delivered on time - his own technical debt extended feature delivery time by weeks. He was aware and admitted his "lack of skills", but wasn't aware of how much he actually lacked.
We managed to take it out the gutter and polish it up a lot in the next two years, but after all the mess and his obvious lack of knowledge, he still remained the CTO, long after I left. So please, if you are a CTO of a startup and are aware you lack skills, don't try to drive technical decisions and actively look for a replacement. Your decisions can create friction for whole company and burn it to ground right before it takes off. And if you work under a CTO like that, just take the damn responsibility and challenge dumb stuff or quit, or you might fall into the sloppy spaghetti.
When the debt got solved - and finally we could open the market in other countries and maintain old ones without causing chaos by each change - the company was nearly burned cash-wise. They got acquired, I left soon, they hired more developers and the situation is better now altho they pivoted.
In my case the founder/CTO was very capable but after a point he just didn't want that position because of some reasons, and he left. The company then decided to just assign the next-in-line people as a group of 3 to act as the CTO replacement. That didn't work very well, and actually 2 of them ended up leaving too. After that we finally hired a guy specifically to be the CTO, and it's been great after that.
(I left the company after a while, but it's still going great with that latest CTO)
I knew a few companies, where founders were fighting over C-level roles.
If a company under 10 people has a CTO it is a bad sign.
If a company over 20 people doesn't have a CTO it is also a bad sign.
I also know a bunch of companies, where the CEO doesn't tolerate other C-levels, for ego reasons.
I worked for a series A startup client with ~50-60 employees (30 or so were engineers) and they had a VP Eng but no CTO. SaaS/mobile app company.
I've seen this occur in practice, and I'm asking you why that's a bad sign.
And just because they have a job title that you can theoretically hire above doesn't mean they're going to like it. And if they don't like it they'll probably quit (might be a good thing) - I know I would.
There are other options though:
1. Put in place a development plan for your founding CTO, and other C-levels, so they can actually grow with their roles. Again, this isn't something that will work in all cases, but it can certainly help. My CEO has been through something similar, from a tiny 2 person startup, to now successfully running a 200+ person company.
2. Transition them into a new role. Tricky, and not going to work for a lot of people, but possibly an avenue worth considering.
[1] Not only can you bring in a CTO above this, but also SVP and EVP roles.
In a small company CTO seems more like a cool title than actually a real role.
VP Eng configures engineering's organizational structure, sets processes, and manages engineering managers.
VP Eng doesn't make architectural or technology decisions.
VP Eng is a good hire for many startups that start out with a CTO who isn't a specialist in management (which will be most founding CTOs).
In large companies, C-suite roles all mean “someone who comes up with company strategy given a particular set of incentives.” E.g.:
• A CEO is the voice of the Board of Directors within the company hierarchy, and—because they can be fired by the Board—is incentivized to strategize in the direction that will give shareholders value and address their demands.
• A COO is ultimately responsible for the company’s operations, both its operational expenses (e.g. product sitting in warehouses depreciating) and operational revenue (liabilities incurred for income unmatched by deliverables); and is on both sides incentivized to strategize in the direction of making the operations pipeline “leaner”—in est, getting other parts of the supply chain to “hold the bag.”
• A CTO (or CIO, depending on the type of company) is ultimately responsible for any IP assets on the balance sheet; and for any expenses that go into producing such IP. As such, they’re incentivized to create and fund R&D efforts (but also to make them lean), and to push to acquire companies with valuable IP (but to be a miser in the M&A negotiations.) They’re also incentivized to find new ways to exploit any technological resources on the balance sheet, in order to increase their liquid value.
• A CPO (Chief Product Officer—not that many stable, large companies have anyone by that name) is ultimately responsible for exploiting developed or acquired IP assets by building operational revenue sources “around” them, and is measured by the new revenue sources they create. This is what a startup’s “business founder” really is, most of the time, except when they’re raising (during which they’re more playing the CEO role.)
I would liken a company’s C-suite to a Congress: it’s a bunch of people with mostly equivalent responsibilities (define top-level strategy and delegate out the execution) but different constituencies driving their beliefs and preferences.
If you’re actually doing anything in your job that a “corporate Congressman” wouldn’t do, then you’re not really in a C-suite role; or, at least, you have multiple roles within the company, and your C-suite role is just a part-time gig.
(I would highly encourage the latter POV: if a technical cofounder is both a CTO and a Head of Engineering, then later they can give away or delegate one of those titles while retaining the other. I say “delegate” because, as a cofounder, they’re a shareholder on the Board, so ultimately they’re “above” whoever the CTO is, through the office of the CEO, even if they don’t personally end up holding any C-suite title in the end.)
I have seen companies that have both. Purposefully before Googling it myself;), my personal experience in such cases CIO would be more business oriented and have a more software/data oriented view; whereas a CTO would be more implementation, technology, infrastructure, enforcement of standards and policies orientation.
Edit, after Googling, other disagree with my experience: CIO is for internal operations, CTO is for external business:
https://www.linkedin.com/pulse/difference-between-cio-cto-ra...
https://www.telegraph.co.uk/business/ready-and-enabled/cio-v...
How I might explain this to a very technically-inclined audience (the way I would explain this to an executive would be "lay out the management realities of what is expected of a CTO", then sit back and wait for any follow up questions).
It may depend upon how you sell the CTO role. If you get board backing, then the technically-inclined will tend to sort themselves out if you present the CTO role evolving into one that needs someone who no longer codes 20% of the time, but instead only in their limited personal time.
Instead, the role evolves into one more akin to a sell-side investment banker, with lots of communicating between lots of different stakeholders. Endless PowerPoints, traveling road shows to meet investors, if you haven't learned yet then taking etiquette classes so you can concentrate on the conversation around the table instead of stressing over being the only one to not know what they're doing at a table in a Michelin starred establishment, prepping your tech teams on how to present to due diligence teams at customers and investors, meeting with tech teams to get high-level presentations on product technical direction while translating board and CEO strategy into those teams' terms, meeting with the board and CEO to set strategy, researching and talking with analysts about industry direction before deciding what you believe that direction will be and defending your analysis, hashing over the same topics with the board and CEO and other C-levels in a nearly infinite number of permutations, learning golf if you have to, learning how to socialize from actual professional trainers if you have to, "have to" defined by the board and investors on any number of other areas, learn how to read and parse financial statements if you haven't already, hashing out share dilution events between C-levels and your technical teams, setting leadership examples for your technical teams, mediating between engineering/technical department heads if you're in a small enough company, recruiting for such department heads, working with a mentor on how to distill and package complex technical details into salient and succinct framing for leadership, take lessons from PR professionals on talking with the media, and on, and on, and on.
Faced with such hardcore managerial demands acting as a translating layer between the technical and investor/C-level layers, and clear expectations that the board and investors want someone who dives into them without a backward glance at firing up Emacs in Javascript mode at work, most sane early founder CTO's who love the technology for its own sake would leap at the opportunity to take the reins of a VP/EVP/SVP type role depending upon the size of the company, where there is a clear expectation they would still be doing some pull requests, pair programming, etc.
a good leader also listens to his team and doesn't make decisions against the teams judgement. so it's not always necessary to replace an inexperienced CTO. you can also give the CTO the opportunity to get the experience they need in order to continue.
I'd say it really depends on your situation - do you like the product? Do you like the team? Do you have stuff to learn? And most importantly, are they willing to let you take the lead instead of backstabbing you?
I had a lot and I'm almost feeling like "I've been through this stuff before" and that demotivates me. But I will accept the argument that learning (by teaching) never stops.
I do like the team. The product? well, it's challenging but I'm not using it. I don't have stuff (at least technical) to learn unless they decide that we need to start moving quickly and not be stuck in legacy code. They started doing microservices with 0% testing and I'm still trying to teach them about contract-driven APIs
> I did not get the job
Well that was a predictable outcome.
Which was probably a blessing in disguise.
The trick of course is defining what the remaining duties are that fall up to the CTO. Specifically, making them desirable to that founder. Chief prototyper, evangelist, and vision-setter might be a good mix.
I thought this post captured a lot of the intricacies of being a CTO:
I imagine it only works if you have a CTO who's doesn't let the change in reporting structure bother them (i.e. someone who isn't egotistical or vain).
VP Eng and CTO should be peer positions both reporting up to the CEO. The VP Eng's job is to keep the company's existing product working and maximize its value to the market. The CTO's job is to search for new potential technical developments or market opportunities that could alter the company's strategy. They need to report directly to the CEO as well to ensure that information flow doesn't get impeded by a VP Eng more focused on what the world looks like now than what it'll look like in the future.
It's the norm to rain fire and brimstone on someone's past decisions when they become your inherited present. At the same time, there's a reality that those past decisions were probably made for reasons, known to be not ideal, and have to change in the future.
Personally, I'd much rather never have those technical trade-offs; but I'm also a realist. The same is true of process - certain things that are bread and butter to small companies are anathema to an organization of 300. We seem to lose sight of that.
Obsession with titles is a real thing. Getting a "VP of Engineering", "Director of Engineering" or "CTO" onto your resume can affect how your career prospects change over time. It is frustrating that failing at being a capable CTO can set you up better than succeeding at being an exceptional Team Lead.
Another top comment of this article describes what the tasks of a VP of Engineering are... except that those are really what a Team Lead does daily.
Titles are really only of some use inside an organization. Between organizations, they are not comparable.
My story: after two tough "failures" and some temporary consulting for a few months, I have joined an investment firm in San Francisco as an external consultant/contractor for the last 2-3 months, with the goal of defining a long-term role after getting to know each other better.
They are now offering me a CTO position within the firm.
They want me (with a small team) to build a number of things that can be considered technology products, such as: a platform to manage a large advisory board; a system to perform a technical due diligence on large companies; a source engine to collect data and metrics with the purpose of augmenting deal-sourcing and decision-making. Other tasks include: defining and maintaining the taxonomy for the IT industry, and representing the firm as an "external" CTO (events, conferences, etc).
Given it's a quite unique and uncommon role in an investment firm, I am now working on a plan to define these things in more details.
<ask> If any of you had experiences in similar roles (perhaps at investment firms in the East coast?), or feel you can dispense good advice, I would love to grab a coffee and pick your brain on a few things. </ask>
Also, wish me luck! One bad career turn is bad, two are really tough to handle. To make a long story short: #1 was as CTO in a startup for a bit over a year, the two founders made a ton of mistakes, not my fault; #2 I was founder/CEO of a company, things didn't go well and after ~1.5 years I had to leave the company, with some important disagreements among founders, but thankfully not much drama. Before that I had two very successful roles at AWS and VMware for a total of ~8 years.
The whole history of ups and downs as founder/CEO/CTO and other roles you've had, sounds like it would make for educational story-telling time for other people who are learning to navigate these waters.
Godspeed, would love to (somehow) hear how it turns out.
The one thing I would say though is don't hand out a title like CTO early. It's overly grand, reduces your flexibility to change and just isn't necessary. It's very tempting for a small team to give out grand titles but it's a mistake. Sure someone has to be CEO, but no one has to be CTO.
There needs to be a passionate owner. A technical leader who understands customers and their needs, understands what’s technically possible, and has the imagination to connect those two things.
I don’t know what you call that person, but it sure helps if he’s got a c in front of his name. CTO, CPO, whatever.
This something the article kinda glosses over, but maybe shouldn’t.
(I’m not sure if this person is great for the CEO role, by the way, just because of how freaking busy the CEO tends to be. There’s too much for her to do to also fulfill this role.)