Skip-Level Meetings

Skip-level meetings are one of the critical keys to successful management at levels of remove. And yet many people skip or undervalue them. I know, I’ve been there. No one wants to add yet more meetings to their calendar, especially the type that are often without an agenda. Still, if you want to build a strong management team, understanding the people who report to those managers and maintaining a relationship with them is hard to avoid.

What is a skip-level meeting? Put briefly, it is a meeting with people who report to people who report to you. There are a few different ways that people hold these meetings, but their purpose is to help you get perspective on the health and focus of your teams. However you choose to hold them, keep this purpose in mind.

One form of skip-level meeting is a short 1-1 meeting, held perhaps once a quarter, between the head of an organization and each person in that organization. This tactic accomplishes a couple of things. It creates at least a surface-level personal relationship between you and everyone in your organization, which keeps you from viewing them as “resources” instead of human beings (something that is a risk in managing large organizations). It also gives those individuals time to ask you questions that they may not feel are worth scheduling a meeting themselves to ask. These meetings are most successful when you provide prompts about potential topics, and remind the person that the meeting is largely for his or her benefit. Each person should come prepared to focus on what he or she is interested in talking to you about.

Some suggested prompts to provide the person you are holding the skip-level 1-1 with include:

• What do you like best/worst about the project you are working on?

• Who on your team has been doing really well recently?

• Do you have any feedback about your manager—what’s going well, what isn’t?

• What changes do you think we could make to the product?

• Are there any opportunities you think we might be missing?

• How do you think the organization is doing overall? Anything we could be doing better/more/less?

• Are there any areas of the business strategy you don’t understand?

• What’s keeping you from doing your best work right now?

• How happy (or not) are you working at the company?

• What could we do to make working at the company more fun?

The 1-1 doesn’t scale forever. If a quarter has, say, 60 working days, and you have 60 people in your organization, doing one a quarter with each member means you have one every day, or five a week for 12 weeks. This gets worse and worse the more people there are in your organization, and at some point it doesn’t make sense—at 1,000 people you’d be doing nothing but these 1-1s, assuming you worked 40 hours a week. However, if you have a smaller organization, dedicating time every quarter to each person does have some benefits.

If you have a larger organization, or are impatient with the idea of adding more unstructured 1-1s to your schedule, there are other ways to get skip-level time. I used to hold skip-level lunches with whole teams, where I would buy lunch for the group and we would talk about whatever was going on. I tried to do these a couple of times a quarter for each team. This has many of the benefits of the 1-1 meeting, in terms of making you more familiar to the team members and vice versa. It doesn’t give you the focus to give career coaching to individuals, but it does help you get a sense of the group dynamics and get feedback directly from the teams.

Of course, people act differently in group scenarios, and when you are the Big Boss they may feel uncomfortable complaining in front of others about problems they’re having with their manager, even when this person isn’t in the room. Many of my lunches served as little more than chats about random technical matters, but I could get a sense for where the team believed their focus needed to be, and I got to answer some detailed questions about the company’s strategic focus, the work other areas were doing, or upcoming projects they were interested in hearing more details on.

In the group setting, these questions can be used to draw out information:

• What can I, your manager’s manager, provide for you or your team? Anything I should be helping with?

• Is this team working poorly with any other teams, from your perspective?

• Are there any questions about the larger organization that I can answer?

For me, the skip-level lunches provided familiarity, which in turn generated more willingness for people to come to my office hours and cover more sensitive 1-1 topics there, whether by their request or, occasionally, by mine.

The purpose of this skip-level process, beyond maintaining trust and engagement, is to help you detect places in which you’re being “managed up” well, to the detriment of the team under that manager. Having people who manage up well in your organization is always a hard situation to detect and respond to. These individuals get to you first, so you hear their perspective before you hear anything else, and you’re predestined to think they’re in the right and to support their decisions. Skip-level meetings are a chance to hear the other side of the story, to get a reality check from the people on the ground.

At this level, you’re constantly making tradeoffs between investing in expensive engagements, such as 1-1s, that can provide deep value but cost you in time and energy, or casual engagements that are more efficient in terms of your time but provide less detailed information. You won’t get it perfectly right. There will still be times when you hear too late about a project that’s suffering, or a manager who’s failing his team, or a team member who’s causing problems for others. Invest some time in learning how to maintain these indirect relationships.

Don’t underestimate this process, even in the case where you know the skip-level reports well. There’s no guarantee that you will keep your close ties with a team just because you used to manage them directly. Managers commonly slip up here when they already have personal relationships and plenty of history working together, so they feel they don’t need to do extra work to keep in touch with those teams directly. I’ve been there and made this mistake. This philosophy sometimes works for a short period of time. But as the teams slowly change, the relationship changes. And even if the team members haven’t changed, they won’t always come to you with problems they have with their manager. Refer back to “Ask the CTO: The Fallacy of the Open-Door Policy” for the reasons why.

