Blog: On Indispensable People, Documentation, and Skill

In a blog post on The Test Eye, Martin Jansson has some things to say about the dangers of The Indispensable Worker. The post is worth reading. I commented there, and do a somewhat better job of it here:

Your point about indispensability is well-taken. In workshops that I’ve attended, Jerry Weinberg has often pointed out the urgency of getting rid of the problem of indispensability. If someone appears to be indispensable, it’s a great risk to the organization; it either has become or will become severely maladapted to existence without that person. This isn’t to say that people won’t be missed when they go; everyone carries tacit knowledge and experience that no one else has. But whether someone will be missed or not, their departure shouldn’t destroy the organization. An “indispensable” person will disappear eventually, one way or another. So if you see the problem, get started on addressing it now.

There was a point with which I disagree, though—at least with the emphasis:

As a co-worker you avoid these traps by requiring documentation enough for someone else to perform the task or that you have at least a backup for the critical tasks.

I’d put that in the opposite order. If you’ve got a backup (in the form of a person who can do that task), then you might not need documentation at all to get the job done; and you might have a better way of performing the tasks that the job requires in the high-pressure moments. This is why commercial airlines tend to have a captain and a first officer in the cockpit, rather than a pilot and a book on how to fly an aircraft.

Note also that there are several relatively high-pressure moments on every flight. Just because something could be done by a single person doesn’t mean that it’s automatically better policy to have only one person doing it. On the contrary, in most cases.

Want to know more? Learn about upcoming Rapid Software Testing classes here.

5 responses to “On Indispensable People, Documentation, and Skill”

  1. gmcrews says:

    Hi Michael,

    I don’t think you picked a very good analogy.

    Even though the pilot may get pretty busy, all commercial aircraft can be safely flown by a single person. The most important function that the copilot serves is quality assurance.

    And regardless of the number of pilots, you will always find checklists actively used in all aircraft.

  2. Gerald M. Weinberg, Blogmeister says:

    I agree. I always prefer a human backup, but only if the organization has taken steps to see that the human backup will be a true backup, and will be around when the time comes that a backup is needed.

    Many organizations claim to do this, just as many claim to keep their documentation current, but few actually do what they claim.

  3. Anonymous says:

    Considering a “Indsipensable” Testin engineer onboard, I take such persons as reason for getting my tests scripted (Test cases or Automation Scripts).
    This does multiple benefits to my testing assignment
    1. I have documented the tests in form of test cases
    2.I can use these test cases to create innovative thinking (by showing the test cases to others and boost their innovation)
    3.Iam not dependent on “Indispensable” engineers
    4.such test cases are handy when such engineers are on vacation or are allocated to some other task
    5.In Long run i’ll be able to create a large test bank for the product.
    Having said that,converting the exploration into test cases can not by itself mitigate the risk, the long term plans should be creating the awareness so that you always have “indspensables” at the same time we are able to live with out them.
    Agreed that each indivual has his/her capabilities when it comes to innovation, nevertheless, we can use the result of such innovation as launchpad for building others.

  4. Martin Jansson says:

    I agree with you both. A human backup is most often preferable. You need to be structured enough when explaining what the backup is supposed to do. This is a good start.

    In some situations it is better to document or perhaps automate the task. For instance, when performing the same set of tasks that would be possible to script in one way or the other.

  5. Michael says:

    @gmcrews: Thanks for your comment. Yes, it is the case that a commercial aircraft can be flown safely by a single person (at least in routine circumstances), just as a commercial application could be programmed and tested by a single person. However, Patrick Smith notes “I fail to understand how after decades of reporting on aviation incidents, the press cannot make it clear that at least two fully qualified pilots — a captain and first officer — are in the cockpit of every commercial jet. The captain is in command and ultimately responsible for the plane and its occupants, yes, but the first officer, or “copilot,” if we must, is not merely along as a backup or helpful apprentice. Tasks are split 50/50, including all hands-on “flying” duties. A copilot is at the controls for just as many takeoffs and landings as the captain, in both normal and abnormal operations, including many emergencies…” In the same article, Smith points notes that in an emergency, the pilots turn to the the immediate action checklist. But they don’t refer to a document; the immediate action checklist is memorized.

    Even if one person can fly the aircraft, it’s reasonable to ask some questions: Is this what we want? When we say “can be”, do we mean in routine conditions or in extreme conditions? We might know the names of Chesley Sullenberger or Al Haynes, but would they have become “heroes” if not for Jeffrey Skiles or for William Record and Dudley Dvorak? The pilots in both cases were doubtless assisted by checklists, but I’ll contend that it wasn’t the checklist that controlled the aircrat and saved the lives. The checklists tend not to cover situations like “all control surfaces unavailable”.

    Here’s a comment from James Bach, who has insight from the perspective of an actual pilot. I’m hoping that James’s brother Rob (a commercial airline pilot) will weigh in, too. Meanwhile, James says,

    “To use a checklist responsibly is not to be dominated by it. That distinction is absolutely critical to safe flying.

    “I come from a flying family. Yesterday I was checking the bolts on a new Quicksilver on floats that my father and his mechanic are assembling. Each of us did some assembly on the various struts, fitting and bolting the parts to the frame (loosley). Then the greybearded mechanic torqued and safetied each bolt, followed by Dad and I who made separate passes to inspect his work. We trust in the skill of the mechanic to do the job right, but we check his work all the same, as he cheerfully dared us to find fault with it.

    “The aircraft comes with a thick manual, to which we occasionally referred. We discovered at least one puzzling contradiction (the manual says the engine won’t burn avgas, whereas the engine has a placard warning against any other fuel exept avgas) and the mechanic identified a design flaw in the landing gear locking mechanism that caused him to suggest a redesign to improve safety (metal fatigue was occuring in the connection between the bowden cable and the gear locking plate, and he suggested installing a clevis joint to alleviate the stress.)

    “As with flying itself (I’m a perpetual student pilot since forever), aircraft maintenance is exacting work, but you will find in all cases it revolves around skill and judgment, with manuals, regulations, and checklists playing a critical but supporting role.

    “There’s an important distinction between ‘serving the purpose of quality assurance’ as one skilled in the work at hand, or as an unskilled lackey who is there only because he can read a checklist.”

Leave a Reply

Your email address will not be published. Required fields are marked *