Knowledge hoarding makes you the single point of failure

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

This feature first appeared in the Fall 2017 issue of Certification Magazine. Click here to get your own print or digital copy.

Knowledge hoarding at your IT job causes more problems than it solves.One important truism I have learned in my 20 years of information technology (IT) professional experience is that knowledge hoarding decreases, not increases, job security. I never want to be the only person at my organization who knows how to perform certain key tasks. Let me tell you why, based on my professional experience.

What is knowledge hoarding?

Knowledge hoarding refers to the practice of learning important work-related tasks and procedures and keeping that knowledge to yourself. Typically, the root cause of this behavior is the mistaken belief that by being the only person at your company with privileged information, you are indispensable to the company.

The opposite of knowledge hoarding is knowledge sharing. An example of this dynamic is an IT professional who ensures that knowledge transfer is part of his or her workflow. After all, another truism that I’ve lived personally is that the best way to demonstrate my domain knowledge is to teach those concepts and skills to another person.

I want to be clear that sometimes knowledge hoarding is unintentional, or can happen to an IT professional by default. For example, my friend Dan worked as a systems administrator for a university institute.

Dan was the only IT professional in that 100-node network. Therefore, Dan held the “keys to the kingdom” of their daily IT operations. If a service broke down, it was Dan who had to restore service.

Dan was therefore valuable to his business, but that value negatively affected Dan’s work/life balance and he eventually left the institute. And you know what? The institute bore the brunt of unnecessary disruption and difficulty due to that immediate loss of institutional knowledge.

Another friend, Laila, took a more conscious approach to knowledge hoarding. Her business adopted a new line-of-business system, and Laila was tasked with “owning” the project. Own it she did — to the point where she resisted sharing product knowledge with the rest of the team.

Sure enough, Laila went on vacation and the application failed. The business experienced downtime as a result of the fact that nobody else in the IT department could address the problem while Laila was out of pocket.

Misconceptions that drive knowledge hoarding

I see three basic cognitive mistakes with intentional knowledge hoarding. The first is another IT truism born from my professional experience:

No one is indispensable to his or her employer.

Several years ago I worked and excelled in my role at a software company. Because of my productivity, the business valued me and I felt secure in my position. Financial tides turned, however, the business was acquired, and most of the staff laid off.

The new owners did not care how valuable the “legacy” employees were to the former company. Neither my stellar track record nor all the good will in the world would have saved my job.

Every day, I remind myself that I am expendable to my full-time employer and my consulting clients. This knowledge keeps me “on my toes” and forces me to:

● Always do my best work
● Treat each day as a gift
● Be proactive about my professional future
● Remain humble and open-minded

The second fundamental mistake is falling into the trap of a fairly common misperception:

My being the only person who knows how to undertake a particular administrative task improves my job security.

Based on both personal experience and the experience of students and friends, the opposite is true. In hoarding and protecting proprietary knowledge, you reduce the stability of your business’ IT infrastructure. You also erode goodwill among IT department team members.

Remember Laila and her overzealous project ownership? Do you think she generated much trust and teamwork in her knowledge hoarding of the company’s line-of-business application? Not likely.

Knowledge hoarding at your IT job causes more problems than it solves.The third fundamental mistake is succumbing to the following fearful notion:

Sharing key IT skills with colleagues gives them ammunition to put you out of a job.

I consider myself fortunate to have reached the point at which I’m not compelled by circumstance to take anyone’s job. Hence, I simply will not work at any company that has developed, either through explicit management support or simply by happenstance, a “dog-eat-dog” competitive atmosphere. As the saying goes, “Ain’t nobody got time for that!”

If you are earlier in your career and find yourself at a business in which team members obsess over how they can advance their position at others’ expense, then you are vulnerable. And, to be sure, colleagues often teach me a great deal about how not to act, both on the job and beyond.

My advice to you is to nevertheless stay true to the knowledge sharing ethic we’ve discussed and continue to learn as much as possible. Hoarding negatively impacts the hoarder far too often to be worth gaining any perceived “edge.”