Manager Accountability

Whether you have experienced managers or first-timers reporting to you, there is one universal goal for these relationships: they should make your life easier. Your managers should allow you to spend more time on the bigger picture, and less time on the details of any one team. This is why they’re around. They’re more than just people who take some 1-1 meetings off your hands; they are responsible for taking a team of people and helping that team succeed. When they repeatedly fail to do this, they’re failing to do their job.

Well, that sounds good, except for one little thing: sometimes managers make your life easier by hiding problems and telling you what you want to hear, until months later you see things falling apart and wonder where you went wrong. So you can’t just expect that they’ll magically make things better—you have to hold them accountable. This small piece of expertise—learning how to hold managers accountable—will be one of your biggest learning opportunities as you work at this level.

It’s hard to hold your managers accountable because accountability on complex teams is often muddled. Your managers may oversee teams with tech leads who are responsible for technical direction and quality. They may also work with product or business managers who set the feature roadmap. And of course it’s rare that a team is truly an island, so other teams will have an impact on that organization as well. With all of this responsibility split into different roles, when can you hold a manager accountable?

Here are some tricky but common scenarios I’ve experienced:

Unstable product roadmap

The team doesn’t feel very productive, the systems are unstable, and there is some attrition happening, but the product organization keeps changing the goals for the team and everything is always an urgent mandate. Is the manager accountable?

Errant tech lead

The tech lead has been down a rabbit hole trying to redesign one of the core systems. The design doc is still barely started, and work is piling up, but the tech lead insists that this is a big problem that can’t be rushed. Is the manager accountable?

Full-time firefighting mode

The manager inherited a team with a bunch of legacy systems that are constantly broken, and the team seems to spend all their time fighting fires. They also support other teams who are using those systems, and the other teams are constantly asking for help and distracting the team with requests. There’s a roadmap to move out of these systems, but you haven’t heard any reports on the progress against this roadmap, and you know the team is killing themselves to keep things stable and manage the support requests. Is the manager accountable?

The answer to all of these questions is yes. Yes, despite the mitigating circumstances in each case, the manager ultimately needs to take responsibility for pulling the team out of these situations and getting them moving forward, because the manager is accountable for the health and productivity of the team.

When the product organization is constantly changing goals, the manager should identify that the changes are causing problems on the team, and work with product to explain the problem and refocus on what’s important. If that fails, she should come to you to help resolve the issue.

When the tech lead is down a rabbit hole, the manager has to bring that person out and work with him to figure out how to make the design process more transparent, bringing in other senior people from other teams if necessary as mentors or collaborators to help him deconstruct the problem and make forward progress.

The manager is responsible for coming to you when the roadmap is stalled because of other issues. If the team can’t do anything but fight fires, the manager should put together a plan for tackling the causes of the fires, and if necessary bring requests for hiring more people or adding more people to the team so that they can get the situation under control. When the team is dealing with too much inbound support, the manager is responsible for triaging that support burden and figuring out whether to refuse some of the requests or, again, whether the team needs more people to manage the workload.

In many of these cases, you’ll need to help your managers. Sometimes they don’t have the clout to push back against product and need your support. They may need your help finding other senior people to partner with their tech lead. You’ll probably have to approve any requests for more people to fight fires, or support them in shifting the support burden to other teams. They’ve done the hard work of identifying the problems that are slowing down their teams, but you need to then help find the solutions or support the path forward. This is what making your job easier looks like—not hiding information, but bringing you clear problems before they turn into raging fires.

Managers need coaching and guidance in the same way that individual contributors need coaching and guidance. Don’t forget to spend time with your managers, get to know them as people, and pay attention to their strengths and areas for development. There’s plenty to talk about in your 1-1s related to schedule and planning, but make time for feedback and coaching. These individuals will have the biggest impact on your overall organization’s success or failure, and in turn will make you look good or bad depending on how well they perform, so take an active role in their management performance.

Good Manager, Bad Manager: The People Pleaser

Marcus is everyone’s best friend. He has a team of devoted employees who think he’s the best manager in the world. He spends much of his day in 1-1s with everyone from his direct reports to the newest junior hires. Everyone agrees that he makes plenty of time for anyone who wants it, and will listen for as long as you need him to. Bring him any problem, and he promises to make it right. Since he took over the organization, you feel like your concerns are really being heard. However, he never seems to get around to fixing those problems. The colleague you complained about still got promoted. The product team is still railroading you. The goals still don’t make any sense. But Marcus is so busy, you can’t blame him; after all, there are just so many problems he’s dealing with.

