The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

by Camille Fournier

For early- to mid-career hires, one aspect of onboarding will likely include contributing to the team’s onboarding documentation. A best practice in many engineering teams is to create a set of onboarding documents that are edited by every new hire as he gets up to speed. He edits the documentation to reflect processes or tools that have changed since the last hire, or points that he found confusing. As the manager, you don’t necessarily need to be the person walking the new hire through this process — that could be a job for a peer, mentor, or tech lead — but you may be the person to get this process in place, and you’ll need to reinforce it for everyone who joins the team.

Your new hire needs to understand your expectations and your style just as much as you need to understand his. You’ll each need to adjust a little bit to meet the other, but if the new hire doesn’t know what you expect from him, he can’t deliver what he needs to deliver.

One final piece of advice: get as much feedback as you can about the new hire’s perspective on the team in that first 90 days. This is a rare period, where a new person comes in with fresh eyes and often sees things that are hard for the established team members to see. On the other hand, remember that people in their first 90 days lack the context that the overall team possesses, so take their observations with the requisite grain of salt, and definitely don’t encourage people in this period to criticize the established processes or systems in a way that makes the existing team feel attacked.

The default scheduling for 1-1s is weekly.

those who don’t have morning standup meetings to work around. Respect the “maker schedule” for your reports and try to give them 1-1 times that aren’t likely to be right in the middle of their productive workflow hours.

How stable or unstable are things in the team or the company? One of the topics of discussion in your 1-1s will be company news. Especially in times of rapid change or uncertainty, make sure you take the time to answer any questions folks may have. Keeping your 1-1s regular through times of uncertainty will help stabilize your team and slow down the rumor mill.

To-Do List Meeting One or both parties comes in with a list of objectives to cover, and the parties cover these objectives in order of importance. Updates are given, decisions are made or discussed, planning happens.

Feedback Meeting Sometimes your 1-1s will be devoted to informal feedback and coaching. It’s good to hold these kinds of meetings at a regular interval, especially for your early-career employees. Quarterly is frequent enough to give the topic attention without it feeling like all you talk about is career development. Many companies force specific individual goal-setting processes on everyone, so you can use this time to review progress toward goals, whether they are formal or personal. If you have an employee with performance issues, feedback meetings should happen more frequently, and if you’re thinking of firing someone I advise you to document these feedback meetings. That documentation will include the issues you discussed and the expectations that you set with the person, in writing and sent to the person (usually via email).

As much as possible, when someone does something that needs immediate corrective feedback (insulting a colleague, missing a critical meeting, using inappropriate language), don’t wait for the 1-1 to provide that feedback. If you see or hear about a direct report doing something you want to correct, try to approach that person soon after. The longer you wait, the harder it will be for you to bring it up, and the less effective the feedback will be.

Getting to Know You Whatever type of 1-1 you do, leave room to get to know the person reporting to you as a human being. I’m not suggesting that you should pry into your reports’ personal lives, but show them that you care about them as individuals.

One final piece of advice: try to keep notes in a shared document, with you the manager playing note taker.

This happens a lot when talented engineers become managers, especially if they pride themselves on their technical skills. If your value to the team has shifted from the thing you’re good at (writing code) to the thing you don’t yet know how to do well (managing people), it can be tempting to treat your reports as if they should be mini-mes.

On the other hand, delegation is not the same thing as abdication. When you’re delegating responsibility, you’re still expected to be involved as much as is necessary to help the project succeed. Sharell didn’t just abandon Beth — she helped Beth understand the responsibilities in the new role and was there as needed to support the project.

Dig Into When you feel like you want to micromanage, ask the team how they’re measuring their success and ask them to make that visible to you on an ongoing basis. Then sit on your hands if you must, but wait a week or two to see what they give you. If they have nothing to share, it’s a sign that you may need to do a course correction, which probably means digging into more details.

If you want to know how stable the systems are, subscribe to information about the alerts, look at the metrics, follow what has happened in on-call. The worst micromanagers are those who constantly ask for information they could easily get themselves. It’s OK to ask for status summaries and OK to use your team as a way of surfacing the most important information from all of these sources, but use a light touch. The team will not be productive or happy spending half their time gathering information for you that you could easily find yourself. And remember, this information is just a piece of the context, not the whole picture, and it means nothing without the goals just discussed.

