For many fast-growing companies, introducing a management role feels, at best, like a waste of time, or at worst, like the beginning of big company ills: more meetings, slower decision making, political maneuvering. You can almost hear the protests of early employees ringing in the hallway: “We’re going corporate!”
But despite the potential objections, an explicit focus on people management is vital to company success, particularly at fast-growing companies. With proper training and a healthy culture, people managers can help teams scale by maintaining morale, ensuring alignment between work assignments and company goals, resolving disputes, and preparing the engineering team for the next phases of growth.
Consider these problematic scenarios:
“At one point, my manager had up to 70 reports. Our feedback meetings were worse than useless. He basically cut-and-pasted my self-review with a few quotes from what my teammates had said about me...”
“I’ve been at the company for six months and I’ve never had a one-on-one meeting with my manager. I’ve had a few different ones, but I’m actually not sure who my manager is right now.”
“On my first day, I was issued my laptop and badge by IT and then told to go to my manager’s office. I wandered around until I found it, but she wasn’t there. I waited in the hallway for two hours. Luckily, some former coworkers from my previous job found me and took me to lunch.”
Any veteran of a fast-growing team can relay similar stories. Are these negative experiences just par for the course? The cost of doing business in tech? On the contrary, we believe an informed approach to scaling people management can avoid such missteps and materially improve the performance of your team and company.
The primary lever for growth is hiring. Here, we’ll talk about the secondary effects of growth, the challenges that come from having more and more humans involved in getting the work done. We’ll start with the need to manage the people that make up the team.
When new teams are formed, whether as a startup company or within a larger organization, the early days feel wonderfully efficient. Brainstorming ideas, hashing out a design, fixing problems—it all feels effortless. The hard work and long hours don’t feel like a burden, because the impact of the work is clear and meaningful. The team builds a bond forged by the challenges they are tackling together and the uncertain road ahead.
If they are successful in building the right product, the team often falls victim to its own success. Overwhelmed by the demands of a flood of new customers, the already hard-working team finds that they cannot keep up. The only option to quickly scale the team’s output is to grow the team.
Remember, teams are groups of people. Because people are unique in their collection of talents and motivations, it’s rare that they can self-organize into a cohesive unit that can efficiently pursue a common goal. This is the key role that people managers play.
People management is distinct from other management responsibilities:
These are important responsibilities, and at many companies the same managers may be responsible for some of these in addition to people management. But they are less critical to scaling than having a people management strategy that helps each team grow more efficiently and effectively. As my colleague Joe Xavier once said, “People management provides the structure and connective tissue to allow a group to achieve a common objective.” Successful people managers achieve this by:
Getting the right people on the team, and getting the wrong people off the team
Ensuring the team is happy and productive by providing motivating work assignments, appropriate compensation, learning opportunities, and career guidance
Helping the team succeed in their work by focusing on the highest-priority outcomes, resolving disputes and deadlocked decisions, and removing distractions
Providing the team with any necessary resources, whether these are new team members that can fill a skill gap, conference room space for a brainstorming session, or a big monitor to display a project dashboard
These are the critical functions of people management. Though the specific practices involved may vary quite a bit, these functions apply whether the team is large or small, junior or veteran, composed of individual contributors or senior directors of large organizations. However, if you flip that list around, it’s easy to understand how a lack of investment in people management can harm the growth of the team by:
Adding the wrong people to the team, or allowing the wrong people to stay on the team too long before taking action
Letting the team’s morale and productivity suffer by ignoring members’ work assignments, compensation, and career growth
Providing no focus or prioritization, and allowing disputes and distractions to hurt productivity
Starving the team of the resources they need to be successful
Those of us who have lived through periods of hyper-growth will recognize many of these problems, and can tell tales of the resulting damaging effects: burnout, team conflict, a loss of faith in leadership, confusion about the team’s mission, and ultimately unwanted departures from the company. For an interesting case study in the value of people management, read Buffer’s revealing retrospective on what happened after they eliminated managers and why they reverted eight months later.
At small companies, people management functions tend to be handled as needed by individuals in leadership positions—typically, the founders of the team. You see examples of this everywhere in the tech startup landscape, such as the common pattern of having the first dozen or so engineers report to a founder-CTO who has little or no management experience. This mode is a form of ad hoc management.
As the team grows larger, this ad hoc mode starts to break down. A founder–CTO may find that after a week full of VC pitch meetings, partner negotiations, and architecture debates, they have no time to schedule one-on-ones, provide feedback, or resolve personnel conflicts. Or they may feel less qualified to deal with these as the team grows and people management tasks become more complex. Or a crisis may erupt: say a key employee quits due to lack of a clear career path or an unresolved conflict with another employee. Whatever the circumstances, the leaders of growing teams at some point realize they need to transition to an explicit management structure and culture, or more succinctly: formal management.
The timing and method of transition from ad hoc to formal management varies from team to team based on many factors. Despite this, there is a common path of how a company scales its people management:
It’s important to distinguish the reporting structure at a company (i.e., who reports to whom) from the organizational structure (i.e., how individuals are organized into teams to get things done). These often overlap, but not always. Holacracy, for example, has a very specific organizational structure, but intentionally avoids any sort of management hierarchy.1 And in matrix organizations, all the ICs in a particular discipline (designers, frontend engineers, backend engineers, PMs) report to a manager for that discipline, but they get distributed into cross-functional teams to tackle specific projects.
As you enter the transition stage, it can be hard to know when the timing is right for introducing formal people management. Leaders, distracted by customer and team growth, often rely on gut and intuition, or simply wait until a crisis emerges to force the issue. But there are usually early warning signs that people management is needed. Recognizing these and taking action can help avoid a crisis.
There are a number of warning signs that suggest a move from ad hoc to formal people management is needed:
Individually, none of these warning signs necessarily indicate a crisis. But if you’re seeing several crop up at your company, it’s time to act. Try to quickly diagnose the underlying causes, and in parallel start working on a more formal approach to management. “Introducing Formal People Management to a Team” describes how to do this.
The longer you wait, the more you are probably accruing what Ben Horowitz has called management debt: “Like technical debt, management debt is incurred when you make an expedient, short-term management decision with an expensive, long-term consequence. Also like technical debt, the trade-off sometimes makes sense, but often does not.”2 In this case, the expedient decision is to keep doing things the way you’ve been doing them rather than address the warning signs by improving your management practices.
But if you’re not seeing any warning signs, or if they are mild and manageable, you may be wondering when you should start the transition to formal management. There are many factors that can influence the ideal timing of this change. At first, you might just look at the size of the team. There is a body of research on how many direct reports a single manager can reasonably handle, often called span of control, with typical numbers quoted in the 7 to 10 range.3 Based on this model, when the founding team grows beyond 10 people, it’s time to move to a more formal management structure.
But different teams require different levels of teaching and assistance from their managers, something Drucker calls span of management responsibility. Some leaders are more equipped than others to perform ad hoc management tasks in parallel with their other tasks. And some team structures allow day-to-day management tasks to be distributed across multiple leaders instead of being centralized in a single people manager. So there is no simple rule for when to shift to formal people management.
There are some obvious factors to assess in planning the timing of your transition to formal management:
Ultimately, the ideal timing depends upon how much people management the team needs, and how well such management is getting done in the absence of an explicit manager.
People management functions are crucial during growth, but it is often necessary to perform them without a dedicated manager during a team’s early stage. Small teams may not have the funds necessary to hire a dedicated person. Or once they decide to do so, it may take many months to find the right person. In the meantime, team leaders may need to get creative to ensure that management functions get done and are not simply ignored.
Here are some ways to survive without a dedicated people manager:
Establish a technical management role. Some companies give their “tech leads” responsibility for technical decisions on the team rather than rely on the team’s manager.
Formalize a Product Manager or Program/Project Manager role. Identify someone who can own the product roadmap and/or help the team break it down into milestones or sprints.
Clearly define the development process (peer reviews, testing strategies, etc.). This allows ICs to better self-manage in these areas.
Encourage healthy peer feedback and train the team on how to do it well. See Alexander Grosse’s blog post “Peer Feedback” for more information.
Optimize the skill balance on the team. Sometimes the perceived need for management is actually caused by a skill gap; for example, the team keeps missing its milestones because the team members are not good at debugging or task estimation. It’s also possible to move ICs around to get more self-managing units—for example, a more junior team may need to borrow someone from a more senior team to hit a particularly challenging milestone.
These approaches can help delay the costs and risks of adding formal management, when necessary. But again, if you see any of the warning signs we described in the previous section, then delaying this process is probably the wrong thing to do, especially as management debt continues to accumulate.
A surprisingly common startup tale involves a group of engineers suddenly being called into a meeting: “Hi everybody, I’d like to introduce Alice. She’s your new manager, so I’ll be moving all our one-on-one meetings to her calendar going forward.” No matter how smart and capable Alice is, such an abrupt transition is likely to generate backlash, chatter about how the company is “going corporate,” and gloomy predictions of more meetings and lots of politics.
The resulting loss of productivity can be costly, especially during a time of growth for the young team. So what can team leaders do to avoid this?
There are some simple steps you can take before making any changes to your reporting structure. To begin with, decide what sort of management culture you want. What are the expectations of managers? How are these different from related roles you might have, such as tech leads or product managers? What is each manager’s primary focus—people development, execution, or something else? How will managers’ performance be evaluated? This may sound like a lot of work to sort out, but it doesn’t have to be. If you know who your first dedicated manager will be, pull them aside and ask them to read a few chapters of a book like Rothman and Derby’s Behind Closed Doors (Pragmatic Bookshelf). Then discuss the book over lunch. You’ll pretty quickly realize what the two of you value about management, and just writing that down gives you a first cut at a management culture.
Consider defining parallel career paths (sometimes called career ladders), one for engineers and a separate one for managers. Many small companies don’t bother establishing these until very late (e.g., Twitter didn’t have them until 2011, five years after it was founded!), so why do it now? An important goal is to avoid the perception that engineers are now second-class citizens who must be “promoted” to managers in order to advance in their career. Management is a very different role requiring different talents from engineering to be successful. Not all great engineers will be great managers (and vice versa), and you want to avoid the situation where senior engineers end up feeling forced to do something they aren’t motivated or suited to do.
Find internal candidates who might make effective managers. You may have engineers who have been successful managers in the past who might be willing to return to the role. Otherwise, look for engineers who demonstrate the qualities you want to see in your management team (empathy, credit-sharing, mentorship, strategic thinking, etc.). Watch out for those who demonstrate warning signs such as an inability to handle conflict or stress, difficulty discussing sensitive subjects, and desire for more control or information access. And importantly, don’t confuse engineering prowess with management potential. Tim Howes, cofounder of LoudCloud, said “Watch out for the temptation to take your top coders and make them managers...management is about people, it’s not about code.”5 We have a more detailed discussion on how to identify and develop management talent in existing employees in “Developing New Managers”.
Tell your team that you’re thinking about making some changes to your management structure. This is not the time for surprises. Ideally, give the team at least a month or more before you make any concrete changes, to allow anyone with concerns or with an interest in pursuing management as a career path to speak with you about it.
The overarching theme here is to avoid surprises and an erosion of trust. A team that understands why management is needed and is ready to take advantage of it is much more likely to maintain high productivity than a team that is confused and possibly demotivated by the change.
Introducing a new management structure can be a stressful moment, and a morale risk if handled poorly. Here are some ideas for how to ensure that this is a positive change for the team.
Try to be as clear as possible about your motivations and intentions for making the change. It’s really tempting to rip off the Band-aid and just show the team an org chart. But to properly digest the changes, employees need to understand why you’re making those changes and understand how they will benefit.
CEO: Okay, folks, we’re making a big change today. We’ve decided that we need people managers, so Ann will be taking on that role. These people will now report to Ann: Bob, Carol, Dave...
General reaction: Groan!
CEO: Okay, folks, I’ve been hearing a lot of grumbling about lack of direction and career growth. I clearly haven’t had enough time lately to spend with each of you in one-on-one meetings, and I don’t see that changing given our upcoming fundraising. So, I’ve decided we need to create an Engineering Manager role, and I’m working right now on a job description and a rollout plan. If you’re interested in learning more, please stop by...
General reaction: Okay, we’re listening.
Keep in mind that many of us have had bad managers in the past and thus may be predisposed to think poorly of management as a role. So, take the time to fully explain the value you expect to get from having people managers and how you plan to evaluate their success.
If you took the time to define your management culture, then communicating this during the rollout will help your ICs understand the motivations for the changes you’re making, as well as what to expect from their new managers. You might even pique the interest of some to consider becoming managers themselves!
If you decide to have an existing team member take on management responsibilities, be restrained in your public praise for their transition, no matter how grateful you are (see “This is not a promotion”). In short, you don’t want to risk the perception that management is the best path to greater recognition, nor do you want to make it more difficult for the person to transition back should they turn out to be unfit or uninterested in the role.
A common concern voiced during rollouts is that engineers will have less influence over the roadmap than managers, despite having a greater base of knowledge about the product and technology in use at the company. Although this is true at some companies, it does not have to be. Providing ICs with an explicit mechanism to influence the roadmap ensures that they too can contribute in a predictable and useful way.
An example: while VP of Platform Engineering at Twitter, Raffi Krikorian introduced a “Platform Steering Group,” which comprised the most senior ICs in Platform Engineering. The Steering Group’s charter was to solicit project proposals from anyone on the team, with a particular focus on tools and technical debt projects that would accelerate future development. They would then review the proposals and select one or more to include in the following quarter’s roadmap. This acted as a bottom-up override mechanism in the planning process, helping ensure that unglamorous-but-important projects would actually get funded rather than kicked down the road.
You can also ensure that ICs have a strong voice in hiring and promotion decisions. There are various ways to do this, but the general point is that having managers solely responsible for hiring decisions can leave engineers feeling disempowered, and magnify resentment in cases where a new hire championed by the manager fails to perform.
Adding a new layer of management can make ICs feel like they no longer have access to senior leadership. One day, you’re reporting directly to the head of your group; the next day, your one-on-one gets cancelled, and there’s a new manager between you and your old boss! Counteract this via occasional skip-level one-on-ones, where the head of the group meets directly with ICs, bypassing any managers in between. You can also use roundtable discussions (where a selected group of ICs meets with senior leaders), attendance at planning off-sites, or participation in executive staff meetings. Try to intentionally “flatten” the org so that communication between senior leaders and the rank-and-file doesn’t disappear, but is, in fact, strengthened.
Last, but perhaps most important, knowing how well the management team is performing is hugely important, and ICs can play a major role in assessing this.
Ask any gathering of engineering managers how many of them were trained as engineers and you’ll consistently get responses in the 80%–100% range. And yet, if you ask them how many received formal management training before becoming managers, the response will be shockingly the opposite, 0%–10%. For some reason, the tech industry treats engineering management as almost entirely a “learn on the job” profession.
We recommend a more disciplined approach. Once team leaders recognize management potential in one of their ICs, they should assist them in the transition to a management role, provide them with lightweight, ongoing training, and help them grow into happy and successful managers. This can provide a strong scaling advantage, for the reasons we previously outlined.
Knowing which engineers will make great managers is a bit like knowing which professional athletes will make great professional coaches. Their background as athletes is an important requirement, but being a coach also requires so many other talents, you won’t really know for sure until they try out the job. Fortunately, there are a few indicators that can help you construct an educated guess about whether a candidate will be successful in a management role.
The simplest way to evaluate management potential is the “Up-Sideways-Down” rubric (see Figure 1-3).
Here’s how Up-Sideways-Down works:
As a manager, you can also try to evaluate whether a promising IC possesses some key traits that are correlated with management success. In rough priority order:
Seeing these qualities can give you a boost of confidence about someone’s ability to handle a management role.
You should also look for negative indicators that should make you wary of granting people a management role:
Again, there is no perfect formula for predicting success as a manager, but looking at these different factors should give you a starting point and provide input for a conversation with the prospective candidate.
Most first-time managers (like many first-time parents) feel woefully underprepared for their new responsibilities. And, frankly, most are. Very few receive any sort of training for the job they’ve been given, and often the transition is sudden and awkward for all involved. But it doesn’t have to be this way.
When asking an IC to become a manager, the first step is to set their expectations. Specifically, highlight what’s likely to be confusing, emotional, or challenging about the new role. It’s easy to fool ourselves into thinking that ICs must know what being a manager is like, since (except for new college graduates) they have had time to observe their own manager organizing meetings, putting together career plans and roadmaps, resolving conflicts, and so on. But there are many aspects of the job that they cannot observe.
We covered much of this topic in “Communicate and Deploy the Plan”. In short, be transparent about why this person is becoming a manager, how their success will be evaluated, and what changes the team should expect day to day, if any. Do this before the reporting relationships change, so any concerns can be surfaced and dealt with prior to the transition.
It would be nice to be able to say, “Sign your new managers up for this 12-week class and they’ll be totally set up for success!” But it’s unlikely such a class exists, nor is it reasonable for every organization to lose people for 12 weeks to get them ready for their new role. But there are simple, time-efficient things you can do to help educate a new manager on the basic parts of their new role.
The simplest approach is to pick a specific management book, blog, or article that you find particularly relevant. Ask the prospective manager to read it and then have a one-hour discussion with you when they are done. It doesn’t really matter which one it is, as long as it is broad enough to cover some essential management skills (e.g., one-on-ones, providing feedback, and setting direction). The goal of your follow-up conversation is to ensure that you both have a shared understanding of the role and your expectations of it. It’s not uncommon for two managers to have very different styles of management, so this is your chance to establish which aspects you want to be done a certain way, and which ones the new manager is free to define on their own. For example, you may feel strongly that managers must provide informal performance feedback to each report at least monthly, but care less about how the rest of their one-on-one meetings are structured. Not establishing these “invariants” up front can lead to friction between you and the new manager down the road.
If you have the time and motivation to do more to prepare your new manager, pick a few ideas from this menu and run with them:
Whichever of these you go with, please remember the most important thing at this stage is not adopting any specific training technique, but fostering the habit of ongoing education, which is so easy to lose track of during the confusing and busy early days as a manager.
When converting an engineer to a manager, make sure you don’t describe this as a promotion, but rather a significant change in role and responsibilities. There are two motivations for this rule. First, you don’t want engineers to think that shifting to management is the best way to get ahead, since this is not a healthy motivation for taking on such a different and challenging role. Second, describing the conversion as a promotion and/or showering the person with fanfare will make it very difficult to step back from the role if they decide it is not for them. If a new manager ends up failing or unhappy in their new role, you don’t want them to have any artificial incentives to stay in that role. Better that they step aside and get some training if they want to try it again someday. Lindsay Holmwood wrote an excellent post on this subject titled “It’s Not a Promotion, It’s a Career Change”. Also see Derek Brown’s post “Management Is Not a Promotion”.
A common approach that we strongly endorse is giving an internal candidate an incrementally increasing amount of management responsibility to assess whether they would enjoy this new role or not. For example, you may have a promising potential manager who is acting technical lead for one of your teams. Before making the role change official, you could first ask the tech lead to take a larger role in career guidance for the team members by having one-on-one meetings with them, perhaps alternating with your own one-on-ones to avoid meeting overload. Then, have them take on more of the team roadmap planning and customer outreach. And then have them present the roadmap to key stakeholders. At each step, you have an opportunity to assess, provide guidance, and gather feedback on whether these responsibilities are appealing or a burden. Be sure to communicate your plans with the rest of the team so that no one is confused about the changes in management responsbilities.
New managers, as with any other employees, should know when and how their performance will be assessed and communicated. Of course, continuous timely feedback is best, but you should also agree on a milestone for a more formal assessment. This is particularly helpful with new managers because, frankly, not everyone is cut out to be a manager, nor will everyone enjoy the new role. Without a mutually agreed-upon date on the calendar for a go/no-go decision, it’s easy for months and months to pass without anyone making the difficult decision to revert.
Make sure when you pick the date, perhaps three or six months out, that you also provide the rubric that you’ll be using to assess them. Will it be solely your view, or will you solicit 360-degree feedback? What aspects of the role will you be looking at? This provides some structure that the new manager can use to guide their own development and do their own self-assessment.
When introducing formal management, most companies have a bias toward converting current ICs to management roles, and there are good reasons for such a preference. Current employees have an advantage in already understanding the product, the technology stack, and the values and culture of the company. External hires, by contrast, are often viewed with suspicion—will they be more corporate and political? Will they share the same values as the rest of us?
While these concerns are valid, hiring experienced managers externally often becomes a necessity, particularly as the company grows. At some point, you’ll run out of qualified and/or interested internal candidates, and need to look elsewhere or risk accruing management debt. And there can be concrete advantages to hiring from the outside, depending on the candidate, including:
Greater experience, particularly with less common scenarios such as firing poor performers, handling layoffs, or executing reorganizations.
Novel techniques for management or engineering that were successful at other companies.
Outside perspective on how the team is approaching its work. Remember that team members often become blind to the flaws in their processes once they adjust to them.
Greater team diversity, which will, in turn, create even more diverse thinking. This includes gender, race, ethnicity, age, sexual orientation, and/or life experience.
A new network for additional hiring and/or business relationships.
In short, a good external hire should bring enough to the table to more than make up for their lack of history and context at the company.
While there may be some areas of domain knowledge that overlap with individual contributors, it’s important to craft a distinct and deliberate hiring process for managers. Start by being clear about what you’re looking for. What are the key talents and qualities you want from your management team? Strong programming chops? Awesome at recruiting? Great at execution? Once you know what the most important qualities are, you can figure out how to source and interview for those qualities, and build a process to distinguish a good fit from a bad one. By being clear and transparent about the process, you will also clarify for the team what they should expect from the new manager.
As with hiring engineers, when hiring a manager to lead your team, you should cover your most important points over the phone or video, asking questions that give you a clear yes/no signal. Avoid interviews that are just 45 minutes of chit chat. It’s especially important to get an indication of values fit during the pre-screen, since this is often one of the biggest concerns about a new manager; will they radically change the culture of the team in ways I won’t like? Some specific qualities you might look for during your interview are listed in “Identifying Management Potential”, and Camille Fournier gives some further suggestions for how to screen for engineering manager potential in “Hiring Engineering Managers”.
Checking references is an important part of the recruiting process for any role, but especially so for management candidates. Some mediocre managers have a tendency to float around because they are great at interviewing and self-promotion. You can cut through this by using your network for backchannel discussion, and by explicitly asking for references from the candidate.
Just remember to be careful with how you perform backchannel reference checks so you don’t accidentally “out” someone at their current company. Ideally, start with explicit references and go to backchannel if you don’t feel like you’re getting enough accurate data or a complete enough perspective. You want to make sure you get a 360-degree view by talking to a mix of past supervisors, peers, and direct reports. The latter is especially important since it is so commonly left out in our standard hiring process.
Even with the best-designed process, some members of the team will feel uncomfortable interviewing candidate managers. Most of them will have never been managers before, and therefore won’t be able to discriminate between good and bad answers to questions. Furthermore, even if they know what to look for, distinguishing a top-notch answer from a ho-hum answer is often more subtle than with engineering questions.
To prepare your team for the interview process, consider holding a pre-brief meeting with everyone to discuss what qualities are most important in the manager candidate. Different teams have different needs—one team might need an experienced technical leader to guide design decisions and mentor junior ICs, while another may need help collaborating with other teams and coordinating deliverables.
Based on the manager qualities outlined earlier, discuss with the team what areas to focus on in each interview session, specifically what questions should be asked and how to distinguish good and bad answers. If you’re not sure how to do this, reach out to your network for help. Your board, company advisors, and past managers should have expertise they can offer here. For example (again from Camille Fournier in “Hiring Engineering Managers”):
Q: When you bring a new team member onto your team, what kinds of things do you personally do as part of their on-boarding? Have you ever been a mentor to a new hire or intern? What was that like, what did you learn from it?
A: What you are looking for: someone who is actively engaged in the work of bringing on new people, and thoughtful about making that process better. Someone who respected the work of mentoring, who isn’t just trying to shed human interactions quickly to get back to code.
Ideally, write the questions and expected answers down somewhere so that the interview process remains stable over time as new team members are hired.
Next, decide who will be on the interview panel, and how the rest of the team can meet the candidate. Panel construction is relatively straightforward—just match team members’ interest and experience with the focus areas for each interview session, and do a practice run with anyone new to the process. But also recognize that almost everyone will want a chance to meet the prospective manager. It’s fairly common for the interview to include a lunch session where team members not involved in the panel can get a feel for the candidate. A more formal approach is to ask the candidate to give a short talk to the entire team, perhaps just a whiteboard session, on some topic of their choice.
Doing mock interviews with the team can be a fun way to prepare and calibrate what they should look for. Offer to buy a manager friend dinner in exchange for being an interview subject for your team. You might even cue your friend to give a few bad answers to see if the team can suss them out. You probably want to sit in on the interviews so you can debrief and offer specific feedback. And of course, an in-person debrief is essential once you start doing real interviews.
Finally, if at all possible, put off making a decision until you have interviewed at least two strong candidates. This reduces stress on the team because absolute judgments are harder to make than relative judgments. Finding two strong candidates can be very difficult in tough recruiting markets, but the extra effort at this stage is far less than the effort required to remove a failing manager later on.
When you’re hiring a manager, it’s even more important than with ICs to be rigorous and to bias your interview process toward saying no. A poorly performing manager can do a lot of damage, and this damage is often more subtle and harder to detect than with technical work. Teams that are eager for management help are especially vulnerable. They may have the feeling that “any manager is going to be better than no manager,” which can lead to softball interviews, a hasty review process, and making an offer to a poor candidate.
Counteract this tendency by reviewing this issue with the interview team and making it clear that you want to bias toward “no” rather than “yes.” As mentioned earlier, being clear about what you’re looking for and the level of rigor you want to have in evaluating answers will help here.
Alternatively, if there are reasons to bring on someone you’re not quite sure about, set up a timeline for an initial evaluation, perhaps 3–6 months, and make it clear to the candidate how they will be evaluated and what the possible consequences are. This could be appropriate when there is a strong advocate for the candidate (perhaps a former coworker), but others on the panel have doubts based on their interview sessions. It’s important that someone, most likely the candidate’s future boss, commits to this evaluation and executes on it.
Lastly, don’t forget that every external hire has the potential to shift the culture of a company away from the values of its founding team, and this is especially true with managers. So, consider setting a cap on the percentage of managers that you will hire from the outside. This will encourage investment in potential leaders on-staff and help alleviate concerns with hiring from the outside in general.
Because some externally hired managers have not been actively coding for some time, we strongly recommend that managers go through the standard engineering on-boarding process, if at all possible. Even for managers that haven’t coded in years, participating in some way should give them context on what their engineers are expected to know, what tools they have at their disposal, and what the day-to-day workflow looks like. Some managers and/or their teams may prefer to do a coding project as a way of getting their feet wet, or even join a team as an IC for several months before taking on day-to-day management. In these cases, set expectations appropriately with the team based on the manager’s familiarity with the technology stack and how far removed they are from hands-on coding. You don’t want the team assuming the manager will necessarily perform as a senior-level engineer, only to have them reject them as a teammate for this reason. (Hopefully this was thoroughly covered during the interview process, but there may be some team members who weren’t involved, so it’s worth resetting expectations.)
While intelligent leaders can argue about the correct ratio of managers to ICs, or the division of labor between managers and technical leads, few would disagree that people managers play an essential role on a growing team. We’ve focused on ways to introduce people management to a small, growing team with minimal disruption.
Our recommended reading list for people managers:
1 See Olivier Compagne, “Holacracy vs. Hierarchy vs. Flat Orgs,”.
2 Ben Horowitz, “Management Debt”, January 19, 2012.
3 See Peter Drucker’s The Practice of Management (HarperBusiness).
4 See John Allspaw’s “On Being a Senior Engineer” and Benjamin Reitzammer’s “Mature Developers”.
5 First Round Review, “What I Learned Scaling Engineering Teams Through Euphoria and Horror”.