Guy Wallace said this on Twitter a while back:

I always wanted the Client to own the analysis & design data rather than me. I don’t convert their words to mine – or to Noun-Verb patterns.

He’s summarized a lot of good ideas about the consulting process.  And his phrase about noun-verb patterns reminded me of  two principles I keep in mind when dealing with performance problems (and with their much-smaller subset, training problems):

• Behavior you take with you; accomplishment you leave behind.
  (That’s Tom Gilbert talking.)
• A result is a noun; doing is a verb.

“Doing” is a good example of a fuzzy label, and that’s part of why I’m writing this.  When someone starts talking about what people do at work, it seems to me it’s easy for their focus to shift.

Sometimes when someone’s talking about what people do at work, he might mean the actions they perform, the processes they go through.  That’s how a person works.  It’s the doing part of what they do.  It’s a verb.

If you need to repair the water damage in your basement, then what the contractor does at work–the verbs he carries out–are things like measuring dimensions, testing materials, inspecting damage, examining structures, considering costs,  and calculating square footage.

Alternatively, when someone’s talking about what people do at work, he might mean on the things those people produce, what they accomplish–the result of their work.

A result is a thing.  It’s a noun. That’s the case even in so-called knowledge work and in service occupations. From this angle, what the contractor does–what he produces–is an estimate for the job.  Or a list of suggested approaches (on paper, or  verbal), or a series of questions for you to ask yourself–a kind of contractor’s initial consultation.

That’s what’s left behind when the contractor leaves.

I think this behavior/accomplishment distinction is crucial when you’re talking about performance on the job.  Companies and organizations are crammed to the institution rafters with ritualized behavior that continues in the absence of any real accomplishment except that the behavior got done: sales people are required to make 30 cold calls a day–not because of any company data about the effectiveness of cold calling, but because Veronica, the sales director, had three early successes from cold calls.

Working from the other direction, Umberto, who handles accounting for your department, tells you to charge the new software under “training materials.”  Not that the software is going to be used for training–but your boss has authority for twice the expenditure under that category than he has under “computer resources.”  Changing the accounting codes is such a slow process that not only would the software be out of date, but Umberto and you would both be retired, before it happened.  So Umberto’s helped accomplish a result (software deployed) but if caught you and he will both be sentenced assigned to Purchasing Refresher Training.

When you focus on results, you can work backward through the factors that influenced those results.  Sometimes (most of the time, actually) you’ll find that “lack of skill or knowledge” on the part of the performer is not the major hindrance to accomplishment.  That, of course, means you’ll likely be wasting your time (and the performer’s) if you try to resolve the situation through training.

As Guy Wallace said, you want the client to own the analysis and the design data.  I’ve said before that while I myself try not to use “understand” as a learning objective, I might go along with the client’s use of it, so long as the client and I can agree on what it looks like (what the results are) when someone “understands” how to perform a FEMA elevation certification.

Now, if the client is hell-bent on ignoring any data that doesn’t say “deliver training,” I’m pretty sure I’m not the right person to be working with that client.

Images adapted from this CC-licensed photo by Sebastian Werner / blackwing_de.