Maria is less well loved. She’ll make time for you if you request it, but unless you report to her directly, she tends to keep her distance. She can be brusque at times, and doesn’t seem to have a lot of patience for office gossip or wasted time. But since she took over the department, things have changed. The roadmap has fewer objectives and they all make sense. Your difficult colleague seems to have gotten some feedback and he’s started listening to your ideas. Meetings run better, and the team is focused for the first time in ages. There are still problems, but they seem less important now that you’re really getting stuff done. And the most amazing thing is that she seems to go home at a reasonable hour every night!

Marcus is a people pleaser. He has a deep aversion to ever directly making people he cares about unhappy. So if you’re in the group that he cares about and you ask him for something, he’ll always say yes, even when there’s too much happening and he can’t possibly deal with all of it. By trying to make everyone happy, people pleasers often burn themselves out.

Signs you might have a people pleaser on your hands:

• Her team loves her as a person but is increasingly frustrated with her as a manager, because she hides problems from them and tries to shield them from the external world.

• He’s more interested in having a team that runs smoothly and avoids mistakes than he is in getting the team to push themselves to really become excellent.

• When she is feeling bad, she wears it on her face and it makes the whole team lose confidence.

• He never pushes back on work, but often has many outstanding tasks and excuses as to why none of them has been finished yet.

• She overpromises and underdelivers, and never seems to be able to learn from this experience to promise less in the future.

• He says yes to everyone and sends contradictory messages to both his team and his external partners about what can be accomplished, resulting in widespread confusion.

• She seems to know about all of the problems that are happening in the company, but hasn’t directly addressed any of them.

I’ve seen many versions of people pleasers over the years. One version is the team pleaser, like Marcus. People tend to love him because he spends so much time with them. He wants to engage with your emotions, to make sure that you’re happy, and to hear about anything that is bothering you so that he can try to set it right. He doesn’t play favorites, but those who are willing to pour their hearts out to him end up getting most of his time. The therapist people pleaser can inspire huge loyalty on his team because of his willingness to hear what you are upset about, and his genuine concern for your emotional well-being. Unfortunately, this can mean he amplifies drama and negativity, and disappoints his team by making promises to them that he cannot possibly keep.

On the other side, there is the external pleaser. She very much wants to make her boss and her external partners happy, and is terrified of revealing problems on her team. As a result, she spends a great deal of energy managing upward and outward, and in particular tends to significantly overcommit her team. Despite wanting to please, she frequently doesn’t provide much praise or feedback to her teams internally. This may seem surprising, but this people pleaser struggles to have difficult conversations internally so she avoids talking about serious issues within the team, and this can actually lead to a refusal to acknowledge good work as well as problems. She will never willingly share problems with her manager, and readily agrees to any requests that come in for projects.

In both cases, the people pleaser struggles to say no, and sends contradictory messages to both the team and the external parties. One manager might insist on jumping on every single issue brought in front of the team and doing all of the tedious work of, say, resolving data problems that are due to bugs in the product. Because the manager doesn’t actually have the focus for this task, the issues are resolved slowly. Furthermore, the team lacks transparency into the problems their customers are facing, and so they struggle to prioritize fixing issues. By attempting to shield the team from having to do unpleasant work, the manager makes that work drag on and reduces the team’s ability to solve problems for good.

People pleasers who focus externally can be a huge blind spot for their managers: because they’re so focused on only talking about good things and saying yes to everything that comes their way, their managers often don’t even know about problems on the team or within projects until it’s too late. These people can be very good at distracting you from your concerns. They have plenty of excuses. They promise to do better next time. They may even be genuinely contrite when you provide corrective feedback, but it’s very hard for them to do things that visibly make others unhappy. And you probably like your people pleasers very much as people. They’re very nice!

You might think people pleasers create teams that feel safe to be vulnerable and fail, but in fact the opposite is true. These managers make it hard for the team to fail in a healthy way, because of the manager’s own fears of failure and possible rejection. An externally focused people pleaser shuts down honest conversation by evasion and, if necessary, emotional manipulation that rests on his status as the person that everyone likes so much. A team pleaser sets her team up to fail by promising things that aren’t realistic, and the result is often a team that feels extremely bitter toward either the manager or the company for failure to live up to these inflated expectations.

What should you do if you find yourself managing someone in this situation? Help the person feel safer saying no and externalizing more decisions so he doesn’t take failure personally. Providing him with strong partners who can take on the task of determining the work roadmap is a good option. Sometimes people pleaser managers work well in agile frameworks because the team itself takes ownership of work planning. Create better processes for getting work scheduled that don’t rely entirely on the manager’s discretion. When it comes to promising things to the team itself, having a structure that specifies the requirements for getting promotions or accessing other opportunities can apply here as well. For example, when promotions involve more than the manager’s discretion, the people pleaser can rightly point to the process as something outside of her control.

