The “Irreplaceable Engineer”

In most teams I’ve worked with, there always was this one engineer the majority of the team considered “irreplaceable”. The one everyone assumed that one day when he’ll leave, the project will fail right away.

But, guess what? time passed and some of them did leave, but the projects — they continued as usual. Moreover, sometimes it was even better off without them.

The “Irreplaceable engineer” is a common team dysfunction I’ve seen over and over again during my career. Having an “irreplaceable engineer” on the team is a very bad habit that is really unhealthy for the team — let’s understand why.

Do you have an “irreplaceable engineer”?

First of all, let’s clarify what is that “irreplaceable engineer” I’m talking about. I’m referring to a situation in which one member of the team is considered crucial for the team to successfully operate and deliver. This usually expressed in this person being very knowledgeable about the system, he‘s probably one of the more senior engineers on the team and he was involved in designing the system and developing major parts of its core components. In many cases he was also part of the project from its early days. Usually he’s involved in every important discussion or change and his opinion is more than not the one that is eventually chosen — by either having the team agree on it or simply him going and implementing it.

So far — can you classify one of your team members as such? Stay tuned.

What’s so bad about that?

While having a very smart, knowledgeable and involved person on the team might sound like a dream come true — in this case, it often comes packed with a bunch of disadvantages.

1. “bus factor” = 1

The most common disadvantage is probably the “bus factor”.

According to Wikipedia:

“The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members. […] The “bus factor” is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel”

In a nutshell: a “bus factor” of 1 means if only 1 specific person “disappears”, the project dies. The lower the “bus factor” is, the less resilient your team is. What would happen if your “irreplaceable engineer” disappears?

Moreover, the less people you have that can solve a specific set of problems — the higher the chances you’ll face bottlenecks and get yourself blocked from moving forward. Let’s assume there are 2 major changes you want to introduce and both touch the very core of the system — if only your “irreplaceable engineer” can work on those areas or (not much better) must be involved in those tasks, it slows you down.

Takeaway: Teams should strive to share knowledge between their members and have interchangeable responsibilities, in order to reduce bottlenecks on the daily-basis and have the highest possible “bus factor” for the long-term.

2. Suppressed growth

Once, a colleague of mine told me something that demonstrates this point better than I could have ever phrase it. He said: “You see, this team, it seems as all the R in the R&D is done by this one person, while all the others are just doing the D”. For those of you who aren’t familiar with the term R&D, it stands for Research & Development.

I thought about this for a while, agreed, and was super sad for that team.

Imagine yourself in a team where all the interesting and challenging tasks (The “R”s) are being done by a single person, while you and the rest are just following the trail and have minimal influence and impact (The “D”s).

How would you learn something new? how would you grow? how would you be happy to arrive at work? You will probably not, it will be really hard for it to happen.

Takeaway: Teams should strive to provide each of its members the ground to grow, be challenged and feel appreciated. Yeah, some people might fail to do the work on the first time, still do it not so-great on the second time, yet you should support and mentor them until they finally succeed — and when it happens — congratulations, you have a stronger and healthier team.

3. Lack of ownership

How would you feel if all you do is controlled by someone else or considered less important? Many things I assume, but there’s one thing I’m sure you are not going to feel — ownership.

Lack of ownership is destructive.

First, it slows the project — if no one feels like they own the project, nobody is going to push it forward. Well, why should they — it’s not theirs so they don’t care as much. Worse than that, if no one feels accountable then major concerns or issues might never arise — because, well, it’s for that super-smart “irreplaceable engineer” to think about and handle.

Takeaway: Teams should strive to distribute work among its members and make them feel highly involved and accountable for it. There should rarely be an area in the system which is considered to be belong solely to one person, as then the others simply won’t care as much about it.

4. Them vs. us

What are teams, anyway?

According to Wikipedia:

“A team is a group of individuals working together to achieve their goal”

I would take it one step further and claim:

“A team is a group of individuals working together to achieve their goal, whereas the whole is greater than the sum of its parts”

Let me explain — given a group of individuals just working together towards a common goal, I don’t think this makes them a team, not in the sense we talk about here and not a great team in any sense. For me — they are just a group of individuals working together, that’s all. Real teams, teams I want to be part of — are much more than that.

Now, do you think a team controlled by an “irreplaceable engineer” where most of its members are just following, where “he decides and we do”, is a team greater than the sum of its parts? It’s hard for me to believe. There will always be “he” and “us”, the team will rarely jell and its members will end up just working together, nothing more.

Takeaway: Teams should strive to make their members feel belonging, contributing and relatively equal. A team with “Them vs. us” is usually not a welcoming team and surely not a high performing team, if a “team” at all.

That’s all for now, I really hope you enjoyed and learned something new!

Want to add something? Think differently? Please, share your thoughts in the comments below.

{Soft}ware is a blog featuring bite-sized content for the busy engineer on soft skills and everything non-tech. It was born because there’s a lot of great technical content out there, but I believe it takes more than great code to become a great engineer.

Passionate about the topic? Want to hear more? Follow us.