Do people really leave managers, rather than companies? And if so, how do you fix the problem?
The data suggests bad management is a real and significant issue. According to a study by Gallup, one in two people admitted to having left a job to get away from a bad manager. In fact, 70% of the factors that contribute to your happiness at work are directly related to your manager.
Yet few managers ask themselves the hard questions: Am I the reason people are leaving? Was it because of something I did, or something I didn’t do? In my experience, managers suffer something akin to the Dunning-Kruger effect. They assume they’re not the problem, but that their employees are.
Just look at the data to see where managers are laying blame. A survey of 5,247 hiring managers who’d hired 20,000 employees said that after 18 months “46% of newly-hired employees” failed and only 20% achieved success.
The biggest causes for failure were:
And what was the biggest takeaway for managers interviewed? They needed better interview processes to weed out the failures before they got into their teams.
To any rational person, this makes no sense. The common denominator isn’t the 46% of employees. It’s the managers. Is the problem really that half of the people couldn’t learn or care about their new job? Or was it that a smaller number of managers overestimated their own abilities to teach, connect and inspire their new hires?
I’ve led teams of engineers for almost a decade but when I look back at my own management career I regularly thought I was a “good manager”, at times even a great one. I attributed any problems I encountered to the people I managed rather than myself. Looking back now it’s clear I was actually a blindingly naive, over-confident, under-skilled, inexperienced manager who made lots of mistakes.
This management overconfidence is a trap I see many other falling into, but thankfully it can be avoided by following a few of the steps below.
1. Always ask for advice
As a software engineer, no matter how senior you are, you always seek code reviews before deploying new code to production. YOLO code changes are only for emergencies 😀
The same is true for managing people. You should always be asking for peer review on a people management problem before you take action, whether that’s from your own manager, your HR team, etc. The bigger the potential consequence of your action, the more thorough you should be about getting help and peer review before making it.
When I have a performance review to write I talk it through with my peers or my boss before delivering it. If I have someone on my team who’s not performing as well as I’d like I ask for help on how to coach them differently. You can do this for pretty much everything, people related or not, and have a better outcome as a result.
Once you think you’ve really nailed your management skills is when you’re at your most vulnerable to failure.
2. Don’t blame, own
Ownership is one of our engineering team’s values and it applies equally to managing people as it does to engineering. It’s not in our culture to say “that’s not my problem” or “that’s not my fault”.
Yet as a manager it’s all too easy to abdicate responsibility and blame the person on the other side of the table when they are not doing as well as you’d like. The fact is every person you manage is different. Just because one management style worked with the previous three team members and it’s not “working” with the person in front of me doesn’t necessarily mean it’s their fault. Like a good sports coach, managers aren’t judged on the performance of individual players, but the team’s effort. So the onus is on you to make sure the right management style is being used for all of your team.
I have to constantly check myself to make sure I’m taking ownership for the relationships in my team and help do everything I can to make things better. Instead of assigning blame to others when things go wrong, I try and figure out out my own role in the situation. What are the things that I have done, or not done, that have contributed to the problems at hand?
If I have any trouble identifying these, I go back back to step 1 above, and ask for advice from my peers. Often after doing this exercise I discover the right next step is not to give “constructive feedback” to someone on my team about their mistakes; it’s to get feedback on how I can better support them in future.
3. Give feedback with empathy
Giving feedback is your most powerful tool for growing your people and your team. It’s also one of the hardest to get right. Do it wrong, and you’ll turn your most proactive tool into something that causes unwanted collateral damage.
Before I deliver any feedback I set aside some time to understand how the other person might receive the feedback. Is it likely to be high-fives all round? Or might they feel hurt or upset? Try to pay particular attention to the wider implications of the feedback you’re giving. Candid feedback could be motivating for a seasoned engineer looking to step up to the next level, but crippling for a recent hire who’s finding it hard to settle in. Don’t give feedback in the moment if the tone or timing isn’t right. Use your emotional intelligence and empathy. You can always save your feedback for another time, and a more private or less stressful setting.
4. Savor your success
One of the best things about being an engineer at a startup are the feedback loops. You can prioritize, design, build, and ship into the hands of users, all within a week, often even a day or two. These feedback loops are fuel for your team’s morale; they have a positive influence on your team’s productivity and power each team member’s happiness and job satisfaction.
Unfortunately it’s easy for managers to get caught up with looking forward all the time. Or to focus exclusively on problem areas. When you do this it’s easy for your team’s shields to drop. They feel unvalued, like just another cog in the machine.
So make sure you celebrate your team’s success and make sure team members know they’re having impact. You don’t have to hang bunting from the ceiling. It could be as simple as giving someone detailed, timely feedback on something they just did really well, passing along some positive feedback you received from your boss about your team’s recent work or calling someone’s work out positively in a Slack channel.
Great managers build great companies
When you stay humble, ask for advice, own rather than blame and give feedback with empathy, you’re on the path to being a good manager. But as we’ve seen, success as a manager breeds complacency, and it’s all too easy to fall into bad habits of overconfidence. Once you think you’ve really nailed your management skills is when you’re at your most vulnerable to failure. You need to constantly revisit what it takes to be a good manager, or risk losing your best people for good.
If this sounds like a management philosophy that you’d like to live and work by, we’re hiring a Software Engineering Manager in Dublin 😀