When you’re managing a people pleaser, one of the best things you can do is show the person that he’s exhibiting the behavior, and highlight the downsides. Sometimes all it takes is awareness that his habit of saying yes is a problem for the team. Recognize that this usually comes from a personal value of being selfless and caring about others, and honor these values even as you try to correct the unhealthy behaviors. People pleasers, after all, just want to make you happy.

Managing New Managers

We talk about management being a career change for engineers, so it’s no surprise that first-time managers need a lot of coaching. As you may remember from your first time managing a team, you don’t know what you don’t know. You probably did whatever good managers had done with you in the past, if you had a good manager to emulate. Perhaps you got a little training or read a book like this one, but more likely you muddled your way through it. Unless, of course, you had a good manager yourself helping you learn the ropes.

Spending quality time with your new managers is important, and you should expect this to be an up-front cost that pays long-term dividends for your organization. You may think that because a new manager has people skills she’ll automatically be good at the job. The new manager may believe this as well! But you know there are a number of skills to being a good manager, and even people with solid people skills will need some training to get there.

When you’ve hired or promoted a new manager, you’re often eager to let her loose completely over her team. Finally, that team is no longer your direct concern! Unfortunately, your new manager can be shockingly clueless as to even the basics. Running 1-1s, for example, is an intimidating experience the first time you do it. What do you talk about? How do you give feedback? How do you keep track of takeaways? No book or training can replace you spending some time asking your new manager how her 1-1s are going, and seeing what questions or challenges she may need help with. Sometimes, you just need to remind her to hold them in the first place!

In the face of a new and daunting job, some people just won’t do it. When your new manager doesn’t manage and slips on too many management details, her team starts to suffer, which means that you start to suffer. When people start quitting because their manager hasn’t given them a career path or isn’t inspiring them, it’s ultimately your responsibility. Use skip-level meetings to help you detect areas where you need to support your new manager fully, and let her know that you’ll be holding skip-levels frequently as you help to guide her most effectively.

One common sign of a struggling first-time manager is overwork. A new manager who is working all the time is probably failing to hand off her old responsibilities to other people on her team, and so she’s attempting to do two jobs at once. It’s one thing for her to be a bit busier, especially as she gets the hang of the new responsibilities, but it’s another thing to see her coming in early, staying late, and writing emails all weekend. It’s amazing to me how many people never quite learn how to let go of tasks and so are just constantly working longer and longer hours. Make it clear that you expect the new manager to hand off some of her old work, and help her identify opportunities to do so.

Overwork is also often a sign of another new manager danger: the person who thinks she’s now in control, the taskmaster of the team, responsible for making all of the decisions. Managers who neglect the job are bad, but managers who take to the job with gusto because they believe it’s the key to realizing authority are sometimes even worse. A manager on a power trip domineers her team, and a skip-level meeting with more senior members of the team will reveal their frustration that they have no ability to make decisions themselves. This is slightly different from but related to the micromanager, who expects detailed reports from every member of the team at all times. The micromanager annoys her team to death by asking for an unnecessary level of detail. The control freak takes away the team’s ability to make any decisions and views her job as assigning specific work to people to be done. Control freaks usually have bad relationships with their peers in product management and other tech teams, because they often fight to make decisions alone instead of collaborating. What’s worse, control freaks often want to hide what they’re doing from their manager for fear of having that control taken away. If your new manager is skipping your 1-1s or evading questions about what the team is working on, you may have a control freak on your hands.

The new manager you’re training should be ultimately making your job easier by more than just taking the responsibility of doing a bunch of 1-1 meetings off your shoulders. She also needs to be on top of the team’s performance and delivery, guiding them to focus on their goals and deliver results. Sometimes new managers fail to realize that they are now responsible for this delivery, and believe themselves helpless in the face of challenging goals or product roadmaps. It’s not your job to nag the new manager, to remind her of what she’s committed to do, or to hold her hands through the basics of team planning every time it needs to be done, but you will need to coach her through this process at first. Clearly set the expectation up front that you’ll hold her accountable for the team, and help her build the skills to achieve this.

First-time managers are tricky because if they truly don’t have the willingness to learn and aptitude to become solid managers, they’re a big problem. Making the wrong person a manager is a mistake, but keeping her in that position once you’ve realize she’s wrong for it is a critical error. I am hugely in favor of making engineers who wish to go into management take baby steps of mentoring and managing very small teams, but this is not always possible and doesn’t always shake out problems that come with scale. Control freak managers, for example, don’t often show up as clearly in smaller management situations, instead holding that impulse back until they feel they have the true authority of title. Keep an eye on your new managers. You may need to provide not only coaching but strong corrective feedback in the first six months.