Consider this scenario: Jack is having a hard time with a project, but hasn’t been asking for help with his problems. You finally hear about his struggles. At this point, it’s appropriate to tell Jack that he needs to be more proactive in sharing his progress, even if it means admitting he’s struggling. You could have Jack give you daily updates as a way of helping, but I would only use that much structure for a brief period. The goal here isn’t to punish him with micromanagement for his failure to communicate status, because all you’re doing is punishing yourself and hindering his ability to be held accountable for his own work. Instead, your goal is to teach Jack what he needs to communicate, when, and how. A word of caution, though; if you treat a struggling engineer or project as a massive failure on the part of the individual or manager, she is going to feel that blame and criticism, and instead of giving you more information in the future, she’ll keep hiding it from you as a way of avoiding blame until it’s too late.

For you, as a new manager, getting into the habit of continuous feedback is training you to pay attention to individuals, which in turn makes it easier to recognize and foster talent. You’re also practicing the art of having small and occasionally tricky conversations with individuals about their performance. Few people are comfortable with providing one-on-one praise or correction, and this helps you get over the feeling of awkwardness.

Know your people. The first required part of successfully giving continuous feedback is a basic understanding of the individuals on your team. What are their goals, if any? What are their strengths and weaknesses? At what level are they currently operating, and where might they need to improve to get to the next level? You can get some of this knowledge by reading their previous performance reviews if you have them, but you’ll also want to sit down with every person on your team and ask for his or her perspective on all of these questions.

Provide lightweight, regular feedback. Start with positive feedback. It’s both easier and more fun to give positive feedback than it is to give corrective feedback. As a new manager, you don’t have to jump into the deep end of coaching first thing.

Performance reviews go wrong because people aren’t given time to prioritize working on them, and many people find them hard to write. They go wrong because we tend to remember and overemphasize things that happened most recently, and forget about the things that happened six months or a year ago. They go wrong because we all suffer from various biases of which we may or may not be aware, and we tend to review people through the lens of those biases, criticizing some people for behaviors that we don’t even notice in others. All of these things are true, and you will probably see all of them play out. Despite all that, this process is incredibly valuable, and you as a manager have the opportunity to make it more or less valuable depending on how you approach

Writing and Delivering a Performance Review Here are a few guidelines for writing and delivering a successful performance review. Give yourself enough time, and start early This process isn’t something you can knock out in an hour and do well. You have a million things on your plate, but plan to spend solid, uninterrupted time working on reviews. Work from home if you need to. You owe your team enough time to read the collected feedback, digest it, and summarize it well.

Try to account for the whole year, not just the past couple of months This will be easier if you keep notes on what has happened with each person throughout the year. One tactic is to keep a running summary of your 1-1s, including any feedback that was delivered. If you haven’t done this, I encourage you to look through your email to remember which projects launched, review what activities were happening month by month, and put yourself back into the perspective of that time period. The goal for viewing the whole year is to recognize not just early accomplishments but also the growth and change you’ve seen since then. Use concrete examples, and excerpts from peer reviews Anonymize peer reviews, if needed. If you can’t use a concrete example to support a point, ask yourself if the point is something you should be communicating in the review.

usually give people a printed copy of the review as they’re leaving on the evening before the review is scheduled. This practice gives them a chance to read it at home, and then come to the meeting ready to talk about what it says. Even though they’ve had the review and gotten to read it, I still take the time to go over each section, starting with the strengths and accomplishments. Again, don’t let them skip over this and jump straight into the areas for improvement. Many people are uncomfortable being praised at length, but skipping that section undermines its value in reinforcing and encouraging their talents. Some reviews are summarized by a scaled ranking, such as a number from 1 to 5 or the equivalent in words (“fails to meet,” “meets,” “exceeds”). If you have to do this, expect it to be the hardest part of the review to discuss for anyone who got anything less than the top ratings. In my experience, people are uncomfortable being told they merely meet expectations, especially those who are early in their careers. Come prepared to dig into the reasons for this score, including examples of how the person could achieve a higher score.

