dealing with problems on the spot

I figured out just the other day that there are at least two different kinds of “hey I need help!” issues that could come up to a staff member at con.   One is a convention safety issue — someone is causing me grief or there’s a situation that’s unsafe.  The other is  what’s known as a service recovery event,  otherwise known as “feedback”.

Usually the “feedback” is some form of “hey you guys, it’s BROKEN here”.  The pattern for dealing with that is:

* apologize

* don’t try to justify why it’s broken or insist it really isn’t broken

* provide the customer with a remedy, with as much flexibility as you can

Good service recoveries can generate more good will than if everything had gone smoothly in the first place.

But if you’re dealing with a safety issue, it’s different.  First of all the first step is not “apologize”. It may be to enforce a rule or to get help or even give sympathy.   So the very first step is to filter the significance of the upset person in front of you: is this a safety issue or a  customer service problem?  Very different paths to follow depending on what you choose.

 

 

What’s the name of that thing?

Today we were discussing solving attendee problems at the con, and someone very helpfully told me what that process is called — Service Recovery. Service Recovery is a bit of magic, if done well it can turn a raving furious customer into your biggest supporter. You need a sincere apology and the flexibility to actually fix problems.

Now there’s another thing that I don’t know what to call it. There’s an email discussion going on, wherein one person is describing the official, documented process and the other person is commenting on the way that process is actually experienced by the people involved. Needless to say, they are somewhat talking past each other, and, I’m sure, each convinced that the other is a buffoon. There must be a word for that second, unofficial process. I just don’t know what it is.

I don’t feel too bad that our organization has both the documented process and the interpretive dance version. After all, we just got a tax cut passed by Congress through a sequence of events that bears very little resemblance to the neat diagram of How a Bill Becomes A Law from 7th grade civics. Put people and politics in a system, and everything goes to pieces….

email anti-patterns

Email is the tool we use every day. It’s the basic communication medium for preparing for the con I’m running. Nothing would run without it, even face to face meetings are announced and scheduled over email. So why is it so damn hard?

Yes that’s a rhetorical question. It’s hard because email cuts out so many cues to the response we’re getting on the other side of the email. And at this point, 35 days or so before the event., it’s hard because we’re all in a hurry. We start to cut corners and respond too fast and before you know it, misunderstanding multiply.

Two particular instances of emall anti-patterns:
1. The more upset you are, the faster you write back.

It’s rare for responding to an email full of whitehot indignation to improve anything, though it may make you feel better at the time. Sometimes the right thing to do is to find a third party to hear your side, and then get back to just writing the simplest answer possible. Sometimes pushing back from the keyboard and taking a walk is the right call.

2. You are so important that even people you haven’t met yet know all about you.

When writing for the first time to someone you don’t know, introduce yourself. Even if you’ve been around the organization for a long time, new people don’t necessarily know who you are or what your responsibilities are. Saves all kinds of questions like “who are you and why are you making demands of me? ”

Toolbox: Seven Questions of Change Management

I’m always working with my teams to accommodate change. Whether those are small changes or large, considering Peter de Jager’s Seven Questions of Change Management has made me better at introducing those changes smoothly.

On beyond the who, what, and where classic questions, some questions are immediately in need of an answer when changes occur.
In short they are:

  1. Why is this change taking place?
  2. What’s in it for me?
  3. What do I do next?
  4. What stays the same?
  5. What could go wrong?
  6. What’s going to be difficult?
  7. When are we going to get there? (And how will we know we’ve arrived?)

I’m still not as good as I could be but when I go back to troubleshoot problems associated with change, I can often identify which question was left unanswered when I initially proposed a new thing.

Toolbox: The Satir Interaction Model

Read more »

High touch vs the System

Maybe all systems with human beings are like this to some degree, but there are tangles that can be unraveled with either a billion emails OR five minutes on the phone. There are times when all the databases and trouble tickets and email confirmations in the world can’t provide the visceral satisfaction that yes, your problem was heard and you are a person deserving of time and attention.

We’re a very distributed team, we really only come together for one big weekend a year. It’s amazing that, with so little face to face time, we don’t have even more miscommunications and upsets than we do.

Thinking about the Debrief

Every year the convention has a debrief for staff after the convention in which we attempt to talk about what has happened in the organizational year  and  find out the lessons learned. I don’t know if I could possibly have resisted posting about it before.  It’s pure candy for those of us who are totally fascinated with how the wheels work behind the scenes.

I say “attempt” because while we do collect a large amount of valuable information, it’s a very formal meeting without a lot of give and take.  Sort of “debrief theater”  rather than the real work of figuring out how to change.  (There are reasons not to do that work in a group of 100 people, for one thing the meeting has to end before midnight,  but I do wonder if there are other ways to make that meeting actually productive.)

But that’s not what I want to write about today.   I have been in the part of the project where I’m severely self-critical of everything that is going askew in the planning, and as there are too many details for any one person to possibly know about and there are lots of people trying to work together with incomplete information and not enough time,  well…   things go awry. Askew. In error.  Pear-shaped.  Less than optimally.   Dead wrong, even.  All the time.  Every day.   And so I am thinking, often, of the retrospective prime directive as found in the  Agile programming community:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. 

As useful as these words are in guiding my interactions with others,  it’s grace to be able to believe that they apply to me as well.

 


Silent resignations

Somewhere out there is Schroedinger’s Volunteer.  Maybe she’s  doing the job and maybe she isn’t, who knows because there’s been total silence.  No bad news but no good news either.

When you ask this volunteer for a status update and then find out that, in fact, nothing is happening — “too much life” is the usual excuse — not only are you down one on the team, but precious weeks have gone by and problems are harder to fix.

Silent resignations of this type are the worst, because for me they damage my trust in the team as a whole and leave me wondering “What else don’t I know?” .

Seriously folks, if you’re not going to do a job or you can’t do a job, just tell someone.  That may be damaging to your pride in the moment, but it’s far less damaging to the team than not doing something and letting people discover the fact later on.  Specifically, waiting until someone asks you for an update and then letting them know that, in your mind you quit the project 2 weeks ago?  Not cool.

 

 

Communicating about Communicating

I am wishing we could add to our “HI My Name is:” labels, some critical additional information.

“Hi, my name is Rachel, I read my email about a dozen times a day on an ordinary day, but sometimes more and sometimes much less.  I try to answer anything to me in about 48 hours, at least for the first pass.  But I get a lot of mail that is FYI and some pieces of mail that need a lot of thought and consideration.  If you haven’t gotten a response from me that you need in a week, I may have miscategorized your mail.   Please resend the email, and be specific about what question you’re asking.   That phone number you have for me is my cell phone, it’s always in my pocket, and almost always on, please don’t call after 11 pm unless it’s an emergency. Texts are fine. ”

If I had this information for everyone on the convention staff (hello my name is E who answers email between 1 am and 3 am reliably and can’t really be reached any other time of day, and isn’t reachable at all on Shabbat or Jewish holidays … for example) I’m sure it would help a lot.  No, I mean, if we ALL had this information about each other, as easily available as a name on a name tag.  That would  really help.

 

 

 

Language alert

I use the word “Let’s”  too much.  “Let’s arrange things such a way.”  “Let’s work on this project.”  And so on.

Mostly “Let’s” comes up in situations when I should delegate and I’m not delegating clearly.   It reflects my own discomfort with delegating, not something from outside.  For example,  I’m trying to please someone or trying to not be perceived as too demanding or trying to remain involved with details that I get invested in but should let go of.

It’s not clear who winds up owning the task when I say “let’s”.  It’s a bad habit that I’m going to try to banish from my speech, and even more, my emails.