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
> 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.
32 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.
If 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.
As 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.
If the aim is to gather evidence of bad performance then the data gathered might not capture items that are evidence of good performance. Basically, you run the risk of applying a filter to the available data such that you're not accurately documenting performance.
The data will be tainted by selection bias and would not characterize what it claims to represent. Another more colorful term for such tainted data is a "shit list".
Sometimes the aim is not to document performance but to create a paper trail to justify future action. This kind of organizational behavior--bad faith bureaucratic procedure, biased scrutiny of performance, opacity of managerial intent, etc.--results in administrative overhead that can be expensive in both financial and human terms.
EDIT: remove "accurately". Combine 2rd and 3rd paragraphs. Remove "So" from start of last paragraph.
The aim is not to document performance generally. The aim is to counteract the natural tendencies of managers to soften their critiques in conversation and of employees to underestimate their poor performance by memorializing feedback in writing.
It's better for employees because it makes it easier for their managers to paint a clear picture of how they need to/can improve, and it's better for managers because in the case they eventually do need to let the employee go, they've already set the expectation clearly, so there are no surprises. As a bonus, there's a paper trail for HR.
> 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."
I’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.
I've never seen a performance improvement plan (PIP) that was anything more than a paperwork drill to comply with HR requirements before firing someone.
1. Was completely deserved. My attitude was horrible. I had stayed at a company too long and my attitude got worse as the raises were minor and our bonuses kept getting cut. It was a vicious cycle. I should have left a lot sooner.
2. Was partially my fault. My performance wasn’t the issue, but I didn’t show the correct amount of respect and deference to the younger team leads. I didn’t know how to play politics correctly. I stayed for a year afterwards because their were some technologies I wanted to be able to put on my resume along with saying I worked for a well known company for 2+ years.
3. The “half” of a PIP came when the company where I was the dev lead was acquired, everyone was jockeying for position above me and I couldn’t get enough permanent developers to meet deadlines - only substandard contractors. I could tell from one of the meetings we were having that I was going to be the scapegoat. I called one of my recruiters and got the hell out of dodge within two weeks and “self demoted” to another job as a senior dev.
And 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.
If 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.
In 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.
No 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.
I 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.)
That'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.
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.
I recall an example from earlier in my career where an employer was looking to prune bad apples in the company.
They failed to deliver the news correctly, and although many knew in their hearts it wouldn't affect them, we were all professionals, majority engineers, and used a logical thought process to resolve it internally;
The news didn't specify who wouldn't be affected, and although the intended number was meant to be rather low (half a dozen people) in a ~100 person company, everyone started looking for other jobs to cover themselves.
Everyone has bills to pay etc and it's unwise not to plan ahead. Logically thinking, there was no harm in having a backup plan.
Well, come time to prune, the expected numbers are pruned, and then, the unexpected (to the employer) happened, tens more people left.
The bad news had given everyone with the "get-up-and-go" a kick to look elsewhere and realise actually we were all being mistreated. The company quickly lost some of their best talent.
That is a good point that I didn't see in my quick scan of the 44 rules...
If you have a target audience, give a specific message to only that target audience. Do not give the message to a larger group than the target audience.
I've seen (and been guilty of) giving a vague, non-specific message to "everybody" when only one or two people were the actual target of the message. This causes incredible problems with those in the audience that are not the target of the message. Ironically, the one or two people that are the problem typically remain oblivious to the fact that they were the target of the message.
If the employee pool is larger than 20-30 but there are only "one or two people [who] were the actual target of the message", the problem might be bigger than those one or two employees.
Unless (or even if) those "one or two" are outright sabotaging team effort or egregiously incompetent, management delivering a vague message to everyone suggests broader problem in the company.
The problem may not strictly be a managerial one. For example, the team and its managers may be driven by decreasing revenue, changing market, new legislation, etc. In any case, it's hard to imagine a situation where "one or two" non-malicious mediocre employees would merit a broad message to the entire team.
You're close to the truth in the second paragraph there. I don't want to go into too much detail, the company is doing well now (I believe) and I harbor no ill-will.
There were issues throughout the ranks, the company grew quickly and had issues adapting. I think the exodus gave them an opportunity to begin again without those that had been jaded by experience.
Indeed. In some cases the opposite was done; the message was given out as a whole, and some were told off-the-record that it didn't include them, this is another problematic approach.
Clearly this is how I became aware of the situation.
They waffled. They wanted to preserve people's feelings by not letting the specific people know. That way, it looks like they're looking at everybody, when really, they wanted to get rid of these six guys.
Let me correct. They weren't looking to preserve anyone's feelings. They were looking to preserve people's opinion of them.
Because one thing I've found is that anytime someone says they did something "to not hurt someone's feelings", it's not the target's feelings they're worried about, it's their own. They don't want the target to have a negative opinion of them. Because they don't want to be the bad person. Or what they perceive as the bad person. But it leads to treating people like children. Which is disrespectful and causes resentment when things finally come to a head.
Be simple. Be honest. Be direct. Be clear. If anyone harbors ill will towards you after that, that's their hangup, not an actual reflection of you.
Well as they said the folks who needed to be terminated were terminated, they just lost more in the process. Presumably the folks who left voluntarily after this would be on the higher end of skills as they were able to quickly find another position.
So the worst performers are terminated, the best performers leave voluntarily, and the company is left with all the mediocre folks and an overall decrease is skills and abilities.
There were many things, perks had been removed over night due to new ideas within the finance team, a lot of the team realised they were being grossly underpaid, and finally, those who were close to their colleagues were left without those they could count on in and out of work.
Yikes. If that didn't predate my experience, I'd say it was the same one. Insane! Soda one jut one of the many small perks that disappeared when this co got it's new CFO. They stopped all company team building "fun days", "soda" went away entirely, not even cheap, and the office was in the middle of nowhere so no shops to pop out to to get your own.
One of the keys to breaking any news is that whether it is good or bad, most people immediately translate it internally into how it impacts them. Bad news makes that translation come out as "Here is what I just lost."
The loss of leadership credibility comes when you are dismissive of that loss as part of the announcement, or you pre-emptively tell people they should be feeling another way. Most change management education will tell you that whether you like it or not, the process will happen the same way as any personal loss - denial, anger, bargaining, depression, acceptance. The trick in business is to speed the process to acceptance without being dismissive of the people going through the change. The tools to do so normally are all about communication: Listening, answering questions, replying with clarity so everyone knows the path forward.
In fast-changing organizations, such as startups, there is also a question of how often you change things. If you send your teams reeling with bad news and changes before they have accepted the last round of it, you will trash morale. One school of thought is not to make small changes, but instead to think out bigger solutions to your problems, and lay out changes all at once. Trying to fix one piece at a time, then rolling changes to smaller parts of the organization every few weeks may feel easier to manage, but it comes at a higher personal cost to the teams, and frequently saps productivity and morale for a longer term.
The advice about how to handle it is spot on, but I feel like it is missing something. That's not a harsh criticism because I'm struggling to articulate it myself.
Two things come to mind. The first is "Don't kill the messenger."
This is now metaphorical, but was originally literal. The reason you don't kill the bearer of bad tidings is because if communication breaks down, you have lost all hope of a diplomatic solution. Now the war has to be fought to the very bitter end of last man standing.
The second thing that comes to mind is an anecdote from raising my children.
My oldest had sleep issues from birth. When he was two, he often stayed up later than me. I would give him a drink, a snack and put a video tape in the VCR. He could come get me if he really needed me, but if it wasn't an emergency, I encouraged him to let me sleep.
More snacks and drinks were physically accessible to him. He was both allowed to get them and physically able to do so.
Inevitably, he sometimes spilled stuff. My policy was that he wasn't going to get in trouble for spilling stuff. Spills happen.
But I needed to know when he spilled things. I also needed to know where it got spilled and what he had spilled so I could clean it up properly. Some juices are the same color, but have very different chemical properties. Some can be easily wiped up. Others need special treatment.
Also, if you don't clean it up, it's going to mold or attract insects, etc. Nothing good will come of it. It is all down side to make your kid scared to tell you they spilled something.
He was a bit weirded out the first time because he was a little hellion who got yelled at out of concern for his safety so much that when he first began using the word no, he said it at full volume because he thought that's how it was pronounced. So he basically figured I would yell at him.
But he told me he spilled something and all I asked was where he spilled it and what was it. He showed me and told me and I cleaned it up and didn't punish him. After that, he was good. He trusted me. I wasn't going to yell at him over it.
Keeping the lines of communication open is critical. If your people are scared to tell you what's going on, then problems are being swept under the rug and left to fester and grow worse. It's vastly worse to make it a problem to share bad news.
> My policy was that he wasn't going to get in trouble for spilling stuff. Spills happen.
That was basically the first thing I told my sister when she moved in after our mum passed away a few months ago: "No matter which mistake you make, tell us. We won't punish you for that. However, if you lie to us, there will be some sort of punishment."
So far, it seems to work out, as she's getting more and more open, and talks to us about her feelings, her day, etc. Something that wasn't possible in the very first beginning. She also admits mistakes she does, and starts to ask for help more often - not as much as we'd like, but... yeah. Hopefully, that will be better over the next months.
Thanks a lot for sharing. Having young kids of my own, this have me a lot to think about. We have a couple of similar arrangements on other matters here, but the way you put it will most probably help me make it clearer and applying it better.
One of my first ever jobs they announced minor redundancies on, say Tuesday afternoon, 1M$ in EMEA (maybe 5000 people). Not too concerning. On Wednesday afternoon the same person "corrected" themselves, 2M$ in this office (200 people). The environment after that was... frenetic.
Also enjoyed the same person later responding to suggestions that we could save money across the board by some sort of pay reduction (so that we would lose fewer jobs) "ah, well we already pay significantly under market rate so if we do that then we're likely to lose our best talent"
Wow. My wife often has to deliver the news that someone’s baby has died or pregnancy has failed, she always has a bad time afterward particularly as it happened to us twice too.
Reading this article really helped me appreciate more how much it takes out of the person delivering the news. I mean I have had conversations with her about it but she often can’t talk about it in detail.
Thank goodness her work is progressive enough to pay for monthly counseling so she has someone to really open up to about this stuff.
I'd argue this is a bit different. (Though one or two of the examples are close.)
We're talking here about sugar-coating, spinning, etc.
Burying the lede tends to apply more to writing a story that goes into a bunch of routine story details or a story that's only peripherally related entirely. And then, after some time, a paragraph about news that's genuinely novel, interesting, etc.
For example, writing about a bunch of routine speech contents and then 6 paragraphs down mentioning some major revelation.
But the commenter is right. The saying is "burying the lede." There is no such thing as "burying the lead." The author of the article meant to borrow the jargon of reporters, to add color.
Your comment is like this more extreme example:
ARTICLE: I thumbled the plate and it shattered on the floor.
COMMENTER: The word is fumbled.
YOU: I would argue this is different because fumbling tends to apply to football.
As an addition to this, if the bad news will have a big impact on whoever you are delivering it to, just tell them the bad news and then sit back and wait for them to start talking.
Reason: If you tell someone they are being let go, whatever you say immediately after that won't get processed. Give them time to let it sink in and get over the first shock. They'll start talking/asking questions when they're able to.
Ok, good advice, but what if someone is just not good enough? Firing someone, stopping a project, it is not the fault of the employee (not always at least). But I'm currently in a situation where I (for my first time) have to tell someone they work too slow and seem to never finish stuff properly. The guy is just not good enough and it start to annoy me because he is not taking steps to improve. I find it very difficult, it concerns an otherwise nice guy that I have coffee or beers with from time to time.
I know it's best to just say: Hey this isn't working. But I want to find a job better suited to him, I don't want him wasting my time anymore when I ask him how he did something and it seems he never put it in our git repo.
Those things are much (MUCH) easier if you provide feedback on things you don't like instantly. He didn't commit something -- tell him. He did something in the way you don't find the best -- tell him. You think he's slow -- tell him right after you found out.
After a while if you decide that it won't work for both of you and things aren't improving, there should be already a good hint for the guy by that moment.
If you just hold everything without sharing with him, for sure that would be very hard to tell him your concerns.
Like apple. Way too hard to simply swallow. But it's ok to go bite after bite.
Have you tried communicating these concerns to him? Break down the expectations, e.g. that everything must be committed in the repo, with covering tests etc? If he takes it on board, win! If he ignores it and takes offense, well at least you tried?
I tried setting dead lines "Ok, lets make sure this is finished next week". But there is always an excuse, but it boils down to him being a poor programmer, he gets stuck and then he works on the other project he is employed in. The poorness is understandable in our circumstance and sort of ok (we were driven into this kind of work and I happen to love it, he happens to have no talent for it what so ever). I did offer other work (back to the lab in stead of doing the bioinformatics) but he does somehow seem to enjoy it. I know, time to be hard and honest indeed.
Arbitrary deadlines rarely work. Psychologically they just encourage "student syndrome" where people feel like they can slack off until the deadline actually seems threatening. Then the deadline is missed. That is the nature of human psychology, not your particular employee.
Ultimately, your job as a manager is to keep your team unstuck. People get fired all the time because their manager is bad at management, as it's certainly a supervisor's privilege to fire people they don't like. But always remember that your assessment "this guy is lazy and doesn't like the field" could be completely wrong and you're just bad at management.
Thanks, this could certainly be it, the next conversation will be along the lines of "what do you need to finish things faster?"
Don't misunderstand, this guy has sometimes been working on something for weeks, and then I decide to take it from him to do it from the ground up in 2 days. He seems to be allergic to git and complains about errors of others that don't even affect him. Still he seems unaware so a respectful inquiry seems best indeed.
I don't think it's possible to have an actual allergy to git, so some training in that area would probably help their productivity. Make sure he knows how to use git, and that he knows your organization's policy in regards to commits. You can set a policy like "just commit everything at the end of the day" and provide a shell script to do that. Don't make git the wedge that isolates you from your employee; make it a productivity tool.
> take it from him to do it from the ground up in 2 days
People that you employ to work for you will ALWAYS do things differently and probably more slowly than you. I have never had someone working for me, asked them to do X, and then gotten a changelist to review that was exactly what I would have done myself. Your employee is not a clone of you, he's an independently-thinking person with different assumptions and experience. (Certainly, if something is WRONG, don't accept it, but it's different... that's the reality of having more that one person working on a project.)
Also... there is no really good way to estimate how productive someone is, including yourself. You could be way above average and nobody that works for you will ever be as fast as you. You also have to expect that someone with less experience than you is going to be slower. For you, 2 days is applying the sum of your domain expertise and X years of a software engineering career to a cookie-cutter problem. For someone that works for you, that could be a month of acquiring career skills necessary to solve problems in the future and some subset of your problem domain experience, and then 2 days of applying those skills. You do enough of those "my boss could do this in 2 days" projects over many months, and then you're the guy that does it in 2 days. That's what experience is.
> complains about errors of others that don't even affect him
Probably worth having a discussion about. I will point out that you're kind of doing this here and in a public forum, hoping that your employee never finds out.
> I don't think it's possible to have an actual allergy to git, so some training in that area would probably help their productivity.
I was going to go back and add "does he need any training" to my original comment then life got in the way and I promptly forgot!
Absolutely do run training; could for example set up a Pluralsight account, run through modules on GIT and any other stacks that are needed. If someone doesn't want to use version control in this day and age then I'd have to agree that'd be my number one priority to get fixed.
Understanding feature branches would be a very powerful change. Not sure exactly how applicable this is to your situation but on a general level I'd recommend making them as atomic / small as possible as a way of starting. I.e. by reducing the scope of an issue down to the MVP, then it becomes easier to just get that done - add additional features/requirements as following issues. And then get on to pull requests ASAP so that you can preferably sit together and review / discuss the changes. This would reduce the feedback cycle down to maybe a couple of days, which would greatly help the pace as well. Good luck.
Always be respectful. But, the complains about errors of others that don't even affect him might be just strategy to cover up (maybe even from himself) his own under-performance and insecurity. Good luck. He sounds like some people I worked with in the past, not as a boss but as a colleague, and it was no pleasure. Down to being sociable and nice at beer.
Btw, the complaining about other people errors from someone like that whose own larger errors are seemingly never addressed can overtime turn the team culture pretty toxic.
The guy is just not good enough and it start to annoy me because he is not taking steps to improve. I find it very difficult, it concerns an otherwise nice guy that I have coffee or beers with from time to time.
It took me awhile to learn, but I keep personal and professional especially with subordinates and supervisors strictly separate. I wouldn’t be grabbing “coffee and beers” with him. It makes it that much harder to do what needs to be done.
Second thought, how does an experienced salaried employee ever “work too slowly” and not meet reasonable deadlines. If I think the deadline is reasonable, I didn’t push back, and there were no external factors , I’m going to work over to meet it - especially if it involves a new to me technology.
In Germany you can expect to get fired within week as soon as HR learns about you working too much overtime. The issue is that they have criminal liability if they endanger your health (it might be limited to cases where it's done repeatedly/egregiously, but no employer wants to be on the bench having to pray that the judge sees it as not his fault that his subordinate happened to work too long despite him knowing about it.
I would hate that as an employee. I’ve been getting jobs that I was barely qualified for with the expectation that I would have to work extra hours to both meet deadlines and learn the tech stack.
So if I spend 12 hours doing 8 hours worth of productive work and the other 4 hours reading, watching tutorial videos in between, should the employer be punished?
well, the max hours you can work is regulated by law. and if you think about it, if a company hires a junior developer, he is greeting paid as a junior and the company is also spending hours on his training ans so on. if the company is switching stacks or wants you to do something completely new to the company the time spend learning is working, nobody is expected to learn that on its own time.
Where are these mythical companies that train developers? Ifthe company switches technology stacks that’s one thing, but if a company is willing to give you a shot even though you don’t know the technology stack, why wouldn’t I be expected to learn on my own time? They could have just as easily hired someone who already knows the stack. Yes the company benefits, but so do I. In a year or two either they are going to payment more based on my knowledge (not likely) or I have the skill set to jump ship and make more somewhere else.
Isn't finding a job better suited to him sort of his job?
The issue seems to be less than he's "not good enough" and more that he's not taking steps to improve. If he was making slow but consistent improvement you'd probably be much more willing to stick it out for him, right?
I am always amazed at how HN takes little morsels like this and votes them up. The information presented is no more insightful or valuable than info found in comments or from the views of less well known or important people. Yet everyone seems to think that it deserves attention and some kind of added respect (which is all based upon what the person has 'achieved' if you want to call it that.) It's as if people seem to think that the knowledge is so significant that the halo will rub off.
So the question is to what extent does it matter what someone says if it's not their a) area of expertise or b) there is nothing truly remarkable about it in other words they are not backing it up with really solid examples based on long term experience?
Would love to be able to do a test. Take the exact same thoughts and unlink them from the halo and see what happens. Would expect exactly the predictable results.
I guess my point is also whether someone who is smart and has enough luck to be able to become wealthy deserves more respect than someone who is just smart and did not have the luck to have that success?
I was once faced with the prospect of losing my job. The company wasn't in a good place financially and they didn't have any projects for me at that moment.
Far worse than the prospect of losing my job was my boss. If there was bad news to be given, he'd just melt into the background and let someone else do it, even though he'd hired me. (It was a rather dysfunctional company in general).
That really stuck with me, far more than facing losing my job did. It's hard to be honest and direct about bad news, but it's the only way you should do it. Anything else is putting your own desire to not face fear above the needs of the person who is going to have to deal with the news. That's a really selfish thing to do.
If there was bad news to be given, he'd just melt into the background and let someone else do it, even though he'd hired me. (It was a rather dysfunctional company in general).
At the level I’m at now, I always ask the hiring manager how do they deliver bad news and what is their theory on feedback. I’m usually responsible for major initiatives even if I am 70% a heads down coder. I actually found it refreshing when a senior manager told me straight up that I missed a requirement and that it was a “big f-up”, after dealing with managers that beat around the bush.
I’ve got work to do, initiatives to lead, etc. I don’t have time to be reading between the lines. I want a manager who lays it on the line so I can course correct. Working at a small company, major mistakes mean a lot.
Even the name "bad news", depending on the situation, can come off as a bit of a deflection - if you're causing the bad news (e.g. firing someone), then it's not bad news, it's just you! Not to say that that it's your fault per se, but the wording is a bit weaselly, which often doesn't do much more than add to the frustration.
But from an everyday perspective, it works all the time? In recent light companies like Uber, Riot Games, Equifax, etc. have come under huge criticism but what do they do? They do "accept" responsibility in corporate speak but just make bs promises and stay quiet and wait for the PR shitstorm to calm down. Then to a good extent the people/the public forget about it and move on. Obviously this is a really bad thing, but they know it's human nature that you can only keep your attention on something (whether good or bad) for so long until you have to move your resources on to something else.
This applies to almost every situation where you have to break bad news, like being a manager or a parent.
When you want to provide negative performance feedback at work, be direct and professional, Don't bury it in a "compliment sandwich" ('You're doing a great job, except when you're not, but don't worry').
It's a hard skill to master (unless you're a non-feeling sociopath) because it means accepting that you will (possibly) be disliked, maybe even hated.
Same for children. They are going to hate you (at least temporarily) for criticism or punishment, but if you try to be fair, fact-based and direct hopefully they will appreciate it down the road when they have more context.
Great article! Loved it. Not sure if the author is posting this, but if you are, one small thing - it’s burying the ‘lede’, not ‘lead’. Thought you’d want to know :)
He should try replacing all the "we"'s and "you"'s with "I"'s and "me"'s as as far as I can tell, he's the only one that had to really be dealing with bad news recently.
Also, would drive his point home further as he'd be speaking from personal experience of using those very techniques during the whole Cambridge Analytic scandal.
I think one important item missing from that list is "Use clear language" (it's hinted at by a number of other items in the list, but that's exactly the problem...).
People tend to use gentler sounding euphemisms instead of stating the situation plainly.
Side note: using Safari, with Ghostery enabled (which blocks the Twitter widget), the homepage links do not work. The URL changes, but the content does not.
In the console I get
> TypeError: undefined is not an object (evaluating 'twttr.widgets.load')
And the context will vary from generation to generation so it's virtually an impossible problem to solve as well. It's even hard for humans to truly understand texts written from another era...
> 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.