Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We must have all come across them - developers that have been around for ages and have a fantastic domain knowledge and yet they fail to share that knowledge with their team.

The team desperately needs to share the knowledge, but they can't seem to pry it out of the hoarder.

In what ways have teams successfully solved this problem?

share|improve this question

closed as off topic by Jim G., Mark Booth, Glenn Nelson, Walter, gnat Jan 25 '13 at 3:52

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Does management back you up? –  user1249 May 3 '11 at 19:18
    
An information hoarder just gathers information, hoarding does not mean they will not share. Maybe you mean to ask how to deal with a secretive, paranoid or protective person? –  asoundmove May 3 '11 at 21:37
    
actually no, an information hoarder is by definition someone that keeps information to themselves. therefore they are being protective of the information they already posess. –  Anonymous Type May 4 '11 at 0:33
    
@Thorbjorn - yes. Management can see the problem. But they are nervous about acting too brashly. –  Acentric May 4 '11 at 11:25
2  
@Anonymous Type - The question is about how to handle information bottle-necks that can occur on a development team and move forward. When I wrote it, I had assumed that all hoarders were trying to entrench themselves. From some of the posts, it is clear that this is not the case. And some very practical suggestions have been made for working with hoarders who lack the communications skills to remove the bottle neck. This perspective is important to avoid undue antagonism. This isn't a hoarder-hate club, I just wanted to know how to deal with a common development problem better :-) –  Acentric Jul 8 '11 at 0:03
show 8 more comments

13 Answers

up vote 31 down vote accepted

Remove code-ownership from the team. Spread the workload. Do code-reviews. Organise knowledge transfer sessions, wait a few sessions and then ask them to do a presentation on their area.

It is, of course, imperative that if you're not the manager then you have your manager's backing, but if everyone on a team is regularly sharing information, there are only so many excuses someone can come up with for not doing the same thing.

Also, his manager should sit down with him and explain that this doesn't threaten his job. Because that's why he's doing it.

It is a good thing for the individual not to be the font of all knowledge. It frees him to do other, more interesting, things.

share|improve this answer
7  
Depending on where you work and what you do, this could very well threaten your job. I'll bet a lot of people who had highly automatizable jobs are terrified their management will find out. Documentation is one way for people to figure out just how much brain power goes into a job, and makes it much easier to replace that person, willingly or no. –  l0b0 May 3 '11 at 13:54
1  
@l0b0 - If a company is successful, there is always something else to do, other projects on the backburner. I would hope that a manager believes in the company enough to sell it. –  pdr May 3 '11 at 14:29
    
@pdr - On this team, the team slogs its guts out on death-march projects and so the hoarder is always "too busy" to run handover sessions, produce docs etc. We tried to change his job to be exclusively a coach, but he'd direct what to do without teaching how or why. He managed to leave them as much in the dark as before. His version of pair-programming is him doing it all while a junior gets confused. It causes retention issues; but we can't lose the hoarder. I want to inspire him into being a great team lead that supports his team mates but he seems afraid to stick his neck out... –  Acentric May 3 '11 at 14:29
8  
@Xcaliburp - again, if you're focussing on him then he will resist. If you're making it team policy then he can only hold out so long. If he outright refuses then he must be fired. I've been in companies that lost someone indispensible and you know what? We survived. –  pdr May 3 '11 at 14:33
9  
Habitually doing anything detrimental to your team should be a reason to lose your job. –  JeffO May 3 '11 at 16:09
show 2 more comments