Don’t confuse “potential” as it might be described by a grade-school teacher with the type of potential you care about. You are not molding young minds; you’re asking employees to do work and help you grow a company. Potential, therefore, must be tied to actions and value produced, even if it’s not directly the value you expected to see produced.

So you’ll not only need to have a good idea about who deserves to be promoted, but you’ll need to make a case for their promotion as well. What does this process typically look like? Generally, you’ll look at the people on your team a couple of times a year, consider their job level, and ask yourself, are any of these people close to the next level? In the case of the early-career staff, the answer is likely to be yes. These days, people fresh out of college tend to get promoted at least once in their first couple of years on the job, because they’re often hired in at an “up or out” level.

The evidence for promotion often takes the form of projects or features they’ve completed independently, participation in on-call rotations or other support, and engagement in team meetings and team planning. The important thing for you to start doing now that you’re in management is to learn how the game is played at your company. Every company has its own variation of the promotion process, and you’re probably in this role because you survived it. If you don’t know how it’s done, ask your manager for advice. How are these decisions made? How early do you need to start preparing packets? Are there limits on the number of promotions that can happen in any given year? As you learn how to play the game, I encourage you to be fairly transparent with your team. When members express the desire to be promoted and they don’t have a strong case for promotion, telling them what goes into the process will help them understand what they may need to change.

Challenging Situations: Firing Underperformers One of the hardest things that any manager must do is to fire someone for underperformance. This is difficult to write about because so much of the act of firing employees is dictated by HR departments these days, even at small companies. There are good and bad things that come out of this, but arguably the nicest thing is that you, as a manager, will have a process and procedure to follow. Upon hearing that someone is underperforming, many companies will have you write the person a document called a performance improvement plan. This is a set of clearly defined objectives that the person must achieve within a fixed period of time. If she manages to achieve them, then she is taken off the plan and all is well; otherwise, she’s fired. Depending on the company, such a plan might actually be an effort to turn an employee around, but often the plan is written in such a way that the person can’t possibly hope to achieve the goals in the allotted time, and it’s just a generous way of giving someone time to look for another job before being fired.

If you avoid tackling negative feedback until it builds to a boiling point, you’re going to be met by a pile of excuses, and then what do you do? Some managers will ignore the excuses at their peril, and lose employee after employee to an unwelcoming team that fails to onboard, coach, and give clear goals to employees. On the other hand, some managers will accept any excuse until problems can no longer be swept under the rug, and the team is furious at management’s inaction with regard to the lagging employee. You’ll always need to have a record of negative feedback to fire someone in any environment where HR is active and a standard performance improvement plan is required. If you have no HR, I suggest that you still give people clear improvement feedback in writing, with a timeline for improvement, and have them acknowledge it in writing as well (email is OK). Not only does this protect you legally, but it helps you treat your employees fairly. A final warning: don’t put anyone on a plan whom you wouldn’t be happy to lose. Most smart employees will take this formal warning as a sign that the organization is not a good fit for them, and leave as quickly as possible.

Ask the CTO: Coaching Someone Out of the Company I have an employee who seems stuck. He’s been with the company for a couple of years and done OK work, but I don’t think he has the potential to be promoted further on our team. Every time he asks what he needs to do to get to the next level, I tell him, but he then goes back to his comfort zone, and no amount of nudging seems to bring about any change. What should I do? This is a fairly common occurrence that managers have to handle. You have an employee who has topped out in the organization and seems to be losing energy. He has achieved expectations in his level, but can’t figure out how to grow enough to get to the next level, despite your efforts. It may be time to coach him out. Many organizations have a rule of “up or out” for early-career employees. The entry levels of most engineering career ladders expect that people at those levels will progress within a certain period of time, and if they don’t, they aren’t meeting expectations and will be fired. Generally, you want to make sure that long-term employees are capable of doing their day-to-day work independently, without a lot of oversight or help. However, once people have gotten past these up-or-out career points, what do you do when they get stuck? Some people will be happy cruising as senior engineers or managers at a certain level for their whole careers, and if you’re both satisfied with the work, there’s nothing wrong with that. Others, like your employee, wa...