Beyond the coaching that you’ll need to provide your first-time managers, I recommend seeking out additional external training. If your HR team has a curriculum for new managers, make sure yours are given the time to attend, and encourage them to do so. You may also seek out additional training opportunities outside of your company, such as conferences that focus on technology leadership, or programs run by current and former engineering managers to specifically address technical leadership topics. New managers are usually eager to learn the tricks of management, and professional programs can help get them up to speed.

Managing Experienced Managers

Now let’s move on to experienced managers. This is a very different set of challenges. Experienced managers can be awesome. The right experienced manager knows what needs to be done and does it without needing help from you to get there. He’s comfortable with the basics and even has some of his own unique tricks. All good, right?

Of course, there can be major downsides. Management tends to be a very culture-specific task in a company. I can give you best practices all day, but if you either work as a manager or hire a manager for a company that’s not a good culture fit, you’ll have problems. There is a reason that many young companies want to seed their management teams with people who’ve been there from the early days and understand the company’s DNA. They get the culture, they understand deeply what is important, and they have the internal networks already built to get things done.

So, the first challenge is making sure this person fits in with the culture of your team. We talk a lot about culture fit for all hiring, but managers create subcultures, and a manager who creates an incompatible subculture can be a problem if you want your teams to work together well. Let’s say you’re hiring a manager because he has expertise in building a certain type of product, and your company lacks expertise in this area. This kind of hire can be great for bringing in knowledge and perspectives. However, often we overvalue expertise in product areas and allow it to blind us to cultural and process fit with our companies and teams. A person with deep expertise in building enterprise-scale warehouse software may seem great on paper to run warehouse technology at your logistics startup. But he won’t necessarily work well with an agile, on-site team if he’s also used to shipping software once every six months and working only with remote development teams who are not involved in the product ideation process.

If you’re building a dynamic, product-centric engineering team, you need managers who understand how to work with teams who ship software frequently, who are comfortable with modern development process best practices, and who can inspire creative product-centric engineers. These skills are so much more important than industry-specific knowledge. It’s easier to gain access to industry information than it is to retrain someone who doesn’t know how to work in your culture. Don’t compromise on culture fit, especially when hiring managers.

Experienced managers will have different ideas about management than you do, and you’ll have to work out the differences. Working out these differences, however, is different than letting the manager do whatever he thinks is best. Even (or perhaps especially) if he’s been doing it longer than you, be willing to learn from him but don’t be afraid to provide your own feedback. Collaborate on areas of difference, allow him to teach you things, and take an active role in the process.

Again, this is a matter of culture. You’re responsible for cultivating the culture of your organization, and especially when you’ve been at the company for a longer period of time, you should ensure that all of your managers respect and nurture the type of culture that you think is best for the team. If you want teams that operate with transparency, make sure the manager shares information. If you want teams that encourage exploration, make sure the manager schedules time and space for his team to explore ideas. Think about what your culture values, and help your managers embody those values while still respecting that every team will be a little bit different and every manager will have certain strengths and weaknesses that you’ll need to account for.

How do you inspire experienced managers? The difference between an experienced manager and a new manager is that the experienced person should be capable of managing independently. This means that a lot of the coaching you provide will be less about the nuts and bolts of management and more about how he can have a larger impact on strategy and direction setting for his area. Don’t forget to think about tasks that you can delegate to him, and he should be an important advisor when it comes to setting organizational direction. While they may not need as much training as new managers, experienced managers often need help expanding their network both within the company and externally, so look for programs that can help them meet new peers.

Hiring Managers

Your organization is struggling. You’ve hired in 10 engineers, each with fewer than 3 years of experience. And despite your efforts, none of the existing engineers who might be qualified wants to take on a management role. None of them has much experience managing, anyway, so you would have to do a lot of training to get them up to speed. So, drowning in people, you decide it’s time to hire in a new manager to take over some of the team. But how do you do that?

Many people are very reluctant to hire in management from outside, and for good reason. We’re barely capable of determining if an engineer is capable of writing good code in a team setting without driving the other team members crazy. And coding is at least a skill that we can ask people to demonstrate for us. Management is…well, what even is it? How do we interview for it? What do we need to watch out for in the management hiring process?

Hiring for managers is a multipart exercise, and those parts are actually very similar to those of a good engineering interview process. First, make sure that the person has the skills you need. Second, make sure that she’s a culture match for your organization.

The biggest difference between a management interview and an engineering interview is that managers can, theoretically, bullshit you more easily. The skills of a manager, as we have discussed at length, are pretty much entirely based around communication. Someone who communicates well in a management interview, who talks a good game, can still come in and get nothing done. But engineers who code well in interviews also sometimes fail to ship anything once they join a team. Separate your fear of what happens after you hire the manager from what you’re trying to evaluate when interviewing her. You can evaluate her and get worthwhile information from the management interview. So how do you do that? Look at the skills you expect from a manager, and ask her about them.

