More praise for clerical staff (or, Why the fox should not watch the henhouse)

Who should manage your Engineering Change Order process? Should that be ... umm ... Engineering, based on the name? Bzzzzzt! No, sorry, thank you for playing. It was a trick question.

Last summer I wrote about why companies need clerical support staff, to offload activities that add comparatively low value from highly-compensated employees so that they are free to do the work for which they are so well paid. Using engineers as an example, I wrote:

[W]ho is supposed to fill out the forms if not the affected personnel? Who but the design engineers can possibly ... fill out Engineering Change Orders?

Let me draw a distinction:

• On the one hand, the detailed technical information has to come from the technical experts -- for example, the design engineers. No-one else can possibly provide it.
• On the other hand the typing can be done by someone else. The metadata can be filled in by someone else. The routine information that is nonetheless required can all be added by someone else.

And that way the design engineers can focus on the work that no-one else in the company can possibly do.

The argument is fine as far as it goes, but I left out one important part. The Engineering Change process – and you can generalize this to other kinds of paperwork – is too important to the company to be left in the hands of the engineers. 

A few nights ago, I had dinner with a friend of many years. We used to work together but he's at another company now, managing their Quality department. He said he had been there about a year before he realized that in all that time he hadn't been asked to approve a single ECO. He asked his people, and none of them were approving ECO's either. Why not? After a little digging, he found that Engineering managed the ECO process; and whenever a new ECO had to be approved the responsible design engineer just copied the list of approvers from the last one. Apparently Quality had been dropped off somehow, years ago, and this copy-paste approach to identifying approvers meant they were never added back on.

My friend made a fuss, and sure enough he was added to the approval cycle for the very next ECO. He reviewed it, and sent it back to the design engineer after identifying a few issues that had to be corrected. So the design engineer deleted my friend's name and replaced it with the name of the most junior guy in the Quality department – presumably someone who would approve it without quibbling.

The story turned out all right in the end. My friend talked to the engineer and resolved whatever the issue was. But it still bothered me, because every step of that story was absolutely predictable.

Of course the Engineering department wasn't focused on keeping the list of approvers up to date. And of course any individual engineer would try to get his change approved as quickly as possible, with a minimum of fuss or delay, and wouldn't worry about the (seemingly extraneous) fretting of some other department. Those things aren't the job of Engineering! The job of Engineering is to create designs subject to requirements, not to manage or equilibrate the impact of those designs across the rest of the company. And that is exactly why Engineering provides critical inputs into the Engineering Change process but should never own it or manage it.

Who, then? Some other department, someone used to managing process. I suppose you could offer the responsibility to Project Management (if that's a separate department for you), or to Quality. But you could also offer the responsibility to a documentation group, along with the responsibility to fill in all the boring metadata on the ECO – metadata that is critical to those groups downstream who are trying to implement the change (Purchasing, Manufacturing, and others) but that is more or less incidental to the engineers themselves. In fact, if you offer to take the burden of seemingly mindless paperwork off their hands, I bet most Engineering departments would gladly give up authority over the approval process in exchange. That's a trade that benefits everyone.

Is there a general rule here? Probably, though it's a little hard to formalize. But every department has activities that affect the rest of the company, even if they look mostly internal. When you're dealing with activities like that, you have to manage them that way. And that is one strong reason why any company larger than the "three-friends-in-a-garage" model needs support or system functions that stand to one side of the core processes and enable them to work.