Take the 2-minute tour ×

I have a few programmers under me, they are all doing very great and very smart obviously. Thank you very much.

But the problem is that each and every one of them is responsible for one core area, which no one else on the team have foggiest idea on what it is. This means that if anyone of them is taken out, my company as a business is dead because they aren't replaceable.

I'm thinking about bringing in new programmers to cover them, just in case they are hit by a bus, or resign or whatever. But I afraid that

  1. The old programmers might actively resist the idea of knowledge transfer, fearing that a backup might reduce their value.
  2. I don't have a system to facilitate technology transfer between different developers, so even if I ask them to do it, I've no assurance that they will do it properly.

My question is,

  1. How to put it to the old programmers in such they would agree
  2. What are systems that you use, in order to facilitate this kind of "backup"? I can understand that you can do code review, but is there a simple way to conduct this? I think we are not ready for a full blown, check-in by check-in code review.
share|improve this question
You can always mention that having redundancy in a given area allows you to KEEP that area instead of having to look for another area. This goes for programming knowledge too so it actually keeps their jobs SAFER that others know what they know. –  user1249 Mar 11 '11 at 10:26
+1 for the title –  Craige Mar 11 '11 at 14:30
At one job, we had an office lottery pool. The manager insisted on joining, on the grounds that he didn't want to be stuck there if we all bailed. –  David Thornley Mar 11 '11 at 14:39
Jeff? Is that you! Dammit you better not be trying to kill us off! –  Glenn Nelson Mar 11 '11 at 15:00
Why in the world was the title changed - "hit by a bus" is an idea so widely known, this topic has its own name and Wikipedia article: Bus number. You don't hear people talking about their team's "lottery number". –  NickC Mar 11 '11 at 21:22
show 4 more comments

13 Answers

up vote 16 down vote accepted


Present the problem openly to them, of course in such a way that they don't see it as a threat, rather an opportunity to make the team and project work better. E.g. "I would like to have other people know what you know in case you get fired" is obviously a wrong approach :-) "I would like to ensure the smooth working of the project even if some of you goes on holiday or gets ill" is much better.

Usually the developers themselves experience the problems themselves every time some of them is on holiday and they need to cover for him/her. Moreover, good developers feel responsibility for the project they are working on, so they will probably agree with this idea. Still, give them time to discuss and (hopefully) commit to the idea. Also, allow them to have their say on how and with whom to share their knowledge inside the team. It may turn out Joe feels OK to work (and share his knowledge) with Jim, but not with Jack etc.


In our team, apart from code/design reviews, we use

  • Rotation of tasks and responsibility areas between team members (each of us has his main areas of responsibility, but every now and then, we do tasks in an area better known by another team member)
  • Face-to-face knowledge transfer sessions (usually when the above tasks require, but also before someone is leaving the team)
  • Team/project wiki

Code review in itself may not be enough as in a lot of areas there is typically a lot more for a developer to know than what is directly readable from code. In other words, there is the domain model as well. You can read what the code actually does, but without the model, you won't know why.

share|improve this answer
Team/project wiki, can you elaborate on this? And also, face-to-face knowledge transfer sessions, do you hold this kind of session regularly on a fix hour? –  Graviton Mar 11 '11 at 8:30
@Graviton, we strive to document the design and implementation of our (legacy) system on the project wiki. This is easier to edit and update (by any team member) then e.g. separate Word docs, and also allows free links between any of the pages. Knowledge transfers we do on when needed, on a specific tool or part of the project. –  Péter Török Mar 11 '11 at 8:35
Knowledge transfers we do on when needed, that's probably during the time a staff resigns? Won't the time needed for this is a bit too short? –  Graviton Mar 11 '11 at 8:45
@Graviton, no, what I meant is whenever some of us is assigned a task on an area better known by someone else. (I will add this to the list above, as this is in fact an excellent way to create "knowledge backup".) –  Péter Török Mar 11 '11 at 8:53
add comment

One way to motivate them to share their knowledge would be to ask them to make a short presentation on their work to other people. Programmers normally take great pride in their work, and this would be a chance to show it off. A presentation is a good opportunity to make them show some of the quirks rarely known by outsiders.

Also, why not just be open about it and tell everyone that you all need to come up with a scheme of knowledge sharing in case someone is hit by a bus. I don't see this as unreasonable. It's happening in my company right now, and although some are defensive about it, they know it needs to be done.

Maybe they could work in pairs on some things, if they are of inquisitive nature, there should be no problem.

share|improve this answer
+1 for working in pairs. –  Péter Török Mar 11 '11 at 9:18
add comment

Getting the internal documentation of the software up-to-date should be the first step, before you start hiring new people. Sure, it means that your valuable programmers will spend some time with Office and UML tools instead of the IDE, but I think it's worth it in any case.

