Being Precious
Being an Irreplaceable Engineer in a Team, or Even… in a Company?
Sounds cool, right?
If you think it’s not cool at all, I completely agree with you.
I’ve been in such a position for a while, and to some extent, it still persists. So now I’m doing everything I can to stop being such an employee as soon as possible.
What Does It Mean to Be Irreplaceable?
Remember that guy from The Phoenix Project? I think his name was Brent. The guy everyone went to for advice and overloaded with work whenever some subsystem broke down, etc.
I don’t recall if the book ever revealed how Brent felt about that experience at work; I don’t think it did. But I do remember one thing: Brent was insanely overloaded with work.
This overload is just one of the consequences of being irreplaceable.
Brent’s subjective experience probably wasn’t explored (or I just cant recall it. Sorry!) because a “Brent” could be quite different – he might enjoy all that attention and work, or the attention might mean nothing to him.
Such “Brent” might have intentionally monopolized a lot of knowledge, or the knowledge might have just landed on him because of poor team or company processes.
Being “Brent” sucks. And not just because of the constant overtime.
“Brent” never grows. The only thing he perfects is what he already knows and does well enough.
The most obvious “advantage” of being in such a position is job security – the protection from layoffs.
Okay, so are we afraid of being fired? Does that mean we’re not good enough engineers who can quite quickly find a new job?
Then what exactly is our precious value? What makes us irreplaceable?
Solely the knowledge and processes that are locked within ourselves. These might be applicable in other job positions, or they might be completely useless.
In any scenario, this so-called “bus factor” is a serious problem, and if it isn’t addressed, it means no one is doing anything to resolve it – neither “Brent” nor the management.
Why might the management ignore such a problem?
Well, without examining and reconstructing the specific case, it’s nearly impossible to make a good judgment.
But generally, if tasks are getting done, development is progressing, and the miracle engineer is still breathing – everything’s peachy, right ¯\(ツ)/¯
Alright, but why isn’t “Brent” doing anything?
It’s either because he hasn’t yet been overwhelmed with so much work that he’s on the verge of collapse, or he genuinely enjoys it.
This is the ultimate “Ego Factor.”
Fame, authority, popularity, power…
What a disgusting and dreadful thought stuff. Ew.
If you find yourself on a team where such a “Brent” is also your team lead – run, quit! Or get them fired!
There are often no long-term benefits from such a “bus driver”, only tails, traps and pitfalls.
Any team development, well, it’s probably obvious – assumes team activities, the distribution of knowledge, and possibly even the distribution of competencies, at least for gaining experience.
It seems that the latter actually depends heavily on the goals and nature of the team, but still applicable as an example, I guess.
And in the end, why should someone be working overtime unless they’re a masochistic no-lifer?
I hope none of my direct supervisors read these lines, but if they do, I hope they understand it correctly…
Anyway – I believe that we, as true engineers, should strive to work as little as possible!
Without sacrificing productivity, of course :)
How? Well, that’s a topic for another big post about the brain, consciousness, Pomodoros, and so on.
Actually, I’ve already written a bit about concentration here, but it’s very brief.
Back on track and more down to earth - workload should be distributed among team members as efficiently as possible, and knowledge should be distributed just as efficiently.
- Please – let’s help others with tasks, and they’ll help us with ours!
- Please – let’s write documentation, at least some! I’m not even talking about high-quality formal specifications – let’s at least leave meaningful comments! And we will have something where to peak!
- Please – let’s work less, so we have more time to study and improve our engineering skills, so we become not irreplaceable engineers, but true engineers who aren’t afraid to leave a project behind, knowing others can continue working on it and successfully develop it further.
Then, I believe, we will become – authentically precious engineers.