CTO

On the role of CTO

I get asked frequently to define the role of CTO, and I thought I would share some of my thoughts.

First, let's start by talking about what a CTO is not.


1) CTO is not an engineering role. CTO is not the top of the technical ladder, it is not the natural progression for engineers over the course of their careers to strive to achieve. It's not a role most people who love coding, architecture, and deep technical design would enjoy doing.

2) From 1, it follows that the CTO is not necessarily the best engineer in the company.

Now, with that out of the way, what is a CTO, if not the best writer of code and natural conclusion of the engineering ladder?

The challenge with defining CTO is that if you look across the folks who hold that title you will see many different manifestations. Some are the technical cofounders. Others were the best of the early engineers. Some started at the company with the title, while others such as myself were promoted into it over time. Some became CTO after holding the title of VP of Engineering. Some focus on the people and processes of engineering, hiring/recruiting. Others focus on the technical architecture, or the product roadmap. Some are the face of the company to the outside technical world. Some CTOs have no direct reports, others manage the entire engineering organization.

In looking at these examples the best definition that we can make is that the CTO is the technical leader the company has in its current stage of evolution. To me, that is rather unsatisfying, and missing the hardest part of the job. I believe instead that the CTO should be the strategic technical executive the company needs in its current stage of evolution.

Strategic: Thinking about the longer-term, and helping to plan the future of the business and the elements that make that possible

Executive: Taking that strategic thinking and helping to make it real and operational by breaking down the problem and directing people to execute against it


So, what does a CTO actually DO?


First and foremost, a CTO must care about and understand the business, and have the ability to shape business strategy through the lens of technology. The CTO is an executive first, a technologist second. If the CTO does not have a seat at the executive table and does not understand the business challenges the company is facing, there is no way the CTO can guide the technology to solve those problems. The CTO may identify areas where technology can be used to create new or bigger lines of business for the company that align with the overall company strategies. Or the CTO may simply ensure that the technology is always evolving to anticipate and enable the potential futures of the business and product roadmap.

No matter what, the CTO must understand where the biggest technical opportunities and risks for the business are and focus on capitalizing on them. When you see a CTO focused on recruiting, retention, process and people management, that is because it is the most important thing for the technology team to focus on at the time.

Strong CTOs also have significant management responsibility and influence. This does not always mean that they are deeply involved in the day to day management, but part of maintaining your ability to shape the direction of the business and the business strategy is the ability to put people behind solving the problems you believe will impact the business. Other executives will have ideas and needs for technology. The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.

Things get tricky when the team grows to be very large, and the CTO starts to hire VPs to manage all the people. Many CTOs give up all of their management responsibilities to their VPs, sometimes going so far as to not even have the VPs reporting to them. It is incredibly difficult to maintain influence and effectiveness as an executive with no reporting power.

I saw this clearly at my previous employer, where the most senior members of the technical staff in large business areas would often hold the title of CTO for that area. These people were always highly respected and technically capable. They understood the business and the technical challenges for the business, and were often called upon to help inspire the engineering team and help with recruiting.

Their downfall was that they often lacked the direct management oversight of any teams, and because technology was frequently viewed as an execution arm, they did not have much strategic influence.

If you are a leader with no power over business strategy and no ability to allocate people to important tasks, you are at best at the mercy of your influence with other executives and managers, and at worst a figurehead. You cannot give up the responsibility of management without giving up the power that comes with it.

The CTO who does not also have the authority of management must be able to get things done purely by influencing the organization. If the managers won't actually give people and time to work on the areas that the CTO believes are important, the CTO is rendered effectively powerless.  If you give up management, you're giving up the most important power you ever had over the business strategy, and you effectively have nothing but your organizational goodwill and your own two hands. Hope you're really a 10X engineer!

My advice for aspiring CTOs is to remember that it's a business strategy job, first and foremost. It's also a management job. If you don't care about the business your company is running, if you're not willing to take ultimate responsibility for having a large team of people effectively attacking that business, then CTO is not the job for you.

Special thanks to my editors Amanda Peyton, Cate Huston and EIC ChrisK.

The Best Decision I Made in 2014

Many people think that the role of leadership is decision-making. The desire to be the one who makes the calls drives some to climb the ladder so that they can become "The Decider."

I'm sorry to disappoint those who want this to be true, but in my experience the role of leadership is in fact to make as few decisions as possible, and to make the decisions that you are forced to make utterly mundane. Here are some of the mundane decisions I've made this year:
The first pass of a seating chart
Perfunctory approvals around uncontroversial hiring
Rubber stamping of well-thought-out architectural decisions
Signoff on budgets for vendor products we clearly need

I set up a lot of policies over the past few years. Some of them I've blogged about, for example, promotion committees. But I've also created policies around how new languages and frameworks are introduced, on-call rotations, even how we buy office equipment (oh the glamorous job of a CTO!). The goal of pretty much all of these policies is to make future decisions easier, and to empower various people on my team to make decisions without me.

So, I don't believe that good leadership is heavy on decision-making. That being said, you can't be a leader without occasionally setting a direction, which leads me to The Best Decision I Made in 2014. It started with a twitter conversation about continuous delivery, on January 3. I have been thinking about continuous delivery forever, and trying to move Rent the Runway in that direction for as long as I've been running engineering. At the end of 2013, we created a task force to make our deployments, then-weekly and taking up to 6 hours to do, faster and less painful. The team was well on their way to success by January 3. And so, inspired by my conversation, I sent this email:

Starting in Feb

Camille Fournier Sat, Jan 4, 2014 at 9:40 AM
To: tuskforce
I want the one ring to release every day. Even if there's no user visible changes. Even if there's traffic. Even if it means we break things
That's it. I held my breath to see the responses. And as they rolled in, one by one, all of the engineers agreed. They were excited, even! So I started to tell others. Our Head of Product. My CEO. I told them "this might cause some pain, the first couple of weeks, as we figure out how to do this safely, but it's important." 

And so, come February, we began releasing every work day. And it was glorious. 

What made this decision so successful? What did I learn from this?

A great decision is often not a revolutionary move. We were doing the technical work to enable this already. The team wanted to be deploying more frequently. All I did was provide the push, to raise the bar just a little bit higher and express my confidence that we would easily clear it. 

The thing I learned from making this call wasn't anything about the decision itself. It was about the process that got me there. You see, this came about right after new year's, when things were quiet at work and I had some time to sit alone and think (or, in this case, tweet). All the sudden, I had ideas again! And it hit me: I need regular time alone, away from meetings and people, in a quiet room with a whiteboard. 

So I started blocking my calendar every Wednesday afternoon, and things started to change for me. In those Wednesday afternoons, I thought through the next evolution of our architecture. I thought through our engineering ladder, and our promotions process. I thought about problems I was having with people and how I could make those relationships better. I did some of the foundational work to create the 7 completely new talks that I wrote and delivered in 2014. I made time for the important but not urgent. In short, I grew from a head of engineering focused on the day-to-day into a CTO who thought a lot about the future.

The best decision I made in 2014 wasn't, actually, to tell my team to release every day. That's just the story I've been telling myself all year. The best decision, really, was to make time to think.