Chapter 4. People Management: Getting Started

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.

In Chapters 1–3, we covered hiring, the primary lever for growth. In this and later chapters, 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.

Understanding People Management

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. The first three chapters covered the mechanics of growing the team and how those mechanics change at different scaling points.

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:

Technical management
Ensure the right technical decisions are being made by the team.
Project management
Ensure projects are tracked accurately and shipped on time.
Product management
Ensure the right product is being built for the customer.

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.

From Ad Hoc to Formal

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.

Dealing with growth

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:

Early stage
This is when ad hoc people management starts. A team of 5 to 25 people (roughly half working on product development) forms around a handful of founders and one founder acts as the de facto people manager while the team builds its product and searches for a market and business model (Figure 4-1).
Transition stage
During rapid growth the team finds a market and starts to grow quickly from 25 to 100. The ad hoc people management approach starts to break down. The leadership team begins to formalize management roles and transition or hire individuals into those roles (Figure 4-2).
Mature stage
The company now has formal people management at scale. The initial management team continues to grow and evolve as the company grows from 100 to several hundred employees. An approach to multi-layer management (e.g., VPs and Directors) is put in place, as are more complex systems for performance management, career growth, and so on.
Typical early-stage reporting structure
Figure 4-1. Typical early-stage reporting structure
Typical reporting structure during transition stage
Figure 4-2. Typical reporting structure during transition stage
Note

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. We’ll cover the various options in more detail in Chapter 8.

When to Formalize People Management

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.

Warning signs that people management is needed

There are a number of warning signs that suggest a move from ad hoc to formal people management is needed:

Ad hoc people managers are dropping essential duties
Team leaders no longer have time for one-on-one meetings. They may be too busy putting out fires and doing “real work” to meet with the team. Or perhaps they spend too much time on one-on-one meetings. Because of urgent personnel issues, team leaders may start failing at other critical tasks like strategic planning and fundraising.
Confusion about the direction of the work and team
Team members become bogged down in disputes about the path forward or are confused about priorities and increasingly need leaders to step in and make decisions.
Declining product quality and productivity
Product quality is slipping—there are more bugs, customer complaints, downtime, and rollbacks. Or team leaders feel that engineering productivity is slipping and wonder whether the team is working hard enough or getting distracted by non-essential tasks.
Morale trending lower, attrition trending higher
Team members see increasing examples of poor morale—grouchy emails, antisocial behavior, and cynical talk around the water cooler. There is a noticeable shift to later arrival times, earlier departure times, or more frequent last-minute “work from home” days. You hear rumblings from individuals that “I’m not progressing in my career” or “The work isn’t interesting anymore” or “I’m feeling burned out.” And employees are leaving the company at a noticeable rate.

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.

Timing the Transition

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:

The founders’ previous management experience
The more they have, the longer they can get by with ad hoc management without accruing too much management debt.
Maturity of the engineering team
This is not simply “years of experience” (although it doesn’t hurt if your engineers have worked for a significant time at well-managed companies). But some engineers are simply more self-managing than others, requiring less time and input from their manager to get their job done, and less coaching on how to improve.4
The team’s familiarity with each other
A group that has worked together successfully in the past may need less management than a collection of individuals who are still learning about each other’s strengths and idiosyncrasies.
The team’s decision-making ability
Some teams are able to act independently, while others require input from founders/leaders to approve their decisions or break ties.
Growth rate
Teams that need to grow quickly will get the most benefit from a dedicated people manager who can drive sourcing, organize the interview process, on-board new engineers, and ensure that they have appropriate work assignments.
Importance of execution versus exploration
If you’re staring at hard deadlines and shrinking market windows, formal management can help improve predictability by reducing churn and duplicated effort. But it can also reduce exploration and serendipity as managers attempt to focus the team on the current strategic plan.

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.

Managing People Without Managers

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.

  • Invest in communication within and between teams. Chapter 11 covers a variety of ways to improve information flow without overwhelming the team with noise.

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

Introducing Formal People Management to a Team

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?

Know What You Want to Do and Prepare Your Team

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. We have devoted a separate section to this topic in Chapter 5, “Defining a career path or ladder”, including references to example career ladders that other companies have published.

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.

Communicate and Deploy the Plan

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.

Be transparent and give context

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.

Bad

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!

Better

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!

Minimize fanfare for new managers

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.