Sadly, some companies don’t really have the role of “manager who has a little time to code” available. These companies split the management and technical tracks so cleanly that managers immediately start with large teams reporting directly to them. Thus the manager’s job becomes an administrative and people management position, and these managers end up grabbing technical time on nights and weekends, if ever. If your company is like this, my advice is to stay technical until you feel that you have truly mastered what you want to learn for writing code and designing systems, and then decide if you want to switch careers into management. It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.

As the manager of the team, you may worry about pushing them too hard, and so you let them miss deadlines without a fuss. The trick is to learn how to balance pushing your team and holding back. If you’re still writing code for the team, this may be a good time to roll up your sleeves and help the team meet its deliverables, or really dig in to the part of the project that’s slipping and partner with the engineers responsible to help understand the situation. Sometimes, teams aren’t shipping because the tools and processes they’ve been using make it hard to get work done quickly. A common example is that your team only tries to release changes to production once a week or less. Infrequent releases can hide pain points such as poor tooling around releases, heavily manual testing, features that are too big, or developers who don’t know how to break their work down. Now that you’re managing the team, start to push for the removal of these bottlenecks.

People Drama Sometimes we let ourselves hang onto that brilliant asshole for too long. You know, that person you think can’t be replaced because he’s just so productive and so smart, but who isn’t a team player and makes everyone around him unhappy. (For more on this kind of toxic employee, see “The Brilliant Jerk”.) A less critical version of this situation is the person who just stirs up drama, who dwells on negative experiences, or who spends a bit too much time on gossip and playing games of us-against-them. You have to be brave and nip people drama in the bud quickly. It’s OK to ask your manager for help with this, especially if it’s your first time doing it, but be aware that your manager may actually have an even harder time dealing with the brilliant jerk than you do. She isn’t seeing the immediate impact on team dynamics; she’s just seeing someone who gets things done. Be prepared to have a series of conversations with both the employee and your boss. It may be that a move to a different team will clear up the situation.

Be careful that vocally negative people don’t stay in that mindset on your team for long. The kind of toxic drama that is created by these energy vampires is hard for even the best manager to combat. The best defense is a good offense in this case, and quick action is essential.

Unhappiness Due to Overwork This problem is much easier to solve. Usually, unhappiness due to overwork has a root in problems that you can address. For example, if overwork is due to (in)stability of the production systems, it’s your job as the manager to slow down the product roadmap in order to focus on stability for a while. Make clear measures of alerts, downtime, and incidents, and strive to reduce them. My advice is to dedicate 20% of your time in every planning session to system sustainability work (“sustainability” instead of the more common “technical debt”). In a case where overwork is due to a pressing, time-critical release, remember two things. First, you should be playing cheerleader. Support the team however they need supporting, especially by helping out with the work yourself. Order dinner. Tell them you appreciate the hard work. Make it clear that they’ll have explicit break time after the push. Make it as fun as you can in the moment.

If your team isn’t working well together, look into creating some opportunities for them to hang out without it being all about work. Taking the whole team to lunch, leaving work early on a Friday afternoon to attend a fun event together, encouraging some PG-rated humor in chat rooms, and asking people how their lives are going are all ways to cultivate team unity. As a new manager I was pretty reluctant to get into this type of bonding, but even most introverts want to have a feeling of relatedness with their team. Assuming you don’t have any of the “people drama” problems listed earlier, small efforts in this area can warm the group up considerably.

Next, remember that your job has changed in some big ways. As his manager, you may now have the ability to override his decisions, but use this power very cautiously. Using your managerial power to override technical decisions is usually a bad idea. Resist the temptation to micromanage people — especially those who used to be your peers. They’re going to be sensitive to the feeling that you’ve been “rewarded,” even if they didn’t want to become managers themselves. If you question their every move and try to make every single decision yourself, you’ll make this sensitivity much worse.

