The job expectations for managing managers are not that different from the expectations of managing multiple teams. You’re responsible for several teams, for overseeing the health of those teams, and for helping them set goals. The difference is one of magnitude. The coverage area for these teams has increased, and there are more projects and people than you could possibly handle by yourself. Instead of managing a couple of closely related teams, you may manage a larger scope of efforts. You may manage functions in your division that you haven’t managed before and that you don’t have a lot of expertise in—for example, a software engineering manager who now also manages the operations teams for a division.
While managing multiple teams can be exhausting and daunting, managing managers adds a whole new level of complexity that is often a surprise. Consider this email I once sent to my leadership coach:
Managing managers, how do I do it without taking up all my time? What processes should I be putting in place to get appropriate communication out of them and enable myself to scale? How do you help with problems that you aren’t in the room to see, with unreliable witnesses? I’m spending all of my time two levels deep in people problems and it’s exhausting.
The answers are even less at your fingertips than they were before. Things are now obscured through an additional level of abstraction, and it’s easy to miss out on details because you no longer engage regularly with all of the individual developers on each team.
This is a tough growth point. You’re going to be pulled in many directions, and figuring out how exactly to spend your time to maximize your leverage across your teams will be critical. In order to do this well, you’ll need to practice honing your instincts, and this practice will require you to follow through on things that you’re not sure are actually important, but you just sense are off.
Let’s take the case of managing the team that is doing work outside of your skill set. It’s tempting to just let them roll and only step in if there are problems. However, as a first-timer in this role, you’re probably not going to detect problems until they’re far gone. You haven’t yet built up the discipline or instincts to let yourself intuitively sense where and when to dive in deep, so you need to do so more frequently, even when things seem to be going well.
You’ll get a whole new sense of your strengths and weaknesses as you work at this level. People who are good at managing a single team, or even a couple of related teams, fall apart when asked to manage managers, or teams that are outside of their skill set. They’re unable to balance the ambiguities inherent in their new role, and fall back into things that they find easy. Sometimes this reveals itself as falling back into spending too much time playing individual contributor. Sometimes it shows up as a person playing project manager instead of training their managers to do that job themselves.
There are people who, by virtue of luck and some skill, get to this level without having to sweat too much. But this is a new game, and it requires a different level of discipline than what’s required to manage a team directly. I’ve discussed getting uncomfortable before, but this is a place where you need to find your discomfort, chase it down, and sit with it unblinking for a while. Here, you need to follow up on all the little things until you figure out what you don’t need to follow up on. Is recruiting happening? Are your managers coaching their teams? Has everyone written up their goals for the quarter? Have you reviewed them? What is the status of that project that should be finishing up? That production incident that happened the other day—did the postmortem happen? Did you read the report?
It’s so easy to take this position and assume that it’s just more of what you were doing before, but that’s a mistake. This position is the first level in a much bigger game, the entrée into senior leadership and upper management, and that will require a large number of new skills.
In this chapter, we’ll discuss some of the keys to successfully overseeing an entire division, including:
- How to get information from your skip-level reports
- What it means to hold your managers accountable
- Managing first-time and experienced managers
- Hiring new managers
- Figuring out the root of organizational dysfunction
- Cultivating your teams’ technical strategy
ASK THE CTO: THE FALLACY OF THE OPEN-DOOR POLICY
I’ve told my team that I have an open-door policy. They can come to me whenever they want to discuss problems. I even try to hold office hours for them to schedule time! And yet they aren’t coming, and I keep finding out about issues that no one has brought to my attention. Why won’t my team help me out here?
One thing that managers have to keep in mind is that part of their job is to ferret out problems proactively. There exists an idea that if you make yourself accessible, hold office hours where anyone can meet with you, and tell the team that you are always available, people will naturally bring their problems to your office. There’s no need to seek them out, because your team trusts you enough to come to you when things are going wrong.
Except this basically never happens. The open-door policy is nice in theory, but it takes an extremely brave engineer to willingly take the risk of going to her boss (or especially her boss’s boss, etc.) to tell him about problems. That even assumes that the engineer knows what the problems actually are well enough to explain them! Even on teams you build yourself, where there’s a huge level of trust and respect, some problems will just never get escalated to you. Some of these problems will cause people to leave, projects to get delayed, failures to explode. You turn your back, and the next minute a team that seemed fine has crumbled.
The risk of relying on an open-door policy increases the further away you get from a team. This culminates in the most classic, clueless executive move of relying on office hours instead of meeting one-on-one and with teams directly, and wondering why the wonderful management staff isn’t managing to retain great talent or get things done. Some people are great at managing up and hiding problems in their organizations, and you won’t ever see these issues if you never take the time to look.
As you manage managers, you’ll ultimately evaluate them on the performance of their teams. If the team is not doing well, what then? Predicting problems is part of your job, so being blindsided by a team that falls apart, has major attrition, or fails to ship a major project on time reflects poorly on you as the higher-level manager. These problems are very expensive to fix the longer they go on, and they won’t bring themselves to your doorstep.
So, part of the job is simply to make sure that your 1-1s have room for real conversation beyond a script or a set of to-dos, as I mentioned earlier. But beyond that, you must make the time to proactively hold skip-level meetings with the people who report to your direct reports.
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.
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
Errant tech lead
Full-time firefighting mode
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.
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.
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.
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.
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.
ASK THE CTO: MANAGING OUTSIDE YOUR SKILL SET
I’m now responsible for managing not only my division’s software development teams, but also the operations and QA teams. I have never had to manage these types of teams before, so do you have any advice on doing it well?
Be careful! It’s easy to think of this as a small leap from managing other software developers, but in my experience, you need to track different important details than you’re used to in these areas, and if you’ve never managed these types of teams before, it’s hard to know which details to focus on. Unfortunately, it’s very easy to miss out on problems in unfamiliar areas until it’s too late.
What happens when this situation goes poorly? In my personal experience, it can be a big problem. When you hire a manager over a team doing things that you don’t deeply understand, it’s easy for that manager to go the wrong way for a very long time before you realize what’s happening. This is particularly difficult when it comes to any sort of projects that have long timelines, where it’s easy to hide a lack of progress.
An interesting way to combat this problem is to use the same mindset that I advised when we talked about mentorship—namely, being very curious. Remember that you’re not expected to know everything just because you’re a manager. Use this to your advantage. Ask the person to teach you about the work she does. Sit down with her and treat her as if she were your mentor, the person to teach you the ropes for this job. Whether it’s QA, design, product management, or technical operations, ask lots of questions, but in an open way. Make it clear to the person that your goal is to understand what she does so that you’re capable of appreciating it better.
One other piece of advice here is that, while you may be tempted to spend more of your time in the areas that you are most comfortable with, to be prepared to devote significant time to the areas new to you, especially in the beginning. It’s tempting for managers who want to trust and delegate to simply assume that people will do the right thing and let them go, but this can easily result in you missing problems in these areas for far too long. What’s worse, if you view these areas as uninteresting or unworthy of your time, you may find yourself reluctant to deal with problems in these teams even when people are clearly drawing attention to them. You’ll feel guilty for having ignored the areas in the first place, and your natural aversion may keep you from facing up to issues for far longer than you otherwise would allow. Grit your teeth and make the time to get comfortable with each area; take time to get to know the manager and employees in the team, and practice asking for details about the area, so that you can start to learn and develop a sense for what the people in that team are actually doing.
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?
To properly debug a system, you need a reasonable hypothesis that explains how the system got into the failed state, preferably one that you can reproduce, so that you can fix the bug. To debug a team, you also want to look for a hypothesis around why the team is having problems. Do this in as minimally invasive a way as possible, to prevent your meddling from obscuring the problems. As an added challenge, team problems are not generally single failures but are more like performance issues. The system is running, but it seems to slow down from time to time; the machines are OK, except occasionally they crash; people seem happy, but attrition is too high.
Debugging a team deserves the same rigor you would apply to debugging a serious systems issue. When I debug a systems issue, the first thing I look at is logfiles and any other record of system state from the time of the incident. When you’re looking at a team that isn’t producing work fast enough, look at the records. Look at the team chats and emails, look at the tickets, look at the repository code reviews and check-ins. What do you see? Are production incidents happening that are taking up lots of time? Are a bunch of people sick? Are they bickering over coding style in their code review comments? Are the tickets that are being written vague, too big, too small? Does the team seem upbeat in their communication style, sharing fun things as well as important work in chat, or are they purely business? Look at their calendars. Is the team spending many hours a week in meetings? Is their manager not doing 1-1s? None of these things are necessarily smoking guns, but they may point to an area to address.
Perhaps everything seems OK in all of these indicators, but the team still just is not performing as well as you believe they should. You know the talent is there, the team is happy, and they’re not being overburdened by production support. So what’s happening? Now is the time to start doing some potentially destructive investigations. Sit in their meetings. Are they boring to you? Is the team bored? Who is speaking most of the time? Are there regular meetings with the whole team where the vast majority of the time is spent listening to the manager or product lead talk?
Boring meetings are a sign. They may be a sign of inefficient planning on the part of the organizers. There may be too many meetings happening for the information covered. They may indicate that the team members don’t feel they can actually help set the direction of the team, or choose the work that will happen. They often signal a lack of healthy conflict on a team. Good meetings have a heavy discussion element, where opinions and ideas are drawn out of the team. If the meetings are overscripted, so that no real conversation can take place, it stifles that creative discussion. If people are afraid to disagree or bring up issues for fear of dealing with conflict, or if managers always shut down conflict without letting disagreements air, this is a sign of an unhealthy team culture.
Be aware, though, that while teams can be black boxes, they share a characteristic of another famous box—the one containing Schrödinger’s cat. The point of Schrödinger’s experiment was to show that the act of observing changes the outcome, or rather, causes an outcome to happen. Likewise, you can’t go into a team and not change the behavior of that team by being around them, sitting in their meetings, and watching their standups. Your presence changes the team’s behavior and may hide the problem you’re trying to find, in the same way that a log statement can cause a concurrency issue to be magically erased, at least for some time.
Ask the team what their goals are. Can they tell you? Do they understand why those are the goals? If they don’t understand the goals of their work, their leaders (manager, tech lead, product manager) aren’t doing a good job engaging the team in the purpose of the work. In almost every model of motivation, people need to feel an understanding and connection with the purpose of their work. Who are they building these systems for; what is the potential impact on the customer, the business, the team? Did they have any part in deciding these goals, and the projects that they’re doing to achieve them? If not, why not? When you see a team spending all of their time on engineering-sponsored projects and neglecting product/business projects, it’s likely that the team doesn’t appreciate or understand the value of the product/business projects they’re supposed to be working on, and therefore they lack the motivation to tackle them.
Finally, you might take a look at the actual team dynamics. Do people like each other? Are they friendly? Do they collaborate on projects, or is every person working on something independently? Is there banter in the chat room, in emails? Do they have a good working relationship with other adjacent departments, and with their product managers? These are little things, but even very professional groups tend to have a degree of personal connection between the members. A bunch of people who never talk to each other and are always working on independent projects are not really working as a team. There would be nothing wrong with that if the team were performing well, but given that they’re not, this may be contributing to your problem.
Sometimes managers of managers choose to approach such problems as something that the team manager just needs to fix. You measure the manager on the output of his team, after all, and it is his responsibility to fix it if things are not going well. This is true, but just as I sometimes jump in and help debug complex system outages even though I rarely write code, it’s OK to jump in and help debug team issues as you see them, particularly when the manager in question is struggling. It can be an opportunity to teach the manager and help him grow. It can also reveal more foundational problems with the organization, such as a lack of senior business leadership that even the best managers can’t identify or resolve alone.
The pursuit of why when it comes to organizational problems is the thing that gives you patterns to match on, and lessons to lead with. We get better at debugging by doing it often, and learn which areas tend to break first and which indicators provide the most value for understanding issues. We become better leaders by pushing ourselves and our management teams to really get to the bottom of organizational issues, searching for why so that we can more quickly resolve such issues in the future. Without the drive to understand why, we rely on charm and luck to see us through our management careers and to make our hiring and firing decisions. As a result, we have a huge blindspot when it comes to truly learning from our mistakes.
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.
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.
There are few strategies I’ve learned about building a roadmap:
Be realistic about the likelihood of changing plans given the size and stage of the company you work for. If your startup has a history of changing the year’s plans every summer to account for the business results from the first half of the year, be prepared for a change in the summer, and try not to promise things to your team that would require continuity beyond that point.
Think about how to break down big projects into a series of smaller deliverables so that you can achieve some of the results, even if you don’t necessarily complete the grand vision. Breaking down the technical work will require you to work closely with the product or business managers to figure out how the details should be prioritized. All of you should be aware by now that things will change quickly, so everything must be repeatedly reexamined with an eye toward what’s most valuable right now.
Don’t overpromise a future of technical projects. Don’t promise your team exciting technical projects “later,” because the product roadmap for later hasn’t been written yet. This kind of thinking will get hopes up and then disappoint. If the project is important, get it scheduled now—or as close to now as possible. If the project is not urgently important, you can put it on the backlog, but you should be realistic that once “later” rolls around, there will be a long list of competing priorities from other parts of the business. If you haven’t taken the time to articulate the value of this work, it will get pushed aside in favor of projects that are more clearly valuable.
Dedicate 20% of your team’s schedule to “sustaining engineering.” This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, doing minor cleanup, and providing ongoing support. Take this into account in every planning session. Unfortunately, 20% is not enough to do big projects, so additional planning will be needed to get major technical rewrites or other big technical improvements. But without that 20% time, there will be negative consequences with missed delivery goals and unplanned and unpleasant cleanup work.
Understand how important various engineering projects really are. Product and business projects usually have some kind of value proposition to justify them. However, the same rigor isn’t always applied when it comes to technical projects. When an engineer comes to you with an engineering project that she wants to do, think about framing the project by answering these questions:
- How big is that project?
- How important is it?
- Can you articulate the value of that project to anyone who asks?
- What would successful completion of the project mean for the team?
The value of these questions is that you start to treat big technical projects the same way as product initiatives. These projects have advocates and goals, they have schedules, and they are managed like other big initiatives. This is a scary process because there are times when you “know” something is important, but you don’t know how to articulate it in a way that the business will value. Especially given the complex nature of technical projects and the challenge of measuring things like engineering efficiency, you’re sometimes stuck trying to explain technical details to a nontechnical partner who may not totally understand where you’re going or why. My advice is to do your best to gather data to support yourself, and talk about what will be possible when the work is done. If you look at a technical project and realize that you’re proposing a bunch of work for a system that is rarely changed and won’t enable core improvements to your technology or business, it probably isn’t worth the effort. Unfortunately, there is never enough time for all the exploratory engineering, legacy code cleanup, and technical quality improvements your team will want to do, and this process will help you pick your battles.
So, back to our uncertain roadmap. Projects change. Teams may even be disbanded or moved around in ways that you don’t understand or agree with. As a manager, the best thing you can do is help people feel capable of tying up loose ends, stabilizing the current in-flight projects, and easing into their new work in a controlled fashion. This is an area where you can and should push back. Make sure that your teams get adequate time to finish up current work. Furthermore, push for engineering involvement in the early planning for the new work so that people can get excited about the projects they are moving on to. Take the time yourself to understand the reasons for the move, and even if you don’t totally agree, do your part to help make those reasons clear to your team and help them understand the new goals. The calmer you can be in the face of these changes, and the better you can show (or fake) enthusiasm for the new direction, the easier the transition will be for your whole team.
When you are faced with waves, you can let them pull you under or you can learn how to surf. Hang 10.
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.
To move forward, systems need constant technical work: new languages, frameworks, infrastructure, and features. There’s only a limited amount of development time and energy that can go into improving these systems, and you’re accountable for making sure the team is placing its technical bets in the right places. You oversee these investments by matching the proposed technical projects and improvements to the future of the product or customer needs. Looking holistically across the portfolio of projects, you can see where the areas of greatest need or opportunity lie, and focus the team’s efforts accordingly.
You’re not the person who identifies all technical projects. Having accountability for the team’s technical investments doesn’t mean that you personally do the research to find potential investments. Instead, you guide these investments by asking questions. What are the current projects, and what surprises or bottlenecks have they uncovered? How is the team thinking about the future of the systems? Which teams are asking for more engineers, and why do they think they need more people? Which teams are slow but don’t want to add more people to improve their throughput? Why are they advocating for this specific project right now? You need to know enough about the work to sniff out misguided efforts and evaluate proposed investments.
By knowing what your teams are excited about and what they value, you can rally them around product initiatives. You know enough to raise concerns when a feature idea is technically difficult and when a technical idea has unforeseen business implications. You ensure that engineers make decisions with an understanding of the business perspective and the future of the product roadmap. When technical work requires uncertain research and development, you’re capable of explaining why that uncertainty exists to your nontechnical counterparts. Understanding the business and customer goals, you offer guidance as to which technical projects can achieve those goals within reasonable time frames.
As a director-level manager, you still need to have enough understanding of the technology in your organization to make specific requests without distracting the senior engineers with questions. By knowing enough about the progress of your teams, the projects, and bottlenecks, you can filter out technically infeasible ideas and map new initiatives onto ongoing projects. These specific requests should be used to keep the teams productive and balance technical risks with organizational goals. Here’s an example of how this works:
Your VP tells you that she wants to improve the search experience to grow active users by next quarter, and she can give you more engineers to do the work faster. You know the team can’t usefully add engineers to modify search because it’s in the process of being rewritten. Instead, you direct them to prioritize the work to expose the new API earlier so that the product team can finally run some of the tests they’ve been asking for. You explain what’s possible to the VP and make sure the team is focused on finishing work that can make those higher-level goals achievable.
Managers who don’t stay technical enough sometimes find themselves in the bad habit of acting as a go-between for senior management and their teams. Instead of filtering requests, they relay them to the team and then relay the team’s response back up to management. This is not a value-add role.
This is a highly technical job that can’t be done by a person who does not understand and appreciate the challenges and tradeoffs of software engineering and technology. If your team invests their time poorly, it will reflect on you as their leader for not helping them come to better decisions. Rely on your instincts to guide where you spend your time and attention, and don’t neglect your technical instincts just because you are busy with people and organizational challenges.
Given your level of technical responsibility, how should you invest your time in order to stay technically relevant?
Read the code. Occasionally taking the time to read some of the code in your systems can help remind you what it looks like. Sometimes, it also shows you places where things have gotten ugly and need attention. Looking over code reviews and pull requests can give you insight into changes that are happening.
Pick an unknown area, and ask an engineer to explain it to you. Spend a couple of hours with one of the engineers who is working on something you don’t understand, and ask him to teach you about that area. Go to a whiteboard or share a screen and have him pair with you on a small change.
Attend postmortems. When outages happen, make it a priority to attend the post-outage debriefs. These meetings are often full of details about the process of writing and deploying software that you miss when you aren’t coding every day. Standards that you thought were obvious have been neglected or ignored. Communication between teams is lacking, and tooling is hurting more than it is helping. In times of failure you can most clearly see where problems have built up, and you learn where your attention is needed.
Keep up with industry trends in software development processes. One major weak spot for managers is losing touch with the tools and processes for actually developing, testing, deploying, and monitoring code. These are the places where new ideas can make your teams significantly more effective. Not every trend is worth pursuing, but make time to learn about how other teams deliver software so you can keep your teams evolving.
Foster a network of technical people outside of your company. The best stories are the ones that come from people you trust. Keeping up a network of peers in engineering and engineering management gives you people to ask for opinions on new trends. Use this network to get the real experiences behind the blog posts, talks, and sales pitches for new technology.
Never stop learning. Find articles and blog posts about technology and read them. Watch talks. Pick something you’re really curious about and dig in a little bit deeper, even if it isn’t relevant to your team or company. Don’t be afraid to ask questions of your team and look for opportunities to learn from them. Learning is a skill that you can practice to keep your mind sharp.
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?
- Andrew S. Grove, High Output Management (New York: Vintage Books, 1983).