Cloud Whispering: Beyond Force-Feeding IT Staff

8 Reasons IT Pros Hate The Cloud

My column IT Staff Fearful Of Cloud? Try Cloud Whispering a few weeks ago gave advice from my experience in dispelling IT staff's fear of cloud. Dispelling, rather than demanding, is really important, because you simply cannot force innovation. Prisoners, as it turns out, aren't people you want to trust with substantially transforming your business. Yet, successful cloud whispering is about more than simply not force-feeding.

First, a little bit of housekeeping. I mentioned in my last column that there were two types of dysfunctional ways that employees deal with their own fear: cloudwashing and sabotage. I promised some future advice about sabotage, and here it is. Sabotage is dishonest; sabotage is harmful to your business goals. Deal with sabotage in exactly the same way that you would deal with someone who is behaving in a dishonest way that is harming any of your business goals.

In my last column, I discussed three cloud whispering techniques: peer validation, finding the "easy" button, and real-world comparisons of security postures. Here are three more that you should include in your cloud whispering strategy to deal with honest, non-prisoners who simply have some valid, functional fears.

1. Propose A Useful And Supportable Implementation

Most IT practitioners who are any good stay pretty busy. Nobody has time for projects that are speculative or that don't solve a specific problem. In other words: Nobody's interested in your fanboy toys.

[Looking for a bigger paycheck? See 5 Salary Enhancing Moves For Tech Workers.]

Good staff members are interested in solving useful business problems. Give them a useful problem to solve, not a "cloud project."

For example, our efforts with platform-as-a-service and software-as-a-service were far ahead of our efforts with infrastructure, mostly because we didn't see any use-case where infrastructure would make sense for us: Other than some customized portal apps, which happily lived on PaaS, our enterprise apps were largely ancient apps that simply couldn't take advantage of IaaS. There were legit concerns about supportability from our enterprise vendors.

Good staff members don't want to get into an unsupportable situation -- and good for them.

I still remember at one job in the ancient past when SANs were still new, when one enterprise vendor accused our SAN, which we had installed without their concurrence, of causing an indexing error in their software. Anything new is always suspect, no matter how ludicrous the attribution is. So, of course my staff was reluctant to pursue a use-case where it was important for our enterprise vendors to support IaaS. They didn't, they wouldn't, and they won't for the foreseeable future.

That's where our need for better disaster recovery came in. We had struggled with budget to do this better for almost 10 years, and cloud DR was the perfect and useful use case. Daily supportability didn't matter as much for this edge case, since we would only be testing a few times a year.

2. Play With Interested Players

As a community organizer, I remember what a fellow organizer once told me: You can only play soccer with the folks who show up to the field. Meaning, you can wish that other people had showed up, but that's not very useful. You have to work with the people who are interested.

In one of our cloud use-cases, I had the "aha" moment that infrastructure staff didn't actually care about disaster recovery. Sure, they cared, but only in the sense of "install servers, boot up, watch login screen appear with no errors, and say, 'My stuff works!'"

That's when I gave app staff the authority to run the project and to manage infrastructure staff's work on the project. After all, I pointed out to the app staff, they were the ones who would be up until 3 a.m. in the disaster recovery site if the app itself didn't work and the infrastructure did. Instant interest!

3. Make The Path Clear

Nobody wants to build their own gallows. That is, you're not getting people to build a system that will put them out of a job.

Unless.

Unless you make it clear that although job XYZ is going away, job PDQ is not going away, and that's the transition plan. Your best employees don't necessarily want to do the same exact job for the next 10 years.

But they do want a job.

Show them the path forward.

In our case, it meant some conversations about "moving up the stack." If you're not racking-and-stacking, maybe you're a system admin. Maybe the person who used to be a system admin is now working as an app developer, all due to cloud computing's efficiencies.

Your best staff will be excited about a path forward.

And that is probably the most important job of the cloud whisperer. Unless the cloud whisperer shows a path forward to staff, when it is very clear to anyone intelligent that their current job will eventually go away in the new cloud world, it's awfully difficult for employees to get super excited and motivated about working on your cloud project.

Excitement and motivation make for successful projects. Prisoners dreading the gallows do not.