Models for Thinking About Tech Senior Leadership

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)

Some companies focus on expanding the cutting edge of technology, and therefore may have a senior leader in the technology organization who is focused on experimentation, research, and new technology generation. This role might own technology strategy, or it might be purely a role for finding new ideas.

Technology strategy/visionary

Technology strategy meets product development. This person often also manages the product organization. He’s focused on how technology can be used to grow the business and works to predict the evolution of technology as it applies to the company’s industry. This differs from R&D in that the visionary isn’t usually focused on research potential; he uses business and technology trends to guide his decisions.

Organization

The organizational manager guides the structure and people in the organization. She owns the plans for staffing the team as well as organizational structure, ensuring projects are staffed accordingly. This role is often paired with “Execution,” discussed next.

Execution

Usually paired with “Organization,” this person makes sure things actually get done. He helps align roadmaps, plan work, and coordinate large efforts. He makes sure that projects get prioritized. He breaks roadblocks, resolves conflicts, and makes decisions in order to get the team moving forward.

Face of technology, external

When a company sells software-based products to other companies, one of the senior technology leaders usually is expected to participate in this sales cycle. She may attend client meetings and speak at conferences to encourage use of the product. A company that is invested in building an engineering brand for hiring purposes may also need one of the senior leaders to play this role by speaking at conferences and recruiting events.

Infrastructure and technical operations manager

This is the person responsible for all of the technology infrastructure and infrastructure operations. This role might be cost-focused, security-focused, or scaling-focused depending on the company and stage of evolution.

Business executive

This is someone whose first focus is the business itself. This person understands the industry and understands the other essential functions of the business at a high level. He balances internal development needs with business growth needs and owns prioritization of projects at a high level.

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.

What’s a VP of Engineering?

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.

What’s a CTO?

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.

Changing Priorities

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.

Setting the Strategy

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?

Challenging Situations: Delivering Bad News

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.

Senior Peers in Other Functions

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.

The Echo

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?

Ruling with Fear, Guiding with Trust

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:

Even those who love you on your team admit being fearful of you and your potential criticism. People are afraid to take risks or fail in front of you because they are scared of being publicly reprimanded in front of their peers. What your attacks have done is create a culture where members of the team are afraid to engage with you, to ask you questions, or to ask you for feedback—which then leads to a vicious cycle of you not trusting them and them making mistakes.

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.

True North

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

• Losing data

• 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.

Recommended Reading

• 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).

Assessing Your Own Experience

• 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?