6 ms·
This hits it right home. The other piece of advice I've learned about breaking bad news, especially in the light of the excellent management tips here I always
by endymi0n 8y ago
This hits it right home. The other piece of advice I've learned about breaking bad news, especially in the light of the excellent management tips here I always refer junior leaders to:
http://www.defmacro.org/2014/10/03/engman.html http://www.defmacro.org/2014/10/03/engman.html
> 32. Have difficult conversations as soon as possible. Waiting will only make a bad situation worse.
> 42. Unless you’re a sociopath, firing people is so hard you’ll invent excuses not to do it. If you’re consistently wondering if someone’s a good fit for too long, have the courage to do what you know is right.
And specifically about this: It's really best to deliver bad news like this not just as clearly as possible, but also as early.
If I'm in the dire situation of having to fire someone, I'm starting with that news right away in the clearest words possible that are not hurtful. The most important thing about it is to leave zero ambiguity.
It will hurt anyway, but it leaves the rest of the conversation to recovery and solution-focus. Maybe it's possible to do a referral or an intro or just giving some space and time to listen.
But if you have bad news, take the OPs advice to heart — and do it as fast as possible.
- ghaff 8y agoAnd be prepared for complete surprise. I've been involved in situations where one would have thought it was incredibly and abundantly clear to everyone involved that things were absolutely not working out. (Without going into a lot of details, heavy and extensive rework in multiple passes of projects they were working on over months.) Yet, getting fired was apparently a complete bolt out of the blue.
- maxerickson 8y agoThis is what the Dunning-Kruger paper is about, that the mental tools of work and self evaluation are interconnected.
- ghaff 8y agoI don't think it's so much Dunning-Kruger as just being being almost willfully oblivious to signals that are trying to tell you things that you really don't want to realize. (As opposed to simply choosing to ignore what you know in your heart is really going on.)
- endymi0n 8y agoThat's really self-serving bias at work. It's also why the part about leaving zero ambiguity is so important. It's exactly the kind of people who didn't see it coming (while you thought you transparently had them on their very last shot) who try to bargain or give you that very, very, very last chance. Surprises like this are rather rare, but emotionally straining for both sides: The surprised ones also are the ones with zero contingency planning or backup plan, but at some point it's really not your fault anymore if you communicated openly all along. It's a life changing experience having someone break down in front of you, but in the end, it's a neccessary experience for both sides and a learning chance too. Your job as a leader is continuously balancing the needs of the individual with the needs of the team. And at the point you finally decided, your team already knew it wouldn't work out for a much longer time than you (if you hired right). It's your job to pull it through and not let the team get dragged down any longer.
- dorfsmay 8y agoNo surprise. If somebody is surprised when you fire them, you failed. You should have brought the issues up and explain what the paths to fix the are, the timeline, and consequences.
- sonnyblarney 8y agoIf it's in any way a surprise than it's 100% your fault as a manager. Having to 're work code' is so common in software it's basically normative. I've never written code that was not re-worked. So that, in and of itself might not be enough information. I understand it can be very difficult with someone who just isn't up to snuff, because it's like telling a mediocre athlete to 'be spectacular' - often it just can't work out. But it still shouldn't be a surprise. Moreover, if they're otherwise decent you could try to find something else for them to do. Some people write terrible code but they are wicked problems solvers, I've seen them work out on integration teams that need people 'on the ball' hunting down problems.
- ghaff 8y agoIn one case in particular, I wasn't the manager and it wasn't software but it was something similar (research/writing) where iteration is to be expected. However, this was a case where the person had to be held by the hand through rewrite after rewrite with others ultimately doing most of the work. Should the employee have been given a clear "improve or you're gone" early on? In retrospect, yes. On the other hand, workplaces that have a low patience for people who don't quickly get to full running speed aren't necessarily the best places to work. And, to use your analogy, if you're dropping a lot of balls as a receiver, the coach shouldn't need to tell you that your job is at risk. This was also a very small company so there really weren't other types of positions. It also meant there weren't a lot of formal processes. On the other hand, the connection between work and results was pretty clear. I agree with your points as a general principle. On the other hand, it's reasonable to expect some degree of self-awareness which can be lacking to a surprising degree.
- sonnyblarney 8y agoYes, someone who literally cannot do their job, I've been there as well. This should happen in the first couple of months however.
- ftio 8y agoAs a corollary to #32, not only should you have difficult conversations early (i.e., even when a problem feels 'small') so that you give people time and space and feedback to improve, you should document those conversations via email. It is difficult and can be awkward to do this, but it's unfair to your employee and makes it harder to let them go later if you don't have documentation of their sub-par performance. I've learned this the hard way. As a manager, it's easy to fool yourself into thinking you're being clear about someone's performance with them, but often we use weak language to soften blow and employees underestimate their weaknesses. Sending a short email immediately after the conversation can clarify your meaning and memorialize the feedback for later in the unfortunate case that you actually need to let the person go.
- pc86 8y ago> It is difficult and can be awkward to do this, but it's unfair to your employee and makes it harder to let them go later if you don't have documentation of their sub-par performance. This is part of why at will employment is so prevalent. Unless the company has additional restrictions on termination, it's much easier to be in a position where you can termination an employee without cause on paper. The majority of the time it will be performance related but being able to termination quickly without official cause eliminates the need to redundant email "documentation."
- scarface74 8y agoI’ve never been at a company that fires people at the spur of the moment unless it’s something egregious without going through a process and having a performance improvement plan.
- jcadam 8y agoI've never seen a performance improvement plan (PIP) that was anything more than a paperwork drill to comply with HR requirements before firing someone.
- 8y ago
- dorfsmay 8y ago32 works both ways. You're a developer/sysadmin/SRE/other, you're stuck, going to miss a deadline, made a mistake, tell your lead and PM as soon as possible. Things do not get better when you wait. Every hour you delay telling them, they lose a bunch of options to fix the issue. This is not as obvious as it sounds, I find myself repeating these to junior people and interns.
- grigjd3 8y agoIf there is a slack channel that I use to coordinate with my PM and other stakeholders, if I am nearing an important deadline, I just leave regular updates there. Make sure everyone who cares has all relevant information.
- basseq 8y agoI tell my team the same thing. There's nothing unforgivable about missing a deadline: what's unforgivable is not telling people it's going to happen.
- scott_s 8y agoAgreed. I want everyone else just as nervous about it as I am.
- balls187 8y ago#32. Feedback. Early and often. I've had to deliver bad news. Sometimes major, sometimes minor, but I always made it a priority to let my teams know asap, to show empathy and to let them ask as many questions as needed. When I was let go, the leaders who took over my teams showed zero empathy which lead to me recruiting away one of the companies top engineers pretty much immediately after leaving. #42 makes a lot of sense. But it's poorly worded. You're not making excuses. Instead as a leader, you are looking to put that employee in a better situation. Letting an employee go is the last step, in what should be a process of trying to make things work for both the employee, and the company.
- dennisgorelik 8y agoThis is great article. I submitted it here: https://news.ycombinator.com/item?id=17938479 https://news.ycombinator.com/item?id=17938479