Knowledge withholding may seem obsolete in an age of competitive open source collaboration,
but the mindset lives on.
We’ve all seen this developer persona at some point in our careers: the rock star developer who is ever so reticent to share details of the work they do.
You ask them to share a diagram documenting system interactions. You get a few boxes and a couple stick figures. You stare at the diagram but can’t seem to make any sense of it.
You ask for more information and hear back, “It’s self-explanatory” or my favorite, “You know Java, don’t you? The code is self-documenting.”
You setup a meeting. They don’t show up, or if they do, they’re waiting to leave as soon as they enter.
For many, this can be attributed to personality traits or some animus borne from prejudice, or a mixture of both. That’s all quite understandable, excusable too in my arrogant opinion. I mean, what would we do without some of these colorful folks.
But when the motivation behind all that reticence is a sense of assured job security, that does not bode well for individual, team and team culture.
To think that by providing some detailed documentation and sharing a meaningful braindump of all you know about a system or systems, you have somehow become dispensable is a myth that needs busting. I’ve worked with several teams over the last few years, and without exception, I have found that individuals who are forthcoming about their knowledge are cherished.
Employers do not want to lose someone who makes their lives easy. And if they don’t appreciate that in you, then to be honest, they’re not really worth working for anyway.
- Write effective documentation you would find useful.
- Don’t hold anything back.
- Make your self dispensable.
That is what may truly make you indispensable, if at all.
