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.
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.
I'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:
DM me if you need you'd like to go over the situation and game plan in more detail.
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:
I hope these resources help as well:
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.