Hoarding Knowledge: sharing enhances productivity

Queuing

 If only one person on the team understands the database, then any work done by other programmers that affects the design of the database must wait up for the one competent individual.  Sometimes that queuing becomes significant and impedes the group. If the expert is not available, the work must wait, or else be done in an inexpert way.

Loss

Experts can go away.

Teams euphemistically refer to this phenomenon as the "bus number" of the team -- the number of people who, if they were hit and killed by a bus, would doom the entire project to failure.  A "bus number" of one is an unacceptable risk. A bus number of 10 represents a well-mitigated loss-of-knowledge risk.

Thankfully, few developers are hit by buses in the street. Instead, experts tend to be hired away by competitors or companies working in entirely unrelated industries. When this happens, teams do their best to muddle along, sometimes making poor decisions along the way and damaging the performance and/or accuracy of their software.

Ransom for Experts

In pathological cases, this reliance on a few experts allows the silo-ed expert to demand a very high wage and a high level of autonomy at the threat of leaving the company. The alternative would leave the company with without his specific expertise. This strategy is aspiration of some programmers we find today, who avoid teamwork for fear of losing their advantage over their employer.

Retaining your best experts makes sense, and they should be protected, but when it degrades to a kind of technical blackmail, companies are advised to mitigate their risk.

Efficiency of Scale

Companies have a tendency to assign work to the single worker who can complete it fastest because of his or her knowledge in a domain. This reinforces the bus number phenomenon and increases the risk of knowledge loss.

It also limits the ability of the rest of the team to acquire and develop necessary skills.

There is no efficiency of scale in software development. It is thinking work, not labor. It is produced through decisions, not machinery.  Batching up work does not make it more efficient, but less so. Specialization creates queuing and a reliance on individual effort instead of creating flow and accountability at the team level.

There is a dichotomy here. One one hand, a person who knows the domain and the technology best will be able to produce a given piece of work faster.  On the other hand, batching and queuing is waste (inventory and wait, in case you're keeping score) that makes the team slower and less predictable.

So now what?

The work system, in order to be efficient and productive, must be based on the idea of gathering and spreading information. It is not necessary that it preserves and exalts specialization among the members.

There will always be experts, and expertise is a real advantage. You should have the most expert developers you can possibly afford. You should give them rewarding and interesting (ie "hard") work and the ability to complete it well.

However, you don't want that expertise to be held exclusively in the head of one person.

Use techniques such as pair programming to spread knowledge, so that more "workaday" decisions can be competently made by many of the individuals on a team.

Having complimentary expertise and good knowledge transfer makes for better throughput for the team, even if some work must still be handled by experts.