How to work with a knowledge hoarder

Now let’s consider a situation in which you aren’t the one who’s gumming up the works — but a coworker’s knowledge hoarding is dragging you down. How can you deal with him or her to everyone’s benefit?

My first suggestion is to be careful how you approach the knowledge hoarder. In all likelihood, the individual operates from what productivity expert Stephen Covey calls a “scarcity mentality.” In other words, the hoarder’s actions are dictated by a low-trust, high-fear “kill or be killed” competitive perspective.

One strategy is to frame your information sharing request in terms that benefit the knowledge hoarder. For instance:

“Hey, Joe. You know, at the moment you’re the only one who knows how to use our new disk-to-cloud archiving solution. That’s cool, but I’d be happy to back you up so you don’t need to stress out on the weekends or when you’re on vacation. Would you mind mentoring me a bit in how it works?”

You could argue that the above approach is a Dale Carnegie-esque psychological tactic that appeals to the knowledge hoarder’s ego. That may be true, but isn’t professional communication and getting things done about diplomacy? A basic understanding of human nature goes a long way in professional interactions.

Alternatively, you could discuss the situation with your manager in a non-accusatory manner. Something like the following:

“Hi Sherry. I’m a bit uncomfortable that Joe is the only person on staff who can run the new archiving appliance. He’s capable, but as human as you or I. Would you mind asking Joe if he’d be willing to lead a ‘lunch-and-learn’ to get some of the rest of us up to speed?”

Once again, some psychology is at play. Joe may feel especially valued as a subject matter expert. Being asked to “show off” his knowledge both appeals to his ego and reduces the company’s exposure to a single point of failure.

More to the point, Joe’s refusal to participate in a “lunch-and-learn” activity would lead any conscientious manager to question Joe’s fitness for the position. Thus, the problem could be solved another way.

If you yourself are an IT manager, then you have a special responsibility to encourage collaboration and knowledge transfer, and to discourage knowledge hoarding. One nice idea is to champion a departmental knowledge management solution. You know, that word many IT pros and developers don’t want to say because they are too busy: documentation.

Bear in mind that, for many businesses, documentation isn’t merely a “nice to have” asset. It is required in employees’ service-level agreements (SLAs).

By linking job performance goals to the degree to which employees document knowledge, it is in everyone’s best interest to share knowledge as explicitly as possible, to everyone’s mutual benefit. More generally, job performance can explicitly be measured by the degree to which employees share their domain knowledge with colleagues, especially new hires.

How to be a knowledge sharer

Knowledge hoarding at your IT job causes more problems than it solves.At every job I’ve worked, my aim has always been to leave a positive legacy with that organization. Whether it be a beautifully documented data center diagram, neat-as-a-pin disaster recovery plans, or an e-mail trail of helpful assistance, I take the old Boy Scout injunction to “leave any area in better condition than you found it” to heart in the professional workplace.

The opposite of Stephen Covey’s “scarcity mentality” is the “abundance mentality,” in which you believe there are more than enough resources (including job roles, compensation, and prestige) to go around. Buying into this belief system lowers stress and helps you live moment by moment, more focused on what you can contribute to, rather than extract from, every situation.

Nobody is perfect. Professional life is about progress, not perfection. A more practical, “boots on the ground” motivation for your sharing knowledge is that you make your job easier. Now that Marvin and Lucy know how to manage the web server, you can finally start to take a look at understanding how that database cluster works after all!

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
Timothy Warner

ABOUT THE AUTHOR

Timothy L. Warner is an IT professional and technical trainer based in Nashville, Tenn. A computer enthusiast who authored his first BASIC program in 1981 on the Radio Shack TRS-80 Model III, Tim has worked in nearly every facet of IT, from systems administration and software architecture to technical writing and training. He can be reached via LinkedIn.

Posted in Jobs and Salary|

Comment:

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>