So, yes, shielding your teams from distraction is important. Or, to put it another way, helping them understand the key important goals and focusing them on those goals is important. However, it’s unrealistic to expect that you can or should shield your team from everything. Sometimes it’s appropriate to let some of the stress through to the team. The goal is not to stress them out, but to help them get context into what they’re dealing with.

You may be a shield, but you are not a parent. Sometimes, in combining the roles of shield and mentor we end up in a parenting-style relationship with our team, and treat them like fragile children to be protected, nurtured, and chided as appropriate. You are not their parent. Your team is made up of adults who need to be treated with appropriate respect.

How to Drive Good Decisions What is your role in the decision-making process for your team? Do you know? You may have a product manager who works with your team and owns the product roadmap, or the set of business features that your team has committed to working on. You probably have a tech lead who, as we covered in Chapter 3, is still deep in the technology but is also thinking about project management and the work that needs to be done. So where does that leave you, the engineering manager? You have more responsibility than you may expect. While the product manager is responsible for the product roadmap, and the tech lead is responsible for the technical details, you are usually accountable for the team’s progress through each of these elements. The nature of leadership is that, while you may only have the authority to guide decisions rather than dictate them, you’ll still be judged by how well those decisions turn out.

Create a Data-Driven Team Culture When you have a product or business head, she should be accustomed to using data about the business, the customers, the current behavior, or the market potential to justify her decisions. Start adding other data to the mix. For example, give that person data about team productivity (such as the time it takes to complete features) or data about quality measures (like how much time is spent dealing with outages, or the number of bugs found in QA or after releases).

Flex Your Own Product Muscles Strong leadership cares about cultivating success and having a team that delivers successful projects, which means honing your understanding of what is important to your customer.

Look into the Future You need to think two steps ahead, from a product and technology perspective. Getting a sense of where the product roadmap is going helps you guide the technical roadmap. Many technical projects are supported on the strength of their ability to enable new features more easily — for example, rewriting the checkout system to plug in payment types like Apple Pay, or moving to a new JavaScript framework model that supports streaming data changes via WebSockets, in order to build a more interactive experience.

Review the Outcome of Your Decisions and Projects Talk about whether the hypotheses you used to motivate projects actually turned out to be true. Was it true that the team moved faster after you rewrote that system? Did customer behavior change in the way the product team predicted when you added the new feature? What have you learned from your A/B tests?

Run Retrospectives for the Processes and Day-to-Day Agile processes usually have a retrospective meeting at the end of each two-week development sprint, where you discuss what happened during the sprint and pick a few events — good, bad, or neutral — to discuss in detail.

The Dos and Don’ts of Managing Conflict Don’t rely exclusively on consensus or voting. Consensus can appear morally authoritative, but that assumes that everyone involved in the voting process is impartial, has an equal stake in the various outcomes, and has equal knowledge of the context.

Do set up clear processes to depersonalize decisions. When you want to allow for group decision making, the group needs to have a clear set of standards that they use to evaluate decisions. Start with a shared understanding of the goals, risks, and the questions to answer before making a decision. When you assign the ownership for making a decision to someone on the team, make it clear which members of the team should be consulted for feedback and who needs to be informed of the decision or plan.

Don’t turn a blind eye to simmering issues. Another way that conflict avoidance manifests is an inability to address problems until they’ve gone on for way too long.

Do address issues without courting drama. There’s a difference between addressing conflict and cultivating dysfunction. You want to allow space for people to express frustration, but mind the difference between letting off steam and a real interpersonal issue. Use your judgment as to what should be addressed and what should be dropped. The key questions to ask are: Is this an ongoing problem? Is it something you’ve personally noticed? Is this something many people on the team are struggling with? Is there a power dynamic or potential bias at play?

Don’t take it out on other teams. Ironically, conflict-avoidant managers often seek conflict when it comes to other teams. They identify strongly with their own team and will aggressively react to what they perceive as threats from outsiders. When something goes wrong, like an incident that spans across teams, the manager turns into a bully and demands justice for his team, or blames the problems on the other team.

Do remember to be kind. It’s natural and perfectly human to want to be liked by other people.