Time to take a little break from the world of Nonads and Nine-Bit Computers. We’ll get back to that at some point, but (program note) if you want more info on this project, and/or you want to stay up to date until the next inevitable Nonad article, check out my Hackaday.io project page I started.
Now we move on to a completely different topic, and maybe not the most pleasant one: about when engineers get fired. I spend my time these days in a purely technical role, but I’ve been working for long enough to have put in some extended time in a managerial role also. And I have had the unpleasant duty on more than one occasion of having to tell someone they were no longer employed at our company.
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. It can also be very tough on whoever has to break the news. I have had people crying in my office after they found out, and I have seen people get angry. I have had to let go of someone who has kids and a family and who was the primary income provider for the family. It never really feels good to be involved in this process, even in the best cases.
There are different reasons why someone may be kicked out of their jobs — Yes, kicked out. That may be a harsh way to say it, but ‘asked to leave’ is just one of many euphemisms that do not accurately convey the reality of the situation.
Here are three different scenarios that I have run into, over the many years I’ve spent in the engineering world. None of them are really great to be involved with, as either a manager or ‘affected employee’. But sometimes, there are silver linings, even at times like these.
Scenario 1: Misery Loves Company
Employees who are relatively junior may not have seen this situation come to pass yet, especially those who work at large companies. Given enough time on the job though, you will eventually witness or even be part of a large-scale layoff of some sort.
For startups and small companies, this is a known risk of taking the job — the company you work at may run out of money, or meet some other fate causing it to be no more. This is the tradeoff you made when you agreed to work there, usually trading job security for equity in the company, and a chance to grow your career quickly. If you did not take this into account when you joined and you were unprepared for this possibility when you lost your job, that is pretty much your bad. But it is not any fun, even so.
For larger companies, a large-scale layoff could be related to a product that is canceled or a division that is eliminated or cut back. These events often track the general economy, so for instance if there is a big recession, even relatively healthy companies will make severe cutbacks in their expenses.
I remember in December of 2000 during the dot-com bubble/recession, our company had several huge 20%+ layoffs, and even cut big divisions like a design consulting business that six months previously was about to IPO.
Our little group that day was busy pranking a well-liked manager who had returned from vacation, and we had filled her office from floor to ceiling with balloons, which was no mean feat because she had wisely locked the door to it before she left, fearing some mischief. We managed to get the ballons in anyway, through the ceiling tiles in the hallway. She was stunned by the effect and delighted by the attention, even if it meant digging her way through mountains of balloons to get to her desk.
Balloons drifted out into the hallway and surrounding office area to a depth of 1-2 feet, through standard stochastic processes. But as people were laughing and kicking them around, someone came over to tell us the consulting division had been cut, and something like 80+ people on the other side of the building were packing up boxes. We all stopped laughing, and quietly cleaned up the balloons. Not that easy, considering they were balloons — (pro tip: scotch tape on the balloon first, then poke a hole, for quiet deflating)
The cognitive and emotional dissonance of that day stuck with me. Maybe it was a form of survivor guilt, but I felt really bad for all those people who were let go. A big downside for them was, they were all suddenly looking for jobs in a very bad economy.
But in many ways, this is the least difficult of the three scenarios I am talking about here. If you find yourself let go as part of a big company cut or a failed startup situation, you can collect your things knowing that it is a random curve ball thrown your way, and is not somehow related to your work performance or ability to do your job.
Other people know that too. Future employers, or fellow employees who make their way to other companies that eventually need people. I wrote previously about the idea of developing your personal brand, and how it is really the only true form of long-term job security in a world where there are no sure bets of continued employment.
If you focus on being someone people like to work with, you can recover from a big layoff situation and find your next opportunity all that much faster.
Scenario 2: Peanut Butter and Lifeboats
Coming a step down from the big layoff disaster event is the smaller, sometimes even ‘routine’ layoffs companies engage in to control costs. In the strong Bull market we have had in the past few years in tech, these have become less common. But just like my previous prediction, if you have not seen one yet, stay tuned. It will happen.
We took to calling these types of layoffs “peanut butter layoffs” because they are often implemented as reductions in force that are spread evenly around. Upper management will ask all groups to reduce costs by say five percent, but the only real way to implement such a cost reduction is by reducing payroll — ie layoffs.
I find this strategy to be somewhat lazy on the part of the management in charge. Instead of making targeted business decisions, they just tweak some numbers in a spreadsheet. It is very common however, and the result is often that managers of teams both high and low performing being forced to pick some of their people to be voted off the island.
I have been on both the manager end and on the receiving end of this process in the past, which plays out in most cases as a Lifeboat Excercise. Low-level managers are given the unhappy task of picking a small number of people, one or two maybe, to be cut from their teams. And the standard process usually is, to figure out who you can most live without. Or perhaps, whose departure will cause the least impact.
Having to engage in this type of planning never felt completely right to me. It seems cold and calculating to have to assess people’s worth to the company and rank them versus each other, and you don’t want to lose sight of the fact people’s lives are in play in this game.
What helps me here (when I participate in the manager role of this process) is to think of the people who are not leaving, and how to best serve them. It’s bad enough that a group is being downsized but has to continue doing their work. It would be even worse if the wrong people were retained, and this led to problems that triggered further reductions down the line.
For the people leaving, there may also be some consolation prizes. Being at the bottom of the lifeboat list just means that the company has found a way to go on without your particular position, with you in it. This doesn’t have to be because you were a bad employee. Many times, it is the position itself that has become expendable, thereby making you expendable also.
This has happened to me in the past. I took a job as a full-time manager that turned out to be a bad move for me. The work was unfulfilling, but in spite of that, I remained on the job. Because it was easy to just stay at it rather than have to go through a big job change event.
The job change event found me, when they moved most of my group to another country and eliminated several other positions as a way to cut our division’s costs in a peanut-butter layoff going on company-wide. Luck was with me, and I landed a technical position in another part of the company, two days before I had to box everything up. It turned out to be the right medicine for what was ailing me, even if it was kind of force-fed.
Even if you were asked to leave because you ended up on the lifeboat list because you were considered to be underperforming, it is not a personal assessment of your worth, but the situation you are in. I would say in my case, I was definitely not giving the company my all, even if my performance reviews were fine. It was just the wrong place for me to be, and when I started working again in the new job, my work output, and hopefully value to the company, increased.
It’s very easy to think “once a bad employee, always one”. But the truth is people change drastically in response to their environment. You really can go from problem employee to star performer, if the change in conditions is right. So if you were let go at some point because you had bad reviews, take this to heart. There are jobs that are bad fits, but not bad employees.
Scenario 3: Summarily Dismissed
OK, that’s not entirely true. There are sometimes bad employees. I’ve been working for forty years, and if you work for long enough, you will see some shit. I had a junior engineer who I was supervising call me one day at DEC to tell me he was not coming in because he was in jail. It seems he drove his car through his ex-wife’s above-ground swimming pool. Fired.
Another guy basically quit, but we had to fire him instead because he just decided not to come to work one day, and go to South America instead. Nobody could reach him, he just ghosted the company, his family, and the country. They had to terminate him because he never filled out any resignation paperwork.
And I won’t, for a variety of reasons, go into the guy down the hall who killed his wife. Suffice to say it is pretty nerve-wracking during the period between someone getting out on bail and the company getting a restraining order against them showing up at your office.
Dramatic. But I would say the most catastrophic cases of people being “summarily dismissed” — meaning let go outside of any layoff cycle — are those who are mild-mannered and reliably showing up to work. These people get fired for not doing their job, but also for going the extra mile and are negatively impacting others. And also the codebase.
I have only been involved with a few cases where people are straight-out fired for poor performance. The one that sticks in my mind was this guy, let’s call him Bob, who was a really friendly and I believe well-meaning engineer. 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.
Bob would get whatever you asked him to develop working, but in the fastest, easiest way possible. Which is rarely the best way. It was not my job at the time to supervise Bob, but the issue was, nobody else was doing it either. So he continued for some time developing a lot of code, which soon ran into big quality and maintenance issues.
Our management definitely gets a big chunk of blame for letting things get out of hand here; we were very lax about code reviews at the time. Bob meanwhile was busy importing huge dependency libraries into the code so he could modify the source, and creating Rube-Goldberg-esque chains of undecipherable control logic all through our (pretty large) codebase.
At some point, another senior engineer and I were tasked with reviewing his work, and we were shocked at the mess we found. Some companies might decide at this point to fire someone, but ours at least is very cautious on this front, and instead transitioned him to a “performance plan”, where he would continue to write code but had to make improvements in order to keep his job.
This is where things went south. Bob got very defensive about any feedback from us, and began to do things like check in code without sending any notice, claiming he ran regression tests when he had not, and agreeing to make changes to his code but then checking it in anyway, unchanged. Any attempts to get him to change his ways resulted in protests that the requestors were being “corporate suits”, intent on being bureaucratic.
My fellow engineer and I at this point begged our manager to remove him from responsibility for the code he had. We were not asking for him to be fired. Except we were. It took another four months though, during which Bob was assigned to work directly with our manager, because there had been claims he had been treated unfairly by me and other senior engineers in the group.
After a few more disasters my boss had to personally clean up, he finally had the sad duty of telling Bob it was his last day. In spite of everything, I really felt bad for Bob, because he was a nice guy. Just a bad coder. Maybe not even that, actually — I would say he too was in the wrong place versus his skill set and desires. I could easily see Bob doing something else, maybe teaching kids to code, or working on a research project or small code base that didn’t need a high level of software engineering to be done.
In the end, I would say the fault here for Bob being fired lies very much on the company, for putting him in a position he could not succeed at. And then, not correcting it until a lot of damage was done. We had problems in our code related to Bob’s work for years after. Years.
I don’t know what Bob is doing now, but in at least one other case like this that I have seen, the person shifted not only jobs but careers, and found something they could really succeed at. I’m hoping this was the case for Bob, too.
My boss for his part also was a really nice guy, and he felt bad about having to let Bob go. The afternoon after Bob left, I went into his office and thanked him for going through that difficult task. I have been a manager and it is largely a thankless job, so having someone show that there is a positive aspect to something like a firing is really appreciated. The truth is, in spite of Bob being a nice guy, he was putting the product, and our group, in jeopardy.
So if you find yourself having to do this unhappy task at some point, think about the people who are still working, and counting on you to keep them safe and productive. But also think about what went wrong, and how you ended up being a firer, in the first place.
The sunniest side of managing people after all is not having to say goodbye to them.
Next Time: Two victims. One killer. How icons of the past met their fate at the hands of an unassuming assailant: The American Standard Code for Information Interchange. What the hell am I talking about? Tune in next time for the answers to this crime story in: ASCII Double-Murder!
The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.
The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information,
I have had the misfortune of having had to terminate the same employee twice. Their performance was dismal, the team morale was lower because they saw that he just wasn't pulling his weight, and there was never improvement, only excuses. He was let go.
The same person moved to a new employer, and later on I ended up there too. And lo and behold, I became his supervisor again. And the same shenanigans were present, all the way down to the team being dismayed. I worked hard to give him the benefit of the doubt, to show that I wanted to help him improve, and in the end it was all just games and excuses. Round two. Not pleasant.
He thought I had it out for him. He was wrong. I have it out for lousy employees who don't respond to any assistance and make excuses and bring down morale. And in both cases, there was a palpable boost when that person was let go. Everyone on the team was relieved- it was like a weight had been lifted. Sometimes you really do have to look out for the rest of the team.
Glad to see you hopping on the hackaday.io train!