Expertise concentrated in a single irreplaceable person is vulnerable to loss
Expertise concentrated in a single irreplaceable person is vulnerable to loss. It is not always possible or economical to duplicate all essential expertise, even when it is critical to the project. Yet the more people on the project that have unduplicated, critical expertise, the more likely it is that one of them will disappear one way or another while his expertise is still needed.
Each person on a project invests a few weeks, approximately, on learning the basics about the project. Much of this learning needs to be done up front, before any really productive work can be done. Thus everyone on a project has valued expertise, and can only be replaced at a cost. However, the expertise some people bring with them, of a business or technical domain, can be harder to replace. Once this expertise has been applied to the architecture or design of the project, this may be nearly impossible to replace. Even where the rationale has been fully documented, one needs the background knowledge to fully comprehend the rationale. This effect can happen in many areas of the project, and it takes a wise person to predict all potential cases in advance.
The generic problem of loss of essential expertise is addressed by ModerateTruckNumber, which advocates keeping the number of people whose expertise is irreplaceable to a minimum, and comments on techniques that reduce and increase ‘Truck Number’. A specific example of dealing with irreplaceable expertise is the LegendRole where there is no one person that can replace the ‘person that does everything’. In general, techniques for disseminating skills are of use. Those used to combat LackOfExpertise assume the recipient of the transferred skill is a comparative novice, but this need not be the case. Of these, ApprenticeShip may be the way to tackle the legend role, while DevelopingInPairs is always worth considering. An approach to aid in holding on to expertise is to offer a CompletionBonus at the end of a project. Consider also supporting a TechnicalCareerPath.
Modern, Agile methods tend to build skills transfer into the methodology. DevelopingInPairs is common, as are other forms of collaborative working. GeneralizingSpecialists are valued; expertise in general is valued. In this environment, it is unlikely that any expertise that gets used will not get transferred to some extent throughout the team. There are some potential loopholes, such as useful work that gets done by a single person, not paired up. CollectiveOwnership in particular, and the techniques needed to support it, work to ensure that Truck Number is not increased as the project progresses.