I believe that Gerald Weinberg was referring to this exact type of person when he commented in The Psychology of Computer Programming (paraphrased because I don't have the book in front of me), If you notice a programmer trying to make himself indispensable, fire him immediately. 25 years later when he reissued the book, he commented that no other piece of advice had gotten him as much thanks as this one.

So that is one solution.

share|improve this answer
1  
That is such an awesome quote, wish i had read this book already. –  Anonymous Type May 4 '11 at 0:35
    
Funny you say this.. I had the CEO of our Company tell me this today and he is from Switzerland (not the US). This seems to be an international feeling that if someone is trying to make themselves indispensable, then fire them. –  staticx May 4 '11 at 1:29
1  
It would be great if I could upvote more than one time. I would give you at least +20 for the quote. –  Jacek Prucia May 6 '11 at 9:12
add comment

Give them what they want - assign them all the maintenance work and tasks that only he/she has the knowledge to do.

No, they can't do new work because no-one else can do these other very important maintenance jobs.

Yes, the new hires are getting the fun work and playing with the shiny new toys but you must do these very difficult, high priority and boring tasks because they don't know any of the things you do.

Unless of course you want to show one of them how to do it....

share|improve this answer
    
+1: They want their job insecurity, let 'em have it. –  Steve Evers May 3 '11 at 15:35
1  
I agree with you in principle, but someone in charge needs to enforce the rules. This will not stand. –  JeffO May 3 '11 at 16:12
1  
In my experience with managers, programmers and managing, 'enforcing the rules' is a nice theory but(short of HR problems)difficult. With some people you can figure out in 5 seconds that you are trying to push wet string uphill. So if they want to do something a particular way then I make them responsible for their decision and turn all their excuses back on them(they can dream up the most amazing and incessant supply of excuses and it saves me thinking up rebuttals). And the rest of the team is not dragged down.When they realize they have dug themselves into a hole they start to turn around. –  james May 3 '11 at 17:23
    
I see this as a very passive aggressive solution. I think it would be much easier just to fire the person. Of course, reason with them first. Make sure they know the importance of the situation. But failing that, cut them loose. –  ConditionRacer Jan 24 '13 at 19:45
add comment

This reminds of this article from Rands in Repose.

I think you need to figure out why this guy is hoarding information. Job security (like the article about The Fez) is a big one. But so is insecurity. Or just that he likes this sort of work and wants it all to himself, or feels some intense sense of ownership about a particular area. Or is over-committed and hasn't seen a way of making the time.

Some of those issues can be solved by non-confrontational tricks:

  • get the guy some tasks that broaden his horizons and force him to hand off some work.
  • figure out where the insecurity is coming from and work on whatever actual issue is leading to the information hoarding.
  • point out to the guy that becoming too stuck in the rut as the only knowledge holder means that he will never be free of it and his career will be tightly coupled with the technology - and all technology eventually goes away.
  • figure out where the overcommitment is coming from and figure out what is most important

It's also worth it to join in in a few attempts at information solicitation - it can take two to tango, and you may not want to rule out the idea that there's enough intimidation going around that the question-askers are not asking good questions, thus exacerbating the problem. You may need to jump in and start backing things up and asking broader questions to get the guy moving. Also, having management there asking questions lends weight and importance to the information sharing activity - it's far harder to back away and avoid management. Usually with a few productive sessions underway, you can step out of the middle and say "you guys have this, you don't need me" and go on to the next problem.

Another key is do NOT let the guy dominate the work in the areas where he needs to share knowledge. Put someone else in charge of the work and make it clear that it's the information hoarder's job to share the knowledge. If he can't share then, you may need to have the brutal conversation where you explain that information sharing is a requirement on the team, not an option. That he's contributing to team schedule issues by not helping someone else learn.

share|improve this answer
1  
+1 for some really positive suggestions. –  Acentric May 4 '11 at 11:29
add comment

I'm not sure 'refuse' is often the right word, usually they're just too busy and don't have the spare time (or inclination, or social skills) to take lots of time off to explain the obvious (to them) to the n00bs.

The positive solution is to provide them with assistants - almost like spreading the work aroudn the team (but I guess there isn't much of a team if you have old-timers who know all about the system, and new guys who don't, given this setup its no wonder they don't want to communicate their precious skills and be replace with a younger, cheaper version!)(you wouldn't either - imagine if your manager came to you and asked you to communicate everything you know to the new outsourced team... hmm?)

I'd recommend the assistant works on a part of the system, and is expected to become an expert in it over time, the experienced dev will be expected to help them do their work in that small area. We've all been there anyway, "if you want to know how X works, forget the (obsolete or non-existent) documentation and talk to Jim".

Giving them an assistant not only confirms their position as experienced developers (which they are), and gives them an opportunity to relieve some of theior workload, but also will spread the knowledge over time. They become mentors or 'first-step to team lead' positions which should reassure them that their jobs are safe, and their experience is valued. If you can't do either of those things then you're failing as a manager.

Don't forget that if you have any kind of super-complx system (which you do, or the new guys should be able to figure it out by themselves) then knowledge-transfer is a very long process. There's no way anyone can sit down and get someone completely up to speed, at my place such a task would take 6 months minimum, and even then.. heck, I'm still learning stuff about what our product does and I've been here nearly a decade!

share|improve this answer
2  
@gbjbaanb - Thanks for the response. I think that part of the problem is that the hoarder is often skilled at coding or problem solving, but not skilled at explaining, coaching, or documenting. So the hoard accumlates unintentionally. I didn't mean "refuse" in the strong way - perhaps "resist" would have been better. We all recognise the need to share knowledge, but then a million and one reasons prevent it from happening. So your suggestion for an assistant could work. An ideal assistant would be a developer that was obsessed with documentation –  Acentric May 3 '11 at 14:39
    
@Xcaliburp - I disagree, you imply that the managers/other team members are always interested in all this "complex and difficult stuff". As a matter of fact most people don't care about documentation, Wikis, presentations. Obviously the species of the "information horder" does so. In some way I count myself into this category, for myself I document veery much. Occassionally I also do it for others, on shared folders/Wiki etc. But usually nobody is interested in that. ;) (Neither in my documentation nor documenting theirselves stuff...) –  Philip May 3 '11 at 17:33
1  
@Xcaliburp: good luck finding that 'dev who loves docco!' :) –  gbjbaanb May 3 '11 at 18:12
    
