How to handle complaints about a direct report?
Hey Taro,
I have a question around how to manage a direct report who I’m receiving performance complaints about.
For context, I’m the team lead for a team that works distributed across vertical teams. We have a new hire who’s been working with us for around 3 months now. He’s working with Team A and has recently been helping them to write App X, a brand new application.
Recently the PM for Team A has reached out to me with some general complaints/concerns about his output. The work this new hire is doing blocks most work for Team A, and the PM feels like they should have finished their work by now, and apparently other members of Team A have raised similar complaints.
Additionally, this new hire has a reputation for working very long hours/late into the night after work. On several occasions he’s posted slack messages at 1am, and the PM is concerned that he’s trying to spend long hours after work to try and make up for his lack of progress.
Myself and my manager have both already had casual conversations with him about his late night work to try and put a stop to this, and myself and other team members have tried to help him with his tasks where we can. We’re in a very small company so while I can try shuffling him around to a different vertical, it’s not like there’s limitless possibilities there.
I’ll be bringing this up with my manager today during our 1:1, but I was also very interested in hearing what the Taro community thinks here.
This is my first time as a manager so I’m very much out of my depth here.
Discussion
(4 comments)- 67 months agoMid-Level Software Engineer [SDE 2] at Amazon
I'm surprised that Team A delegated critical work to a new hire before they reached the 90-day mark. I'm also surprised that Team A's response to blockers is to complain, rather than get to the root cause of those blockers. Why is the new hire struggling to complete their task, and why is the PM time-boxing it?
These are questions and observations I'd raise in the context of a team retro or blameless post mortem. In a vacuum, I see the new hire trying to compensate for Team A's lack of planning, guardrails, and failure to set expectations around communication and team availability.
- 4
7 months agoTech Leadership Coach • Former Head of EngineeringI'm pretty sure this is a case where something went wrong with expectation setting and skill calibration out of the gate.
I would approach this issue head on rather than getting them to work 'regular' hours.
If someone's skills are subpar, but have good intention to deliver, you'll typically see working long hours as a coping mechanism. Taking that away will only lead to more stress and slow down delivery.
Here's how I would approach this:
- Review the interview notes to see if there's any issues with the initial assessment / calibration. No interview process is perfect. Use this as a way to not only see where the candidate skill gaps are, but also what can be improved in the interview process.
- Examine the work they've delivered so far. The scenarios drastically differ if it's only a output velocity issues vs. if there are quality issues as well. If it's pure velocity, it would suggest that given enough time the velocity will go up. If there are quality issues, they may not know what something that's acceptable quality looks like, so they would need more reference points.
- After performing the due diligence from the prior 2 points, I would have a formal, structured meeting to go through what you've been observing and where you think the gaps are in a 1-1 with your direct report. Have a candid conversation and don't sugarcoat. It's better for both sides to get everything on the table since aligning skills vs. expectations is most likely the core issue here.
DM me if you need you'd like to go over the situation and game plan in more detail.
- 27 months agoTech Lead @ Robinhood, Meta, Course Hero
Your #1 priority should be to talk to and observe this new hire as much as possible. Figure out the root cause of the issue - Right now, it only seems like you're treating symptoms (e.g. getting them to work less and doing some hand-holding).
It seems like this new hire is working very hard and wants to do right by the team, so there's a good chance they're not simply a low performer and their talent isn't being nurtured properly. This could be for a variety of reasons:
- They have too much scope (especially as a new hire)
- Their onboarding wasn't sufficient
- They have a lot of anxiety and are afraid to ask questions
- The code review process for them is inefficient
- The product planning wasn't thorough enough, and the initial requirements for this new app are wildly out of proportion
I hope these resources help as well:
- 47 months agoTech Lead @ Robinhood, Meta, Course Hero
As Daniel mentioned, the situation with Team A is also weird. What stands out to me is that the new hire was given mission-critical, blocking work. This is another way you can attack the problem to make things better on top of remedying the new hire's performance. In general, you should strive to find multiple angles to solve a problem, especially as a manager.
What you should do here is see if you can make the new hire's work non-blocking - You always want to decouple as much as possible. Is there a way you can mock up the functionality of whatever components they're assigned so other engineers can start execution ASAP?
At Instagram, we did this for back-end <-> front-end all the time. Big Tech back-ends are extremely complex, and it could easily take weeks, if not months, to add fairly basic features like a new field on a JSON response. However, as long as the front-end and back-end engineers could agree on what the protocol looks like (i.e. what will the shape of the JSON be), the front-end engineers can just mock the data model on their end and do the client work.