Provide ways for individual contributors to have influence

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—see “Making a Hiring Decision” for a discussion of hiring/promotion committees, Amazon’s “bar raiser” model, and other approaches. 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. For detailed guidance, see “Assessing Manager Performance”.

Developing New Managers

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 outlined at the beginning of the chapter.

Identifying Management Potential

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 4-3).

Evaluating management potential from various perspectives
Figure 4-3. Evaluating management potential from various perspectives

Here’s how Up-Sideways-Down works:

Up
Think of examples of your IC “managing up”—in other words, giving you constructive feedback, accurately representing the state of work, and alerting you of impending problems such as a schedule slip or an uncovered design flaw. Engineers typically have many opportunities to manage up during the course of a software project.
Sideways
Identify examples of how this IC has worked well with others. Have they shown that they can work well with their current and future peers, such as other people managers or technical leads? In addition to the aforementioned feedback, status reporting, and escalation of issues, they should also be an effective collaborator, sharing responsibilities when appropriate, distributing credit when credit is due, and not pointing fingers when problems arise.
Down
Find examples of when the IC has shown leadership. You want to see that they can guide the work of other engineers, helping them learn and become more effective. Since they have not been officially managing yet, this often takes the form of mentoring an intern or helping a new hire come up to speed on the tech stack. They may have hosted a brown-bag session to teach the team about an area of expertise, or improved the team’s process for getting work done. Or they may simply show a penchant for helping others who are having problems, whether those are professional or personal.

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:

Mentorship
Do they happily help coworkers improve their skills and knowledge, even when it means slowing down their own work?
Communication
Can they clearly articulate complex ideas, in both verbal and written form? Can they address difficult subjects, such as critical feedback, without mincing words or being vague?
Empathy
Do they seem capable of understanding the feelings and perspective of others, even when they may feel differently themselves? In cases of conflict, do they first seek mutual understanding or are they focused on victory?
Organic leadership
Does the team look to this person for guidance and direction, even without a formal leadership role? When they talk, do others listen and act?
Humility
Can they gracefully share credit with others when appropriate? Or conversely, do they seek the limelight, even when it’s not in the best interest of the team?
Strategic thinking
Can they see beyond their current assignments to understand the bigger picture, how the work of the team fits the overall product direction and the needs of the business? Do they push back or ask hard questions when they don’t see how these fit together? Can they set aside short-term goals long enough to realize there is a larger strategic opportunity that the team should pursue?

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:

Handling stress
Do they lose sleep or composure when the team is on a tight deadline?
Conflict avoidance
Are they unable or unwilling to discuss difficult or controversial subjects? Do they give in quickly when others present a differing viewpoint, or can they stand up for their ideas and hash out a compromise?
Difficulty communicating
When you ask for feedback, do they have a hard time being open and honest with you? Do they prefer to talk to you first about issues with their teammates rather than addressing them directly? Have they failed to volunteer important information that you subsequently found out about via other channels?
Desire for control
Do they seem motivated by having others do their bidding? Do they often ask you to intervene in a situation to help make it go their way?
Information hoarding
Are they constantly seeking greater access to information, especially from your peers and managers? Do they withhold information from peers and reports? Do they trade in hallway rumors and gossip?

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.

Surviving the Management Transition

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.

What to expect: the first-time manager

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.

Time management and the “manager’s schedule”
As has been written about in many places (most famously by Paul Graham in one of his most widely read essays), the manager’s schedule and the individual contributor’s schedule are completely different, for good reasons. The switch from one to the other can feel very awkward to the new manager, like “death by a thousand time slices.” Remind the new manager that being highly available and interruptible is an important part of their job, that handling an interruption is actually a form of getting work done, and that when they need focus time (hopefully infrequently) there are ways to achieve this—headphones, conference rooms, or working from home.
A manager may no longer be “one of the gang”
The manager role can be a lonely one; simply wearing the manager title can leave you uninvited from informal group lunches or from that snarky chat channel that everyone seems to be enjoying. It’s not inevitable, but knowing that it’s likely will help the new manager handle it with less emotion.
A manager’s work output is totally different
Engineers are wired to feel rewarded when they build stuff. These reward circuits take a long time to rewire after a management transition. A new manager needs to learn how to feel good about the things their team builds, and realize that this depends on their work as a manager: providing clear direction, helping the team develop their skills, and removing obstacles from their path. New managers often cling to writing code and weighing in on technical decisions because this rewiring process takes so long. This can distract the new manager from learning about their new job, and leave no space for engineers on the team to establish their own technical leadership. To counteract this, you should set expectations now on how much and what kind of technical work is acceptable and under what circumstances. For example, you might say “you’re welcome to read your team’s code, but you should only write code when all your other management work is done,” which emphasizes that the needs of the team come first. For more on this, read Cate Huston’s “The Hardest, Shortest Lesson in Becoming a Manager”, about letting go of coding tasks, and why it’s hard but the right thing to do.
Being managed as a manager
The way an IC is managed and the way a manager  is managed can be very different. As a manager-of-managers, explain how you intend to provide direction, define goals, and set expectations. Also, try to be clear about where you are comfortable with autonomy and where you expect to be involved in decision making. If this is your first time managing managers, you may not be clear on these yourself, so seek some guidance from a mentor or company advisor if you need it.

