The day-to-day job of a senior manager depends greatly on the company you’re in. It would be silly of me to say that my job running a startup engineering organization of 70 people was the same as the job held by a senior manager who’s over thousands of people at a Fortune 500 company. Books upon books upon books are written about senior management at scaled companies from a general perspective. I’ve listed some recommended reading at the end of this chapter for general-purpose senior leadership advice. All of these books are fantastic and essential guidelines for senior leaders.
But we’re not general-purpose senior leaders. We’re technology senior leadership. This book is for the engineer who wrote code for a while and eventually moved into management, and successfully grew a career up along that path. And as engineers, we share some common responsibilities that are specific to our role as technologists and come partially from our upbringing working in that ever-changing world.
As technical senior managers, we bring special skills to an organization. In particular, we bring a willingness to embrace and drive change as needed. We’re able to question the way we do things now, and try different things if our current way of operating isn’t working. We understand that technology evolves quickly, and we want our organizations to evolve to keep up with these changes. We have a unique role, but we still need to succeed in our general senior management roles. It’s not enough to be a change agent; we have to create an organization that can successfully follow through on the changes we want to push.
Your first job is to be a leader. The company looks to you for guidance on what to do, where to go, how to act, how to think, and what to value. You help set the tone for interactions. People join the company because they believe in you, in the people you hired, and in the mission you helped to craft.
You’re capable of making hard decisions without perfect information and willing to face the consequences of those decisions.
You’re capable of understanding the current landscape of your business, as well as seeing into its many potential futures. You know how to plan for the months and years ahead so that your organization is best suited to handle those potential futures and capture opportunities as they come along.
You understand organizational structure and how it impacts the work of teams. You know the value of putting in place management that strengthens this structure rather than undermining it.
You can play politics in a productive way, in order to move the organization and the business forward. You work well with your peers outside of engineering and seek out their perspectives in addressing issues with a wide scope.
You understand how to disagree with a decision and commit to deliver on it even though you disagree.
You know how to hold individuals and organizations accountable for their output.
In his book High Output Management , Andy Grove breaks down management tasks into four general categories:
Information gathering or information sharing
Whether you’re a CTO, a VP, a general manager, or a head of engineering, your days are shaped by those four tasks.
WHAT IS MY JOB?
I came to engineering from what the industry likes to call a “nontraditional background.” I suffered (suffer?) a strong sense of impostor syndrome when interacting with folks from more traditional CS backgrounds. This was especially difficult when leading folks whom I perceived to be more technical than I.
This background, combined with a strong desire to be seen as smart and “right,” sometimes led to some less-than-productive conversations about technology directions. I’d find myself arguing the merits of a language choice or technology purely based on the technical merits. When this happened I became another engineer arguing in a group of engineers.
It took me a long time to realize that my job wasn’t to be the smartest person in the room. It wasn’t to be “right.” Rather, my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way.
I care about technology—it’s a factor in every decision we make as a team—but technology alone doesn’t make a productive and happy team. A good leader shapes technology discussions to inject the strategic objectives and take into consideration the nontechnical implications of a technical decision. It’s not about being the lead engineer, chasing the latest language or framework, or having the shiniest technology. It’s about building a team with the tools and attributes to build the best possible product for our customers.
I have a very opinionated view of the job of the CTO, especially as it applies to product-focused startups. I stand by it, but I realize that it’s not the universal model for CTOs at all companies. I also know that there’s a great deal of muddiness in senior levels of management. Where does the VP of Engineering fit in? How about the Chief Information Officer? Is that a role we need to fill? What about the product team?
Instead of trying to cover all of the variants of roles in senior leadership, I’m going to start by explaining some of the most common roles that senior management can play, and how those roles can fit together. These descriptions may make sense for your company, and they may not. Some people will be able to play several parts, some people will be able to play only one or two, and some companies won’t even need people to play all of these parts. All of them break down at large-enough companies, at which point you often have to look at these roles division by division. But by presenting a taxonomy, I hope to help you consider the possible skills you’ll need to be successful in various senior leadership positions. The common roles include:
Research and development (R&D)
Face of technology, external
Infrastructure and technical operations manager
Here are some combinations of these roles that I’ve observed personally and from a distance:
Business executive, technology strategy, organization, and execution: CTO or Head of Engineering (VP/SVP)
R&D, technology strategy, external face of technology: CTO, Chief Scientist, Chief Architect, sometimes Chief Product Officer, usually for a company that is selling a software-based product
Organization, execution, business executive: VP of Engineering, General Manager
Infrastructure manager, organization, and execution: CTO/CIO, possibly VP of Technical Operations
Technology strategy, business executive, and execution: Head of Product (or Chief Product Officer), sometimes CTO
R&D, business executive: CTO or Chief Scientist, cofounder
Organization and execution: VP of Engineering, sometimes Chief of Staff
As you can see, organizations can mix and match and define these roles in different ways depending on business needs. The CTO role in particular changes its focus wildly depending on the company, although most strong CTOs have a strategic function under their command, whether it’s business-focused, technology strategy, or both.
In an organization where the CTO is the executive manager of all of engineering, responsible for strategic leadership and oversight, what does the VP of Engineering do? What does a great VP of Engineering look like?
The VP of Engineering role varies just as much as the CTO role does, based on the needs of the organization. However, the VP role has one obvious difference from the CTO role. The VP is usually at the top of the management career ladder for engineers. This generally means that the VP is expected to be an experienced manager of people, projects, teams, and departments.
As companies grow, it’s common for the VP-level role to change from an organizationally focused job to a business strategy position. These people often act as mini-CTOs for divisions, balancing strategy and management. You may end up with multiple people in “VP of Engineering” roles who are responsible for portions of the engineering team. Their roles become more strategy-focused over time, while the organizational management duties fall more to their deputies at the director or senior director level. Let’s put the complexities of large companies aside and focus on the VP of Engineering that you’ll most likely encounter in a company that has a single person in this role.
As the person in charge of the day-to-day operations of the team, a good VP of Engineering has a solid handle on processes and details. She’s capable of tracking several in-flight initiatives at once and making sure they’re all going well. Often a great VP of Engineering is described as having a good “ground game.” This person is capable of dropping into the details and making things happen at a low level. While some CTOs will do this, if there’s both a CTO and a VP of Engineering, the VP is usually the one pushing the execution of ideas, while the CTO focuses on larger strategy and the position of technology within the company.
The VP of Engineering also handles a significant amount of management responsibility. She aligns the development roadmap to the hiring plan, planning out how teams need to evolve in order to make sense given the expected growth in the team. She may work closely with recruiting and run the hiring process, ensuring that résumé screening and interviewing are going smoothly. She should be a coach to the engineering management team, identifying and improving existing talent and working with HR to provide training and development resources for those leaders.
The VP of Engineering job is both a big one and a detail-oriented one. This is one of the reasons it’s such a hard job to hire for, even though most companies will need to hire this role in from outside. This person has to be good at quickly understanding what’s going on in an organization. She must be able to gain people’s trust and show wisdom in management and leadership. Unfortunately, most engineers are reluctant to trust people without technical credibility, but many managers at this level of seniority won’t be interested in going through a hard technical interview process only to take on a role that’s mostly focused on organizational management.
The VP of Engineering also needs to have some stake in organizational strategy, and often she owns this strategy entirely. She’ll be heavily involved in helping teams set goals to achieve business deliverables, and that means she’ll need to be closely aligned with the product team. She must ensure that the roadmap is realistic and that the business goals are translated into achievable goals for the technology organization. She should have a strong business and product instinct and a track record of getting teams to deliver big projects, including the ability to negotiate deliverables.
The people I know who excel in this role are capable engineers who care deeply about their teams and prefer to stay out of the spotlight in favor of creating high-performing organizations. They’re interested in the complexities of getting people to work together effectively. They want their teams to be happy, but they know that it’s important to tie that happiness to a sense of accomplishment. They represent the health of the team to the other senior leaders, and cultivate a healthy, collaborative culture. They are very comfortable identifying gaps in processes and managing highly complex, detailed work without getting overwhelmed.
At a small company or startup, “senior management” often implies that your title is CTO. And yet the CTO job is one of the least well-defined roles in the technical world. If you’re a CTO, what are you supposed to be doing? If you want to become a CTO, what do you need to do to get there?
Let’s start by talking about what a CTO is not. CTO is not an engineering role. CTO is not the top of the technical ladder, and it is not the natural progression engineers should strive to achieve over the course of their careers. It’s not a role most people who love coding, architecture, and deep technical design would enjoy doing. 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 the natural pinnacle of the engineering ladder?
The challenge in defining the role of the CTO is that if you look at the folks who hold that title, you’ll 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 being the VP of Engineering. Some focus on the people and processes of engineering, hiring, and recruiting. Others focus on the technical architecture or the product roadmap. Some CTOs are the face of the company to the external technical world. Some CTOs have no direct reports, while others manage the entire engineering organization.
After looking at all these different examples, the best definition I can give you is that the CTO is the technical leader at the company’s current stage of evolution. To me, that definition is rather unsatisfying, and misses the hardest part of the job. To expand, the CTO should be the strategic technical executive the company needs in its current stage of evolution.
What do I mean by “strategic”? The CTO thinks about the long term, and helps to plan the future of the business and the elements that make that possible.
What do I mean by “executive”? The CTO takes that strategic thinking and helps 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 be able to shape business strategy through the lens of technology. He is an executive first, a technologist second. If the CTO doesn’t have a seat at the executive table and doesn’t understand the business challenges the company faces, there’s no way he can guide the technology to solve those challenges. 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 he 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. If he is focused on recruiting, retention, process, and people management, that’s because it’s the most important thing for the technology team to focus on at the time. I present this idea in contrast to the notion that the CTO should focus on purely technical issues, as the “chief nerd.”
Strong CTOs also have significant management responsibility and influence. This doesn’t always mean they’re 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 putting 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’s incredibly difficult to maintain influence and effectiveness as an executive with no reporting power.
I saw this clearly at a 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 its technical challenges, and were often called on to help inspire the engineering team and help with recruiting. Yet they had trouble being successful because they often lacked the direct management oversight of any teams, and because technology was frequently viewed as an execution arm, they didn’t have much strategic influence.
If you’re a leader with no power over business strategy and no ability to allocate people to important tasks, you’re at best at the mercy of your influence with other executives and managers, and at worst a figurehead. You can’t give up the responsibility of management without giving up the power that comes with it.
The CTO who doesn’t 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, he 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.
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.
ASK THE CTO: WHERE DO I FIT?
I’m so confused by the various titles in engineering leadership. CTO, VP of Engineering—what’s the difference? How do I know which of these roles I want to hold?
I understand the confusion. There are numerous popular articles out there on the difference between these roles because it’s hard to give specifics about them beyond “it depends.” Of course, there are many different ways to do these two jobs.
To decide which job you want, you may ask yourself a few questions. Do you think you might cofound a company someday? Do you want to help oversee technical architecture and set up processes and guidelines for evolving it? Are you also willing to go deep into understanding the business side of things in order to ground that technical architecture in the company’s growth? Are you willing to do external events, speaking, selling to customers, and recruiting senior managers and engineers? Are you willing to deal with managing and mentoring senior individual contributors? You might be a good CTO.
How about management? Do you enjoy managing people? Do you enjoy making engineering processes more efficient? Do you like to have a broad view of the work being done by a team and a hand in prioritizing that work? Are you fascinated by organizational structure? Are you good at partnering with product managers? Are you willing to exchange depth of focus into technology details for focus on the effectiveness of the overall team? Would you rather sit in a roadmap-planning meeting than an architecture review? You’re probably more interested in following the VP of Engineering path.
Some people will have a mix of answers. I’ve been a VP of Engineering and a CTO, both times via promotion. I was always thinking about the technical architecture, but when my job required it I was happy to focus on the organization. For me, though, having only an organizational focus is not enough to keep me motivated. I like to think about organizational structure, but I get bored with the details of process and roadmap planning, and need to have some technical and business strategy oversight to be engaged.
The fastest route to becoming a CTO is to be a technical cofounder, but that guarantees you the job only so long as you and the startup grow together. The fastest route to being a VP of Engineering is to get management experience at a larger organization and then join a growing startup.
I’ll leave you with some advice my own VP of Engineering once gave me: “Wanting to be a CTO (or VP of Engineering) is like wanting to be married. Remember that it’s not just the title, it’s also the company and the people that matter.” Titles are definitely not everything.
One morning, the CEO wakes up and in the fresh morning light, she has a revelation. She sees an opportunity for the company to develop a new product line that can push the business to a new stage of growth. She spends some time sketching out this vision and presents it to the rest of the senior leadership team. On board with this change, they begin to make the moves needed to make the vision a reality. But it doesn’t happen quickly. There are in-flight projects to worry about. Some things are almost complete, and it would be a shame to cancel them before they got finished. All of these concerns mean that the teams are slow to come together to work on the initiative, until suddenly the question comes down: so, why aren’t you working on the top priority?
Priority changes from senior management can sometimes happen without warning. Leaders who are removed from the day-to-day schedules of the teams can forget that teams have long priority lists that may have been mapped out weeks or months ago and may take weeks or months to complete. So when these leaders see an opportunity or feel that the priorities of the organization need to change, they often expect that change to happen immediately, without consideration for the reality of the current state of affairs.
This question may be asked of managers at every level, but most often originates from senior management. Expect to get this question from your boss. When you feel the need to ask it of your own teams, ask yourself why they don’t understand what the priorities are and what they should be cutting to address them.
Do you know what the top priority is? Do your teams know what it is? Do the developers on those teams know what it is? Sometimes the answer to this question is simply a matter of communication. You don’t know what the top priority is, or you didn’t communicate it clearly and urgently to your management team, and they didn’t communicate it clearly and urgently to their development teams. You didn’t explicitly go through the list of things in flight and kill or postpone work in order to make room for this priority. You need to do that, if it’s truly urgent. Saying something is top priority is one thing, but making the actual tradeoffs on the schedule to get people moving on it is completely different.
We forget that the people above us or in different organizations don’t have the same detailed understanding of what our teams are currently doing, and why. I don’t believe it’s necessary to constantly provide minute details to peers and your manager for every team in your large organization. However, when you’re taken to task for not focusing on the right priority, it’s a sign that you and the CEO have a misaligned understanding of reality, and you need to get on the same page. Your team may be crunching to stabilize a system that’s causing frequent outages, or in the last push of a major project that has been ongoing for a long time. If you think that the team needs to finish their current work before shifting to the new top priority, you must communicate that clearly.
Be prepared to push both up and down to maintain or change focus. If you think a big project should be finished before slotting in new work, get as many details as possible about the value of that project, its current status, and the expected timeline. Be realistic. If someone above you has changed business focus so urgently that he’s willing to have this conversation, expect that you’ll probably need to compromise on the current work in progress and cut some parts short or move some people off of it. Your team may not be happy with the change. People generally don’t enjoy being pulled off of what they’re working on for a new executive whim, especially if they believe their current work is important.
The more senior the management and leadership position you take in a company, the more the job becomes making sure that the organization moves in the direction it needs to move in, and that includes changing direction when needed. You do this by clearly communicating the direction to your teams, and making sure they understand it and are taking the necessary steps to change course. Ask your teams for the list of projects the change will impact, so that you can communicate it upward. This will force your management team to actually think about the new initiative and start to plan for it. Ask for the goals of the initiative from its originator, and see how you can combine those goals with work already in flight.
Finally, never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in. You’re going to tell your own senior management and leadership team. You’ll hold an all hands meeting. You may need to send some email detailing the changes as well. A little bit of communication planning can go a long way in such situations. Try to anticipate the questions you might get and prepare answers for those questions. Be as clear as possible about the projects or structure to be changed, so there’s little room for confusion. And don’t forget to sell this change as a good thing!
You’ll also need to repeat information when you’re communicating up. When you want your boss to act on something, expect that you’ll need to tell him the same thing three times before he actually listens. The first two times, the issue may still resolve itself, but the third time, it’s a sign that something bigger needs to happen. You may be surprised to find that you start acting the same way toward your team. Many problems will get raised to you and then resolved on their own, so you may decide you need a degree of sustained struggle from your team before it’s time to step in. I’m not recommending that you adopt the “three-times rule” as a policy, but it does tend to happen, whether you plan for it or not.
The larger the organization, the harder it’ll be to change priorities quickly. If you’re working for a growing startup with a founder CEO, this slowness will frustrate him. The best thing you can do to manage this situation is to proactively keep the CEO informed about what’s happening and why. Do your best to show that you understand his priorities and tell him about the concrete steps you’re taking to meet those priorities.
In the summer of 2014, as the SVP of Engineering at Rent the Runway, I had a big challenge ahead of me. My CEO told me that she wanted to put me up for promotion to CTO at the next board meeting, but that as part of that promotion, I’d be asked to present the technology strategy to the board. She then returned every attempt I made at giving her this strategy until I finally created something that met her standards. And the rest, as they say, is history.
I suspect she didn’t have to put me through this exercise to promote me. The board was very happy with the fact that I had grown the team and developed the technology to a point of stability and high feature throughput. I’m incredibly grateful that she did push me through this exercise, however. During that process, I went from having only a vague idea of what setting strategy meant to having a concrete, forward-thinking strategy encompassing a way to think about both the technical architecture and the engineering team’s structure, which in turn ultimately influenced the way the company itself thought about its overall structure.
When I talk about senior leadership, I emphasize strategy as a critical element. Most people don’t even really know where to begin when it comes to setting strategy at the senior level. I know I didn’t. I had coaching, from the CEO and from an executive CTO coach that I was working with. I solicited input from my peers on the executive team. I posed theoretical questions to the senior members of the engineering team and used them to help me see some of the detailed problems. I certainly didn’t do it alone. So, with that in mind, what does setting technology strategy look like?
I started by considering the team, the technology we had currently built, and the company. I asked the engineering team where their pain points were. I asked several executives in various areas where they expected growth to come from in the future. Then, I asked myself several questions. I considered where the scaling challenges were now, and where they might be in the future. I examined the engineering team and found its productivity bottlenecks. I studied the technology landscape and wondered how it might change in the near future, especially as it pertained to personalization and mobile development.
Armed with my conclusions about the existing systems, teams, and bottlenecks, and having imagined the places where we could make things more efficient, expand features, or improve the business, I used the data to come up with a rough idea for a possible future. I spent some time sitting alone in a room with a whiteboard or paper and drawing out the systems in place at our company, slicing and dicing the systems and teams across various common attributes. For example, I looked at systems that were customer-facing versus systems that were internal operations–facing (such as warehouse and customer service tools); I looked at backend versus frontend. Because our technology had to model most of the business data to operate, I realized I had a unique insight into the way that data flowed and changed, and possible axes for evolution.
Once I had that data mapped, I could plan out actionable ideas to improve operational efficiency, expand features, and grow the business. I considered the places we would want to potentially limit or expand information sharing between systems. Did we want personalization systems that tried to operate on the real-time state of the world at all times, or did we want personalization systems that acted more like a view adjustment on subsets of the data? How could we use various product and operational attributes in parts of the data flow to have operational as well as personalized input into what our customers experience? All of this thinking forced me to consider the structure of the business, the needs of the customer—both internal and external—and possible future evolutions. By doing this research and speculation, I was able to design a technology strategy that supported these factors into the future.
I said earlier that the CEO sent back many of my attempts to get this work done. Really, she rejected two things. The first was an underdeveloped strategic plan that was almost entirely about system and architectural details and offered very few forward-thinking ideas beyond the next 6 to 12 months. It certainly did not attempt to address the business drivers that were critical to the team’s success. The second was my slide deck. As a speaker, I’ve been trained to make slide decks that are sparse, in support of an audience that listens closely. This board needed a deck that was very dense with information. It’s not uncommon for company boards to read through the slide deck before a meeting, so that the meetings can be focused more on details than on presentations. I didn’t understand this at the time, so I wasted a lot of energy trying to make something that wasn’t informative on paper. Lesson learned.
As you can see from this tale, good technology strategy here meant several things. It meant technology architecture, yes. It also meant team structure. It meant understanding the underpinnings of the business and the directions in which it was headed. I like to describe technology strategy for product-focused companies as something that “enables the many potential futures of the business.” It’s not just a reactive document that tries to account for current problems, but it anticipates and enables future growth. If you’re in a product-focused business, this is the heart of your technology strategy. It’s not about actually deciding the product’s direction, but about enabling the larger roadmap to play out successfully.
The hardest part, in many ways, was getting started. The second-hardest part was getting comfortable making a guess about the future with highly imperfect information. Going through this exercise was the difference between my ability to lead in a reactive fashion, looking at the known environment and making plans to accommodate it, and my ability to lead in a forward-thinking fashion. Now I had an idea about where we needed to go, as an architecture, as a team, and as a company.
After I clarified this architecture for myself, leading became in many ways much easier. I could show the engineering team a vision of where we would go as a technology platform, not just what the product roadmap looked like. I had ideas about things we could work on that would directly move the company forward, beyond making the technology work. The architecture led the technology’s organizational strategy, which ended up leading some of the company’s organizational strategy—something I was quite proud of being able to influence.
We all have times when we have to deliver bad news to our teams. Maybe the company is having layoffs. Maybe the team is being disbanded in order to give more support to other projects, and everyone is being scattered onto other teams. Perhaps there’s a policy change that you know will be unpopular. Those roadmap changes we just talked about sometimes fall into this category as well. You, the manager, have to be the messenger and deliver this news, but you know the team isn’t going to be happy.
What do you do in this situation? Well, communication is key. As a person in senior leadership, you’ll need to excel at communicating sensitive information to large groups. Here are a few dos and don’ts:
Don’t blast an impersonal message to a large group. The worst way to communicate bad news is via impersonal mediums like email and chat, especially mediums with commenting abilities. Your team deserves to hear the message coming from your mouth directly, and without you to guide the message, you can expect some misunderstandings and bubbling animosity. That being said, the second-worst way to deliver this message, especially to a large group that you know won’t be happy, is with them all in a room at once. You may think that trying to communicate bad news to everyone at once is the best way to keep it from spreading before everyone has heard it, but the result is still impersonal. It’s hard to see everyone’s reaction, and one or two deeply unhappy members can quickly rile up the whole team before the message has had the chance to sink in.
Do talk to individuals as much as possible. Instead of impersonal or group-based communication, try your best to talk to people individually about the news. Think about the people who are going to have the strongest reaction, and try to tailor the news to them. Give them space one-on-one to react, to ask questions, to get it straight from you. And as necessary, make it clear that these are the marching orders and that you need your people to be on board with the changes, even if they don’t love them. In a case where you need to get the message out to your whole organization, talk to your managers first, give them talking points, and then let them share with their teams before bringing the whole group together.
Don’t force yourself to deliver a message you can’t stand behind. You may have a hard time delivering this news because you don’t like it yourself. Maybe you violently disagree with the policy change. Maybe you hate the fact that the team is being split up. If you absolutely can’t deliver the news in a way that won’t betray your strong disagreement, you might need to have someone else help you deliver it. Perhaps you ask another executive to step in, or maybe someone from HR. Depending on the size of your team, you can deliver the information to a trusted lieutenant and have that person help to share it. As someone in senior leadership, you have to learn how to maturely handle decisions you don’t agree with, but that doesn’t mean you have to go it alone.
Do be honest about the likely outcomes. The more you can commit to the direction specified by the news yourself, the easier this will be. If there are layoffs, acknowledge that this process is not fun but that everyone needs the company to survive. If a team is being disbanded, feel free to point out both the accomplishments of the team up to this point and the changes that make this the right path forward, and emphasize that there are many new opportunities now for learning and growth. Being forthright with people will help them trust you more and make them more likely to tolerate the unhappy news well.
Do think about how you would like to be told. One piece of news that you may have to deliver someday is the news of your leaving. In fact, you’ve probably had the experience of resigning from a job already, or moving from one team to another. How did you communicate that news? Did you send a memo? Well, maybe to HR, but to the rest of the team you probably pulled people aside to tell them face-to-face if you thought they would want to know before it was public. You may have had a going-away party, written a farewell letter, or given a final lecture to the team about what you learned in your time at the company. It’s OK in some circumstances to celebrate these sad changes, so long as you can do it with grace. All of these lessons apply to delivering hard news to your team.
ASK THE CTO: I HAVE A NONTECHNICAL BOSS
This is the first time I’ve ever had a boss who was nontechnical, and it’s turning out to be really hard. How do I effectively manage this relationship?
The first time I ever experienced a fully nontechnical manager was when I started reporting to the CEO at Rent the Runway. Reporting to a nontechnical manager can be a total culture clash. Fortunately, a few best practices will help you manage this relationship:
Don’t hide information behind jargon, and be careful with details. Your new boss is probably very smart, but he may not have the patience for technical jargon, and it is very unlikely that he wants to hear a ton of details about nuanced technical decisions. Part of this process is learning to distinguish the type of information that is valuable to communicate from the type that is not.
Expect that you will need to run your 1-1s with your new boss, so come prepared with a list of topics. Busy executives can be frustratingly hard to pin down; even getting 1-1 time is a challenge, so don’t waste the time you have. Up until now you may have expected both parties to bring some specific topics to the meeting, but that won’t necessarily be the case now, so always come prepared. If you’re having trouble getting your 1-1 time honored, send the agenda in advance to remind your boss that you need her attention—and it never hurts to be on good terms with the executive assistant who manages her calendar!
Try to bring solutions, not problems to be solved. CEOs generally do not want to hear about how things are failing, nor do they want to hear about your disagreements with your peers or your troubles managing. In the case that you have a CEO who doesn’t want to hear too much about problems, respect that you’re not going to get much coaching from him on the management side of things, and find another person to get that from. With that said, don’t shy away from delivering bad news.
Ask for advice. It sounds contrary to my advice to bring solutions, but nothing shows respect like asking for someone’s advice. Your boss may not want to be stuck solving your problems, but you can bet that she’ll be happy to provide feedback if you phrase it as needing advice.
Don’t be afraid to repeat yourself. If you’ve brought up an important issue that seems to have been forgotten, bring it up again if it’s really important. You may have to do this a few times before you get any traction. Three times is often the magic number.
Be supportive. Always ask if there is more you can be doing to help. As much as you can, show that you are there to support your boss and the company.
Actively look for coaching and skill development in other places. You no longer have a manager; you have a boss. You probably still need to work on some skill development the first time you work in a senior leadership position, so get a coach, ask for training, and create a peer group outside of the company to support you through this brave new world.
Many of the major revelations for me as I moved into senior management involved the relationships that I needed to develop with the other people on the executive and leadership teams. I had the opportunity to work with people I respected across many functions, and because we had a large and diverse leadership team I got to know many different types of senior leaders. I got along better with some than with others, and I evolved my perspective by learning from both types of interactions.
Senior leaders, more than any other group in a company, must actively practice first-team focus (introduced in Chapter 6). They are dedicated first and foremost to the business and its success, and secondly to the success of their departments as a way of contributing to the overall business success. Leadership books such as Patrick Lencioni’s The Five Dysfunctions of a Team  write about this relationship, and while many of us start to practice this type of leadership with other engineering managers as our “first team,” senior leadership is often the first time your peers all operate in a very different way than you’re used to, and having few to no peers on your first team who are fellow engineers can feel very isolating.
So what does it feel like to work well with cross-functional peers? To start with, you let them own their areas, and they let you own yours. Many of us learn how to do this earlier in our careers, when we have to work with senior designers, product managers, or other business team members, but if you haven’t learned how to let a peer own her specialty, now is the time. Giving her respectful deference when it comes to her turf is fundamental. If you disagree with her management style or application of her skill set in places where it isn’t directly affecting your team, you treat that disagreement like you would treat a good friend who happens to date people you don’t love. Unless she asks for your advice, try to stay out of it as much as possible, and certainly approach any disagreement you choose to discuss with kindness. Be willing to let those differences lie.
Of course, you’ll disagree with your peers. The place for this disagreement is either one-on-one or in your leadership team meetings. These meetings are where you hash out differences of opinion on strategy, challenges the company is facing, and details of direction setting. If the numbers don’t make sense, ask the CFO in the context of these meetings. Also expect to defend your own technical decisions and roadmap in this setting.
This brings us to the second element of trust, beyond trusting someone’s abilities. In The Five Dysfunctions of a Team, Lencioni notes that absence of trust is a fundamental dysfunction. In this case, what’s missing is the trust that your peers are actively trying to do their best for the organization, that they are not trying to manipulate situations, undermine you, or otherwise get their own way. So, beyond establishing basic respect for your peers’ ownership of their turf and respect for their abilities as functional experts, you also have to put aside the idea that they’re acting in irrational or self-interested ways when they disagree with you or do things you don’t like.
Establishing this fundamental trust is really difficult. You will probably have some degree of a cultural clash with some, if not all, of your peers. The values that make a great CTO are probably slightly different from those that make a great CFO, CMO, VP of Operations, and so on. A very common clash occurs between people who are extremely analytically driven and those who are more creatively or intuitively focused. Another is between the people who prefer to embrace agility and change (and, yes, sometimes disorder) and those who push for more long-term planning, deadlines, and budgets. You have to figure out how to understand and trust everyone’s styles across the spectrum.
Engineers frequently struggle with the transition to respecting and communicating well with diverse peers. I believe the struggle with respect is a side effect of the current tech culture, which tells us that engineers are the smartest people in the room. It can’t be said strongly enough: your peers who are not analytically driven are not stupid. On the flip side, we undermine ourselves when we fail to talk so that nontechnical peers can understand what we’re saying. Throwing out jargon to people who aren’t familiar with it—and who don’t even need to be familiar with it—makes us look stupid to them. We therefore need to figure out how to communicate the complexity of our work in a way that an intelligent but nontechnical peer can understand.
The final element of this first-team trust and respect is the cone of silence. Disagreements that happen in the context of the leadership team don’t exist to the wider team. Once a decision is made, we commit to that decision and put on a united front in front of our engineering teams and anyone else in the company. It’s easier said than done—I’ve struggled frequently with hiding my own disagreements with my peers. Letting go when you don’t get your way, especially when you don’t feel that your objections have been heard, is hard, and it will have to happen from time to time. At this level especially, you must decide whether you want to fall in line or quit. The middle ground, openly disagreeing with your peers, does nothing but make the situation worse for everyone.
As the senior-most person in an organization, you’ll be watched more closely than you’ve ever been watched in your life. Your presence causes people to focus all of their attention on you. They seek out your approval and try to avoid your criticism. Shifting your mindset away from “one of the team” to “the person in charge,” especially if you came up through the team and grew the team yourself, is a challenge for many at this level.
You’re no longer one of the team. Your first team is comprised of your peers at the leadership/executive level, and your reporting structure has now become your second team. If you shift your mindset successfully, you will probably start to detach socially a little bit from the overall organization. When there’s a happy hour, you go for a drink and then leave the team to socialize. Closing down the bar with your whole organization will tend to have bad consequences for everyone, so I strongly advise that you avoid doing that with any regularity. Socializing heavily with your team outside of working hours is a thing of the past.
You need to detach for a few reasons. First, if you don’t detach, you’re likely to be accused of playing favorites. In fact, you probably will play favorites if you maintain very strong social ties with people who report up to you on the team. This hurts, but it is true. Maybe you don’t care, but personally I found that having my team believe I was playing favorites made the overall team unhappy and made my job a lot harder.
Second, you need to detach because you need to learn how to lead effectively, and leading effectively requires people to take your words seriously. The downside of leading at this level is that with a throwaway comment, you can cause people to change their whole focus. This is bad, unless you’re aware of that and actually make use of it appropriately. If you try to maintain a “buddy” image, your reports are going to have a hard time distinguishing between their buddy thinking out loud and their boss asking them to focus on something.
Detaching also means being thoughtful about where you spend your time. As the senior leader, you’ll often suck all of the oxygen out of a room. Your mere presence will change the tone and structure of meetings you attend. If you aren’t careful, you’ll end up pontificating and change the direction of a project because you had a great brainstorm in a one-off meeting you decided to drop into. It sucks! I know! It’s frustrating that you can no longer be one of the team whose ideas are there to be evaluated and potentially rejected—but you are no longer that person.
If you’ve ever worked with anyone who overlapped with Steve Jobs at Apple, chances are you’ve heard that person talk about “Steve” and the impact he had on some project he or she was working on. Apple employees used the specter of Steve to argue for and against decisions, as a moral compass for what the organization should be doing. The culture you build and reinforce will have some of this effect on your company. They may not refer to you by name, but as you choose which behaviors to model in front of the team, they will learn those behaviors and copy them. If you yell, they learn that yelling is OK. If you openly make mistakes and apologize, they learn that it’s OK to make mistakes. If you always ask the same set of questions about a project, people start to ask those questions themselves. If you value certain roles and responsibilities openly above other roles, ambitious people will seek out those valued positions. Use this power for good.
There are other reasons you need to detach. You’re going to be part of hard decisions that will impact the whole business, and these decisions may cause you a great deal of stress. It won’t be appropriate to discuss these decisions with other people at the company. It’s deeply tempting to rant to those people you consider friends in your reporting team about the challenges of your position, but this is a bad idea. As their leader, you can easily undermine their confidence by sharing worries that they can’t do anything to mitigate. Transparency that may have been harmless or even possibly helpful at lower levels of management can become incredibly damaging to the stability of your team at this level.
You may not be “one of the team,” but that doesn’t mean you should stop caring about the team as individuals. In fact, I encourage you to care more about people as individuals, at least in a small way. Taking the time to get to know as many people as you can as humans—asking them about their families or hobbies or interests—is a good way to help them feel that they’re part of a group that cares about them.
As you grow more detached from the team, it can be easy to start to dehumanize people and treat them like cogs. People can tell when that’s happening, when their leaders stop caring about the individuals in the organization. They’re less likely to feel committed to giving their all, to taking risks and pushing through hard circumstances, if they feel that no one really cares about them personally. Nurturing that kind of connection, even at a superficial-seeming level, helps to reinforce that you do care about them and not just their current projects or work output; that you know they’re people outside of work. It grounds you without attaching you too strongly to individuals. You’ll have to make hard calls as an executive, but your team deserves a leader who’s able to be kind even while making those hard calls.
You’re a role model. What kind of leaders do you want to develop? What kind of legacy do you want to leave?
Camille considers herself to be a good leader: technical, charismatic, capable of making decisions and getting things done. She’s also sometimes short-tempered, and when people don’t live up to her expectations or things go wrong, she can be visibly annoyed and openly angry. She doesn’t realize that this hard edge and short temper are making people afraid of her. They don’t want to risk getting blamed for failure or openly criticized for making a mistake, so they take fewer risks and hide their mistakes. Camille has accidentally created a culture of fear.
Michael is also a good leader: technical, charismatic, capable of making decisions and getting things done. He’s also good at keeping his cool. Instead of getting tense and angry, he gets curious when things don’t seem to be going well. His first instinct is to ask questions, and these questions often cause the team to come to their own realizations about what’s going wrong.
You might be surprised to learn that the story you just read is true: it’s my own experience accidentally creating a culture of fear when I became a senior leader. Here’s an excerpt from my very first review as a senior leader:
As you can imagine, this was a shocking and uncomfortable thing to hear. And while I can make dozens of excuses for it—people take criticism more harshly from women, I came from the finance industry where this was a normal culture, everyone just needs to toughen up—it was clearly a problem. People were afraid to take risks, and if you want to have an independent team capable of setting their own direction and pushing themselves, you need them to take risks.
How do you know if you’re creating a culture of fear? It can come from placing a high value on being correct and following the rules, and having a strong affinity for hierarchy-based leadership. I also believe that coming from places where conflict was openly tolerated, if not actively encouraged, made me even more likely to create this culture. Engineering culture has a high tolerance for open debate to resolve conflict, so leaders who come from heavily engineering-focused backgrounds may feel particularly comfortable aggressively sparring with others over issues. Unfortunately, when you’re the leader, the dynamic changes, and those who may have fought back when you were an individual contributor will feel threatened by you as a leader.
- Practice relatedness. One marker of the culture of fear is a tendency to treat people impersonally. In my early days of management I had a habit of focusing too much on efficiency. I wanted to dive right into the issue at hand, to get into the intellectual discussion, the status update, the problem that needed to be solved. I didn’t take a lot of time for small talk, for getting to know my team as people or letting them see me as a person, and as a result, I didn’t have much of a personal relationship with them.
- Apologize. When you screw up, apologize. Practice apologizing honestly and briefly.
“I’m sorry, I should not have yelled at you and I have no excuse for my bad behavior.”
“I’m sorry, I did not listen to you and I know I contributed to your frustration at this situation.”
“I’m sorry, I made a mistake when I neglected to tell you about Bob.”
Apologies don’t need to be drawn-out affairs. A short apology that takes responsibility for your role in creating a negative situation or hurting another person is all that is necessary. If you go too long, it often turns into an excuse or a distraction. The goal with apologizing is to show people that you know your behavior has an impact on others, and to role-model for them that it’s OK to make a mistake but that you should apologize when you hurt other people. You’re showing the team that apologizing doesn’t make you weaker—it makes the whole team stronger.
Get curious. When you disagree with something, stop to ask why. Not every disagreement is an undermining of your authority. When you take the time to seek out more information about something with which you disagree, you’ll often find that you were reacting to something you didn’t really understand. For those of us who care about doing the right thing or making the best decision, attacking something we disagree with makes that harder. When we attack, many people evade or shut down, and they learn that it’s a good idea to hide information from us so we won’t attack or criticize them. When you get curious and learn how to turn that disagreement into honest questioning, you can learn more about other perspectives on the issue because your team will open up. This is how you get the most information out and help everyone make the best decisions.
Learn how to hold people accountable without making them bad. As a leader, you want your teams to do their jobs well. If they fail to meet their responsibilities, you’ll be the person to hold them accountable. But it doesn’t start with responsibility and end with consequences. Other elements are needed along the way. How do you measure success? Does the team have the capabilities needed to succeed? Are you providing feedback along the way? I think many leaders forget these requirements and hope they can get a junior team to achieve something just by setting the goal clearly, or believe a more experienced team shouldn’t ever need feedback. Think of the times you’ve made a person or a team out to be “bad” because they failed. Are you holding yourself accountable for setting them up for success? When everything is clear and you’ve all done your best, I bet you’ll find that accountability comes with far less character judgment, because you all clearly see what has happened.
The culture of fear is pretty common in technology, and it survives best in environments where things are otherwise going well. Don’t be fooled by external circumstances that enable your bad behavior. If you’re feared but respected, the company is growing, and the team is working on interesting problems, you might get along OK for a time. However, if you lose any of these elements, you can expect to see people who have better options leave for greener pastures. I know firsthand that having a team that fears but respects you isn’t enough when they’re frustrated by other things happening around them. So work on softening your rough edges, practice caring about your team as humans, and get curious. Building a culture of trust takes time, but the results are well worth it.
A core role of senior leadership is sometimes overlooked. This role, played by the senior leader of a functional area (the CTO plays it for technology, the CFO plays it for finance, etc.), sets the baseline of what excellence looks like in this function. I call it “True North.”
True North represents the core principles that a person in a functional role must keep in mind as he does his job. For a product leader, True North includes thinking of the users and their needs first and foremost, measuring and experimenting as much as possible, and pushing back on projects that don’t address the stated goals of a team. For a CFO, True North includes looking at the numbers, at the costs of work and at the potential value, and making sure that you’ve considered how to make those numbers work in your company’s favor, that the company isn’t accidentally spending more money than expected, that the team knows when it’s at risk for going over budget.
For a technical leader, True North means making sure that you’ve done your job getting things ready to go into production. It means you have honored your agreed-upon policies for review, operational oversight, and testing. It means that you won’t put something into production that you don’t believe is ready for your users to experience. It means you’re creating software and systems you’re proud of.
Technology leaders must help set the standard for True North in their organizations for different types of projects and exposures. Another way to think of this is through the lens of risk analysis. Risk analysis doesn’t mean that we don’t take risks. Some things that are generally considered “bad” can be OK under certain circumstances. These include:
Having a single point of failure
Having known bugs and issues
Being unable to tolerate high load
Putting out code that is undertested
Having slow performance
There are situations and companies in which all of those risks are acceptable to take. That being said, True North helps us understand that all these issues must be carefully considered when we put code into production. Just because these rules have exceptions doesn’t mean we forget that they exist.
I call this concept True North because it’s important to understand it as an underlying pull, as a guiding instinct that we as leaders have developed over time and strive to help our teams as a whole develop as well. When our teams develop this instinct, they can be trusted to independently follow these guidelines without much direction or nudging.
The True North for each functional area is slightly different, so there will be natural tension in the organization. Product managers may care more about the user experience and less about the production support burden. The finance team may care more about the overall cost of infrastructure and less about the risks for availability. This tension is healthy because it forces us to reckon with all of the risks, not just the risks that our particular function cares about.
When you examine your role as a leader, looking at the ways that you set True North can help you understand your strengths and areas of ownership. If you consider yourself a technical leader, part of your job should be setting True North for large facets of the critical technology. As a CTO for a commerce company, I set True North for most fundamental technical decision making around production readiness, scaling, systems design, architecture, testing, and language choice. That doesn’t mean I made all of those decisions, but I guided the standards by which such decisions would be evaluated. I delegated True North for matters of mobile and UI-specific development, but pushed the senior technical staff in those areas to articulate what the standards looked like.
True North leaders rely on the wisdom they’ve developed over time to make fast decisions when they don’t have time to delve into all the details. If you want to become this type of leader, you must spend enough time early in your career to hone these instincts in order to be comfortable making fast judgment calls. That means staying technical; following through with projects, languages, or frameworks long enough to learn more than their basics; and also pushing yourself to keep learning new things even when your day-to-day doesn’t involve writing code.
Arbinger Institute, Leadership and Self-Deception: Getting Out of the Box (San Francisco: Berrett-Koehler, 2000).
Brené Brown, Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead (New York: Gotham Books, 2012).
Peter F. Drucker, The Effective Executive (New York: HarperBusiness Essentials, 2002).
Marshall Goldsmith and Mark Reiter, What Got You Here Won’t Get You There: How Successful People Become Even More Successful (New York: Hyperion, 2007).
Andrew S. Grove, High Output Management (New York: Vintage Books, 1983).
L. David Marquet, Turn the Ship Around! A True Story of Turning Followers into Leaders (New York: Portfolio, 2012).
At this level, your coaching and mentoring are likely to come from people outside of your company. You no longer have a manager, you have a boss. Do you have a professional coach, either provided by work or paid for yourself? This is a good investment even if your job doesn’t pay for it. A coach can give you guidance and direct feedback, and unlike your friends, she’s paid to listen to you talk.
Beyond a coach, how is your support network of peers outside of your company? Do you know other senior managers at companies in your area? A peer group helps you see what the job looks like at other companies, and is a place where you can share experiences and get advice.
Do you particularly admire any technology senior managers? What is it about them that you admire? What could you be doing to be more like them, if anything?
Think back to the last time you needed to change priorities for part or all of your team. How did it go? What went well, and what didn’t go well? How did you communicate the change to your team, and what was their reaction? If you were to do it again, what is one thing you would do differently?
How well do you understand where your business is going for the foreseeable future? Do you understand the technology strategy that will help you get there? What are the critical areas of focus for the team, such as feature velocity, performance, technical innovation, and hiring, that need to evolve to reach the goals of the company? Where are the bottlenecks or opportunities for technology evolution to push the business forward?
How is your relationship with the other members of the company’s senior leadership team? Which relationships are good and which are bad? What could you do to improve the bad relationships? How well do you understand the priorities of these team members, and how well do you think they understand your priorities?
If I asked your team which executives you got along with and which ones you hated, would they be able to tell me without hesitation? When the CEO or the leadership team comes to a decision that you don’t agree with, are you capable of leaving that disagreement behind and supporting the decision to the rest of the company?
Are you behaving like a role model for your team? Would you be happy to learn that people were emulating your behavior on a daily basis? When you sit in on meetings with your team, do you dominate the conversation or are you more interested in listening and observing?
When was the last time you asked someone you don’t talk to regularly about his life outside work? The last time someone emailed to say she was sick and couldn’t come in, did you take a minute to wish her a quick recovery?
What are the fundamental principles you want your senior engineers to be considering when they evaluate work and make decisions? Or, if you are focused more on organization than technology, what are the fundamental management principles you want your managers to be following when they lead their teams?