29

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?

sheikhjabootie
  • 849
  • 6
  • 12
  • 2
    Does management back you up? –  May 03 '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 03 '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 04 '11 at 00:33
  • @Thorbjorn - yes. Management can see the problem. But they are nervous about acting too brashly. – sheikhjabootie May 04 '11 at 11:25
  • @Anonymous Type, actually I persist: A hoarder, whether of information or otherwise is just a hoarder, i.e. someone who collects information (or things). A hoarder may also have other characteristics, but in this case the wrong characteristic is highlighted and clouds the meaning. Unfortunately there aren't any good definitions available online, but there are a few articles and nothing I saw indicates that hoarding equates being secretive and keep everybody out. So while hoarders, of course try to retain ownership of their things (the whole point) they do not necessarily hide them. – asoundmove May 06 '11 at 05:03
  • I had a job once where I had all the information but no one to give it to. It was most frustrating. – Matt Ellen May 06 '11 at 08:12
  • @asoundmove - I agree with you. I think my original question was tainted with a negative assumption about the motives of the hoarder. Some other posts have highlighted many ways in which a hoarder can become such without any kind of selfishness intention. I've edited the question to make it more balanced. in particular I've replaced the word "refuse" with the word "fail". Sorry if makes your comments appear out of context. – sheikhjabootie May 06 '11 at 08:13
  • @asoundmove: huh? take alook at the average item hoarder, do they hoard their stuff out on the side of the street where others are free to browse/pick it up, or do they keep it all inside their house even though there is no room to move? I don't think you need a wikipedia defintion to help you understand what I am saying. If they didn't hide them (in this case information) what exactly would be the point of "hoarding"? – Anonymous Type Jul 07 '11 at 00:36
  • @Anonymous Type - I think @asoundmove's point is that the hoarding itself is not necessarily intentional. The hoarder discovers knowledge in the course of his work but he doesn't necessarily have the skills to pass the knowledge on. – sheikhjabootie Jul 07 '11 at 00:59
  • @CodingHero & @Anonymous Type: my point is to not judge whether a hoarder is secretive or not by their hoarding nature. Hoarding is about collecting information or things. Some collectors like to proudly share for others to see (while retaining ownership), other collectors like to keep things to themselves. Not all are the same. – asoundmove Jul 07 '11 at 03:10
  • ok so now you are talking about a collector of information? that is not the same thing as a hoarder. Please don't generalise and confuse the definitions of the two words just to try and prove your point. – Anonymous Type Jul 07 '11 at 06:17
  • 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 :-) – sheikhjabootie Jul 08 '11 at 00:03
  • @codingHero : Fair enough, point taken. I also did learn some useful stuff from the tips given here. – Anonymous Type Jul 12 '11 at 01:29

13 Answers13

35

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.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • 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 03 '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 03 '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... – sheikhjabootie May 03 '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 03 '11 at 14:33
  • @pdr - The team/product/company would survive his departure, but it would be a real set back. I'd like to avoid it if we can. The team policy thing is tricky because there always seems to be something else that is more important that stops the information handover from taking place. A critical issue, looming deadline, etc. The team is always fire-fighting and the other team members aren't able to help because they are so in the dark. Somehow he has to want to share the knowledge without alienating him; there needs to be a positive incentive. – sheikhjabootie May 03 '11 at 14:48
  • @l0b0: Ensuring a person's job security for that type of position only means that they'll end up doing the same crap day-in and day-out. Someone happy to do that needs to be gone anyway - they'll never get any better. – Steven Evers May 03 '11 at 15:34
  • 9
    Habitually doing anything detrimental to your team should be a reason to lose your job. – JeffO May 03 '11 at 16:09
32

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.

Apalala
  • 2,283
  • 13
  • 19
btilly
  • 18,250
  • 1
  • 49
  • 75
  • 1
    That is such an awesome quote, wish i had read this book already. – Anonymous Type May 04 '11 at 00: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. – Engineer2021 May 04 '11 at 01: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 06 '11 at 09:12
11

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....

jqa
  • 1,410
  • 10
  • 13
  • 1
    I agree with you in principle, but someone in charge needs to enforce the rules. This will not stand. – JeffO May 03 '11 at 16:12
  • 2
    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. – jqa May 03 '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
10

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.

bethlakshmi
  • 7,625
  • 1
  • 26
  • 35
9

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!

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • 3
    @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 – sheikhjabootie May 03 '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 03 '11 at 17:33
  • 1
    @Xcaliburp: good luck finding that 'dev who loves docco!' :) – gbjbaanb May 03 '11 at 18:12
  • 1
    @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 :-) – sheikhjabootie May 04 '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 05 '11 at 18:52
  • @Philip - I agree that if nobody will read it then it's pointless to write documents. But I'm struggling to think of when that can occur. If the work you are doing is likely to outlast your stint in that job, then someone besides you must maintain it. I've found that adding design documents, and configuration tutorials to our development wiki has really helped free me up as a bottleneck on my team. Sure staff prefer to just ask me things, but if I refer them to the wiki enough, they break the bad habits. – sheikhjabootie May 05 '11 at 23:45
4

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.

Steve
  • 5,264
  • 1
  • 21
  • 27
  • 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 03 '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 May 03 '11 at 14:46
4

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.

Carra
  • 4,261
  • 24
  • 28
3

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.

John Gaines Jr.
  • 1,116
  • 6
  • 8
  • 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 03 '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 03 '11 at 21:23
3

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.

Phoenix
  • 131
  • 4
  • @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... – sheikhjabootie May 04 '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 04 '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 04 '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? – sheikhjabootie May 05 '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. – sheikhjabootie May 05 '11 at 11:09
  • Hehe, that still sounds like the way we do it today. Try getting into MIT, Harvard, Oxford, etc. with a 2.0 GPA and no giant bags of money. (or a 4.0 GPA and no giant bags of money. Come to think of it, the giant bags of money seem to solve everything) – Phoenix May 05 '11 at 12:09
  • Yeah - if our budget was augmented with a few giant bags of money our retention issues would be solved ;-) – sheikhjabootie May 05 '11 at 23:49
  • @Phoenix - the other thing is the different needs of developers at different points in their careers. An experienced senior developer doesn't want/need to be micro-managed by his team leader. They just need to touch base every so often. They're quite capable of delving into a complex system and figuring it out. And they know when to escalate things if they get stuck. On the other hand a junior will quickly get out of his depth and will worry about looking stupid if he asks for help. So you have to intervene and support juniors much more. And it's the juniors that really suffer from hoarders. – sheikhjabootie May 07 '11 at 00:44
  • +1 for this answer, I don't know why it is still sitting way at the bottom; two of the hardest things to teach are critical thinking and problem solving. Unless the person involved wrote the book, so to speak, they surely learned the information from somewhere. Why can't others? – EKW Oct 21 '15 at 16:34
2

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
2

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
Michael Riley - AKA Gunny
  • 4,928
  • 3
  • 29
  • 44
1

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.

temptar
  • 2,756
  • 2
  • 23
  • 21
-2

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.)

mg1075
  • 597
  • 1
  • 5
  • 9
  • 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
  • 1
    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