Let's take a moment to parse this sentence carefully. It's true in two ways.
An employee that voluntarily shares his knowledge with his coworkers, keeps nothing solely in his head, but rather strives to document publicly the knowledge and know-how he acquires on the job, is the most precious employee the company has. He knows that if he quits tomorrow, he is totally replaceable, in the sense that there's nothing he would need to teach his replacement - it's all there in the open. No knowledge is permanently lost. This is the guy you never actually want to replace.
An employee that hoards knowledge and positions himself as the omniscient guru, to whom all must come for answers, should be the first one fired. Sometimes people do this unintentionally. They don't see a problem with having all the answers. That's why managers need to instill into them the following mantra: the stuff you keep in your head should only be a copy.
Let's call it brain cache.
What you bring to the table as an employee is your attitude, your ability to reason, make smart decisions and learn. Everything else is basically brain cache. A cache is a powerful thing, mind you. But if the problem of replacing an employee boils down to warming up a new brain cache - that's at least manageable.
p.s.
I'm trying a new format in this post: highlighting sentences for readers to quickly skim the text. The idea is that if you read only the highlighted text you should get a succinct version of the post, but still in sentences that make sense together and form a continuous and coherent version of the text on their own.
As an avid blog follower, I find myself practically always skimming posts - sometimes hundreds each day. I don't really read any blog post word-for-word unless I know for sure it's interesting enough. Especially wordy ones (like this one). There are just too many of them. I suspect I'm not the only one who does this. If you're reading this (and you're able to see the subtle HTML formatting I've applied), I'd be interested to hear you opinion. Is this actually helping you read, or is it just annoying?
10 comments:
It's annoying, but that's because I already highlight the text myself when I'm reading it :)
Love the highlight format!
My thoughts are that the title is too dramatic.
Yes it would be nice if everyone wrote in the wiki. It's just that it's such a pain in the ass to write stuff.
It's actually not as hard as you may think. Some documentation is explicit, like writing wiki pages, but other things you can do are much easier. e.g. once you form the habit of doing everything "publicly" basically anything you do is at least findable by someone else. Include future-you.
Examples:
1. Don't discuss project in email, at least not email addressed to private addresses of specific people. Use a mailing list for the project or some forum system for all your discussions and suddenly a lot of the stuff you may forget to document "properly" are already at least part of the archives. (private inboxes tend to disappear along with the employees attached to them)
2. Doing code reviews? Don't do them verbally, F2F. Use a system like ReviewBoard to document the process and make sure that anybody browsing the code in the future can also find the trail of breadcrumbs leading to your code-review discussions. That becomes quasi code-documentation.
3. Somebody's asking you for help doing something they weren't trained to do. You could do it for them, or, you could instead use this first-chance as the opportunity to document the how-to and send it to that person instead.
4. New guy arrives at the team. Do you spend days explaining stuff to him, only to get a "broken telephone" effect? Or do you instead advise him to read the history of your project's forum, document anything else he learns verbally and send you for review? This way you're making sure he understood it properly, and you also get updated docs.
Once these habits are formed and you become naturally "suspicious" of any ephemeral form of knowledge transfer, you're on the right path. No need to be a psycho about it - just be in the habit of thinking "what if I get asked this again? will we remember this discussion in 5 months time?".
Somehow the post is assuming the only reason to be considered irreplaceable can be the hoarded knowledge. I want to challenge this assumption.
One can (and should) be irreplaceable because of the skills, not knowledge.
Skills do not easily boil down to knowledge. Or you would be learning driving, dancing and marathon running from books. Skills are developed by years of practicing, and modeling learning as "warming up a cache" could lead to "interesting" failure modes.
vadimus, I believe the article is assuming that one can hire a similarly-skilled person within a reasonable amount of time.
That depends mostly on two things, I guess:
1. whether one needs a great engineer or an outlier. For the vast majority of projects, great engineers suffice.
2. location. If you live in an area with sufficiently many smart people, it shouldn't be a problem ... if you don't, different story.
Oh wow...by that logic you'd end up getting rid of people like Claude Shannon, Robert Noyce, Benoit Mandelbrot and John von Neumann. Welcome to Mediocristan !
Well, not everybody is lucky, like you, to have the late Von Neumann working in their team. The rest of us work with humans.
Besides, are you calling Mandelbrot a knowledge hoarded? The guy wrote great books. Definitely a keeper.
Vadim, the post does not assume what you state.
Assaf, the title says "fire the irreplaceable people" and then the post goes on discussing knowledge hoarders. If that's not an equal sign between them I don't know what is.
Sorry I have to break out the logic first-aid kit here, but the title doesn't say fire _only_ the knowledge hoarders. Hence no equivalence. The point of the article is that knowledge hoarding is a sufficient condition for firing someone. There may be other sufficient conditions. Additionally, it does not argue that knowledge hoarding is a necessary condition for firing someone.
Post a Comment