Back 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.

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.

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.

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.

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.

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.

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.

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.

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.

> 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?

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 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.

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. :)

> 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.

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.

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".

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.

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."

>> 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.

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.

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.

"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.

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.

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.

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.

It's good to see that you took the situation as an opportunity for personal growth.