Communication breakdown

Have you ever experienced the rollout of a new tool or process that eventually had to be trashed or replaced because it was unusable or indecipherable? Have you ever experienced a lousy reorg that led to half the team leaving? Have you ever experienced an outage that caught you off guard, wasn’t acknowledged, and had no end in sight? Sure you have! These putrid, preventable problems are common in part because of poor communication.

While imperfect people do design poor processes, assign misfit managers, and deploy faulty features, the impact of these issues can be significantly mitigated with good communication. Unfortunately, engineers are often inexperienced when it comes to engaging large groups. Heck, we’re terrible at communicating with people we see every day (read Evil assumptions and Writing for readers). There’s a better way. Your time is short and valuable, so let’s get right to it.

Roll with it, baby

Rollouts and reorgs both require communication plans. That’s because they both involve a significant change that people can only accept after going through denial, anger, bargaining, and depression (read Things have got to change: Change management for details).

Let’s start with rollouts. If you need a major tool or process change to roll out smoothly, there’s certainly extra work involved, but the work isn’t complicated.

Here’s a straightforward checklist based on decades of proven experience.

• Define and determine baseline success and health metrics, including criteria for success or rollback
  • How else can you tell if it’s going well and brag about it later?
• Prepare and review online (and possibly live) training, documentation, and job aids
• Run two to three pilots, capturing a range of customers and identifying customer champs
  • Incorporate pilot feedback in product, training, documentation, and job aides
  • Meet success and health criteria
• Define and test your rollback plan
• Receive a green light from management for a broad rollout
  • Show the results of your pilots, along with your health and success metrics
• Send four-week advance notice to all impacted customers
  • Include a rude Q&A and pointers to training, documentation, and job aids
• Deliver live training (as appropriate)
• Send one-week notice to all impacted customers
  • Include the updated rude Q&A, training, documentation, and job aids based on feedback
• Assign room or Teams channel plus a virtual team to handle incoming issues
• Send one-day notice to all impacted customers
• Send day-of notice to all impacted customers
• Track, triage, and dispatch issues via the virtual team
  • Trigger rollback if health fails to meet agreed-upon criteria
• Send regular progress reports to all impacted customers listing metrics and issues
  • Send daily until all major issues are resolved and success criteria are met (last daily report is the celebration mail)
  • Send weekly for the following month
  • Send monthly for the following quarter

For smaller changes or fewer impacted customers, you may not need as many pilots, notices, and progress reports. However, skipping any of these steps for org-wide changes puts success in jeopardy. Without metrics of health and success, you can’t tell if the rollout is going well and if you made a difference. Without pilots, you won’t discover and fix all the little blockers and missteps that get magnified later. Without testing your rollback plan, you may get trapped in a fustercluck. Without plenty of advanced notice, training, documentation, and job aids, your customers won’t be ready when the change happens. Without a virtual team for issues, you can’t stay on top of problems. And without progress reports, your customers and management won’t know that things are getting better and the change was worthwhile.

The two items that people often miss are a rude Q&A and job aids.

• A rude Q&A is a series of unfiltered questions and polite answers. While an FAQ tells you what the provider wants you to know, a rude Q&A addresses what the customers want to know. Customers love and value a rude Q&A.
• Job aids are cheat sheets, scripts, tools, one-pagers, and/or maps that make the change easier to use and understand. One useful, simple job aid beats 10 pages of documentation.

Meet the new boss

While the work for a rollout can be substantial, at least it’s straightforward. In contrast, reorgs are rarely routine. That’s why reorg communication plans are so important. They provide time to spot issues and mitigate them before the reorg is broadly announced. That can be the difference between a reorg that discourages and disperses versus a reorg that reinvigorates and retains.

Typically, you only reorganize one layer of management at a time. Otherwise, people don’t know who their manager will be, and issues can’t be resolved in advance. After you’ve figured out the desired reorg, here’s a timeline for communicating the reorg smoothly and respectfully.

• -14 days (Monday): Engage the outgoing and incoming managers, allowing them to raise issues and ensuring that incoming managers accept their new responsibilities. Any issues raised must be resolved that week to avoid postponing the reorg.
• -11 days (Thursday): Engage stakeholders and critical team members, resolving serious objections that arise. Critical team members include any thought leaders who would influence the team’s reaction to the reorg.
• -6 days (Tuesday): Have an all-managers meeting, followed shortly by a full-team meeting with all staff directly impacted. These meetings should go smoothly since stakeholders and critical team members are already informed, and their issues are addressed.
• -4 days (Thursday): Send reorg announcement broadly to the organization, forwarding it to partner orgs who frequently collaborate with you. The reason to wait two days after the staff and team meetings is to allow time in case anything unusual happens that changes or cancels the announcement.
• 0 days (Monday): Org changes go into effect. Your reorg announcement may say the org change is effective immediately, but it typically takes a few days for the systems to update. If you update systems before the announcement, folks might inadvertently find out early.

I started this two-week timeline on a Monday, but you can adjust it to your needs. Keep the transition as short as possible. Anything longer than two weeks increases the likelihood that information will leak before you’ve had a chance to address concerns, which may doom your plans. If you have good reason to believe everyone will be happy with the change, you can compress the transition down to one week by combining the first two steps on Monday, telling the team on Wednesday, and sending the announcement on Friday.

If any manager, stakeholder, or critical team member raises an issue you can’t resolve adequately, consider canceling the reorg. In my experience, two out of three proposed reorgs get canceled or delayed. That’s why when people ask me about reorg rumors, I say I have no idea if they’ll happen. It’s better to get reorgs right.

Down for the count

As I mention in Tell me why: Incident RCAs, customers should be notified immediately of any incident that impacts them. The practical rule is: Notify customers of an outage immediately if you believe there’s a fair chance that customers will eventually notify you.

Why err on the side of notifying immediately, even if it means a slight delay in mitigation? Because when a customer notifies us first, we appear to be caught off guard and out of touch with our own services—not a way to inspire confidence. Also, customers outnumber us by a wide margin. We can quickly get swamped with duplicate incidents raised by concerned customers. This social denial-of-service attack is distracting and unnerving. The noise and stress often disrupt fixing the issue. Thus, notifying customers first is worth a short delay in mitigation.

These days, Microsoft’s internal incident management system can post outage notifications for you, if you don’t use another system to do that. Regardless, you need to provide the following details in the message body: a short, clear description of what is happening; who is impacted; any actions customers need to take (with documentation links as needed); and a final line that indicates when the next update will be available. Post another update at that time or when the issue is mitigated, whichever comes first.

Note: DO NOT use Information Rights Management (IRM) when emailing outage announcements. Some internal groups use IRM to prevent replying all to the announcement. However, IRM announcements take much longer to open, are difficult to work with, and may not open if any dependent services are offline (which is possible during an outage). Instead, send your outage announcement to a customer distribution list with restricted senders. That way, no IRM is needed and customers cannot inadvertently reply all to the broad distribution list.

Failure to communicate

You shouldn’t need to abandon a rollout, lose half the team after a reorg, or be caught off guard by an outage. Communicating using a proven rollout checklist, a reorg timeline, or an immediate and clear outage notification can smooth out the rough edges, keep everyone impacted reassured and informed, and mitigate any issues that arise.

Yes, it’s extra work and takes more time to do things properly. However, rollouts, reorgs, and outages already involve a ton of work. That work gets wasted if the rollout fails, the reorg results in an exodus, or the outage breaks customer faith. A little bit of extra time and preparation is well worth the greater success, lower anxiety, and steadfast loyalty. Do the right thing and communicate.