Communications Plans

I’m working on writing up a framework for a communications plan for the next convention. We’ve never made an organized list of all the things that need to get told to people and when they have to get said. Probably that’s because we’ve bought into a mindset that it’s a trivial step along the way.

Here’s the takeaway: telling people things is real work. It takes time and planning and attention to detail.  The bigger the organization gets, the more work it takes to just tell people things.

Yes, I suppose there is a lot more of substance to say here, but one of the things we have to do is convince people that telling people things is real work. Otherwise they’ll look at this request for a plan and go, oh we’ll just do it when we get to it.  Because that’s worked so well for us in the past.

 

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.