Let’s start with 1-1s. As we’ve discussed, 1-1s are an essential tool for a manager to determine the health of her team and gather and impart valuable information. Any manager you hire should role-play a few 1-1s as part of the interview process. One of the best ways to do this is by asking the people who would report to the new manager to interview her by asking her to help with problems they have right now, or have had in the recent past. Similar to a senior engineer being asked how he might approach debugging an issue that you just resolved, a good manager—even without a full understanding of the people or projects involved—should have good instincts for questions to ask and suggested next steps that might improve matters. You can take it a step further and actually role-play other types of difficult situations, like dealing with an employee who is underperforming, or delivering a negative performance review.

Importantly, a manager must also be able to debug teams. Ask the manager to describe a time when she ran a project that was behind schedule, and what she did in that scenario. Or ask her to role-play with an employee who is thinking about quitting. Ask the manager to describe how she’s coached employees who were struggling, and helped great employees grow to new levels.

Ask her about her management philosophy. If she doesn’t have one at all, that might be a red flag. While a new manager may not be able to answer this question well, an experienced manager who has no clear philosophy is a cause for concern. What does she think the job of a manager is? How does she stay hands-on, and how does she delegate?

Depending on the seniority, you might have a candidate come in and give a presentation to a group of people. The point of this is not specifically to judge the contents of the presentation, but to see how she is at commanding a room, answering questions posed by a group, structuring her thoughts, and getting up in front of an audience. These are skills that a senior manager should possess, and if she lacks those skills, take that into consideration when you’re deciding whether to hire her. I’d caution you not to overvalue this step, however. As a pretty accomplished speaker myself, I think speaking skills are useful for certain types of leadership but not all, and there’s only so much you can learn from how well a person presents herself in front of a group. Plenty of otherwise excellent managers are uncomfortable speaking in front of strange audiences.

What about technical skills? You want to make sure that you get enough of a sense of a candidate’s technical skills that she’ll be able to establish credibility to the team she’ll be managing. In the case of someone who will need to write some code, give her an abbreviated version of your standard technical interview. For a noncoding manager, ask technical questions that you believe she should be able to address given her experience. Design and architecture questions based on the types of systems she’s built or managed are a good approach. Make sure she can discuss the tradeoffs that were made and why. You might also have her mediate a technical debate between engineers who disagree on the solution to a problem. A good technical manager will know what kinds of questions to ask that tease out the core issues and guide the group to a solid consensus.

So, those are some ideas for skills to look for. The second aspect is cultural fit. As we’ve covered, this is important throughout your team, but by far the biggest place where it can cause grief is in a management hire. Have you ever worked with a manager who didn’t understand the culture of the company or environment? Say, a person from a big company at a startup, who doesn’t seem to embrace the startup speed and informality? Or someone from a startup working at a big company, who doesn’t know how to get consensus? I’m not suggesting that big company employees can’t make great startup managers (look at me, for example), or that startup employees can’t succeed in a larger environment, but you want to understand the culture of the company around you and evaluate the manager’s ability to fit into that culture.

How do you screen for cultural fit? I discuss this more in Chapter 9, but to summarize, first you need to understand the values of the company around you. Do you have an informal structure that doesn’t lean too much on hierarchy, or is hierarchy taken very seriously? Either of those cultures will cause problems for a person who is used to the other. I’ve seen managers from big companies who treated their peers well but their underlings and other lower-level staff members like they were less than human, which caused massive friction in the startup space. I’ve also seen managers from startups who were used to being able to act on whatever they thought was most important struggle in environments that required more sign-off from other parties. This is the most obvious cultural element. If you value servant-leadership and you hire a manager who wants to dictate exact marching orders to the team, there will be a bad fit. Similarly, if you value collaboration and hire a manager who thinks that the loudest voice in any conversation should win, you will also have problems.

Culture fit is so important in managers because they shape their teams to their culture, and they hire new people based on their cultural ideas. If you hire a manager who doesn’t fit in culturally with the team she’s managing, one of two things is likely to happen: the manager will fail and you’ll have to fire her, or most of the team will quit and then you may still have to fire her. Sometimes changing the culture of an area is inevitable, and hiring in a new manager will hasten that change. You can use management changes to your advantage in this way. In fact, you see this frequently at growing startups, where they hire in more seasoned managers and executives to round out the lack of experience of the rest of the team. Sometimes this works incredibly well, and sometimes it’s a massive failure. No matter what, you will usually see attrition happening around the hire of these bearers of new and different culture, so proceed here with caution.