@Philip - when you're a junior dev, all you want to do is code. But as you gain seniority and become a team leader, you realize that most systems need lots of skilled people to collaborate and build a solution that no single person can do alone. So the best code is no longer the fastest, or smartest, but the simplest. Helping your team mates is the best way to build awesome software. I don't love writing documentation, but the thought of my "name" being cursed years hence for being the dev who built this big ball of mud is enough incentive to try to excel at that part of the job :-) –  Acentric May 4 '11 at 11:48
    
@Xcaliburp: Sure, but are you telling me that you would like to write tons of documentation that everybody can understand easily but nobody would read, not even you? ;) –  Philip May 5 '11 at 18:52
show 1 more comment

Make communication a commitment for each team member and assess them on this as part of the annual review.

Make sure that the team is recognized for achievements and not just individuals and ensure that all individuals know that team success is their priority, penalize them if they prevent the team succeeding.

Ensure there are no blocks to communication, make sure that there are process and systems for writing docs and sharing information; e.g. wikis, sharepoint sites, scheduled deliverables for design docs etc.

share|improve this answer
    
All well and good, but it doesn't prevent hoarding of information. The hoarder can still thrive in such an environment. And once somebody starts hoarding it is hard to penalize them since they hold the keys to valuable knowledge. –  edA-qa mort-ora-y May 3 '11 at 14:02
    
Then it is a management issue - all staff are aware that they should communicate, the "hoarder" will be penalized at review time (or by whatever process there is for career management). If you have other suggestions please feel free to add them. –  Steve Haigh May 3 '11 at 14:46
add comment

Make sure that all projects have at least two programmers that can work on it. This to make sure you always have a backup when someone leaves the firm.

We also started a wiki that contains all our database information. It's a very helpful way to quickly access or update information.

share|improve this answer
add comment

If the "hoarder" is truly not doing so on purpose, but is in fact just doing so due to something like lack of social skills, time commitments, etc. By all means get them an "assistant" or junior programmer specifically charged with easing the workload or helping extract the knowledge. Make it clear to both parties that this is the new persons purpose and involve the "hoarder" in the interview process. Management has to take a hand in this and make it possible for them to share their knowledge. That's the purpose of management, to remove obstacles and make it possible for workers to get work done.

share|improve this answer
5  
Forget the junior assistant. Get a seasoned, smart, knowledgeable person to work with him. They become colleages in the sense of the word, and person #2 writes the documentation. Remember, reward people's strength, don't punish their weakness. –  Christopher Mahan May 3 '11 at 17:55
    
@Christopher - well put. I've been in the situation of being an "unintentional hoarder", and I can tell you, trying to share this excess of specific knowledge with a junior is torture. It's gotta be someone experienced who can pick it up and digest it as easily as possible. –  Carson63000 May 3 '11 at 21:23
add comment

Who's the boss? Where does it end? You don't have to share information. You don't have to provide documentation. Continuously fail to get things done on time. Don't follow coding standards. Either someone in charge thinks this is important or they don't. There should be consequences. They are basically stealing from the company.

share|improve this answer
add comment

People who play the "I've got a secret game" are the absolute worst. These poeple tend to be insecure and create or flourish in crisis mode.

I would make them document every change or modification they do to the system. I would also make them provide a post mortem for each fix they developed to include...

  • what happened
  • why it happened
  • how to prevent it from happening
  • what other systems are vulnerable to the same bug

I would also make this person responsible for...

  • developing coding standards
  • maintaining a code library
share|improve this answer
add comment

In my experience, information hoarders can be classified into two types: Those who like to share their knowledge and get some sense of gratification from overtly helping others, like myself, and those who don't. Obviously.

Now, both sides have their reasons, and the one that likes to share their knowledge will rarely give it all out for typically the same reason that the one's who don't share their knowledge don't: they are trying to make the people around them better, and in my biased opinion, they are correct in doing so. (of course, you also have those who don't share knowledge simply to make themselves indispensable as well, and that is for the wrong reasons, and they should be done away with as they usually aren't that great to begin with)

