Best People Management Skills (2019)
In this blog, we’ve focused on ways to introduce 50+ best people management skills to manage a small, growing team with minimal disruption. People management is a very different role requiring different talents to be successful.
Not all great engineers will be great managers (and vice versa), and you want to avoid the situation where senior engineers end up feeling forced to do something they aren’t motivated or suited to do.
Find internal candidates who might make effective managers. You may have engineers who have been successful managers in the past who might be willing to return to the role. Otherwise, look for engineers who demonstrate the qualities you want to see in your management team (e.g., 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, the co-founder of LoudCloud, said: “Watch out for the temptation to take your top coders and make them managers... People Management is about people, it’s not about code.”
Tell your team that you’re thinking about making some changes to your people 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 people 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 people management structure can be a stressful moment, and a moral risk if handled poorly. Here are some ideas on 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 them and understand how they will benefit.
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.
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 people 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 people 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 blog.
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.
Do they happily help coworkers improve their skills and knowledge, even when it means slowing down their own work?
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?
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?
Does the team look to this person for guidance and direction, even without a formal leadership role? When she talks, do others listen and act?
Can they gracefully share credit with others when appropriate, as well as blame? Or conversely, do they seek the limelight, even when it’s not in the best interest of the team?
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 people management role. You should also look for negative indicators that should make you wary of granting people a management role:
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
Can they stand up for their ideas and hash out a compromise?
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?
As has been written about in many places, 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 slice.
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 is no longer “one of the gang”
The manager gig 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 get rewired 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 her 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 her 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.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide.]
Spread your workload
During my many years of experience as a team lead (albeit only very recently in software development), I have seen other team leads “flog their workhorses”.
In many team environments, there will be members who are less likely to willingly accept tasks that they don’t enjoy - the “complainers” (i.e. they kick up a stink) and those who just get their heads down and complete any task that you give them - the “reliables”.
I have seen many team leaders, including myself in my early years, naturally, give the fewer fun jobs to the “reliables” as there is less chance of resistance and less chance of conflict with the person they’re assigning the task to.
In the very short term, this strategy may work in your favor, however, there are some repercussions:
The team as a whole may begin to pass work off to the “reliables”.
The “reliables” will eventually burn out.
The “reliables” will become frustrated and you will more than likely lose their respect.
Internal conflict will arise as the “reliables” will separate themselves from the “complainers”.
The solution involves sharing the load equally. If you have a “boring” task to Member A today, give the “boring” task to Member B tomorrow - regardless of whether they complain. This will build up a culture of every team member being equal.
It is better to avoid the problem, to begin with, and the best way to do that is to let the team decide on its own who does what. If you want to become a great team leader you need to stop being the team “task dispatcher”.
Normally a group of people will do a better job at this than a single person. Your job (as the team leader) is to allow this to happen. i.e. make your team self-manage.
If your team is not yet there, here is a good goal for you to strive for and invest effort in. The first step is to stop deciding for them. As long as you decide who does what, the team will not take charge of its own work.
After all, why should they worry when you do this for them? Now, I know this is not that simple to accomplish. but here’s what works for me when I approach this problem.
Making your team manage their own work
Explain the new “rules” to the team – when expecting someone to start doing something new, I found it usually helps to state my expectation. so the first thing is simply to tell them that from now Making your team manage their own work on I expect them to divide the work between them.
Teach them how to do it – When I ask for someone to do something new I like to make sure they know how to do it. In this case, I would explain how I think tasks should be divided. I give my tips and advises on how to balance the work, how to make sure everything is done as fast as possible and what I would expect to see.
I found that visualizing a problem goes a long way in solving it. and in this case, I devise a way to put all the work “tasks” into a single visible place. I found that a physical task board does a very good job at this. so that’s my preferred technique, but an excel list can do just as well.
As a lead, I do make sure to track how the team is doing (at least when at the start). So a mechanism for tracking this should also be decided on. Again a Task Board does a great job at this, but a shared excel task list with the people names also works just as well.
And last, like any new skill, mistakes will be made along the way. That’s ok. Mistakes are what people learn from, so don’t try to prevent them, make sure the damage isn’t too big, and that people learn from them.
Help your Team
The best way to help your team to serve their clients even better, to achieve and sustain a culture of continuous improvement, is to start by showing them deep respect.
You do so by challenging their thinking about the current work process, asking lots of open, probing questions to uncover the root causes of the current impediments. No process is ever perfect, so you can focus on helping the team to discover what its key constraint is at any particular time and then devise countermeasures to remedy it.
The key constraint is the area in which improvement will show the biggest bang for the buck when measured across the entire system, improving the overall flow of the work process, likely reducing cycle time and waste, with less overburden or absurdity involved.
By engaging your team in problem-solving, you’re showing them that you choose not to attempt to solve the problem alone. You trust them to be best placed to come up with the most promising improvement ideas, as they are closest to the work being done and have all the facts in hand. As a team leader, you truly respect your team’s knowledge and their dedication to finding the best answer.
Even so, team members can’t quite do it all alone because they are often too close to the issue to fully appreciate its full context. They may also avoid tough questions about the nature of the work and the reasoning behind certain inefficient practices.
By showing mutual respect, better countermeasures can be devised, the team can derive more pride in the quality of their work, and everyone can enjoy a more satisfying journey of professional accomplishment.
To better serve your team, work to understand yourself better, assessing your own strengths and weaknesses. Strive to become aware of your team’s characteristics as well, sensing their professional and emotional development needs. Be ready to adapt your leadership, coaching, and mentoring style to suit the team’s current spot on its journey to professional mastery.
Energize the Team
Try This Menu of Potential Agenda Topics to Spice up Your Team Meeting
By far, the most common request I receive for help with sales meetings is with agenda topics. Sales managers are craving ideas to make their team meetings more meaningful. Here are some of my favorite agenda items:
Personal Updates. Go around the horn asking each person to share for a minute or two what’s going on in his or her personal life. It’s a great opportunity to enhance relationships on the team and to build empathy.
When people are transparent, we may discover important news in a team member’s life that helps us better understand why the person is moody, grumpy, elated, distracted, etc.
If someone’s kid is really struggling or he’s dealing with a terminally ill parent, wouldn’t that be valuable to know?
On the flip side, if the top producer announces that she’s buying a summer home on the lake, wouldn’t that serve as good motivation for the rookies on the team?
Review the Sales Results and Highlight Outstanding Performance. While I’ve made the case that we should scold individuals in private, we should definitely celebrate success in public!
The sales meeting is a great place to distribute and review sales reports. Give the top producers their due. Highlight outstanding individual achievements or marked improvement. Be generous with praise.
Success Stories. Ask a handful of salespeople to share the specifics about a recent sales victory. You can either ask the individuals to come to the meeting prepared, providing guidelines about what and how long you’d like them to present to the team, or you can spring the request right at the meeting.
Just pick out a few salespeople and ask them to tell the story of how they won a certain piece of business. Tell them it’s permissible to brag about their sales heroics, and that the more specifics they can give, the more everyone else will benefit.
Challenge your team into ravines
Homework is actually something you do at work, or sometimes at home if you’d like. I call it homework because it doesn’t relate to the day-to-day actual task, and it’s not something that’s officially designated as part of your job.
It’s usually a task that you incorporate into your actual work, such as “try to say ‘yes’ at least three times a day” or “be the last one to speak in every conversation.”
Giving people on your team homework is a great way to teach new skills. It’s important that this homework be a ravine-like task. If it’s not scary or annoying to your team members, they might not be learning anything new.
You can only ask someone to jump into a ravine with open eyes after you’ve done this yourself at least once. You need to be able to feel what it’s like to be aware of this learning opportunity and to get over your personal fears and feel great afterward. Only then can you talk from your own point of view about the learning process.
You can inspire others to do jump into ravines only when you have your own story to share about some deep learning you’ve done and how it scared you. Don’t make one up.
If you want to learn something real as a team leader, learn to practice what you preach. Don’t fake it—others will know, just like you’ve always been able to tell when someone was deceiving you. If you don’t have a story, do something real, and only then share it.
You should, of course, explain this homework concept to your team. Usually, it’s better if you do it in a one-on-one meeting because some people might feel more comfortable openly talking about their reservations from doing it without anyone else listening.
Sometimes, if real learning is going to be a team effort, you should discuss the reasoning with the whole team as a group. And yes, it will be scary. Teaching a team how to jump and plan ravines is a ravine in its own right. It will feel awkward and unnatural, but it’s part of your own learning.
Is it under your control?
By now, you may have strongly disagreed with one of the commitments I wrote in the previous section. If you haven’t, take another look at the commitment sentences above. Is any one of them specifically bothering you? One of them should stand out like a sore thumb. Or at least it does to me.
If someone ever asked me to commit to something like this, “I will fix these five bugs by the end of the week,” I would say, “I can’t commit to that.” Why? Because I can’t really promise to fix a specific set of bugs by a specific date. Bugs, many times, are not as innocent and easy to fix as they may seem, so my commitment can easily be broken.
I call this kind of commitment, “committing to something that’s not fully under your control” and it’s the subject of the next section.
Turn an impossible commitment into a possible one
If a team member commits to fixing bugs in a specific amount of time, as a team leader I’ll ask them to change their commitment to something they can actually personally live up to something under their control.
What’s under their control? Usually, their time and what they choose to work on are the only things under their administrative control. The trick is to notice someones committing to something outside their control and then ask them to commit to one or more steps that can lead to this desired goal.
“I will fix these bugs over the next week.” turns into:
“I will work at least 5 hours each day for the next week to solve these bugs.”
Here’s another commitment that requires another person to accomplish. That person is not under their control, so it’s impossible to commit to:
“I will meet with David today, and together we’ll decide how to solve this.” This turns into:
“I will send out a meeting request to David today about solving this.”
When people commit to things under their full control, they’ll feel comfortable about committing to such a thing.
But what about the third behavior I mentioned (saying you can’t commit to something)? When people have practiced the idea of integrity, they will feel comfortable saying that they cannot commit, and then you’ll have discovered possible roadblocks that have never been mentioned before.
“I can’t commit to that because the CEO asked me to do another project, and I won’t have time.”
“I can’t commit to that because my machine isn’t strong enough to crunch those numbers.”
Now that you’ve discovered these hidden problems, you (or, better yet, your team members) can do something about them. For example, you can teach your team members how to solve that specific problem so that the next time it happens they won’t need you to steer them in the right direction.
So how do you get them on board?
It’s important to realize that it’s not a “me” and “them” thing. It’s a team issue, and you need to be part of the team. You need to learn and use commitment language as well.
Here are the steps I’d take to accomplish the language of commitment:
Assemble the team, teach them the language, and explain the whys.
Begin using this language in your meetings.
Fix just-in-time language errors.
Launch a commitment language initiative at a team meeting
Assemble the team in a single room, where possible.
Explain that now that everyone has the time to start learning new things, you’d like everyone to start using a different mindset about promises and commitments.
Explain that from that moment on, you’ll be asking people to use concrete commitment language when promising to do something.
Explain that you will be a bit of a pain in the neck over the next few weeks as you all adjust to this new way of speaking, and ask that people help each other out using the new language.
Teach the basics of the language (what words are non-commitments, what a commitment sounds and feels like) and see if you have several promises people have made in the past day or so that you can practice this on.
If a pair promised the previous day to sit on something together, ask them to use commitment language to say the same promises in the form of commitments.
IGNORE HUMAN ISSUES
As we’ve said before, a team leader has two major areas of focus for his team: the social and the technical. It’s rather common for leaders to be stronger in the technical side, and since most leaders are promoted from a technical job (where the primary goal of their job was to solve technical problems), they tend to ignore human issues.
It’s tempting to focus all your energy on the technical side of your team because, as an individual contributor, you spend the vast majority of your time solving technical problems.
When you were a student, your classes were all about learning the technical ins and outs of your work. Now that you’re a leader, however, you ignore the human element of your team at your own peril.
Let’s start with an example of a leader ignoring the human element in his team. Years ago, a close friend of Steve’s—we’ll call him Jake—had his first child. Jake and Steve had worked together for years, both remotely and in the same office, so in the weeks following the arrival of the new baby, Jake worked from home.
This worked out great for Jake and his wife, and Steve was totally fine with it as he was already used to working remotely with Jake.
They were their usual productive selves until their manager, Pablo (who worked in a different office), found out that Jake was working from home for most of the week. Pablo was upset that Jake wasn’t going into the office to work with Steve, despite the fact that
Jake was just as productive as always and that Steve was fine with the situation. Jake attempted to explain to Pablo that he was just as productive as he would be if he came into the office and that it was much easier on both him and his wife for him to mostly work from home for a few weeks.
Pablo’s response: “Dude, people have kids all the time. You need to go into the office.” Needless to say, Jake (normally a mild-mannered engineer) was enraged and lost a lot of respect for Pablo.
There are numerous ways that Pablo could have handled this differently: he could have shown some understanding that Jake wanted to be home more for his wife and, if his productivity and team weren’t being affected, just let him continue to do so for a while.
He could have negotiated that Jake goes into the office for one or two days a week until things settled down. Regardless of the end result, a little bit of empathy would have gone a long way toward keeping Jake happy in this situation.
BE EVERYONE’S FRIEND
The first foray that most people have into leadership is when they become the leader of a team of which they were formerly members. Many leads don’t want to lose the friendships they’ve cultivated with their teams, so they will sometimes work extra hard to maintain friendships with their team members after becoming a team leader.
This can be a recipe for disaster and for a lot of broken friendships. Don’t confuse friendship with leading with a soft touch: when you hold power over someone’s career, he may feel pressure to artificially reciprocate gestures of friendship.
Remember that you can lead a team and build consensus without being a peer of your team (or a monumental hard-ass). Likewise, you can be a tough leader without tossing your existing friendships with the wind.
We’ve found that having lunch with your team can be an effective way to stay socially connected to them without making them uncomfortable—this gives you a chance to have informal conversations outside the normal work environment.
Sometimes it can be tricky to move into a management role over someone who has been a good friend and a peer. If the friend who is being managed is not self-managing and is not a hard worker, it can be stressful for everyone. We recommend that you avoid getting into this situation whenever possible.
COMPROMISE THE HIRING BAR
Steve Jobs once said: “A people hire other A people; B people hire C people.” It’s incredibly easy to fall victim to this adage, and even more so when you’re trying to hire quickly.
A common approach we’ve seen is that a team needs to hire five engineers, so they sift through their pile of applications, interview 40 or 50 people, and pick the best 5 regardless of whether they meet the hiring bar. This is one of the fastest ways to build a mediocre team.
The cost of finding the right person—whether by paying recruiters, paying to advertise, or pounding the pavement for references—pales in comparison to the cost of dealing with an employee you never should have hired in the first place.
This “cost” manifests itself in lost team productivity, team stress, time spent managing the employee up or out, and the paperwork and stress involved in firing the employee. That’s assuming, of course, that you try to avoid the monumental cost of just leaving him on the team.
If you’re managing a team where you don’t have a say over hiring and you’re unhappy with the hires being made for your team, you need to fight tooth and nail for higher-quality engineers.
If you still keep getting handed substandard engineers, maybe it’s time to look for another job. Without the raw materials for a great team, you’re doomed.
TREAT YOUR TEAM LIKE CHILDREN
The best way to show your team you don’t trust them is to treat them like kids— people tend to act the way you treat them, so if you treat them like children or prisoners, don’t be surprised when that’s how they behave.
You can manifest this behavior by micromanaging them or simply by being disrespectful of their abilities and giving them no opportunity to be responsible for their work.
If it’s permanently necessary to micromanage people because you don’t trust them, you’ve got a hiring failure on your hands. Well, it’s a failure unless your goal was to build a team that you can spend the rest of your life babysitting.
If you hire people worthy of trust and show these people you trust them, they’ll usually rise to the occasion (sticking with the basic premise, as we mentioned earlier, that you’ve hired good people).
The results of this level of trust go all the way from keys to a building to office and computer supplies. As another example, Google provides employees with cabinets stocked with various and sundry office supplies that are free to take as employees need them.
The IT department runs numerous “Tech Stops” that provide self-service areas that are like a mini electronics store. These contain lots of computer accessories and doodads (e.g., power supplies, cables, mice, USB drives, etc.) that would be easy to just grab and walk off with, but since Google employees are being entrusted to check these items out, they feel a responsibility to Do The Right Thing.
Many people from typical corporations react in horror to hearing this, exclaiming that surely Google is hemorrhaging money due to people “stealing” these items. That’s certainly possible, but what about the costs of having a workforce that behaves like children? Surely that’s more expensive than the price of a few pens and USB cables.
LOSE THE EGO
It’s especially important when you’re playing the role of a servant leader. This pattern is frequently misunderstood as encouraging leaders to be a doormat and let their team walk all over them, but that’s not the case at all.
We admit that there’s a fine line between being humble and letting others take advantage of you, but humility is not the same as lacking confidence.
You can still have self-confidence and opinions without being an egomaniac. Big personal egos are hard to handle on any team, especially in the team’s leader. Instead, you should work to cultivate a strong collective team ego and identity.
Part of “losing the ego” is something we’ve covered already: you need to trust your team. That means respecting the abilities and prior accomplishments of the team members, even if they’re new to your team.
If you’re not micromanaging your team, you can be pretty certain the folks working in the trenches know the details of their work better than you do.
This means that while you may be the one driving the team to consensus and helping to set the direction, the nuts, and bolts of how to accomplish your goals are best decided by the people who are putting the product together.
This gives them not only a greater sense of ownership but also a greater sense of accountability and responsibility for the success (or failure!) of their product.
If you’ve got a good team and you let them set the bar for the quality and rate of their work, they’ll accomplish more than they would by you standing over them with a carrot and a stick.
Most people new to a leadership role feel an enormous responsibility to get everything right, to know everything, and to have all the answers. We can assure you that you will not get everything right, nor will you have all the answers, and if you act as you do, you’ll quickly lose the respect of your team.
A lot of this comes down to having a basic sense of security in your role. Think back to when you were an individual contributor; you could smell insecurity a mile away.
Try to appreciate inquiry: when someone questions a decision or statement you made, remember that this person is usually just trying to better understand you. If you encourage inquiry, you’re much more likely to get the kind of constructive criticism that will make you a better leader of a better team.
Finding people who will give you good constructive criticism is incredibly difficult, and it’s even harder to get this kind of criticism from people who “work for you.” Think about the big picture of what you’re trying to accomplish as a team, and accept feedback and criticism openly; avoid the urge to be territorial.
The last part of losing the ego is a simple one, but many engineers would rather be boiled in oil than do it: apologize when you make a mistake.
And we don’t mean you should just sprinkle “I’m sorry” throughout your conversation like salt on popcorn—you have to sincerely mean it. You are absolutely going to make mistakes, and whether you admit it or not your team is going to know you’ve made a mistake.
They’ll know regardless of whether they talk to you or not (and one thing is guaranteed: they will talk about it with one another). Apologizing doesn’t cost money. People have enormous respect for leaders who apologize when they screw up, and contrary to popular belief it doesn’t make you vulnerable.
In fact, you’ll usually gain respect from people when you apologize, because apologizing tells people you are level-headed, good at assessing situations, and— coming back to HRT—humble.
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 the expertise they can offer here.
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 thought 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.
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.
A poor-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 recruitment from the outside in general.
Because some externally hired managers have not been actively coding for some time, we strongly recommend that managers go through the standard engineering on-boarding process, if at all possible.
Even for managers that haven’t coded in years, participating in some way should give them context on what their engineers are expected to know, what tools they have at their disposal, and what the day-to-day workflow looks like.
Some managers and/or their teams may prefer to do a coding project as a way of getting their feet wet or even join a team as an IC for several months before taking on day-to-day management.
In these cases, set expectations appropriately with the team based on the manager’s familiarity with the technology stack and how far removed they are from hands-on coding. You don’t want the team assuming the manager will necessarily perform as a senior-level engineer, only to have them reject them as a teammate for this reason.