de Stricker

Pattern vigilance

Hm, I'm not hearing from John in response to my email.   Hm, Julia is surprised I don't know the information she says she emailed me yesterday.

It was subtle - and dismissible as a glitch - at first, but over more than a week, the evidence began to mount: Some emails sent to me were disappearing into thin air without bouncebacks to the senders. My technical support contractor worked hard to get to the bottom of it - but we will never know how and why a number of my regular correspondents' messages were suddenly deemed spam.

The episode made me wonder ... how often in our work do we see a small divergence from patterns and let it go as just an exception?  How much evidence do we need before we see a problem?  What are the thresholds by which we determine when to say "I've been noticing"?

The bottom line is vigilance.  Deviations from current patterns may be legitimate alterations in organizational procedures ... but it never hurts to ask, "Hm, why?"

Jargon Cleanup: Communicating to non-insiders

A spa has recently opened in my neighborhood. I went in to get a price list and was impressed (I could use some of these services) and disappointed (I don't understand what some of the services are).  I guess what "St. Tropez" is about, but within the categories in the brochure, I am lost as to what some of the spa jargon might mean.  Not to worry, Google later tells me.  But still:  Would a well established business not want to appeal to a new clientele unfamiliar with the 'insider' words?

The Spa brochure - intended as a sales tool but speaking mostly to the initiated - reminded me how much attention we need to pay to the way we communicate with our own clients.  Just as I am going back to the spa counter to tell the owner that the brochure is not fully informative for new clients, so I remind everyone in the information profession to be mindful of jargon and constantly ask "will non-insiders know what we mean?" 

It looked like a good idea ... at the time!

I was reminded how often we find ourselves asking "now why did we (they) do that?" when out of the blue came an email: "Do you have documentation on the process for recording a decision?  It's needed for a workshop tomorrow and here's what I have so far."  My colleague and I proceeded to exchange messages and in minutes crafted a brief list of questions that, in its very simplicity, seems to call out:  If only we always documented how we made a decision, we wouldn't find ourselves in those corporate memory fixes!"  With thanks to Jackie for prodding me, here is an abbreviated version of the list:

1. What situation, event, problem, or opportunity gave rise to the need for a decision?  Is it a one-time circumstance, or one likely to recur so that we need to consider a policy?

2. Who "owns" the responsibility for making the decision?  Who has relevant input?

3. What is the goal - what are we trying to achieve or avoid? (In part the inverse of 1.)

4. How is the decision process structured, and how much room is there for departing from it?

5. What data, input, background (etc) was available and considered at the time of the decision? (This is critical to avoid the risk of hindsight casting a decision in untoward light.)

6.  What are the options in addition to doing nothing?

7. What extrinsic factors come into play?  ("While options A, B, and C all have intrinsic merit, B was chosen because security is the top priority.")

8. Was the decision near unanimous, or contentious?  (No names are needed, but it's helpful later to understand whether there were doubts.)

9. If the decision involves implementation of any kind, who has responsibility for it?  What process is in place to ensure it moves forward?  What happens if implementation stalls?

10. Shall we "check back" later and measure whether the decision was a good one? When and how?

In times of rapid employee turnover, this simple "template" for capturing "what we were thinking" can be a powerful tool ... if it's consistently used!