After all, they had to delve deep into the arcane and esoteric seas in order to learn what they know, usually through pure experimentation, a liberal application of critical thinking, flashes of intuition and insight, and mystical rites involving various types of sacrificial livestock, and they came out the better for it. The line of thinking usually is that if the people around them are too lazy to or can't manage the same then they shouldn't even be doing the job to begin with, and they certainly aren't worthy of their knowledge. When those around them go through the same things that they had to, then they will come out a better programmer because they will have learned how to think well and solve complex problems and all that.

It's essentially forcing others to become better through strife. While plenty will be trod over and cast out, those who make it through the gauntlet will inevitably be far better than they would have if they became better through cooperation.

Now, as for getting them to share the information: you can't force them to do so. Trying to force them to will make them see you as either greedy, lazy, or too stupid to get there on your own, and they certainly aren't going to take pity on you in any of those cases. If someone higher up attempts to force them to do so they might become very nasty, turning all their considerable intelligence towards thwarting the individual, or even quit outright rather than betray their principles, after all, there are plenty of places that could use their skills and knowledge.

There's really only one way to get one of these that doesn't like to share their knowledge to willingly share their knowledge: become worthy of it. Usually having knowledge that they don't have is enough (but hard to do). Quid pro quo and all that. Otherwise, buy a couple of goats and dive on in.

share|improve this answer
    
@Phoenix - tell the guys to figure it out themselves and the journey will hone their skills? I guess every cloud has a silver lining ;-) i'd rather work somewhere where I got help and support than dog eat dog... –  Acentric May 4 '11 at 12:04
    
A cooperative team as a whole will probably be better than a single programmer who is really good. However, it only takes one or two really good programmers to turn a good team into a great one, even if they are simply utilizing what they know and not sharing it. Those who share will often omit bits, which will lead to problems that others will have to solve on their own. Giving it all away leads to a problem akin to learning versus memorizing. To truly learn something you must understand it in all it's complexities, rather than simply performing by rote as others have instructed. –  Phoenix May 4 '11 at 13:18
    
Also, I was just thinking: It's not really "dog eat dog" either, because they're not trying to foster competition between the individual programmers, instead, they're trying to foster competition between the programmers and knowledge itself. –  Phoenix May 4 '11 at 18:10
    
In traditional Australian Aboriginal culture, they didn't have writing, so instead they made information scarce and therefore valuable. Only the most respected elders could be entrusted with the responsibility of passing on the learning of the ages. Those that wanted information 1) had to be worthy of it, and 2) had to pay for it. This worked fine for about 30000 years and then some dudes with writing came along and the problem with sharing information perfectly was solved. What you describe sounds like the Aboriginal way which works - but wouldn't it be even better if they just wrote it down? –  Acentric May 5 '11 at 11:06
    
I guess what I mean is, we're not talking about getting rid of the good programmers with all of the knowledge, we want to keep them doing the good work that they do, and we also want the other programmers to be able to work effectively too. I see what you mean about the "dog eat dog" thing. You think the struggle for quality information is beneficial in the long run. It's just in my experience, recruits with any kind of talent or passion get so frustrated with how hard it is to do anything without information sharing that they quit pretty quickly and go work somewhere more supportive. –  Acentric May 5 '11 at 11:09
show 3 more comments

A lot depends on the type of knowledge involved; whether it's directly code, or business process oriented. Typically the latter is available elsewhere in the business...and can be acquired.

Secondly, there's an argument in ensuring that no developer gets to spend their entire working life on specific areas without sharing, so as to speak. So if you have a line manager who is responsible for doling out work, it's worth getting him to ensure that any business change requests come through him/her to be doled out without a specific developer becoming the first line of contact for a business process owner...This will hamper efforts on the part of a developer to become a guru.

share|improve this answer
add comment

Would it be in the best interests of both parties if the information hoarder was encouraged to find a company with a smaller size or even to start his or her own company? Perhaps the person would thrive in that smaller type of environment. (Am curious if anyone has ever tried this approach in the real world, as well.)

share|improve this answer
    
Whoever downvoted this, please be so courteous as to give a reason why; or maybe you are an information hoarder, too? –  mg1075 Jan 24 '13 at 17:47
    
I don't know the downvoter's reason, but I think the OP is more concerned with the team, and this doesn't appear to do anything for the team except remove the hoarder from it. –  Zachary Yates Jan 24 '13 at 18:32
    
@ZacharyYates - understood. My implicit assumption is that the action I suggested might ultimately help all parties involved in the situation, even thought that would mean the hoarder leaving the team. –  mg1075 Jan 24 '13 at 18:39
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.