How I Got Myself FIRED as a Software Developer and How You Can Do It Too

— Hey
— Hi, yeah, so because of budget constraints we decided to replace you
— Uhm, ok
— Ok, thanks

This was the last conversation with the IT department manager. It was supposed to be a discussion to find the best solution for both parties (client company and me) to continue working together.

This was a problem because I was about to move back to my home country and the company didn’t do remote (even though I worked remotely for 2 months with no issues when I broke my leg).

In reality the conversation lasted 2 minutes in total, which means people had already decided what to do with me.

This outcome might seem normal, but the talks that I had with most stakeholders in my project were that they understood that they need me to continue working on the project, so remote could be an option.

Just so you understand the context, the project was still still on-going with important feature requests coming in every week. The team consisted at all times of a technical lead (me) and 1–2 junior-mid developers. The project was fullstack with React, NodeJS, Python.

90% of the project was done by me (based on amount of contributed commits and other parts of the project done by me). I'm mentioning this not to brag, but to make you understand my role.

With this information, here’s my experience on how to get you fired in no time:

1) Don’t sugarcoat anything

As I kept working for the client company as a freelancer I noticed behaviour patterns that are completely opposite from the ones I’m used to. Working in Eastern Europe (Latvia) and mostly with people from the same region, you develop what one could call a No-BS-policy. I can sum it up like this:

1. When I walk by people, I say “Hi” instead of chit-chat. Coffee breaks are for chit chat.
2. Don’t bother people at their desks without reason. Even better, send a message instead. There’s no guarantee that by disturbing someone, you didn’t just make them lose their focus and train of thoughts.
3. When a company meeting is not focused on my team, takes a lot of time and is just a typical BS meeting, I work on what’s important for the team and ultimately the company instead of using the meeting time pretending to be interested in something that brings 0 value. And let’s be honest, there are a ton of meetings that bring 0 value.
4. If something doesn’t work in the team or the company, speak out.
5. If your project owner/manager is not clear with the specifications of a task, tell him that. If you don’t understand his clarifications, point that out until it is crystal clear what exactly he means.
6. If some process doesn’t make sense, speak out.
7. If something impedes the progress of any team, speak out.

If you think that “This will definitely get me fired”, you’re right. Especially, in countries with much more sensitive people. In Europe, in my experience, the more you go to the west, the more sensitive people become.

2) Clearly show your unhappiness in a meeting with no clear agenda or action points

We’ve all been there. Let’s say there is confusion about the project you are in. So naturally someone organises a meeting that is supposed to clear things up. You go to the meeting with high hopes, that are swiftly destroyed by the generic aspect of the meeting. I noticed this to be especially true when managers, developers, testers are all together in such a meeting.

The reason for this cramming is “efficiency, efficiency, efficiency”. The only problem with this is that managers and developers are comparable to people from different countries without any common language. We just don’t understand things the same way. 

Even when it comes to questions, developers tend to have a harder time understanding what question has to be asked, while (and I’ve witnessed this numerous times) some managers will ask a question for the sake of asking a question.

What is more, sometimes they won’t have a question, but a comment that could only be compared to someone reading a book on grammar and walking around correcting people and feeling good for himself as the truth bearer. Ugh…

This might partially be explained by the fact that managers tend to want to shine and climb up the corporate ladder, while developers just want to program and don’t care about attention.

Such meetings make me uncontrollably display my distaste with the current situation I’m in.

3) Push back the deadlines

Inevitably there will be a discrepancy between what a manager expects and what a developer can do in the time period he’s given.

Can you do this in the next 15 minutes?

Can you do this by the end of the week? (a big feature with many unknowns some of which are completely out of my control)

Can you deliver today? (asked when you’re trying to get your foot out the door)

I’ve heard all of these. If you’re a software developer, probably so have you.

If I can, I simply answer that “I will get back to you in <INSERT TIME PERIOD>”. This allows you to:

1. Evaluate the projects capabilities for the requested feature.
2. Think of all the things you might have forgotten at the time when this was requested.
3. Think of whether or not the ongoing development tasks create any conflicts with the new feature.
4. And so on.

Each point can (and will) alter your estimation. I strongly suggest this kind of (friendly and diplomatic) pushback culture to be established early on. The fact that the aforementioned feature evaluation process benefits all stakeholders, must be clearly communicated.

What do you think was the actual time it took to finish that “Can you do this in the next 15 minutes?” request?

It took 5 hours.

You might think “But Roland, what you’re saying makes total sense”.

The only issue with this is that logic for some is like garlic for vampires.

A pushback propagates through every stakeholder back and forth. If someone from the top says “10 days” but I say “20 days” then I might have just messed up someone's plans for 10 extra days. Naturally, shooting the messenger is what ends up happening.

I’ve been this messenger many times.

I know what you might think. “Oh he’s just a ranting ex-employee”, “He’s incompetent at what he does”, “He’s just arrogant and entitled”.

I hear you. Might be that you’re right.

Thing is, this happened to me twice this year. Both times the same pattern. Nobody had any issue with me openly. Nobody complained about my technical skills, about my skills to work around problems, about my team lead skills. People actually praised my work and I knew that it brought value. Colleagues expressed genuine sadness and shock when I would announce that I’m leaving.

The “shock” part is interesting, though.

You see, in both companies the people, who were supposed to know about my contract termination, didn't.

In the first company the usual process of firing someone is by talking with the senior developers about the suspects performance, how it might be improved. There’s a lot of back and forth before a decision is made. A similar process is in the current company. However, on both occasions it was kinda of a “hush, hush” topic until it was delivered to me and without consulting with other developers.

Some got angry, some went to talk with the management, some got scared.

Essentially, the situation was political. It was an insanely complex battle of Ego versus Reason. Not just “their” ego and reason, but also mine.

I agree that in a different context, it would be much wiser to just take the hits, make a happy face and speak out at the right moment for the sake of my teammates, the project and the company. Because at the end of the day, employees in a company are on the same team and are striving towards a common goal in one way or another. Nobody wants to impede another teams progress if confronted about it.

But…

It’s hard. It’s hard to stand and look as some random guy takes all the credit while you sweated day and night. It’s hard to be pushed over the edge. It’s hard to look like you care when you think something is both stupid and useless. I get it.

However, these are not unsolvable problems and there are skills to solve or adapt to them. In my case I learned these skills from 2 books that I highly recommend:

1. Ego is the enemy by Ryan Holliday. It’s short, it’s full of examples of great people and most of all — it’s humbling af.
2. Extreme Ownership by Jocko Willink, Leif Babin. Taught me to take ownership of whatever is my part. To take ownership of failure of not clearly communicating everything down and up the chain of command.

If I become a CEO one day, these 2 books might be on the must-read list for the company staff.

In conclusion, it’s not that I think I’m infallible. Quite the opposite, during the past 2 years I feel like I finally passed the Daning-Kruger bell-curve and understood how much I have to learn in software development and life.

Also, I don’t consider managers in general a menace. Good managers are priceless and I’ve had ones in my previous job experiences. However, I can’t deny the feeling that competent and intelligent ones are the overwhelming minority. Same goes for some developers. There are plenty of arrogant and overconfident software engineers that think that only they bring value and everyone else is just living off their greatness.

They key to harmony between both sides is well established open communication and understanding each others inevitable differences. Learning each others habits and way of speaking and thinking is something that should be a part of the company training.

Easier said than done, right?

Thank you for reading and if you have had a similar experience or you think I’m just plain wrong, I’d love to hear your thoughts in the comments.