Preparing the team for their new manager

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.

Lightweight management training

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:

Mentorship
Ask a few managers you know, either in the company or outside the company, to meet for 30–60 minutes (perhaps weekly for a month) and talk about their transition, what they wished they had known before starting the job, or the biggest challenges they’ve faced. If it goes well, try to make this a recurring monthly session, giving the new manager a safe space to share challenges and ask for advice.
Professional coaching
There are lots of executive coaches out there, not all of them great. But if you know a great one, or can get a referral from your network, the money you spend on this will probably be repaid many times over.
Reading group
This is a great way to foster ongoing learning in your management team, and there’s no reason why a prospective manager couldn’t join the discussion before their transition. Just make sure you or someone you designate is in charge of selecting the reading for each session and guiding the discussion.
Focused practice sessions
Use part of your one-on-one time to practice the skills you think will be most difficult for your new manager. For example, “Imagine that I report to you, and I’ve been working for several months leading a project with an important client. You’ve decided that my job performance isn’t up to snuff and have decided to replace me as the lead with one of my peers. Take a few minutes to think about how you’d break the news to me. Then go ahead and try it.” Because of your reporting relationship, some new managers may be more comfortable practicing these skills with a mentor or a trusted peer.
Shadowing
Have your new manager shadow you in all your meetings (except perhaps one-on-ones) to get a better sense of a day in the life of a manager. This is especially useful in areas where the new manager has had little or no visibility, such as recruiting and closing candidates, presenting to upper management, collaborating with other senior leaders, or meeting the legal obligations that managers have regarding harassment and hostile work environments.

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.

This is not a promotion

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.

Performance Assessment and the Go/No-Go Decision

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. Additional guidance on how to help managers thrive is covered in Chapter 5.

Hiring Managers Externally

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.

Interviewing Managers

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 (see “Interviewing” for a discussion on how to hire ICs). 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.

Pre-screening

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? See “Hiring, Values, and Culture” for examples of how to interview for values. 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 explicit and backchannel references

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. Some more specific tips on how to do reference checks are covered in “Reference Checks”.

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.

Preparing ICs to interview managers

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.

Making a Hiring Decision

The general decision-making process for hiring is covered in Chapter 2. But 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.

On-Boarding Managers

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

Conclusion

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. In this chapter, we’ve focused on ways to introduce people management to a small, growing team with minimal disruption. The next chapter covers how to build a people management structure that maximizes team productivity and helps the team scale effectively.

Additional Resources

Our recommended reading list for people managers:

High Output Management by Andy Grove
Perhaps the most efficient education in technical management in existence. For example, a complex issue, rendered simple: “A manager’s output = the output of his organization + the output of the neighboring organizations under his influence.”
Peopleware by Tom DeMarco and Timothy Lister
More humane than Grove, but just as insightful: “The business we’re in is more sociological than technological, more dependent on workers’ abilities to communicate with each other than their abilities to communicate with machines.”
The Mythical Man-Month by Frederick Brooks
His influence can’t be understated. Get the edition with the “No Silver Bullet” essay added on.
Managing Humans by Michael Lopp
A collection of bite-sized essays, as thought-provoking as they are delicious.
Leading Snowflakes by Oren Ellenbogen
An excellent book focused specifically on helping engineers make the transition to engineering management.
Drive by Daniel H. Pink
His motivational framework of Autonomy, Mastery, and Purpose was a major influence on the content of this book.
First, Break All the Rules by Marcus Buckingham and Curt Coffman
What separates great managers from the rest? Read this book to find out.

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

Get Scaling Teams now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial