The subject came up at work, and I got to thinkin'. Engineers typically abhor overhead. If he's a programmer, writing code is productive while most everything else is overhead. If he's a hardware designer, schematics and possibly layouts and parts selection represent productivity. Things such as status reports, quality control, meetings, and record-keeping are usually deemed distractions to his "real" work.

Most engineers will recognize that at least a minimum of overhead is necessary for the job--even if they're not wholly sure why--but they balk when it gets excessive. In contrast, those whose jobs are, by definition, overhead can often relish additional justification for their employment. Managers live for meetings, charts, and plans. Quality control teams eat up documentation, paper trails, and metrics. Engineers, though, don't have much empathy for such as these.

The problem many organizations have with engineers is in their lack of understanding of the need for overhead. In following their bosses' orders to follow processes (i.e., overhead), engineers often cut corners, skip steps, or provide insufficient information. The effects can be a loss of required TL9000 certification, more bugs in the products, deficient designs, disorganized development, or an utter failure to learn from one's mistakes. Without buy-in, bug reports are too terse to prevent future occurrences, tests are skipped or only executed for success cases (as opposed to error paths), designs wander away from customer requirements, or morale drops (and all that this implies). Organizations must have engineer buy-in to necessary overhead processes.

Gaining engineer buy-in is actually just as simple as can be. Unfortunately, most bosses (i.e., overhead personnel) revert to ineffective methods common to their positions, demonstrating a lack of understanding of engineers, when trying to gain buy-in. A running cynicism among engineers might be: "Hourly status reports to see progress," or, more cynically, "The beatings will continue until morale improves." Pulling a stubborn mule is not going to yield the desired results.

How, then, to get engineer buy-in to overhead? It takes a brief, one-time investment of time, but no brow-beating. Show the engineer the problem and ask him to solve it. By their nature, engineers are problem-solvers. For example, show how the business has been adversely affected by logic errors in software. Ask the engineer to solve the problem; how can they reduce logic errors? More than likely, the solution will be something like code inspections and/or automated testing. Better yet, if the engineer comes up with a viable solution that's "outside the box"--something totally different--the company may very well find a superior solution that all the coercion in the world would not have discovered. Depending upon the complexity of the process or the size of the organization, it may be sufficient to walk the engineers through the time-tested problem-solving steps that led to the overhead activity. Nevertheless, allowing free discussion and brainstorming by the engineers is a must, else it's just overhead rammed down their throats; besides, without brainstorming, superior solutions will be missed.

As quality control and management are nontrivial activities, having engineers approach these as theoretical problems to be solved may be similarly nontrivial. The result, though, will tend to encourage the engineers' empathy and understanding for the need of such overhead. Even better, superior solutions may be created, and everybody in the organization wins.