In his book High Output Management,¹ Andy Grove talks about cultural values as one of the ways that people make decisions inside of highly complex, uncertain, or ambiguous circumstances where they value the group interest above their own. I find this insight very powerful. His observation is that most new hires act in self-interest until they get to know their colleagues, and then they move into group interest. So, if you start them in a highly complex or uncertain job, they tend to fail unless they quickly settle into the cultural norms and use cultural values to align their decision making. If you can screen for managers who naturally gravitate toward the cultural values that your company already possesses, they are more likely to make this shift quickly than managers who have very different personal beliefs.

Finally, I would be remiss if I did not point out one of the critical elements to hiring in new managers: the reference check. Do thorough reference checks for anyone you’re planning to bring on board, even if you’ve worked with that person before. Ask the references to describe the ways that the person succeeds as well as the ways she fails. Ask them if they would work with or for this person again. Ask them what they love about the person, and what drives them crazy. If you’re not doing reference checks when you hire management, you’re doing your team a massive disservice. Reference checks, even ones chosen carefully by the candidate, often reveal a lot about what you can expect to get when hiring her. Don’t leave out this crucial step.

Debugging Dysfunctional Organizations

I believe that the best engineering managers are often great debuggers. Why would this be? What is it about these two tasks that produces such an overlapping skill set?

A great debugger is relentless in his pursuit of the “why” for a bug. This is simple when we’re looking for errors in application logic, but we all know that bugs can go many layers deep, particularly in complex systems that involve many separate parts operating over time-delayed networks. A sign of a poor debugger is a person who, when he adds a log statement to a piece of concurrent code to attempt to find an error and sees that the error can’t be reproduced, assumes that he’s fixed the problem. It’s a lazy habit, but a common one. Sometimes there are problems that seem impossible to determine, and many people don’t have the patience to dig through layers of code (theirs and others’), logfiles, system settings, and whatever else is needed to get to the bottom of something that happened only once. I can’t blame them. Obsessive debugging of one-off issues is not always a great use of your time, but it does show a mind that won’t be satisfied with the unknown, especially when that unknown might cause you to be paged at two o’clock in the morning.

What does this have to do with management? Managing teams is a series of complex black boxes interacting with other complex black boxes. These black boxes have inputs and outputs that can be observed, but when the outputs aren’t as expected, figuring out why requires trying to open them up and see what’s going on inside. And, just as sometimes you don’t have the source code, or the source code is in a language you don’t understand, or the logfiles aren’t readable, the black boxes of teams can resist yielding their inner workings.

Let’s work through an example. You have a team that feels slow. You’ve heard complaints from their business partners and product manager that they’re slow, and you agree that the team just seems to lack the same energy as your other teams. How do you figure this out?

Setting Expectations and Delivering on Schedule

One of the most frustrating questions that engineering managers get asked regularly is why something is taking so long. We’ve all been asked this question before. We’ve been asked it as hands-on engineers, as tech leads, and as managers of small teams, but the question takes on a whole new level of intensity when you’re managing team managers, because answering it is significantly harder when you aren’t embedded deeply in the details.

First things first: hopefully you’re being asked this question because something is running over plan by a significant margin. That is the time when it makes the most sense to ask, and when you should do your best to understand the scenario and answer.

Sadly, we are often asked this question in times when things are not taking any longer than the estimate. We are often asked this question when our leadership, for whatever reason, either didn’t like the original estimate or didn’t ask for it at all, and now they’re upset, despite nothing going wrong.

Therefore, you must always be aggressive about sharing estimates and updates to estimates, even when people don’t ask, especially if you believe that the project is critical or likely to take longer than a few weeks. This means you must be aggressive about getting estimates, and as we all know, software estimation is a very difficult process. Negotiating the process that your team uses to estimate, on what timescale, for what projects, may be part of your job at this level.

Engineers often don’t want to estimate at all, or estimate beyond the boundary of an agile sprint (generally two weeks). This philosophy is completely reasonable if you believe that estimates must be fairly accurate, that the requirements are unknown or will change frequently, and that most of the work should be bound to features that mostly fit within one or two sprint efforts. With that said, few of these things are always true. Estimates are often useful even if they aren’t perfectly accurate because they help escalate complexity to the rest of the team. Not every project necessarily has requirements that change frequently, and it’s possible to do up-front work to drastically reduce the unknowns that make software estimation difficult. You may argue that the up-front work sometimes makes the overall process take longer than simply looking at the project sprint by sprint, and you may be right, but again, we’re not just talking about engineering teams here. We’re talking about businesses that want to plan and get ideas of costs for effort. We’re also, in some sense, talking about goal setting and learning how to get better at understanding the complexity of our software and systems. We can’t predict the future perfectly, but teaching our teams how to hone their instincts about complexity and opportunity is a worthy goal.

