The #1 new engineering managers mistake
2 Simple tips on how to deal with underperformers
There is a single mistake every new manager makes - tolerating underperformers because they are improving.
If you listen to the most common advice in LinkedIn, it’ll seem as the manager and company are always to blame. That everyone can be amazing engineers, and just need the opportunity.
In my opinion, not everyone can be a great software engineer. When people hear it, they become defensive.
“With the right coaching, everyone can do it”
“It just takes motivation and grit”
“In a great company, X will thrive!”
Imagine any other profession - a doctor, a researcher, a kindergarten teacher.
Nobody thinks everyone can be an amazing doctor! I know I definitely can’t. Same with being a kindergarten teacher - I barely survive 2 days at home with my own child 😅
But try saying that someone is not a good fit for the software engineering career… People will throw stones at you.
So if a software engineer is improving with time, it’s very tempting to believe they have a bright future.
That’s why new managers struggle with underperformers. They confuse improvement with high potential:
Today I’m going to cover:
Why the mistake is so dangerous.
How to avoid that trap.
You will be wrong. Stay humble.
Why confusing improvement for potential is so dangerous
Ray Dalio wrote:
If someone who has been getting grades of 30s and 40s on their tests raised their scores to 50s for a few months it would be accurate to say that they are getting better, but they would still be woefully inadequate.
This improvement is what makes it so hard to deal with the situation. Most managers are nice people, and want their employees to succeed. Helping an engineer grow and thrive in their role is one of the most satisfying experiences for a manager!
Imagine you hire a nice and motivated engineer. You expected it’ll take them a month to get on board, but it takes two. A task that should have taken 2-3 days, takes 4-5.
But they improve! They appreciate your help, and you have a great relationship.
They become your go-to person for simple tasks. You tried to give them a project to lead, but it didn’t go very well, so you decided to wait a few months for the next one.
I know very few managers who will be able to let that person go. Most of us fire people too late:
There are 2 reasons for that:
The emotional connection we discussed above. You don’t want to hurt people.
The sunk cost fallacy. We spent so much time training that engineer, and we don’t want to go through that again.
So we lie to ourselves and become satisfied with mediocrity. And who suffers? Your team. Most talented engineers want to be surrounded by other talented engineers.
How to avoid that trap
1. Set very concrete goals
Most onboardings I encountered don’t have very concrete goals. You give the new employees time to adjust and want to see them slowly improve.
This makes it very hard to evaluate a new hire. You’ll tend to be forgiving, and even a small improvement will make you feel good with the decision.
The simple solution is to decide in advance, what success will look like:
How long before they should be able to complete a task in repo X without any help?
What type of tasks do you expect them to accomplish in the first 30/60/90 days?
If it’s a more senior hire - what inputs do you expect them to provide?
How long before they should be part of the on-call rotation?
The questions will help you be objective.
Let’s say you expect the new hire to be part of the on-call duties after 2 months. The time arrives, but you don’t feel confident about it. Unless you set that concrete goal in advance, you’ll probably think:
“Oh, they are almost ready. Let’s give it a couple more months”.
2. Set checkpoints to evaluate yourself
I really like the 30-day method from ‘Fall In Love with the Problem, Not the Solution’, by Uri Levin:
if you’re managing people, read the next paragraph, close the book, close your eyes, and think about it.
Every time you hire someone, allow yourself 30 days, and then ask the following question: “Knowing what I know today, would I hire this person?” If the answer is no, fire them the next day. Every day this person is still on board you’re creating more damage to your team.
If the answer is yes, on the other hand, then give that someone a little raise (in salary or options or anything). You will then establish unbelievable commitment. Now, if you would say, “I don’t know yet,” then you’re lying. But if you really need another thirty days, take that time and think hard on it.
People hate making hard decisions - so most will just stick with the default. The default is to work with what you’ve got.
That’s why I love internships - there is a point in time where you are forced to make a decision. There is no default, you have to choose whether you want the intern full-time or not.
It doesn’t have to be 30 days, but I suggest to not dwell on it too long.
told me in Germany they have a 6-months probation, but in my opinion, 3 months is always enough to know.3. Don’t focus on what you’ll lose
The worst question you can ask yourself is:
“Am I better with or without this person?”
The answer will almost always be ‘with’. And then you start to measure all the time you put into training, the improvement made by the employee, the hassle of hiring again, and so on… You’ll never be able to make the right choice this way.
Levine’s “Knowing what I know today, would I hire this person?” is a much better question.
You should think in the longer term, 2-3 years ahead.
Accept that you will be wrong
8 years ago, I was working as a programming bootcamp instructor. It was a 6-months long bootcamp, intended for people without prior knowledge.
Near the end of the course, we had 2 struggling students. We assumed both of them would be mediocre developers in the best-case scenario.
This is what happened in reality:
One of them was indeed a mediocre developer, and he gave up the profession after a few years. The other one was very passionate, he worked like crazy, and became a senior developer very quickly.
During a survey we did, I talked with his manager in the first role outside the bootcamp. He mentioned how he was one of the best developers in the department, and it was a pleasure to work with him.
So you can never know in 100%. Nice graphs are just… nice graphs. It’s impossible to summarize a human being as a line on any graph.
As with everything I write, this is just a framework to consider. A hugely motivated engineer can break any ceiling, no matter what your intuition tells you.
Final Words
Even though I admit that I was wrong a couple of times, I’ve never (yet) met someone who regretted laying off an employee (no talking about Twitter-style mass layoffs).
If you have a doubt - there is usually no doubt.
What I enjoyed reading this week
Turning a yellow spot into the sun by
. How to recognize true high performers. A truly amazing framework by Wes.Lone hacker takes down North Korea’s internet by
. A couple of months ago I became a paid subscriber of , and I really enjoy it!How we got our first 1,000 users by
. If you think about starting a startup, this one is a must-read.
> But try saying that someone is not a good fit for the software engineering career… People will throw stones at you.
Same if you say programming is not for everyone – speaking from experience. 😃
Great piece Anton!
You've perfectly captured this topic, Anton. I was a few times a member of a team that suffered because a manager was afraid to make the decision to let an under-performer go. We had to pick up their work, fix their bugs, were woken at night during on-call because of their mistakes.
Even though managers might delay letting go of under-performers because of emotional connection and sunk cost, they undermine their position in front of top-performers through such behavior, which has far worse consequences.