I recently had the honor of speaking to a large group of storage and network engineers on the topic of devOps. My segment was squeezed in between some other content that I’m pretty sure was much more important to them, like product announcements, demos, calls to action, etc.
Why do I think that?
Well, during the segment I asked the crowd a question- “How many of you have read The Phoenix Project by Gene Kim [et al]?”
I counted maybe 15 hands out of…a LOT more. I was flabbergasted.
If you haven’t read this book, it’s highly likely that you do not understand your customers’ problems, and therefore do not understand your customers. One day, you’re going to walk into your biggest customers and they’re going to be very sorry to tell you that you’re not needed anymore, as your offerings (and perhaps sales model) don’t align with their new strategy.
The worst part is, you probably think you’re pretty darn good at this IT stuff. You know your tech (for years now!), you’ve got your speeds and feeds down pat, you have gobs of expertise in this technology or that. Your customers (almost all of them IT folks) come to you with their problems. Perhaps you even socialize with many of these people, and consider these relationships completely safe.
It’s not that your customers won’t need the products and services you currently offer. It’s just that the way that they CONSUME these will require an understanding (on your part) of their new (or soon-to-be new) models and processes that will drive their “accelerating acceleration”, and yes, I’m talking devOps here. Your services need to be updated to align the products with these new ways, which means making automation, scripting, and infrastucture-as-code major core competencies. Show them how your products and services assist or enable their transformative efforts, or somebody else will. “Somebody else” could be another department (app dev, for instance) that will transform their use of technology outside of IT and REALLY put the screws to your offering. If the products you specialize in can’t align with this philosophy, it’s time to focus on obtaining new expertise in the technologies that will replace them.
Just yesterday I visited with two customers, both of which had “Shadow IT” instances turn into permanent business transformations, as the “Shadow IT” folks were able to deliver value to the business within days, where the IT ops folks were taking weeks into months to deliver the same services. Times have changed, people.
I wouldn’t even start down the road of learning automation or Infrastructure-as-Code until you’ve READ THIS BOOK. (There are many others, this one will be the most entertaining and therefore most likely to be completed). You need to know WHY all of this is important, remind yourself WHY we do what we do as IT professionals, and understand the nature of your customers’ desires to transform in order to steer your own efforts, both personal and organizational, in the right direction.