The sunny side of firing someone
madned.substack.comBack when I was a junior developer I used to think tech companies -even the smallest ones- generally had some kind of reasonably accurate performance review process, where engineers who were underperforming for a while were eventually weeded out.
In my experience ever since, that's simply not true. There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get away with it for years. While their coworkers who have only been at the company for a few months will be routinely called out on their mistakes, missed deadlines etc.
Some people are less fireable than others and I'm afraid it has little to do with how good they are at what they do.
Companies rarely fire tenured staff except for layoffs. Often this is due to issues such as
- Tenured staff have a track record, if they are suddenly under-performing it seems more likely that their manager is to blame. Rather than a lack of ability.
- Tenured staff have institutional knowledge which can be hard to estimate and replace, the fact that a bad engineer still knows why something was done a certain way and can help others is sometimes sufficient.
- Tenured staff sometimes have implicit responsibilities that are unclear to new hires. An engineer with 10 years in the company might spend almost all of their time doing some form of product/tech leadership. The rare times they write code it may be deficient in some manner or another.
- Tenured staff know how to read the tea leaves. The fact that they are still with the company likely indicates that they know how to avoid situations where they will get let go. Sometimes this is as simple as hopping on maintenance work for profitable systems.
On the other hand, a new engineer doing their first project may actually not have the skills to get the project done. Or, more likely they were hired for new initiatives that leadership is fundamentally skeptical of.
In my experience, an inner circle is established at a company when it is still relatively small. Those fortunate enough to be in that protected circle can do no wrong. Any hires after that in group is established bear the brunt of that companies issues. It's very true with startups.
Lots of good points here, but maintenance work for profitable systems seems like a valid use of time.
Now, some profitable systems are slowly bitrotting and tenured engineers can keep busy doing routine work while failing to address or escalate the bitrot. But I think people who are good at making sure boring and stable things stay boring and stable are usually underappreciated.
Companies pay for people do to maintenance for profitable system even if those systems doesn't much need maintenance, meaning lots of people in those roles don't do much. The point isn't that all maintenance engineers are worthless, but that it is an area where you often can be incompetent but still be kept around.
Unfortunately I know of one engineer right now who is basically completely impervious to getting fired, simply because they keep waving around some self diagnosis of being especially sensitive, not on the spectrum mind, just easily offended by trivial issues. Even going to the trouble of writing a blog about their challenges at work for being called out for doing no work, and then playing the victim. I think management have done the math and figured continued employment costs less that legal fees if they were fired.
More likely it is just that they have a bad manager not willing to go through the process of firing them. I know as a manager firing people sucks but you sometimes need to do it to keep the rest working the best together. Companies do make it really hard sometimes.
As a non manager, keeping parasites around is bad for moral.
Firing them is also bad for morale, for different reasons. Only solution is to not hire parasites in the first place.
It’s not. People who work hard don’t like when others are doing little and getting paid.
It makes them question why THEY are the suckers doing the hard work.
I suppose keeping "parasites" around, until eventually slowly slowly firing them, is the worst?
Smart, gets things done on time, pleasant to work with. Pick any two and you’ll do fine. Neil Gaiman’s commencement speech. I think if two are lacking for a while you get fired…
Something tells me in the anecdata above, the unfirable characters involved picked 1 _at most_:
The teflon engineers don't seem smart and probably can't get things done on time if at all.
While the sensitive engineer seems unpleasant to work with, while not contributing at all.
Neil Gaiman has a knack of saying immensely compelling stuff, that's all there is.
> Smart...pleasant to work with
Does anyone have tips for having high code standards, but still pleasant to work with? I got feedback that I have high standards, but I also go to the effort of explaining why I think an approach is better in code reviews and don't talk down to people in code reviews (and got feedback saying this), but I'm not sure it's enough.
if you want to enforce higher standards than your colleagues, you have to put in most of the work to reach those standards. For instance, if you think a section of a code needs unit tests, maybe write some of the tests yourself or at least suggest how to.
also be modest, and make sure to frame your standards as cooperating to improve the company’s code, not competing to show you’re a better programmer
the ultimate goal is to make your high standards more of an asset (“he’s improving the code”) then a burden (“he’s criticizing us and making us do more work”)
High code standards or specific preferences? Are your comments more like, "If this receives two requests at once it will result in a race condition" or more of the "you used tabs but I like spaces" sort?
Imposing preferences on others via the mantle of "best practices" is a great way to annoy them.
Well most of these preferences should be fixed by automated code formatting and listing tools so they shouldn’t be discussed unless people are turning them off for some reason.
I'm not sure how well it works exactly, but when I'm advocating for more rigor or error-checking or other high standards, I try to include justification for why changes to the project under consideration need to be held to this higher standard.
Have some conversations to build consensus with your team about what standards the codebase should be held to at this phase in its lifecycle, and when that decision should be revisited as the project matures and evolves.
It's fine to personally have high standards, but it's important to keep those distinct from the actual needs of the current development work.
For a given standard X like "always check errors" or whatever "Does this change maintain property X of the code?" is a very different question from "Is it worth maintaining property X in our codebase today".
Justifying that a change you advocate for is better is not enough; you also need to reach consensus on that improvement being worth the cost in time, complexity, maintenance, etc.
Also, don't try to revisit that consensus for small matters. Having consensus about what you're collectively aiming for, and people feeling confident that they're aiming at a stable target, is itself extremely important, and is worth trading off a bit of code quality for.
Something else I find really helpful for building credibility in your proposals being well-calibrated instead of universally "do better" is to look for opportunities to change your mind, to be persuaded by someone's argument, and for opportunities to say "This is great as-is; no need for complication here" or "Thanks for keeping this simple". You might consider aiming for "good taste and well-calibrated standards" as a replacement for "high standards".
Help people feel confident that you will advocate for lower standards when appropriate, and they'll believe you way more when you advocate that higher standards are worth it in a specific situation.
Comment on the code review but follow up privately and offer to pair.
It’s extra work but it shows the contributor that you’re not just out to poke holes and make extra work, it shows you actually care about their development and progression as an engineer
This - hammering someone's code review with tens of comments can put people on the back foot. Part of any good senior and higher engineers responsibilities is to lift the people around them up.
It might help to have some rationale or at least anecdotes.
The people nobody(tm) likes are the ones that insist on things without knowing why and/or without any relevant experience. They read it in a blog, or someone told them that's better, Google does it, cargo cult etc.
Start by assuming your coworkers have their reasons why they do something, not because their standards are lower. Maybe it's not worthwhile to spend time on making something a little more perfect when there's other more valuable things to invest your time in.
On the other hand, it is possible that your peers truly have lower standards, less experience, and don't understand what they're doing. Unfortunately there's no easy solution to that. It's possible that by being the annoying guy that always nitpicks you will be able to drive some improvement, but it'll take its toll on you. As others said, lead by example works somewhat. The problem though is that sometimes the "why" in software engineering only happens after many years.
I'll also second the idea of doing your code review with those people as a discussion vs. an offline process where you leave comments that can be interpreted in different ways.
Try this; 1. every PR review call out one neat thing you _really like_ and maybe ask how they figured that out 2. Be explicit in the dichotomy between "recommendations/nits" and "you shouldn't merge this". Weight things toward the former. Have a style guide for the latter things and be very conscious of when someone is violating the actual style guide or just your own biases. If you really have high "standards" write them down... Otherwise they are just whims, not really standards.
To put a finger point on the advice above: you should _never_ be enforcing "your standards" but the "team's standards". If you can't tell the difference, that's its own kind of problem.
Pick your battles. Try to identify cases where at the end of the day, it doesn't matter if the code is not "the best TM".
Also don't hesitate to tag your comments as "nitpicks".
Try and organise a workshop to set some common coding standards. Having a commonly understood standard for good is an excellent way to start the process.
Not clear if the meaning here is coding standards as in how you name things, spaces vs. tabs, comments etc. or something else about the code. Coding standards (the style aspects) should just be solved by tooling, you don't let anyone merge code that's not to standard by having a tool verify that.
You can be all 3. Lots of smart people out there doing great work who are pleasant to work with.
But you gotta treat them right. Everyone becomes unpleasant in a bad environment
I agree a lot of this depends on the environment. Are you asking people to work on things they enjoy working on? What's the team like? What's the culture like?
"Smart" is maybe something that can be measured in a vacuum (though in practice it means more than just IQ) but most of the other parameters are very much influenced by the company, team, managers. I totally agree that people can become unpleasant if they're in a bad environment or pushed in certain ways. I've worked with some people that I thought were total jerks and we eventually became great friends, often the friction at work is about something stupid/situational + the general social awkwardness of many software people.
> There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get away with it for years.
That would be Wally from the Dilbert comic strips...
I have seen that when the employee in question has much lower salary requirements than others, appearing to provide a sort of false economy to management, even as their actual value is entirely negative.
I accidentally solved one of those problems, myself... having stumbled upon evidence a very poorly performing employee was reading articles on the web most of the day, only doing a few minutes of coding and taking some steps to hide logging of this fact (which was actually the part that caught my attention). Setting up screen recording and running it for several days hammered the point home. Said employee at the end of this period conveniently reported running into technical difficulties with their project, necessitating more time to work on it. That nicely drove the point home, putting the final nail in and effectively catapulting them out the door...
A company secretly screen recording me makes me shiver
"evidence a very poorly performing employee was reading articles on the web most of the day"
Sounds like probable cause for a warrant. Not that employers needs a warrant to use their own property, but to assure employees that they aren't being watched unless there's legitimate suspicion.
A warrant??? I'm not aware of any country where you can/need to get a warrant to "spy" on your employees. In some countries that would be illegal. If said employee manages to do what others do while mostly surfing the web that's great. If they aren't delivering then by all means fire them (ideally with some sort of process to actually let them fix it). I don't see what the spying buys other than the mistrust of employees, the news getting out, and people not wanting to work for you.
I didn't say they needed a warrant. I said the opposite.
I think this is illegal in Europe or parts of Europe! I’d feel differently if you were told this would be happening.
I think the general rule in Europe is that your employer may record your screen as long as you know it's happening.
Which I do agree with, assuming it’s work devices too. But secretly recording devices is just weird.
Ah the “protected species”
Great article. Firing someone is hard. Even for poor performance it can be really hard, like heart-pounding fight-or-flight anxiety-ridden hard.
It’s worst when the person who is doing badly at their job is a nice, well-liked person like “Bob” in this article.
But it helps when you realize everyone involved in that situation (a person is dragging the team down) is miserable, and the misery only ends when that person leaves. It also helps when you realize there’s a really good chance the person who needs to leave is the most miserable of all - they know they’re operating in a low-trust environment and it sucks.
I think there’s a lot to be said for “person-job fit.” Sometimes people really excel in one job and really struggle in another, but even folks who are really struggling are likely change averse and reluctant to do the work to go find a new job. In that case, severance can actually be a blessing.
That was me once. The severance I got helped me immensely by freeing me up to hunt for a better job full-time. Once I was out from under the soul-crushing drag of the bad-fit job, I realized I didn’t even want to be in that line of work, and changed careers. I’ve been much, much happier since.
>> operating in a low-trust environment
As someone that has performed exceptionally well in high-trust environments, and essentially not performed in a no-trust environment I can confirm that the latter is both miserable and terrifying.
Finding someone everyone likes is harder than finding someone who's good at their job, so the reasonable thing to do is to encourage the nice-but-useless person to do better rather than fire them and have the entire team demoralized by that event, and by the recruitment process, and the additional stress while there's an unfilled role.
In my experience improving someone's work is often really easy too - you just need to find something they like doing. Most people I've worked with who are "bad" are actually just bored.
That may be the case sometimes but it’s not universal. Some people are not that motivated and don’t really want to work hard at their job, for any number of reasons.
One of the worst hires I made was a person who was an accomplished engineer in another tech stack and aced the technical interview, but when he showed up to work had nearly no interest in learning our stack or working more than a few hours a day. I spent 6 months trying to help him learn, but even after all that he was being outperformed by new grads, because they were trying and he wasn’t.
The person was friendly and well-liked. But nobody wanted to collaborate with him because they knew it would just make their work harder than doing things solo.
When we let him go, it was a big productivity boost for the team, even though everyone was sad it didn’t work out. The morale impact in the short-term was neutral, but within a few weeks as everyone saw there was literally no drop-off from his absence, everyone realized it was necessary and morale went up notably.
I have been a manager and I've realized that a huge portion of it is a communication problem. Not all of it but a big portion of it and not many managers realize this.
When I was a new manager I noticed an employee that would just get everything wrong and do things with a low amount of quality.
Turns out the problem was with me. As a new manager I failed to communicate and define objectives clearly. I simply assumed such things were obvious. The employee assumed different things and as a result his work output and what I expected were mismatched.
After some time reviewing my own behavior I began spending a huge amount of time defining and planning out the scope of the project at hand. I take the time to make sure that objectives and what's needed are completely clear. When I did this the employee in question delivered beyond expectations.
Turns out this guy was a literal technical genius and that his performance problems were largely communication problems on my part. The guy can literally solve technical issues no other engineer can solve and could finish his tasks twice as fast.
Other high performing employees I realized weren't necessarily technically advanced. They were just better at predicting and meeting my expectations and that was the key. They were managing me, and I wasn't doing any management.
If I hadn't reviewed my own behavior I would've went down the wrong road of firing a technically superior engineer while only keeping the people that could "manage up" better.
I will say that there are tons and tons of managers who don't realize this and even adopt a philosophy around managing as little as possible. What these managers don't know is more than likely they are letting go of engineers who are not only technically competent but technically superior by subconsciously pre-selecting for people who are better at predicting what you want rather then people who are technical wizards. You can recognize these types of managers as they have a bias for certain types of engineers who take "ownership" of something or essentially manage a product so you don't have to. These people are good people to hire but at the same time this philosophy is not scalable.
There are places for both types of people in a company and a company does worse if it only has one type.
That’s fantastic introspection, but to give another anecdotal piece of data: I spent 6 months stressing about how to keep iterating communication and fit with an underperformer, and he never managed to contribute (I was the second of four managers he worked with over 3 years).
Kudos for recognizing your own mistake, owning up to it and ultimately correcting it. That is no minor feat.
But I do wonder if you're not extrapolating too much from this single case. Just because you made the mistake once doesn't necessarily mean it is very common per se.
I was fired "without cause" a little over a year ago. I know it wasn't workforce reduction because the company was hiring for my team at the same time. There's a chance I even was part of an interview for my replacement.
Weird to me that I was trusted with interviewing around the same time, but cut loose. No warnings about performance or anything else of the sort. And since it was "without cause", no reasoning was given.
I suspect I was just unpopular with my managers, and I was maybe too vocal about my issues with the codebase.
Anyways, I got a new job and got promoted to team lead 5 months after starting there. My managers and even the VP of my department have given me great reviews.
Sometimes it really just is your environment.
I wish that getting fired would not carry so much stigma as it does today. I got fired 3 times in my early career. 2 of those times I believe were completely unfair, only 1 time made sense because I had burned out and lost motivation (also, the company wasn't doing well financially). In all of these cases, getting fired was a valuable life experience.
The 2 times which were unfair, I learned that people can be unjust, spiteful and irrational; I learned to recognize and avoid working for such people later in my career.
The time when I got fired after burning out, I learned to be more attuned to my own feelings and to never allow myself work on something that I don't enjoy. It made me more selective about opportunities.
Tellingly, none of the places I got fired from ended up succeeding... On the other hand, one of the startups which I spent the most years working for is doing quite well.
Every time you get fired, you can learn something important; maybe you were overly ambitious and your skills don't yet measure up to the role or you made a poor choice when it came to company selection.
Getting fired can mean a lot of things, not only negative things. Aiming high can be seen as a positive attribute. Being willing to step outside of your comfort zone can also be seen as a positive (even if it didn't work out). I always learned a lot, even if sometimes I was learning by counter-example; by observing other people's mistakes as well as my own.
Also, people need to feel pressure in their lives. We need to learn how to fall and how to get back up. It's OK to fall. It's good to assert yourself and take risks, even if it means putting yourself in the firing line.
This. Getting fired is largely a perception thing as much as it is performance.
How your manager perceives you and his ability to perceive things and his personality influences everything.
Great comment, great advice.
I've been in the unfortunate position of having had to fire about 5 people over my career. I take it as a very solemn responsibility that requires full attention and compassion for the person being fired. I make it a real conversation, where I try to make them fully understand the position of their teammates.
What is interesting is that most of the time (4 of the 5 times) the person understands fully, gets their shit in order, and goes out and gets another more appropriate job. These firings are good for the team, and so far as I can tell, good for the individual.
One time, however, the individual didn't see it this way, and went to great lengths to keep their cushy sinecure, including but not limited to reporting random things about teammates to HR. This burned a lot of bridges, and I'm really surprised this person did this. It showed a huge lack of awareness of social convention and a startling degree of unprofessionalism.
Literally the first day I got made head of engineering for the first time (so, running a group of dev teams, instead of just one) I was tasked with firing 20 engineers I had worked with for about 2 years.
I helped about 60% of them find new jobs, and one entire team I managed to actually get hired together as a team (and they all got a pay raise), but baptism of fire or what. I got through a lot of whisky that week.
Firing people sucks. It was actually the right move for the business in this case and we are lucky enough that the market for tech in general is fairly good in any given large city, but argh. That was a shite week.
> One time, however, the individual didn't see it this way, and went to great lengths to keep their cushy sinecure, including but not limited to reporting random things about teammates to HR. This burned a lot of bridges, and I'm really surprised this person did this. It showed a huge lack of awareness of social convention and a startling degree of unprofessionalism.
One thing I've learned is you can't project your own morals/ideals/whatever onto anyone, even if you think you really 'know' them having worked with them for some time. You never really know what's going on, and shouldn't make assumptions. It's difficult, but after a while, you learn to just follow the process and try to placate the rest of the team.
'Yep, I know <so and so> is doing that, yes, I knew it before you. Yep, I'm working on it. No, can't talk about it. How about we figure out together what crap we can give <so and so> to do that won't block anyone else while that process goes?' etc.
> Literally the first day I got made head of engineering for the first time (so, running a group of dev teams, instead of just one) I was tasked with firing 20 engineers I had worked with for about 2 years.
I assume this was part of the deal? You can't say "hey, would you like to head-up engineering" without knowing this would be your first big assignment.
Yeah well.
I've also seen people be remarkably oblivious with what they're doing being a complete time suck of rework. And in spite of this they apparently thought they were doing just fine and I think even resented the rework a bit.
The article fails to address when the firing is actually wrong and incorrect.
I work at anduril and I know of a new manager who 6 months into the job fired 2 people and had one person quit because he couldn't handle dealing with him.
The manager obviously is blind to see the statistical significance of that many people gone in 6 months. He likely views it as a performance problem of 3 people rather then the more likely 'him' problem.
Keep in mind if you're fired it has hugely to do with the perspective and the personality of the people judging your work. Sometimes that judgement is valid, but just as often it is not valid at all. Additionally keep in mind the political motivations and machinations going on in the background. Along with firing people for political reasons... Many people not suited to be managers.
If you find yourself in that situation where you are fired do not ignore the reasoning behind why your manager fired you but also be sure to weigh it against many other opinions because often your manager is making an unjustified decision.
A lot of the stories in this article are justified though. One person was judged and placed under several people so they could all make an accurate assessment before piling the plug.
> The article fails to address when the firing is actually wrong and incorrect. > > I work at anduril and I know of a new manager who 6 months into the job fired 2 people and had one person quit because he couldn't handle dealing with him.
You can't tell from "statistical significance" if a firing is good or not. Maybe those three people have needed to be fitted for a while. Maybe, as the article says, it comes down to job-fit and the three employees are great people in the wrong job.
There are bad managers. But you can't identify them solely based on numerical analysis of turnover.
No exact answers exist but probabilities are very real.
3 people being simultaneously not fit for the job is quite unlikely.
You have a choice here. Either 1 person is unfit for the job or 3 people. 1 person being unfit though not for sure is Far more likely.
By one person I mean the manager is not fit. But in these cases usually the manager side steps the numbers and thinks he's doing the right thing.
I was in "position 3" about a year-and-a-half ago. I got over the shame / self-worth issues, but honestly there were a couple of betrayal-of-friendship issues from people I considered pretty close friends where it came out that what they were saying to management and each other wasn't what they were saying to me. I even asked on a couple occasions to sit down and tell me what I could do better... Got a huge pay increase and a happier job now, so it's not a sob story, but the friendship thing still stings.
The bittersweet aspect of this scenario in my experience, is that time heals some wounds only. With time, the friendship may survive. But it’ll never be the same of course. Neither party will want to revisit the topic of the exit from the organization, because it makes them both uncomfortable. On the sad side, there’s no chance of closure. But on the bright side, your friendship overcame some serious challenges, which speaks to your character and helps restore confidence. (I’m not assuming your friendships will survive in some form in your case, but am hopeful for you)
The guys never reached out after the fact, so I haven't spoken to them, which is part of why it makes me sad to think about. I don't lack for friends and other positive things, it's just sad because I really liked these guys.
Firing someone usually sucks.
Having your manager fire someone that really needs to be fired can be massive relief though, I think that is pretty much the only case where there is much of a sunny side.
It's a huge relief to the team to have a bad performer removed.
I've been on a team where a bad player was removed and the whole team was noticeably better performing a month later. It sounds a little "woo woo" to say it, but I think a lot of energy was freed up by the firing. Instead of thinking about how to deal with our bad teammate, we could focus on getting our work done.
And if you don't fire or contain the bad apples, the good ones will go.
Having been demoted and fired, but never having been in a management/doing-the-firing position, it is nice to see the other side of this. I thought this was a relatively fair treatment to the employee being fired and also shines a light on what the title is indicating: sometimes there is some benefit to the people around.
--
> There are jobs that are bad fits, but not bad employees.
>
> Scenario 3: Summarily Dismissed
> OK, that’s not entirely true.
Made me chuckle. So did
> We were not asking for him to be fired. Except we were.
It's funny how the perspective shifts to reality given some distance and time.
--
I also thought he might be wrong about Bob; maybe Bob can and did or will learn good software development principles. Perhaps Mad Ned is being unnecessarily harsh. Or perhaps I'm overly optimistic. But I remember a time when I couldn't write code very well at all. Now, I can, at least when the stars align properly... and one of the nice things about code is the malleable nature of it: get it right once, and it is in source code management history forever.
I had a "Bob" a few years ago who was a unique case: He was a very intelligent, experienced senior developer who at some point lost his ability to actually ship. Given a relatively straightforward feature, he went into agonizing detail in his documentation, spent months implementing layer upon layer of abstractions, held himself to noble standards like never testing or debugging on a production server...and the end result after a year (plus) of effort was a repo full of such high-brow code that nobody could make sense of it. Once he was gone, we got a junior developer to rewrite his last feature in two weeks.
He was moved around between a few managers after he passed the zenith of his 15 year stint at that company, but from what I was able to piece together he didn't succeed in bringing a single feature to production in the last five years he was there. He was just so darned friendly and smart that nobody was willing to do the needful and separate him.
> Bob did well on our interviews and was hired as a software developer in charge of infrastructure components. But it soon became apparent that his development habits were very heavily biased towards the hacking end of the spectrum.
I'm primarily a self-taught developer. Can anyone recommend some resources (e.g., books about professional software engineering practices) so that I don't end up like Bob?
"Bob"'s problem was counterproductive pride and being unteachable. There is no room for ego in a precise profession like ours, and none of us writes perfect code. If "Bob" had learned from his peers during code reviews, he would have been fine.
To answer your question: The Pragmatic Programmer by David Thomas and Andrew Hunt, Writing Solid Code by Steve Maguire, and Code Complete by Steve McConnell.
There is no book to teach these parts. Books teach some simple principles but there are many right ways to write code. Ask your manager and coworkers for real feedback. Let them know that you can take anything. It even set up some anonymous feedback method. And no matter what they tell you don't get defensive. Just say thank you for the feedback and reflect on it later. You can even get mad later but still please try to see it from their side. 99.99% of people really are just trying to help you. Last look at how coworkers are writing code and how they are solving problems. I still learn daily from reading others code.
I totally agree with learning from others do but I don't think you'll get too much use out of asking for honest feedback.
Either people won't trust it's 100% anonymous, won't see an upside for themselves or maybe bad actors.
Regardless of whether you're self taught or minted from a program, the lesson to learn here is that your colleagues can get rid of you if your work doesn't conform to their expectations.
It's just as possible that Bob's colleagues were anally retentive simpletons that couldn't handle the truth of his code, as it is that Bob is a loosy-goosy house of cards coder whose results were always C- material (I've worked with both.)
Point being, if you want to keep your job you should aspire to be a good 'culture fit' and if you want to be a good developer then work with great people and read more source code than you write.
There are plenty of good books, but IMO the problem with Bob (and the thing to keep in mind not to become one) is that when the company tried to help him, he not only resisted, but effectively sabotaged this.
Books are good, but if you are new at the company or do not know how it works, find a few more senior folks who are doing well and ask them for advice. Run your architecture / solutions past them, ask for opinions, etc.
I think a vast majority of folks fired like Bob just did not listen to strong, non-subtle signals from the company trying to prevent the firing. My 2c.
I like Code Complete by Steve McConnell. It was popular at Microsoft when I worked there in the late 2000s.
I re-skimmed it recently, and it still held up, but the advice has influenced a lot of other writers so it may not feel as profound as it was then, but I think it's sound advice in terms of software craftsmanship.
It's also worth noting that Code Complete biases toward processes that work for a large company where there's lots of cross-team collaboration. The advice is good in general, but you should weigh certain parts less if you're working on a smaller company and especially a fast-moving startup.
Also Joel Spolsky's blog is fantastic.
Build a medium-sized project on your own, especially one with evolving requirements. Bonus: come back to it 6 months later. You'll learn about scaling a codebase past 1000 lines (and maybe 10,000 lines), weigh the pros and cons of hacky workarounds, go through the pain of refactoring, and gain perspective about how projects evolve.
Code quality can be a religious issue for some people, and some teams have somewhat strange ideas on the subject that they've agreed to agree about despite the ideas not being reasonable or valid.
Perhaps Bob was an engineer with a long record of success in other teams, who was surprised and justifiably defensive when his colleagues weren't happy with his work and demanded he do things differently for vague reasons that didn't make sense.
He's probably much happier now that he's in a more compatible team. Perhaps he's the guy in the photo.
This article actually describes both reduction-in-force (lay-offs) and firing. I've had the unfortunate experience to do both during my career and I can tell you that, for me, it's very painful to lay-off someone even if it's just because they're not the strongest performance in the group. On the other hand, firing someone who deserves it actually creates feelings that are closer to relief (not firing someone who deserves it is probably the worst thing I've ever observed for a team's morale.)
IMO the world really needs a gallery of images in which people are cheerfully going through dreadful life events, e.g. being fired, signing divorce papers, burying a beloved pet. People could look at these images when they are anxious, and it would make them feel better.
I might misinterpret you. But why do we need to soften the blow? Why do we need to appear reasonable and cheerful at dreadful life events?
They suck. We are allowed our "negative" emotions. We need to allow the shame and fear and anger and bitterness and sadness. We need to be able to voice these. And not forced to hide them for the sake of a society that doesn't want to see these. Or for our peers and their well being.
But as said. I might be tainted by experience and misread you.
People generally are very sad when they go through awful life experiences. That's fine and it's often expected. It's common for people to weep at a funeral, for example, and it might be somewhat inappropriate to be cheerful and cracking jokes.
I think that seeing people happily go through dreadful events would be therapeutic for some people because it would reduce the anxiety that people experience when anticipating these events happening in the future.
I wish for a day when if I have to fire someone, the organization that I am a part of has the combined advantage of insight, influence and capability to find alternatives for both the organization and the individual being fired.
I hope my organization has the insight to know where the person I am letting go would be a better fit in... and has the influence to recommend them there inside the organization or another one.
If the fired person is fit for no place of work in the or circle of influence in the current state of the organization, I hope we would still be able to provide support for them while giving them the opportunity to still engage in the orgaznization until they find an alternative... or find a useful opportunity inside when things change or when they they change i.e. acquire the skills that may be more useful to the organization.
I don't know how this can be made possible... i.e. what the organizational values that will be required to be able to achieve this while still being sustainable... or if government involvement is required and how can organizations fund tho government programs through taxes.
In some cases the experience is simply too traumatic for the fired employee, there’s no amount of professionalism, empathy, care, support the firing organization can provide to suppress a toxic dynamic to any remaining “engagement” with the organization. In these scenarios you really need to pull the band aid off and hard-terminate them; it’s best for everyone. And take your good intentions and put them into a retrospective and action plan to fix the organization, eg. modifying your interviews, eg. nipping performance problems in the bud, eg. pursuing only sustainable growth.
It’s also not easy to predict how a fired employee will react, but gets easier with experience. But big companies don’t leave room for any continued engagement for this reason- after layoffs they provide support at significant arm’s length.
No there are alternatives. You support the team switch before termination. Termination is a last resort option and should only be done after multiple people managed the person directly to remove bias.
I've seen a scenario where 2 people at anduril (where I work) were fired in 6 months and 1 person quit to get away from the manager. Statistically in this case it's a managerial problem and you need to place those employees in different teams to know that it's the manager that's the problem and not the employee.
Simply assuming the employee is the problem without additional oversight is the wrong path.
I hope the experience does not have to be toxic or negative. Maybe the company is transparent enough to reveal it's vision enough to the employees and it is not a random and unexpected decision... maybe those who are not needed anymore are in the position to know more or less when and why so they don't have to feel that it has to do with them personally.
>take your good intentions and put them into a retrospective and action plan to fix the organization
May be this will be the path to get there. I doubt it will happen by a political plan designed by career politicians out of popular fantacies they like to sell to the masses... which then they plan to impose on everyone. That approach will most likely backfire in unexpected ways. I believe it will have to happen organically and will most likely will come about in the most successful organizations who can afford to build it... at least in the beginning... before it becomes available to everyone.
Also, it is important to make organizations responsible for this and not end up with individuals funding this through increased taxes for the working class. Next time your favourite billionaire talks about UBI or something similar, ask them if they are willing to offer unemployment benefits or something like an UBI to people they hired and let go from the corporation itself... or if they are willing to pool in extra taxes for this purpose so that multiple organizations can offer this to their former employees. They have incentives to make it the "government's problem" i.e. just use the income taxes from the working class to make this happen... and they absolve them of any responsibility and commitment to make this work.
I definitely wished for this. Sometimes I think this is well worth the additional weeks/month or two of support financially and otherwise to both keep good morale and to be pretty decent to that human being.
I had to look at the author's name to find out if I was Bob! Though the latter paragraphs about ignoring the other engineers requirements about reviews, etc don't fit.
After a few gigs that didn't go great, I ended up at a research org, where my less than perfect code that would do things in a non-scalable way was actually appreciated and a benefit. This org had amazing engineering capabilities, and amazing research. I was an oddball that straddled the line between the two.
My engineering improved slowly, and I eventually ended up in management, and now run two start-ups. I don't get to code much at all any more, but the experience has given me a new direction in life.
It's great when a manager can recognize that even though you're not the right fit for that company, it's possible your weakness there could be a benefit to someone else.
I can't remember who I was listening to on a podcast, but they said that rather than firing people, they would regularly recommend they go work for a competitor. :)
Run two startups? ... Nice to have you here Jack!
> I remember in December of 2000 during the dot-com bubble/recession, our company had several huge 20%+ layoffs… A big downside for them was, they were all suddenly looking for jobs in a very bad economy.
This was me. The small firm I worked for went belly up during the dot com burst when all our contracts dried up. But, I ended up getting an amazing job at a Fortune 500 company where I still am this day. I have had an amazing career and it is largely thanks to losing my job back then.
I think the article misses the case that the manager is just an unprofessional idiot and fires someone (or usually more than one) just because he doesn’t like them.
I have seen in the past. They fired promising engineers out of the blue (no negative feedback until then) and for completely random and unprofessional reasons given, e.g. we think you don’t like us.
Even if the manager is unprofessional idiot, the manager can't fire somebody without working with other people at the company, such as their boss, HR, and probably the Finance department.
They can certainly drive the decision, but they need the buy in of others too.
I was referring to small companies and startups where there aren’t such things and founding engineers are like gods within the company and can have such ‘professional’ attitude.
I have seen it happening.
Years ago, I was Bob but a junior engineer.
I had previous experience working in research, and tended towards a more hacker's style of coding that had always been good enough for the prestigious lab where I interned. Looking back, the older guys on my team were signaling disapproval to management but would never correct me to my face, and never offered constructive feedback. My manager was largely the same way. People in tech tend to be terrified of controversy and struggle with conflict.
Getting PIP'd was the best thing for me, because it established clear standards and goals for me in my role. In sixth months, I got promoted. Sometimes it's a communication thing.
Have any managers here been asked to fire ppl so the company could more easily raise another round of funding? Firing as a signal to investors that the company won’t waste money.
Not at a growing young company.
There are cases where a late-stage startup got into too many businesses and the next investor wants them to cut a line of business. Like I can imagine Uber having to shed UberEats if that was going poorly, but the investor liked the core driving business.
This is a fairly terrible article. As anyone who's run a business knows, sometimes you have to let someone go not because you're in economic trouble, or because they're an axe murderer, but just because they're not the right leader for their position. It's not so much "summarily fired for poor performance" as "wrong person for the moment".
It’s a terrible article because, despite explaining many scenarios well, it missed one example?
By far the most common though, and the one in which you're most likely to need advice.
Publishing an article about firing and only talking about cases where someone went to jail for assaulting his wife, or where the company is about to run out of money, is not exactly helpful to the founder agonizing over what to do about his head of marketing who isn't scaling effectively.
I agree that is a very common scenario in general, and I have seen it happen myself many times. But intro mentioned that the scope of the article was about firing engineers.
> Now we move on to a completely different topic, and maybe not the most pleasant one: about when engineers get fired.
So in context of the article’s purpose I think it is a fair representation - I very rarely see firings related to “wrong person for the moment” for engineers. But I very commonly do see firings for poor performance in engineering which, as the industry’s overzealous interview practices may suggest, is difficult to discern in an interview.
Even if you disagree with my perspective, I do still think you do yourself a disservice by jumping to the hyperbolic “it’s terrible” instead of writing your feedback in a more constructive manner, like you did in this subsequent comment.
I was fired from my first industry job. I had been thrilled to find my first role as a software developer, was making more money than I had ever made in my life, and my relationship with teammates started out super-pleasant. The team, and company-at-large, seemed similarly thrilled to be bringing me on-board.
I was woefully unprepared, having worked mostly meaningless jobs up until then. I was complacent and lazy and took the opportunity I had been given for granted. I started out strong and did good work for the first few sprints, but fell back on my old habits.
At the same time, my supervisors seemed to have unrealistic expectations for a first-time software professional. The team also despised pair-programming (even if done occasionally), and the dread and resentment any time I asked for help were palpable.
A couple of months in, a supervisor started dropping hints that they weren’t happy with the quantity nor quality of my contributions. The 100-day check-in was a trainwreck. Half an hour or so of two supervisors dumping on me. The only kinda positive thing mentioned was that I “socialize well”.
I was eventually given typed meeting notes, and they considered that my PIP. The next few months had ups and downs but overall nobody was happy. I started responding to recruiters and exploring potential new jobs, but the company already had my exit in motion. After about 10 months total, I was fired because I was late finishing my work and “depending too much on other developers”.
The timing and manner of my firing were humiliating, as were the terms of my severance.
I was initially heartbroken, and went through the five stages. In retrospect, I still have mixed feelings about everything that happened. I really tried to get my act together and do better work, but was never given any structure or support. It seems their mind had already been made up at 100 days, and they just wanted to get their ducks in a row before firing me.
Fortunately, I found another job not too long after getting fired. I felt I had learned my lesson, and came out very strong out of the gate and worked harder to sustain that. There was also more structure and collaboration. We got more learning resources (we were basically expected to learn on our own time, with our own money, at the first company). My teammates and supervisors liked me, and were patient in giving me time to learn and grow. The salary and benefits were much better. I eventually left after less than 2 years because I felt I had hit a ceiling and couldn’t grow much more within our legacy tech stack, and I didn’t want to get pigeonholed and have to write enterprise Java for the rest of my career.
I’m now in my third industry role, learning and collaborating more, using the coolest tech stack ever, and making even more money. I’m even playing a leading role in team-wide learning initiatives, and I’ve had opportunities to evaluate potential new hires. I feel infinitely more happy than I was at the first company (and a lot happier than I was at the second).
I’m writing this partly for catharsis, but also to provide an example of being fired not meaning the end of the world, and in my case it ended up being a blessing in disguise.
The first company also seems to have found devs who worked out much better for them, and they even got acquired by a larger company in their space.
So overall I think it ended up being a win-win.
It's good to see that you took the situation as an opportunity for personal growth.
During a period where people at our company were being let go, one of the managers fainted at work (we assume after having to do it). I imagine it’s quiet a difficult thing to do.
Mad Ned is the best tech writer on Substack these days, I think.
I certainly was let go under a type 3 scenario recently. I can empathize with poor Bob (and the firing manager!). It was a bit abrupt in that my second serious set of conversations was the one where I was notified I was being let go. I discussed that with the head of engineering and I think he felt terrible about that since we'd talked about a "multiple conversations" route on the way out. It was also hard and emotional for a number of us. Both the head of engineering and the head of HR came near to tears twice throughout. My (former) head of engineering was basically grumpy cat personified as a human, but a big softie inside. So the display of emotion was exceedingly rare. Also, one of my closest coworkers was completely shocked, and a number of other people I knew at the company seemed pretty surprised too.
Ultimately I think there were a variety of factors always. Our company did less and less cutting edge neural network research, and more software development. It slowly turned from informal and small to scaled and rigorous software development. I couldn't keep up, career-wise, and I can definitely say everyone of us involved gave it our best shot to make it work. Despite everything else, it was hard to leave. The employees are good employees, and I like them a lot. I'll miss that group of people.
Something I found interesting too was that there's an interesting budget trade-off between struggling in a job position and struggling emotionally when moving towards a fire/layoff threshold. I went through a rather terrible time a year or two ago when a lot of cumulative trauma came to head and opened up in my personal life. We had a pretty generous vacation policy -- 45 days a year (yes), and all of that for ~1.5 years was used to supplement my hours, though I technically swapped in FMLA for some of it. Not having vacations definitely added to things. But there was an interesting tight race that happened that as I recovered, there was some pile of damage that had built that I wasn't able to really resolve yet, but was able to just stay productive enough to keep it from triggering a letgo condition.
Then of course the present. Feeling a lot better about my interactions with self and other, but enough of a period of struggle that only actions really can show that turning around. Buoyed by some confidence, I took a few risks and fell on my face, and tipped off a signal I'd thought I was pretty far from. It was a hard process for all of us.
Of course there's the feelings of shame, etc. But I think getting to have an empathetic conversation and knowing it was a "lack of work" rather than behavioral primarily (or much at all) really salved it. Now I'm tangled in a huge mess with a very overarching IP clause that's tangling the job search, but after a long break for the burnout just to keep the job, I think maybe it's time to go part time and just travel the country or something. Make friends, focus on a garden plot, and catch up on all the life I missed. With how strict our hours were plus other obligations, I was spending 10-12+ hours on work and work-related stuff each day. Humans weren't designed for that.
Anyways, hope that was an interesting account. I think I can see the struggles, and like most things I think it was out of most of our hands despite best efforts. I still thrive in nn research, so it will be nice to really get back to that more.
On the one hand, I've previously suggested that managers should be quicker to fire underperforming workers, but on the other hand, it's absolutely true that some disappointments from workers are because of my own lapses in communication. When I wrote about one-on-one meetings, some people suggested to me that one-on-one meetings allow a manager to tell one worker one story but tell another worker a completely different set of facts, and the end result is that workers ended up feeling like they've been lied to. So when I recently wrote about this, I included this story, which I think shows both sides of the issue.
There are times when workers feel they’ve been lied to when they have simply misread or misheard some communication from their manager. This is an actual communication that I recently had with a freelancer I was working with, putting together some preliminary numbers for a marketing campaign:
Me: About Task 3, can you wrap this up by Thursday or Friday?
Them: I’m busy on Thursday, but I can get to Task 3 on Friday or Saturday.
Me: Are you sure you can’t get this done on Friday?
Them: I don’t know. I’ve got some things scheduled for the afternoon on Friday. I’m not sure how long that might go into the evening. But I can get it to you by Saturday afternoon, for sure.
Me: Look, this doesn’t have to be perfect. Don’t go overboard. Just put in what time you can on Thursday and Friday. In this case speed is more important than quality. Whatever you can do is fine.
Around 9 PM on Friday I had not heard from them, so I wrote to them again:
Me: Hey, can you please send me whatever you’ve got regarding Task 3?
Them: I told you, I can get it to you by Saturday afternoon.
Me: I told you the deadline was Friday.
Them: You never said the deadline was Friday.
Me: What I said was, whatever you have by this point, Friday night, is fine. I think I said that speed is more important than quality.
Them: Yeah, but you never said that Friday was the deadline.
Me: Okay, that’s fine, but please send me what you have.
They sent over what they’d done so far, and it was fine. In this case, we were both a little bit in the wrong, in that neither of us made explicit what the deadline was. I thought I’d been reasonably clear that by Friday night they should just send me whatever they had, but they felt that I’d authorized them to keep going until Saturday. It’s important to be very clear about expectations, otherwise workers hear what they want to hear and then they sometimes feel that you lied to them.
In this case, I simply failed to make 100% explicit that the deadline was Friday night. If I had invested a little more time into the communication, I probably would have made clear what my expectations were.
I've previously suggested that larger, stable firms should do more to offer some kind of apprenticeships to novice tech workers. But in small startups, when the whole team is just 4 of 5 people, often you need for everyone on that team to be perfect, so if someone on that team isn't perfect, you need to be fast to fire people. This was one of the main conclusions that I put in my book "How To Destroy A Tech Startup In Three Easy Steps."
> "This is an extremely bad thing for the people who have to leave, who in most cases do not even get much warning that it will happen."
If this is the culture then the person being cut loose is the winner. Not much warning is bad management / leadership.
This is done because when employees are let go they could become potentially hostile to the company. That's why they don't inform people beforehand of the firing.
What should absolutely be done is inform him of the exact performance problem and steps to improve. An actual well intended PIP and not just a way to throw someone out.
I guess he means that they didn’t have any negative feedback until then.
Thank you.
A lot of the scenarios described here aren’t “firing” someone, as I understand it, but making someone redundant.
The difference being that being fired suggests the employee did something to deserve it, but being made redundant could happen to the best of employees.
We don't really use that term (making someone redundant) in the U.S. I've heard it on British shows so I assume that's where you are. It means laying someone off, right? Meaning a workforce reduction?
Yeah, exactly - with this context the article makes a bit more sense to me! :)
The best part is you don't ever have to see their face or listen to their voice again.
By the time you have to fire somebody, that's usually a huge relief.
This is really vile. You realize the what you're doing to someone when you fire them?
Personally I think people with your style of personality aren't suited to be managers.
To the other replier: it's definitely not sarcasm.
I hope that's sarcasm. Enjoying that sort of thing is not healthy. Unless the person being fired is a literal enemy of yours