The required expertise is not available


Expertise is a limited resource, and what there is available may be stretched too far.


In any new project there are likely to be some areas of skill and knowledge not covered yet by any of the available staff.  As long as these are relatively small, then learning on the job may be appropriate.  Otherwise, approaches specifically aimed at filling the gap may be required; buying in expertise to do the work, or for mentoring or training.  Once all required skills are available, there may still be problems in applying them effectively to do the work, the people with the scarce skills may be stretched too far.

Prevention, Amelioration, Cure

If the required skill is absent, there is little alternative to buying in the skill.  Given time, the skill could be developed without being bought in.  This latter approach may be necessary in particularly innovative or domain-specific areas where there is no skill available to be bought.


The problems of building teams using a balance of experts and less expert staff are addressed by the patterns DomainExpertiseInRoles for enterprises or large projects, and HolisticDiversity for small projects or individual teams within large projects.  Three specific patterns to deal with working around shortage of expertise are DeCoupleStages to organize the development process to be worked by low skill workers, GenericsAndSpecifics to get the experts building the core of the system, and SubsystemBySkill to arrange work to suit the skills.  All of these three are to some degree contra-indicated and should ideally be replaced by a more aggressive approach to skills transfer.  A LegendRole can occur where one person holds much of the expertise.  Approaches to transfer skills and knowledge include ApprenticeShip, DayCare and DevelopingInPairs.  Even where there is no immediate shortage of skills, skills transfer should be used to ensure there is a ModerateTruckNumber.


One particular interaction with expertise and approaches should be noted.  Selecting ‘easier’ problems on the first architectural iteration might modify the ArchitecturalSpike to better suit the situation.  We want to tackle the high risks first, but alongside architectural risk, there is the need to gain experience rapidly.  We may want to select the hardest problems that we think the team can tackle successfully, and leave even harder problems to the second architectural iteration (see Ref 1).  The counter-argument to this is that such an approach may leave us needing considerable changes to the work we did in the first iteration.


Agile approaches tend to value skill highly and recognize that the differential between cost and added value of good quality people is in favour of paying for quality.  In addition, they set great store by efficient skills transfer approaches such as DevelopingInPairs and for a less formal approach, OpenWorkspace, thereby paying dividends in increased expertise in addition to delivered product.  The ideal team member is a GeneralizingSpecialist who can put his hand to almost any task, and has expertise in a few related areas.


1. C2 Wiki Easiest thing first hardest second – with a few opinions for either side of the argument