The Burden of Knowledge
Your best software developers are not the ones you turn to for everything. Your best are constantly distributing knowledge and removing themselves from being a key-man dependency. Your best have delegated sufficiently that they have freed themselves up to learn new skills.
It is a natural instinct for software developers to want to learn more, to consume all of the knowledge in their vicinity. Like a sponge growing heavier the more it soaks up, it feels good to become the owner of more knowledge. This applies to good software developers anyway; you can spot the bad developers a mile off. Bad developers have closed their minds off and don’t want to learn anything new. I know what I’d do with a sponge which couldn’t soak up anything new.
“Find the most talented person in the room, and if it’s not you, go stand next to them” — Harold Ramis
[paraphrased to be less sexist than the original which assumed the most talented person would be a man]
Developers start their careers fresh-faced (though perhaps not literally given all them damn hipsters) and ready to learn. Some think they know a lot already and others more wisely know they have much to learn. If you encounter any that thinks they know it all, these are the toxic ones to avoid. The best new developers know there is plenty of whitespace on their knowledge canvas and look to mentors to help fill those voids.
In most companies there are people who know what they are doing; they know shit. They seem to know a lot and seem to know something useful about everything. They are experts in their field. The best ones don’t call themselves that on their job title, of course, but are expert nevertheless.
When you are inexperienced and have questions you cannot yet answer, you look around for those that can help you answer them. You’ll find that people gravitate to the Solution Givers, the Experts, the Gurus. It is only natural to be impressed with these people. It is only natural to model yourself on them and want to be in that position yourself in the coming years.
Knowing stuff is addictive. You know stuff; you answer questions; you earn respect. It feels good to be revered and good to be needed. So you know what you want to be in 3 years; you want to be an expert in something. Let’s be honest: everybody has a sneaky desire to be indispensable. Good, little grasshopper, you have noble ambitions.
Your aim, however, should not be indispensability. Being indispensable may sound attractive as it seems like the obvious way to guarantee ongoing employment. After all, you couldn’t possibly fire an indispensable person right? Being indispensable comes with a hefty price attached; a price paid by both you and your employer.
Let’s fast forward on your career path to being indispensable. You are now indispensable; congratulations! Now that you’ve worked so hard to get here, you are going to want to protect your status.
How do you continue being indispensable? Well first off, you should stop all attempts to knowledge share with your team. Every little piece of information that you give them makes them more powerful and you more weak.
Secondly, you should cease all delegation. Empowering your team will only make you more easy to replace. You should seek all opportunities to do absolutely everything, no matter how much you hate doing each task.
Finally, and this is absolutely crucial, you should not view your team as collaborators; if these people know what you know they can take your job. Your team is now your enemy. Collaboration means sharing credit and potentially letting others have a meaningful say; a dangerous game to play in your position.
Does any of that sound enjoyable? Does that sound like the kind of culture you want to be a part of?
If you are the only person in your team who knows how to do something, that isn’t an achievement; that is a failure.
I spent the start of my career with the completely wrong attitude; I saw the experts around me and I wanted to be that. I wanted to know things that no one else did and took pride in every piece of unique knowledge I gained. Every new thing a medal to cherish.
It took me a while to realise that knowledge isn’t a badge of honour; knowledge is a rock that must forever be carried. Every new rock weighs you down; slows you down. You want to get on with actual development, right, the real work you signed up for? Well, sorry, but you are the only person that knows about this CI system so someone needs your time. You are the only person that knows how to configure the build system, so someone needs your time.
Every opportunity you had to share knowledge with the team and didn’t, that is a lost opportunity further down the line for you to do something new and exciting. You will be constantly weighed down by the things only you know.
You’re so busy doing everything that you don’t get time to do anything. What first attracted you to the job — the opportunities for learning new things, the development, the career progression — is now out of your reach and you’re busy doing things you don’t enjoy doing but didn’t want anyone else to do.
You tire, you burnout, you leave. The company just lost its indispensable expert. Worse still for you; you learn how little of your skills are actually transferrable to a new company and how much were specific to the last company. The company-specific skills make you valuable only to your current company and don’t translate well to others.
Development should be a social experience; it is a team game. Failure to treat it as social results in loneliness, isolation, key-man dependencies and knowledge gaps.
It is easy to change, however. Paired programming, code reviews, dedicated knowledge sharing sessions, delegation, documentation, mentoring and simply talking more all help to alleviate the bus factor in your teams and distribute knowledge.
Sharing knowledge is the mark of a professional software engineer. If you have unique knowledge which is crucial to the company, it is your duty, as a professional, to share it.