New engineering managers think of the job as a promotion, giving them seniority on engineering tasks and questions. This is a great approach for ensuring they remain junior managers, and unsuccessful leaders at that. It’s hard to accept that “new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading.
Congratulations! You’ve progressed to the level where people trust you to manage other humans. Maybe you’ve had some training from your HR department about some basics of management. Maybe you’ve had some great managers in the past you want to emulate. But now the rubber hits the road, and it’s time to put all those thoughts and ideas into action.
First, let’s focus on managing individuals. There are a bunch of books out there that will give you more thoughts and ideas about this topic; my goal here is to give you the basic elements of management as I see them. Once you’re in the management hot seat, how should you think about performing the basic tasks of managing people?
Part of your focus throughout this period of adjustment to management is to figure out your own management style. Many of you will be learning how to manage individuals while simultaneously being responsible for running a team. In the next chapter, we’ll talk more about the challenges of dealing with the team as a whole, as well as how the technical side of your role might be changing, but it’s important to start by considering the individuals. After all, your team is only as healthy as its individuals, and as the individual manager, you’ll have a huge impact on each person.
Taking on a new report
Holding regular 1-1s
Giving feedback on career growth, progression toward goals, areas for improvement, and praise as warranted
The first thing that happens when you start managing is that you take on people as direct reports. These may be people you’ve been working with for a while, or they may be completely unknown to you. As you go through your management career, you’ll repeatedly experience having someone new start to report to you. How do you get to know this person quickly so you can manage him best?
How do you like to be praised, in public or in private?
Some people really hate to be praised in public. You want to know this.
What is your preferred method of communication for serious feedback? Do you prefer to get such feedback in writing so you have time to digest it, or are you comfortable with less formal verbal feedback?
Why did you decide to work here? What are you excited about?
How do I know when you’re in a bad mood or annoyed? Are there things that always put you in a bad mood that I should be aware of?
Maybe a direct report fasts for religious reasons, which sometimes makes him cranky. Maybe he always gets stressed out while on-call. Maybe he hates reviews season.
Are there any manager behaviors that you know you hate?
If you asked me this question, my answer would be: skipping or rescheduling 1-1s, neglecting to give me feedback, and avoiding difficult conversations.
Do you have any clear career goals that I should know about so I can help you achieve them?
Any surprises since you’ve joined, good or bad, that I should know about?
Things like: Where are my stock options? You promised me a relocation bonus and I haven’t gotten it yet. Why are we using SVN and not Git? I didn’t expect to be so productive already!
For more ideas, see Lara Hogan’s excellent blog post on the topic.
Another approach that many experienced managers use is to help their new reports create a 30/60/90-day plan. This can include basic goals, like getting up to speed on the code, committing a bug fix, or performing a release, and is especially valuable for new hires and people transferring from other areas of the company. The more senior the hire, the more he should participate in creating this plan. You want him to have some clear goals that will show whether he’s learning the right things as he gets up to speed. These goals will also require some work from you and from the team, because it’s very rare that everything is self-evident, well documented, and totally obvious to a newcomer.
Unfortunately, sometimes you will mis-hire a person. Having a clear set of expected goals for your new hires that you believe is achievable in the first 90 days will help you catch mis-hires quickly, and make it clear to you and to them that you need to correct the situation. Create a set of realistic milestones based on your prior hires, the current state of your technology and project, and the level of the person coming in.
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. This expectation setting on your part should include specifics like how often you want to meet with him, how the two of you will share information, and when and how often you’ll want to review his work. If you expect him to send you a weekly summary of his progress via email, tell him. Help him understand how long he should work alone trying to solve a problem, and at what point he should ask for help. For some teams this might be an hour, and for others it might be a week.
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.
Regular 1-1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time.
I had an interesting conversation once with a friend, another CTO who has a lot of management experience. He sheepishly admitted to me that he didn’t like doing regular 1-1s because he himself had always resented being forced to do 1-1s with managers that he felt he didn’t need. “Regular 1-1s are like going to a psychiatrist when you’re fine and discovering you have depression.” I bow to his experience. It is absolutely true that every person and team is different: they need different things, have different communication styles, and focus on different things. That being said, if you’re not a CTO with years and years of management experience, you should probably start by assuming that you need to do regularly scheduled 1-1s.
The default scheduling for 1-1s is weekly. I encourage you to start with weekly 1-1s and adjust the frequency only if both of you agree that this is more than you need. Weekly means that you talk frequently enough to keep the meetings short and focused, and it gives you room for the occasional missed week. When you meet less frequently, any missed 1-1s must be rescheduled, which is usually a drag on both of you.
Try to schedule your 1-1s for times when you and your report are both likely to be in the office. Mondays and Fridays are bad days for 1-1s because people tend to sometimes take long weekends and miss these days. I prefer to do 1-1s in the morning before things get busy, in order to avoid having the schedule slip or being forced to reschedule due to other things coming up. However, morning 1-1s only work with people who also get in early and 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.
If you interact with her frequently, you may not need a weekly set-aside time to chat.
A very junior person who’s just joined the team might appreciate more time than a senior person who’s in a groove. On the other hand, a senior person who is pushing through a difficult new project may appreciate more dedicated time for you to help her with some of the details of that work.
A person who’s not good at pushing information up may need more face time to do so.
Be careful here. Some people assume that good relationships require very little attention, and spend all of their time on their bad relationships. But there are plenty of people, myself included, who feel a strong need for regular 1-1 time even in good relationships. Just because you think things are going smoothly with this person doesn’t mean that she agrees. Don’t make the fatal error of spending all your time with your problem employees and ignoring your stars.
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.
Now that you have these 1-1 meetings scheduled, what should you actually use them for? I’ve seen several distinct styles of 1-1 meetings, and the type of 1-1 that’s most effective depends as much on the manager as it does on the managed.
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. This style follows the “don’t waste time with pointless meetings” mandate and ensures that things will happen. The downside, of course, is that sometimes you wonder why you needed to do this in a synchronous manner. Often the list is somewhat artificial and made up of things that could have been handled via chat or email. If you decide to adopt this style, make sure that the list you bring and the lists you encourage your reports to bring are meaningful for 1-1 discussions. Make sure there are nuances that deserve verbal communication in the 1-1 setting.
In general this style is very professional and efficient, if sometimes a bit cold. It forces your reports to think beforehand about the meeting and what they might want to discuss. One manager I knew used a shared Google spreadsheet to keep a running list of topics for discussion that both he and his reports had access to, so each could add to the list whenever a thought came up, and they would review it during the 1-1. It also gave both parties a chance to see what was on the other’s mind before the 1-1 happened, so that they could prepare.
I am not a very organized person, and 1-1s with strict requirements for to-do lists don’t resonate with me. I’m happy to adopt these requirements if my reports want them, but I prefer a more fluid style. My goal in a 1-1 is first to listen to anything my direct reports want to discuss. I want the meeting to be driven by them, and I want to give them space to bring up whatever they feel is important. I view a 1-1 session as much as a creative discussion as a planning meeting. The downfall of the rambling 1-1 is that, if it’s left unchecked, it can turn into a complaining session or therapy. Empathetic leaders can sometimes allow themselves to get sucked into an unhealthy closeness with their direct reports. If you start focusing a lot of energy on hearing reports’ complaints and commiserating, you’re quite possibly making the problem worse. You don’t have to have a to-do list, but problems in the workplace need to be either dealt with or put aside by mutual agreement. There is very little value to repeatedly focusing on drama.
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. The same goes for praise! When something goes well, don’t save up your praise—give it freely in the moment.
When you get to the stage where you’re managing managers, a lot of your 1-1 meetings will be diving into details of projects they’re overseeing that you don’t have time to dig into on your own. When you are managing only a handful of individuals, the only time you should be using a 1-1 to do progress reporting is when you have someone who’s off on a side project that you’re not personally overseeing. Getting progress reports from people you’re already working closely with is a waste of time because all you’re hearing about is the delta of work between now and the last standup or project review. If your 1-1s are frequently status updates, try breaking out of the habit by asking your reports to prepare answers to questions that are unrelated to the current project status, or ask them to come prepared with questions for you to answer about the team, the company, or anything else. And for those rare people who just really don’t have much to talk about except for progress, you may want to take that as a sign to meet less frequently.
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. Let them talk about their family, friends, hobbies, pets. Get to know their career so far, and ask them about their long-term career goals. It doesn’t have to just be a focus on the next skill or promotion. Show that you are invested in helping them now and in the future.
For variety, you can do your 1-1s as walking meetings, or over coffee or lunch to get out of the office. Just remember that when you’re not taking notes you’ll probably forget some important things, so try not to rely on these for critical conversations. Many of us have overstuffed office spaces with very few private conference rooms, but as much as possible, do your 1-1 meetings in private so that you can feel free to discuss sensitive topics without worrying about being overheard.
One final piece of advice: try to keep notes in a shared document, with you the manager playing note taker. For each person you manage, maintain a running shared document of notes, takeaways, and to-dos from your 1-1s. This is helpful for you to keep context about what has happened, and is useful for remembering when and what feedback was given. It will also be an essential historical record to refer to when you’re writing reviews or delivering feedback. If you’re distracted by having a computer open in front of you during the meetings, just leave time at the end to add notes.
Jane has given her tech lead Sanjay a big project to manage. It needs to be done by the end of the month, which should be fine, but Jane is worried that the deadline will slip. So she starts attending all of the standups that she normally doesn’t go to, and asks questions directly of the team about their blockers. She looks through the project tickets and makes a bunch of comments, and even reassigns some of them to other team members. When she discovers that Sanjay and the product manager decided to deprioritize a feature, Jane decides that it’s time for her to take over the project, and she tells Sanjay that from now on she will be managing the day-to-day.
It’s no surprise when, despite the fact that the project shipped successfully, Sanjay tells Jane that he feels like he doesn’t want to be a tech lead anymore. In fact, he seems pretty low-energy, and his normal engagement and hard work are replaced by him leaving early and saying nothing in meetings. Her best team member has become a low performer seemingly overnight. What happened?
Micromanagement creeps up on you. A high-stress project that can’t be allowed to slip seems at risk, and so you step in to correct it. You delegate something, but then discover that you don’t like the technical choices the team has made to implement it, so you tell them to rewrite it. You force everyone to come to you before making decisions because they just can’t be trusted to do the right thing, or there have been too many mistakes and you always end up paying the price.
Now, let’s take a look at Jane’s colleague, Sharell. Sharell has given Beth her first big project to run. Sharell knows that this project needs to ship on time, but instead of sitting in on every meeting and tracking every detail, Sharell works with Beth to determine which meetings she should attend, and helps Beth understand which details to escalate to Sharell. With this support, Beth feels confident running the project, but also knows that Sharell has her back, and when things get stressful toward the end of it, Beth enlists Sharell’s help to cut scope and get the project out on time. Beth leaves the experience feeling more confident, and ready to take on bigger projects and work harder for Sharell.
Jane’s and Sharell’s decisions highlight the subtle differences between the micromanager and the effective delegator. Both Jane and Sharell are attempting to delegate the management of a high-priority project in order to train a new leader on their team. However, Jane ultimately never gives up control and undermines Sanjay, while Sharell makes it clear to Beth what the goals are and what her responsibilities are, and provides support and guidance to help Beth succeed.
The hardest thing about micromanagement is that there are times when you need to do it. Junior engineers often thrive under detailed oversight because they want that specific direction. Some projects go off the rails, and you occasionally need to override decisions made by your reports that could have big negative repercussions. However, if micromanagement is your habit, if it’s your default approach toward leading your team, you’ll end up like poor Jane, accidentally undermining the very people you need to be growing and rewarding.
Trust and control are the main issues around micromanagement. If you’re micromanaging someone, chances are you’re doing it because you don’t trust that a task will be done right, or you want to very tightly control the outcome so that it meets your exact standards. 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. When a deadline slips, as it inevitably will, you view it as a failure to control the situation precisely enough, and so ratchet up the attention. You catch something not going the way you expected, and it seems to reinforce your belief that micromanaging the team is an appropriate use of your time.
Autonomy, the ability to have control over some part of your work, is an important element of motivation. This is why micromanagers find it so difficult to retain great teams. When you strip creative and talented people of their autonomy, they lose motivation very quickly. There’s nothing worse than feeling like you can’t make a single decision on your own, or feeling like every single piece of work you do has to be double- and triple-checked by your manager.
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.
It’s important to remember that being a good leader means being good at delegating.
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.
How do you decide when to ask for this information to begin with? My philosophy is simple: if the team is making progress on its goals, the systems are stable, and the product manager is happy, I rarely dig into the details beyond a cursory overview. However, that requires goals with a plan for people to be making progress against, and a product manager who can give you another perspective. When you are managing a team that doesn’t have a clear plan, use the details you’d want to monitor to help them create one. What are you holding them accountable against this month, this quarter, or this year? If you can’t answer that question, the first step is to help the team create those goals.
As engineers, we have an advantage because systems can push valuable information up without the team needing to do much of anything. If you want to know the status of work, look at the version control system and the ticketing system. 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.
If you’re managing a single team or two directly, you should know all of the details of the project status as part of your regular team processes (like morning standup meetings). Different details are important at different project stages. In the beginning and design stages of a project, you may want to be more involved in order to facilitate a good set of project goals or a good system design. When you’re close to a delivery date, progress details become more important, because there are more decisions to be made and those specifics convey much more actionable information. During the normal workflow, though, it’s usually enough to know what’s moving forward and what is taking longer than expected, especially if you can use that information to reshuffle work or help a struggling team member.
I’m one of those deeply technical managers, and I have opinions about the way systems should be built and operated. Letting go has been hard for me, so I developed some guidelines to help me feel better about the structure around these issues. Developing basic standards as a team helps everyone communicate with one another in code and design reviews, and it depersonalizes the process of providing technical feedback. For me, basic standards meant things like how much unit testing we expected to happen with each change (generally speaking, as some tests were always required), and at what point technical decisions should be reviewed by a larger group (like when someone wants to add a new language or framework to the stack). As with goal setting, putting standards in place here helps people know which details are important to think about when they’re creating the technology.
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. Hiding important information intentionally is a failure, and getting stuck on a problem or making a mistake is often just an opportunity for learning.
In the long run, if you don’t figure out how to let go of details, delegate, and trust your team, you’re likely to suffer personally. Even if your team doesn’t quit, you’ll end up working longer and longer hours as your responsibilities increase. If you’re already in this situation, try limiting the hours you’ll let yourself work in a week. If you were only allowed to work 45 hours this week, what would you do with those 45 hours? Would you really spend five of them nitpicking a junior developer’s code? Would you pore over the details of some project that is going smoothly, searching for any minor error? Or would you direct your attention to bigger problems? Would you take some of those hours to focus on the future instead of the details of the current moment? Your time is too valuable to waste, and your team deserves a manager who is willing to trust them to do things on their own.
When I say performance review, what goes through your head? Do you cringe? Do you roll your eyes about the wasted time, or groan at the thought of doing all the work? Do you get a rush of fear over what surprising new flaws you will hear about? Or do you get a little bit of nervous excitement to hear what people think about you?
If performance reviews make you shudder, you’re not alone. Unfortunately, the review process is not something that every manager takes seriously or handles in a mature way. Now that you’re managing people, you have a lot of power to shape the experience your direct reports have with reviews. That experience starts long before the reviews are written. It starts with continuous feedback.
Continuous feedback is, more than anything, a commitment to regularly sharing both positive and corrective feedback. Instead of saving these kinds of comments for the review cycle, managers and peers are encouraged to note when things are going well and raise issues as they happen. Some companies have started to adopt software that makes it easy for teams to provide continuous feedback and track that feedback over time, but the most important thing is that the team has adopted a culture of providing feedback frequently. 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.
There are some steps you can take to be great at giving continuous feedback:
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. This understanding gives you a baseline you can use to frame your feedback, and helps you find some things that you might want to focus on.
Observe your people. You can’t give feedback if you aren’t paying attention. If anything, I think the best outcome of attempting a continuous feedback cycle is not necessarily the actual feedback generated, but rather that the effort forces you to start paying attention to the individuals on your team. Starting this habit early in your management career, while you still may have only a few people to manage, helps you build up those observational muscles. Practice looking for talents and achievements on your team, first and foremost. Good managers have a knack for identifying talents and helping people draw more out of their strengths. Yes, you’ll also want to look for weaknesses and areas for improvement, but if you spend most of your time trying to get people to correct weaknesses, you’ll end up with a style that feels more like continuous criticism.
Sometimes it helps to have a goal, so task yourself with regularly identifying people who deserve praise. Adopting a habit of positive recognition forces you to be on the lookout for things to praise, which in turn causes you to pay attention to what individuals are bringing to various projects. You don’t have to do this in public, but every week there should be at least one thing you can recognize about someone on your team. Even better, look for something to recognize weekly for everyone who reports to you.
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. Many people respond better to praise than they do to corrective feedback, and you can use kudos to guide them to better behavior by emphasizing the things they’ve done well.
Positive feedback also makes your reports more likely to listen to you when you need to give them critical feedback. When they believe that their manager sees the good things they do, they’ll be more open to hearing about the areas where they might improve. It’s best to give critical feedback quickly in the case of an obvious misstep, but continuous feedback is more than in-the-moment corrections. Use a habit of continuous feedback to talk about things that don’t seem to be going well as you start to notice them, rather than waiting until the review cycle to have uncomfortable conversations.
Bonus: Provide coaching. Ultimately, continuous feedback works best when you, as a manager, pair that feedback with coaching. As situations arise, use coaching to ask people what they might have done differently. When things are going well, praise them, but also make suggestions as to what could be even better in the future. Coaching-based continuous feedback means going beyond a simple “good job” to really engage with the details and form a partnership with your direct report where the two of you are working together to help her grow.
Why do I list coaching as a bonus? It’s not always a core need for doing the job well, and there will be many times when you don’t have either the qualifications or the capability to provide the coaching that everyone on your team needs. Coaching is most important for your early-career team members, or those who have the potential or desire for advancement. Many people will be content with doing the job they know how to do well, and as long as they are doing it well enough, it’s not a good use of your time to try to coach them. Save your valuable coaching time for those who are receptive to it.
Continuous feedback, even if it’s just regular recognition for good work, is an important tool in the hands-on manager’s toolkit. However, it’s not a replacement for a more formal, 360-based performance review process.
The 360 model is a performance review that includes feedback from, in addition to a person’s manager, his teammates, anyone who reports to him, and coworkers he regularly interacts with, as well as a self-review. For example, an engineer with no direct reports might solicit reviews from two other engineers on her team, the new hire she was mentoring, and the product manager she works with. Performance reviews take a long time because you need to give and receive feedback from many different people. As a manager, you then have to gather all that feedback together and summarize it for the person being reviewed.
Performance reviews reward the time spent by providing a valuable chance to synthesize a bunch of information about a person. Beyond that, 360 reviews give you at least a high-level view into what other people are thinking about your direct reports. The self-reviews give you a sense of what your people believe about themselves, their strengths and weaknesses and accomplishments over the year. Writing the summary review gives you the chance to focus for longer than a few minutes on the individuals and look at the big picture over a longer period of time. All of this should help you see some patterns and trends that you might overlook in the process of day-to-day continuous feedback.
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 it.
Here are a few guidelines for writing and delivering a successful performance review.
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. My advice is to start by reading the collected reviews and taking a few notes, processing the information for a little bit before trying to write a full summary. Give yourself enough time to write and come back to what you’ve written at least once before you have to submit the review.
Most companies expect that managers will read feedback and anonymize it as part of writing up their summary, but some companies have open processes where the original peer feedback is visible and identifiable to the person being reviewed. Even in an open process, as the manager you should still read that feedback and use it as part of your review writing, since the manager review is still often considered the most important summary of all review feedback.
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.
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. Forcing yourself to be specific will steer you away from writing reviews based on underlying bias.
You want to celebrate achievements, talk about what’s going well, and give plenty of praise for good work. This goes not only for the writing process but also—and especially—for the delivery. Don’t let people skip over the good stuff in order to obsess over the areas for improvement, as many will want to do. Those strengths are what you’ll use to determine when people should be promoted, and it is important to write them down and reflect on them.
Writing about areas for improvement is often a tricky part of the feedback. In the best case, there are a couple of clear themes that run through peer feedback, and that you have observed, to comment on. Here are some examples of themes that I have seen. There are people who:
Struggle with saying no to distractions and end up helping with other projects instead of finishing their own
Do good work but are hard for others to work with, tending to be overly critical or rude in meetings, code reviews, or other collaborative activities
Struggle to break their work up into intermediate deliverables, and don’t balance planning and design with getting things done
Work well with other engineers but do not work well with other departments or teams
Struggle to follow the accepted best practices of the team, cut corners, or otherwise do sloppy work
More often, you’ll get a lot of scattershot feedback that’s moderately helpful at best. Some people will seem to be reaching for something to say, and others will have a particularly harsh impression that no one else seems to share. Especially in the case of scattershot feedback, make sure that the feedback you’re seeing makes sense before you deliver it. For example, if only one reviewer mentions sloppy work, is the problem that the work is sloppy, or that the reviewer has higher standards than the rest of the team? Use your judgment in this case. If the feedback seems valuable for the person to hear, share it, but don’t just blindly report all grudges.
What about the case where you have very little meaningful feedback for improvement? This indicates that the person is ready to be promoted or given more challenging work. If the person is doing a solid job at her level but isn’t ready for promotion, the feedback should indicate one or two skills she needs to expand to become qualified for promotion. Some people may never need to be promoted out of their current level, but the nature of the tech industry is such that skills need to be refreshed to stay current, so you can also focus on new technical learning opportunities.
Set expectations appropriately before reviews are delivered. If someone is underperforming across the board, the review should not be his first time getting that feedback. Similarly, if someone has recently been promoted, you may want to prepare her for the fact that she will be reviewed based on higher standards.
I 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.
One of my most critical promotions happened during my time in finance. The finance world has a strange way of giving out titles. Drawing from the days when firms were built on a partnership model, there tend to be only a few “public” titles: Associate, Vice President, Managing Director, and Partner. The Vice President title is a critical leap. Achieving it is (or was) a sign that a person has proven herself worthy of building a long-term career at the firm. Therefore, the time it takes you to get a VP title is a strong signal for your future success, and getting the promotion is a complex process that’s done only once a year and run by the senior managers.
My manager explained this to me twice. First, when I got my own VP promotion, he walked me through all of the materials we’d be gathering to support my case. Projects shipped, yes, but also signs of leadership, and work that pushed me beyond my immediate team. The second time I went through this was when I prepared the packet for someone who worked for me. We gathered all sorts of evidence, including the letter the candidate got commending him for being the floor fire warden. Both of these promotions were successful, but I have no doubt that we succeeded at least partially because my boss/mentor knew exactly how to play the game.
If you’re a manager, you are going to play a key role in getting people on your team promoted. Sometimes it will simply be up to you to determine who gets promoted, but more commonly promotions will be reviewed by your management, or a committee. 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.
To clarify, take the example of Famous BigCo. Famous BigCo hires engineers out of college at level E2 (level E1 is reserved for interns). Famous BigCo has a policy that an engineer who shows no sign of advancing past level E2 after two years at that level doesn’t have a future at the company. It has this policy for levels E2–E4, but at E5, you can stay forever.
So, if you have a team of E2s and E3s, you need to be preparing them to be promotable every couple of years. Fortunately, this is usually straightforward. As long as you don’t stop them from getting promoted, they’ll be moved forward by the process. Your job with this group is to make sure that they’re learning how to estimate their own work, getting it done roughly within the estimates, and learning from their mistakes. 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.
You should also prepare yourself to start identifying promotion-worthy projects and trying to give those projects to people who are close to promotion. You, as the manager, are in a good position to identify what’s coming up for the team. Depending on how work gets assigned, you may either directly assign these projects to people, or encourage people to volunteer for projects that are a stretch goal for them. Keep an eye out for opportunities for your team members to stretch themselves and grow.
This work does start to change the more senior your team becomes. Many people will not continue to advance past a certain level, at least not within the same company or team. There are fewer opportunities for people to show the kind of leadership or breadth of impact needed to get promoted as they become more senior. Sometimes there is nothing you can do about this, except perhaps to refer them to other leaders in different parts of the company for mentoring or guidance. As much as it might hurt you to lose them, they may be better off in another team or even another company with new challenges.
Many companies expect you to be acting at the next level before you get promoted to it. This practice exists to prevent the “Peter Principle,” in which people are promoted to their level of incompetence. It also signals that there’s room for another person acting at that level on the team. Keep this in mind as you think about your team’s careers. If there is no growth potential on your team because there’s no room for people to work at a more senior level, it may be a sign that you need to rethink the way work is done in order to let individuals take on bigger responsibilities.
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.
Whatever the procedure is at your company, the process of coaching someone out should begin long before any performance improvement document is filed with HR, and long before the actual act of firing. One of the basic rules of management is the rule of no surprises, particularly negative ones. You need to understand what a person is supposed to be giving you, and if that isn’t happening, make it clear to her early and often that she is not meeting expectations.
The ideal is that you know exactly what job she is supposed to be doing, and if she isn’t doing it, you can say, “You aren’t doing X, Y, and Z. Do more of those things.” Of course, like all perfect circumstances, reality is rarely so simple.
A common, straightforward scenario is closer to the following. Your employee, Jane, has been with you for a few months. She seemed a little bit slow in the onboarding process, but you gave her the benefit of the doubt; the code base isn’t in perfect shape, and there’s a lot of business jargon to learn in a new hire’s first few months. However, it’s been six months, and when you look back over that time, you see very little in the way of achievement on Jane’s part. In fact, the few things she has done have not gone well—they have been very late, very buggy, or both.
This situation sounds straightforward on paper. Tell Jane that she is not meeting expectations, that her work is too slow or not well done, and give her a strict deliverable. But Jane has excuses, of course, and some of them are believable. The onboarding wasn’t good. Her first month was interrupted by the company party, and then you were out for a week on vacation, and she has not had anyone to ask questions of. In fact, it sounds a little bit like the issue is you and the team, not her at all.
This situation is why you start giving feedback early and often, and keep records of the feedback you’ve been delivering. Feedback, positive or negative, should be a conversation. 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. I once heard a story about a great engineer who was put on a surprise performance improvement plan by his manager after someone in the organization complained that he had bowed out of a project. This manager, who had not been paying any attention to the situation and had approved the engineer focusing elsewhere, gave in to pressure to set up a plan that served to do nothing but poison any goodwill the engineer might have had for his manager and the company. It’s no surprised that the engineer resigned soon thereafter, despite having easily achieved the goals of the improvement plan.
When was the last time you talked to your reports about their career development? If it was more than three months ago, can you make sure to put this in your next 1-1s?
Have you given feedback to your reports in the last week? When was the last time you handed out kudos in front of the team?
When was the last time someone behaved in a way that needed correction? How long did it take you to give corrective feedback? Did you give the feedback in private, or did you do it in public?
Have you ever been given a performance review that felt like a waste of time? What was it missing that could have made it more valuable?
What was the most useful piece of performance feedback you ever got? How was it delivered to you?
Do you know how the process of promoting people works in your company? If not, can you ask someone to walk you through it?