So, accept the fact that you’ll need to do some degree of estimation. Play with different methods, and see what works for your company, but make it a habit across your teams.

Another core element of agile software development is the emphasis on learning from the past. When estimates are wrong, what are we learning about unknown complexity? What are we learning about what is worth estimating, when? What are we learning about how we communicated those estimates and who was disappointed by the miss?

It is your job to make it clear, as best you can, what “long” actually is by providing your best view into the timescale of a project, and proactively updating that view when it changes, especially if it gets much slower.

Even with your best efforts, sometimes you’ll be asked this question when you’ve been clear about what “long” is, when you’re not actually taking so long, or when things completely outside of your control have come up and caused delays that were well communicated. It sucks when this happens, and it usually happens because someone is feeling stressed or being pushed to deliver faster than you ever claimed to be able to deliver. There’s no easy answer to this situation. Sometimes patiently reminding the other person that things are going as fast as they can and everything is on schedule is the only solution. But blame is not usually a fully rational exercise, or one that can be totally avoided under stress. Showing some empathy for the person providing pressure and being willing to help out in other ways can go a long way to shifting focus from blame to action.

Finally, don’t be afraid to work with your managers, tech leads, and the business to cut scope toward the ends of projects in order to make important deadlines. As the senior manager, you may need to play tiebreaker and make decisions about which features are worth cutting, and which features are essential to the project’s success. Help the team look out for these features, and be willing to take the fall for cutting back on someone’s favorite idea if it’s essential to getting the larger project done. Be smart about what you’re willing to give on. If you give only on matters of technical quality, you’ll just slow down the team after the project is launched, so be sure to look at product features in addition to technical nice-to-haves.

Challenging Situations: Roadmap Uncertainty

A very common problem that managers at all levels face is the challenge of changing product and business roadmaps. Especially in smaller companies, it’s hard to get people to commit a year in advance to the work that will be done for the next year. Even at big companies, changes in the market can lead to sudden-seeming shifts in strategy that cause projects to be abandoned and planned work to be cancelled.

This is really hard for engineering managers to deal with. Changes in strategy are where being stuck in “middle management” feels the most unpleasant. You may have very little ability to push back on the changes to strategy coming from above, and even when you’ve promised your team that certain projects will happen, you sometimes have to pull back on that promise because of unexpected changes. This makes the team unhappy, and they complain to you. Because you have no ability to do much about it, you can feel like it exposes you as powerless, and your team might feel that they’re being treated not as humans, but as cogs in the corporate machine.

Coming into play here is a secondary challenge: how do you make the time for your team to deal with technical debt and other engineering-focused projects when there doesn’t seem to be a clear process for prioritizing that work? After all, if you don’t put any time into dealing with the technical issues themselves, your team’s ability to do product features will slow down. And yet the product team will never have technical debt on their roadmap, so the planning process often means there is no time allotted for this type of work.

Staying Technically Relevant

One question I hear a lot from managers is “How do I remain technically relevant?” We know that without investment into our technical skills, we run the risk of becoming out of touch with the field and obsolete before our time. But what does technical relevance really do for you? To answer that question, let’s start by clarifying your technical responsibility.

Assessing Your Own Experience

• How often do you talk to your skip-level reports? Do you meet with them one on one, or as groups? How do you proactively reach out to your teams? How much time do you spend seeking out information, instead of passively handling the information that comes to you? When was the last time you sat in on a team meeting?

• Without looking at your existing documentation, write down your view of the job description for the engineering managers who report to you.

  • What are they responsible for?

  • How do you evaluate them?

  • What areas are most important for success, in your opinion?

• Now, look at the job description your company uses. Are there differences in what you wrote compared to that description, or do they match well? Given that description, what things are you potentially overlooking in evaluating them?

• Finally, do a quick mental review of their current performance. What areas need coaching and development? Make time to cover this in your next 1-1.

• If you manage an area that is outside of your technical comfort zone, how often do you check in on that area to make sure things are going well? Have you taken some time to learn from the manager of that area a little bit about what it takes to succeed in that role? What new things have you learned in the past three months that help you understand that team better?

• If you have one team that is clearly operating more smoothly than others, what are the differences you notice in their processes? Their interactions? Is their manager doing things differently than other managers? How does the team interact with that manager, and how does that manager interact with you?

• What is your interview process for managers? Do you spend time talking about their personal values and their management philosophy? Do you have the team interview their potential manager, or do you keep them out of the process? Do you spend time getting references for candidates?

• What are your organization’s goals this quarter? This year? How are you merging product goals (if any) with the technical goals? Does your organization have a mandate that is well understood by the teams?