Communicate Change? I Can’t Complain!

Jon Hildebrand recently made a brilliant vBrownbag presentation about DevOps Culture, and how behavioral and organizational shift can be more important than the actual tech involved. I highly agree, and wanted to expand upon the concept to a more broad topic that we normally fail to address in business: communicating change.

"I'll be right over!"
“Mom’s making meatloaf!”

The rules of business are these: you make a product or service and sell to your customer. You keep up with the demand and the changing times, and expand and grow your business where possible. All the while you communicate via marketing: “Hey! vMikeB is opening a new store in your area!” or “vMikeB is offering a new widget, this time with BBQ sauce!” This chain of communication keeps your customers engaged, informed, and focused on your narrative, and in turn your product or service.

What I believe is not done well, unfortunately, is that most businesses do not share the same courtesy to their internal customers. We grow, shift, change, and fail to tell our employees about new services, plans, offices, etc. Or maybe at best they receive an email that goes in the unread pile, because “Inbox Zero” isn’t for everyone.

Except for Santa. Santa practices Inbox Zero, because awwwwwwww!

Our internal customers can be our biggest champions of change if we enable them, or they can be our biggest roadblocks if they feel at all slighted. I see this with EUC/VDI transformation, moving away from traditional desktop/laptop infrastructure and going towards a centrally managed desktop system with zero/thin/repurposed endpoints: if you do not inform your users early, and often, they will hang you out to dry. Seriously: imagine I just deployed one thousand virtual desktops, and delivered as many thin clients with USB ports disabled (because security, that’s why). I didn’t tell my users about this change, I’m just enforcing policy. If even 10% of those users have smart phones that they want to plug in and charge/play music/transfer files, or specific desktop printers they want to use: now i’ve got 100 people telling everyone in the business how terrible the new EUC implementation is.

In a different life I worked in customer service, and there is a saying: “If one customer has a bad experience, they will tell ten other people. If a customer has a good experience, they may potentially tell two people.” 10 vs. 2. WOW.

Everything is NOT Awesome…

So those 100 people? They just became a bullhorn of project-killing negativity to another thousand people in the business! How will my users react and adopt my solution now? If I am merely marginally successful, then I may receive no accolades at all, and if I really impress my users, they maybe tell 2 of their friends. Doesn’t seem quite fair, does it? C’est la vie…


Angry (Lego) people can be a risk to your business, by slowing or impeding the progress that the business has planned and paid for with money as well as precious time. Think internal campaigns are expensive? Try losing key departmental knowledge holders and cultural leaders within your business because change wasn’t communicated. What about organizational shift like DevOps where people feel that their jobs are going to be lost or obsolete?

About ten years ago I migrated and deployed a new ERP system for a large manufacturing company. From day one I ensured that I had the tools, resources, time, and funding to make the project a success. I spent the better part of a year hammering out all of the issues with Supply Chain integrations, Shipping and Receiving printing issues (if you’ve done this, you know it sucks), image and document management and automation. All of it. It was my baby, and I raised it to walking and talking. On the Go-live day I was there from 5am until 2am the next morning, anxious and at the ready.

Nothing happened.

We just… couldn’t get over the hump.

Literally, nothing happened that day. I code promoted into production the night before, everything was pristine and functional, and even made sure the inventory database was clean and up to date. The users couldn’t leverage the new ERP system because they lacked sufficient training. Or so they said. I know for a fact that a few were unhappy due to the move from a green-screen AS400 interface for which they knew all the keyboard shortcuts. The new system was an installed fat client with a “point-and-click” interface, which actually slowed order input significantly. Others knew the workflows, but did not know the more advanced nuances that came with a new system, or where certain work needed to be input on a different screen/system/application.

The operation was a success, and the patient still died.

You guys know what that flat line means? Somebody mute that constant beeping, I’m trying to save a life here!

Change can be welcomed by our internal customers much like our external ones, simply by utilizing the same mechanisms our marketing team already use: email blitzes, Expos, Lunch-and-Learns, webinars, etc. Gamification can even come into play, if you are willing to push past the cheese factor and into a bit of fun. For EUC initiatives: hand out your thin/zero clients or tablets with a gift bag, containing instructions, FAQ’s, and a gift card to Starbucks. Or celebrate the “brand new BYOD policy!” and tell employees that they can use the devices they already feel comfortable using – have them bring devices in to test, and hand out prizes for bugs or issues during the pilot phase. Make it fun!

DevOps you can host a lunch and learn with your various silo’d departments and have an open forum for dialogue. Tell them what’s coming, and to think about how they want to build their resume: do I want to be more on the development side? Do I want to help support daily operations? Can I architect the environment and work on integration of existing components/solutions? Give employees the chance to kick around what they already know together in a break-out session, build a CI/CD proposal on paper, and award the most innovative group. Use your internal knowledge holders and uplift them.

The above ideas sound like they may be costly, or a waste of time, but I posit this idea: what is the cost of a day of employees sharing ideas and warming up to your effort, vs. the hundreds of thousands, possibly millions of dollars of spend on project work, lost revenue, and lost productivity?

Leave a Reply

Your email address will not be published. Required fields are marked *