Once you have a current documentation, you can let your programmers cross-check it to make sure everyone understands what the others have written. Still no need for new people.

Then you can consider hiring new people. Or not, depending on the workload in your company.

share|improve this answer
@ammoQ, not too sure whether this scales; what happens after you employ new people, are you going to draw the UML again? And what if the design architecture changes? Do you have a system to review those? –  Graviton Mar 11 '11 at 9:26
@Graviton: New people just read the documentation written by the existing staff. No need to draw the UML diagrams again. If the architecture changes, you have to adopt the documentation. Yeah, that sucks, I know. But there are UML tools to help you with that, they read the source code and generate class diagrams and stuff. –  user281377 Mar 11 '11 at 9:56
BTW, how do you think the new staff will learn the internals of the software when there is nothing but the source code to learn from and the existing programmers to ask? –  user281377 Mar 11 '11 at 10:02
@ammoQ, I don't know; if I knew I wouldn't have to ask the question. –  Graviton Mar 11 '11 at 10:54
@oosterwal, luckily we can use a standard build management system (Maven) now, so there is only a minimal need for documenting the details of the build process. (And if a team member adds new modules without updating the build config, all of us gets a mail from the Continuous Integration server in 5 minutes, telling that the build is broken, and by whom.) But yes, back when I wrote custom scripts to automate the builds & releases, I documented them well. –  Péter Török Mar 11 '11 at 16:41
show 5 more comments

If you're in a large company you can call HR and talk about this issue. Believe me, the guys in accounting have the same problem if key personnel is hit by a bus. The marketing folks will also have a lot of trouble if a key salesman becomes a zombie in the middle of important negotiations - it happens often, or so I've been told.

I believe the correct HR language for this is Succession planning. Your company may have already policy and frameworks for dealing with this.

share|improve this answer
add comment

One place that I worked at had the same problem. What they did was hire one junior developer to work with each Senior developer. They created small teams of 2 that worked on projects together. Every few months or projects they would rotate the junior developers between the teams. This way the Senior developers remained the subject matter experts but the junior developers began to get a good grasp of all the systems and how they worked together. Plus with the team size doubling projects got done faster.

For bigger projects that came up Senior developers were sometimes asked to act as a Junior developer on another part of the system for the length of a project so that they could start to learn the other systems.

The key there was to respect the knowledge and seniority of the existing developers while still expanding and growing the team. It was a slow process but over time worked just fine.

share|improve this answer
add comment

One of the things that makes successful open source projects so successful is the lack of code "ownership". By that I mean that no-one is the sole maintainer of an area of the application--anyone can and is encouraged to make contributions to any part of the application. It's something I believe strongly in.

What you want to do is to explain that the way things are is actually hurting the team you have now. Here are the points you want to get across, and preferably in this order:

  • I can't free you to work on other cool stuff coming down the pike if you are the only one who knows how this works.
  • We want you to be able to take a good vacation, but can't afford to because no-one else can do what you do.
  • It's an unpleasant fact that people change jobs because they are unsatisfied with their current position, we don't want to lose you because you feel trapped by the area you are working in.

On a personal note, I have had to deal with a co-worker passing away. While there weren't any information silos, the loss still hit hard. The chances of this happening are far lower than the third bullet point above.

Once you've put your case out there, enlist their help for ideas on how to rectify the problem. Do come with your own of course. Their ideas will help them realize that they are part of a team, and they are needed for more than just their area of expertise. It might be that Jane may have an interest in what Joe is doing, but feels a bit intimidated by it. Knowing that can help make the knowledge transfer more fun. Some of the things you'll want to do are:

  • Cross-train the current team. You might loose a little efficiency in the short term, but there may be some lessons learned in one corner of the app that can be applied to other parts of the app. Have Jane and Joe work together on each other's project for a while.
  • Foster a culture of knowledge sharing. A company I worked for had a "brown bag tech talk" program. Anyone could present on any approved topic (usually introducing technology or software processes). The company catered lunch and the presenter got a couple hundred dollars for their effort.
  • Mentoring should be a way of life. The purpose of mentoring other people is to free you to do new things, and makes you even more valuable to the company.
  • Find ways to cross the information silo boundaries without pulling rank. The more fun you make it, the less threatening it will be. If the people on your team are as good as you say, they probably aren't completely happy with the way things are. You'll have to be the judge of whether the team can handle it, but you can have a "let's pick on so-and-so" week. Always start with yourself here. The idea is to get everyone's eyes on what "so-and-so"'s responsibilities are, and how they can solve the problems they're having better. As long as you start with your neck on the line first, they'll get the idea that no-one is out to take their job

In general, try to impress on them that you want to make the work more enjoyable, and you need their help to do it.

share|improve this answer
add comment

Interns might be a good idea, they'll be direct subordinates to current developers, so they won't feel threatened.

As the company grows, you'll be needing both old developers AND those who made it after their internship.

