Identifying and letting underperforming engineers go

Problem

A few years ago as a new engineering manager, I inherited a team that was growing really fast. To keep up with the growth, the company had gotten into a staff augmentation model and hired contractors. The model was contractual but the engineers would be hired as full-time employees for a locked in period unless performance concerns arose. This story is about one engineer in particular that had been hired a week before I inherited the team. After spending a month, I realized what bar the team was at and what bar the engineers we were aiming to hire for. So in my first 1-1 conversations with this new engineer, I started to get a spidey sense of incompatibility from a skills perspective.

Actions taken

I started to pair the tech lead on my team to work with the new engineer so I could get some feedback to back my spidey sense, since I wasn't involved closely enough to the code. I also started to look into some PR's, some tech designs when I could. I booked in two 1-1's every week and in them, I started to give this feedback. The engineer would be very responsive, he would say yes to everything and go back to work. Unfortunately, it wouldn't change his behavior outside the 1-1. I recommended an Android development course and a book on design to help with the skills issue. Three pieces of feedback from the team that I really had to pay attention to were: 1.) This engineer lacked skills which became a point of frustration with the other engineers on my team since he would go around asking really basic questions that he could Google for/should already know about
2 .) We were starting to really fall behind on some of the work he was doing, which although wasn't super critical, was super easy to do. 3.) This engineer was spending a lot of time at the foosball and ping pong table after falling behind a lot. I had more 1-1 conversations where I tried to pry open any reasons (personal or otherwise) that could be a blocker for him but I couldn't hear anything substantial.
Eventually, 1 month in the job as an EM, I had to let this person go in his probation period. It was a fairly difficult conversation, but I had all the information and data to back it up. I gave him a reference to a professional services company where I thought he'd be a better fit and he now works there :), so we got lucky in the end. I also helped changed the interview process to be able to apply the same rigor in interviewing contractors.

Lessons learned

Never lower the bar on your hiring. The cost of incompetence is too high. Even with contractors. Treat everyone as you would treat your own engineers. First three months of any new engineering hire are key. Put in a strong probation process in place. There should be one even for contractors. Pair new developers with strong leads/engineers on your team in the first three months and constantly collect feedback for points to discuss in 1-1's/potential failure modes Provide all the support you can as a manager for a new engineer to succeed. Recommend courses/give and get feedback/review PR's if you have the time/monitor fits. Learn to trust your manager spidey sense. It's a really important trait for being a good leader. Also teach, empower and trust your team to give you candid 360 feedback. Your team is your biggest asset as a manager. It's ok to do what seems like a little micromanagement sometimes, especially with new hires, if you deem that's the best thing to do for the benefit of your team. Make sure that's backed up with solid data.