Truck Number Composite

Problem:

Expertise is difficult to distribute among project members. The difficulty rises as a function of the number of team members, their specificity of experience, and the complexity of the project.

Measurement:

Truck Number -- the size of the smallest set of people in a project such that, if all of them get creamed by a truck, the project is in serious trouble.

IdeaChampion: Truck Number == 1

The Idea Champion-driven project depends on a sole Idea Champion to provide the vision, coordination, and architectural knowledge that makes the project fly. This makes it possible to use lots of PlugCompatibleInterchangeableEngineers to build a project. However, the quality of the project depends solely on the skills of the Idea Champion, and the project is in jeopardy if it loses this person. In this case the Truck Number is one.

However, it may be possible for upper management to find another Idea Champion to replace the road pizza. As long as the project is well organized and documented another visionary could well be able to walk in and take over. Maybe. (Oh, Pollyanna...)

See: ChiefArchitect, etc.

TeamsIntegrateDiversity: Truck Number == ???

The Teams Integrate Diversity project spreads out the knowledge through quick training or mentoring programs. Accountability and responsibility are assigned somewhat arbitrarily. This creates a team where accountable individuals are not able to carry out their responsibilities, because the problem is not within the realm of their control. This really doesn't change the Truck Number, but is nonetheless a dysfunctional state of affairs. In fact, the Truck Number is impossible to assign here because no-one knows whose knowledge keeps the project on track and whose knowledge the team can do without or replace easily.

Alternative arguments welcome here. Eh, Alistair?

Flock of Specialists: Truck Number == 1

Flock of Specialists projects depend on a large number of experts. Each team member is an expert in a narrow field, knowing only their area of expertise. The Truck Number may appear to be large because of the spread of expertise, but the number is in fact one. This is because a critical area of expertise is lost when any one team member gets greased by the truck.

Solution:

You're kidding, right? We're just here to discuss the problem.

The ideal is to have all expertise distributed so that the project could not be wrecked by the loss of any individual or small group of people. This is usually hard to achieve; one person can't be expert on everything unless "everything" is very limited.

The US military addresses this problem in a number of different ways. The Truck Number is fairly significant in combat because you are pretty much guaranteed of having losses in just about any combat team. Therefore, the US military cross-trains its fire team members to a high degree and utilizes redundancy in all of its operations.

As I understand it, the US military does something interesting with respect to this. Cross-training is important, but there are still mission-critical specialists. Logically, the team tries to avoid putting the mission-critical specialists in danger, and is willing to sacrifice (literally) non-critical team members for the sake of the specialist, and therefore the mission. (For example, it's the least critical members of the team who are allowed/asked to take off their gas masks first.) Is there a lesson here for the management of software engineering teams? Having been in the military, I'd say that was almost true - at the same time that the mission critical specialists are protected, everyone is expected to know the full job and immediate plans of their immediate superiors, and be ready to step into their superiors' role at an instant's notice. This is definitely a lesson for mushroom managers - you know, the ones that keep you in the dark and feed you...