They call him the fireman. Oh sure, he probably has a title like "system's administrator" or "lead technician" or even lead developer, but his real job is putting out fires. Let's call him Bob. There's "Networking Bob" and "SysAdmin Bob" and "Developer Bob" etc. When the server goes down, call Networking Bob. The server needs an upgrade - "SysAdmin Bob's the guy. If a backup needs restoring, code needs tweaking, some work-around needs to be worked around, some proprietary Application is failing.... there's a Bob that can handle it. He'll come in with fire hose blazing and takes care of business. If a vendor needs placating.... ok... so call Sally, Bob's abrasive - but he does get the job done. The CIO thinks he worth 3 regular employees. Shouldn't everybody have a Bob? Well...
Bob has a couple of problems that are troubling. Like most people, he enjoys the little boost he gets from people treating him like the Amazing Kreskin. He loves those oohs and ahs when he can solve a problem that everyone else finds puzzling. It's nice to be the "go to" guy. Sure, it means he gets called in whenever anything goes wrong, but aside from interrupting his 15 month long game of WOW in his Mom's Twinkie-wrapper laden basement, he prefers to be on the job anyway. Being the "go to" guy gives you a competitive advantage. It means you are indispensable. Bob goes on vacation and things go haywire because no one knows what Bob knows.
This means that Bob is not just the "go to" guy. He's also the "go-to-and-leave-it-with-him" guy. He can do it faster if he's left alone. When a crisis emerges Bob isn't the team leader of a group who are all working to solve the problem, he's the tragic lone figure at his post - well, not so much a post... maybe a rack. Anyway, he's the lone ranger charging in, changing code, re-writing config files, editing data directly, using repair utilities and generally playing the role of manic Genie with glasses and a pocket protector. And he likes to "go it alone". He's not much of a collaborator. Being collegial means the accolades are evenly distributed instead of belonging soley to him.
Bob fixes problems fast and does not document the fixes. There's no post fix review of what went wrong and how he repaired it. Bob provides enough of an explanation to satisfy the non-technical Boss who needs it. Beyond that, Bob's work is undocumented by design. Surprising eh? I bet you thought that a lack of documentation was a result of time management issues. Nope - not in this case. Nothing Bob does is written down - at least not in a way that can make it repeatable - and Bob likes it that way. Remember, he's the compendium of knowledge at your company. He want to be sure he stays the "go to" guy.
Bob also gets to set his own agenda - at least some of it. Because he is such a productive employee Bob can pick and choose the stuff that receives priority. In fact, people and departments become supplicants to Bob. They need him. They need not just his skills, but also his favor if they want things done. They know that Bob can even circumvent company policy with impunity to accomplish certain tasks. The boss knows in the back of his mind, that if he ever loses bob, it will take him 2 months to recover from the loss of knowledge.
So, you think Bob is a figment of my fertile imagination eh? In the past 2 years I have on 2 different occasions been hired to go into a small to medium size company (less than 20 servers) and "clean up" after Bob (not "the" Bob - but certainly "a" Bob). The task was simply to figure out all the stuff he did and try and document it or tell the company what to do about it.
Recently, a 3rd situation arose where a "developer Bob" built a proprietary application that became the basis for a companie's business "Developer Bob" would bring in the install files on a CD and install it in the company offices, then leave - with the CD in hand. The application has hard coded links and database calls to external systems and no one really knows how it works. When changes are needed they simply have to call "developer Bob" and live with whatever timeframe and cost he dictates. Because he's become increasingly difficult to work with they would like to leave "developer Bob" - but they are frightened that to do so would mean jumping out of the frying pan and into the fire.
My Advice? When you see a Bob developing in your company, work hard to make sure he documents everything. Don't let him be the lone ranger. If he insists or becomes intractable, fire his butt and replace him with 2 eager college kids at half his wages. It will be more difficult in the short run, but you'll thank me later.