I think this might work.

share|improve this answer
add comment

Generally, when some manager suddenly starts caring about documentation and succession planning, it is a strong warning sign that the programmers are about to be fired or laid off. It is such a departure from typical managerial behavior and concerns that it sets off all kinds of warning signals in programmers.

Everyone is told to document all their procedures and processes

Level 3 of "Warning Signs Of Corporate Doom".

As an alternative, one essay suggests that we would encourage a culture of "Up or Out" although the counterargument is that very few companies have a technical career ladder that in any way resembles the financial and power spectrum that the (mis)managerial career ladder contains.

share|improve this answer
I disagree. A company's worth is highly dependent on Intellectual Property (IP). This includes patents, processes, and all internal documentation. An employee who is unwilling to share their secret knowledge by documenting it is not worth the paper their secret knowledge is written on. An employee's secret knowledge does not add tangible value to a company. –  oosterwal Mar 11 '11 at 15:03
@oosterwol - being able to assemble and manage a productive development team is a much better predictor of valuation. Saying you have great documentation is like saying you have great source control. Of course they are necessary, but it won't differentiate you from the competition. –  JeffO Mar 11 '11 at 16:00
@Jeff O: Documentation won't differentiate you from your competition today because all the IP knowledge is in the heads of the current developers. In five years, when all the current developers have moved on to companies that do value documentation, the new developers will struggle trying to maintain the old code and failing to implement ideas that were proven to be bad in the past, but never documented. –  oosterwal Mar 11 '11 at 16:31
add comment

Building on the concept of full documentation that @ammoQ started in his answer...

A good manager works to develop the skills of their direct reports so that any one of the reports could replace them. Make your developers understand that an employee who provides complete transparency of their job is more valuable than one who keeps all their work secret and hidden. If the 'secret' developer' died today it would be a huge cost liability to the company to regain that lost knowledge. If the 'full-disclosure' employee died today, the company would still be at a loss, but it would be less devastating. Therefore, the 'full-disclosure' employee has more value.

Any employee who tries to keep hidden knowledge in order to make themselves immune to being fired also makes themselves immune to a promotion. You cannot move a developer into a more challenging and rewarding position if there is no one to complete the mundane tasks they are burdened with today. If the mundane tasks are fully documented and fully disclosed than you can hire a new junior-developer to fill in and promote the previous developer to a more senior position.

This means that you, too, need to document what you do and provide training to each of your direct reports. That way, if you died today, one of them could fill in for you until a full-time replacement was found.

share|improve this answer
Could you provide a link to one document on the Internet that demonstrates a specification written well enough to build an entire application of substantial size? I think this falls under Urban Myth. –  JeffO Mar 11 '11 at 15:42
@Jeff O: You are right--there is no single document that is complete enough to describe a complete system of substantial size. The idea that you could describe such a system in a single document is the result of poor project management and a history of poorly written specifications. A substantial system must be specified with a hierarchical series of documents. The root document provides a high-level layout of the system and links to its child documents. Each child document provides additional information until the end-node documents that specify only a single tangible feature. –  oosterwal Mar 11 '11 at 16:02
add comment

Before I would start bringing in new programmer's, I'd ask each of them to help create their own documented legacy.

Either with a wiki, or a 3-ring bible of documents about every aspect of their job.

Or if you want really detailed and thorough documentation, hire a technical writer, to interview each programmer and then create a documentation of everything, everyone does, daily, weekly, monthly, yearly.

Then make a wiki version of it, that your programmer's can update/edit/participate/comment on.

Then you have a system that will grow in time, and be the improved learning curve for any new programmer's.

Also honestly it is not wise to have programmer's just stuck in one core area, it really pay's to cross train, cross core work.

Then you can use your existing personnel, when 1 person takes a vacation or something like that.

share|improve this answer
add comment

Every time one of your programmers is off sick, phone him up repeatedly with questions and problems.

Every time one of your programmers is on holidays, phone him up repeatedly with questions and problems.

They'll soon realize that it's better for them as well as the company to not have single people responsible for core areas.

share|improve this answer
add comment

Nobody wants to get hit by the bus, but they also don't want to have to take over someone else's project on short notice and maintain their project as well. Then everyone runs the risk of going out of business.

If you're developing in silos, you need to start moving people from one project to another. Start off with documentation, code review or fixing a simple bug. Any small acts of code protection/territoriality should be addressed before this gets too far out of hand.

Having a lone specialist on a piece of your code is an efficiency illusion.

Anyone ever want to go on vacation?

share|improve this answer
add comment

I've had many more companies go under due to stupid mistakes by management. You won't crash and burn if one or two engineers leave, you'll just have to work a bit harder for a while. Sheesh, I manage an offshore team that loses someone every quarter. Start moving the tasks around. Today.

share|improve this answer
add comment

Your Answer


