Changing culture does not happen by osmosis, it happens through incessant education. The DevOps continuum of services your organization originally intends to create and implement is a journey more than a concrete destination. It will evolve over time no matter what your original plans were, no matter what your vendor of choice tells you, and no matter what resistance you meet along the way. If anything, resistance within your organization will push your journey left or right from its originally intended path. The lack of features in your tooling, or the introduction of those same features over time, will impact the journey of DevOps your organization will embrace. Culture is fluid. DevOps is fluid. So managing the impact they will have on each other should warrant dedicated concentration, and resources, in the form of training and education.
Audience Educational Considerations
It is not just your practitioner base that will need perpetual education to use your DevOps services to maximum effect. It is also the business community that relies on DevOps information and the executive community that may have sponsored the journey into DevOps in the first place. Education for the non-practitioner is more than just a matter of managing expectations, although that is a big part of it; it is a matter of helping this community learn to watch “change” or innovation as it moves from idea to production. DevOps will make an extraordinary impact on the speed of innovation delivery, as well as the quality or reliability of delivery. Engaging your business community and training them so they see this, comprehends what it means to them, and keeps them informed of the improvements will be critical to the long-term success of your efforts.
Consider how managing expectations will impact adoption of DevOps services from a business point of view. When you first start on your DevOps journey, usually only the build and deployment services are launched as the “core” of the service. As you do this, you will need a way to keep your business community (i.e., the audience of what you do), informed as to your progress, and what key features or functions remain on the drawing board. How you communicate this information will be key to managing the expectations of your audience.
For example, your initial efforts at build and deploy may only include the application code as its target. But over time you may begin to deepen what can be automated down the stack—say databases or middleware—as your next target. Eventually you are automating server O/S or even network definitions. If this is the services plan your organization takes on, you need to outline the timeline for expansion to the business community—not just in bullet points on a chart or timeline graphic, but specific benefits they should expect to receive at each milestone (i.e., why they should care).
As your actual journey of DevOps begins, you may find, as an example, that you never get to network definitions in your automation efforts for one reason or another. Why you’re not reaching this goal needs to be explained, as well as the impacts of this. What drives this conclusion should also be explained; it might be for a very good or legitimate reason. But altering the DevOps journey needs to be ingrained in the business culture. Taking small steps, minimizing risk, learning from mistakes, and moving on—all are key lean concepts, agile methods, and ultimately they ensure the success of your DevOps efforts. The need to communicate changes in your plans to the business community helps manage expectations, but beyond that, it teaches the business community that information will be flowing constantly—and will be important constantly, even if it is brief in each segment.
Whether your organization plans to expand DevOps services by moving down the stack, or perhaps by adding more capabilities laterally, you will need the ability communicate direction as well as “how” to take advantage of the expansion of DevOps you offer. So for example, if you are expanding your DevOps service by moving down the stack from app to operating system (OS), you will need to show the business community how to watch changes at each level (app, middleware, OS) or, if you are expanding your services laterally, adding automated testing, then release orchestration, then monitoring integration, and finally production provisioning automation. You need a plan for communicating each success, as well as “how” the business community can take advantage of what is accomplished.
This communication plan should manage expectations, inform of changes in strategy or direction, inform of success/failure/alteration, and teach the business user how to use what you have done. Your communications plan may be looking at new data that was not previously available, or tracking innovation change differently. But educating your business community base will not be a “one-time” event; it will be a perpetual activity. Therefore, how you create this process should be built for perpetual delivery, not just a one-and-done delivery.
The frequency of offering it will depend on the specifics of your organization’s needs. But the frequency should always keep pace with the changes and successes of your DevOps services delivery. If that is weekly, then weekly, if that is monthly then monthly. What you do to communicate, and how, will depend partly on that frequency and the size of your audience. Keep in mind your tooling vendor is also constantly enhancing its toolset with new features. The frequency of delivery may also need to incorporate those impacts as well.
Practitioner Educational Considerations
Educating your practitioner community generally is focused on tooling proficiency. But that may be a limited view. The architecture of your DevOps services is arguably more important than the specifics of how you use the build tool. Consider how your DevOps practitioners intend to accomplish the ability to scale build automation, as an example. I could just train the practitioners on how to use the build tool and then turn them loose, automating builds armed with little more than a cursory understanding of my preferred build tool. And over time using this training method, I will have as many methods to construct build automation as I have engineers who touch my tools, namely “n” methods. Having that much diversity in “how” I construct build automation creates variability that, with a large portfolio of apps, does not scale and is difficult to sustain without constantly throwing labor at it.
Conversely, my architectural approach to build automation established by the DevOps team instead might be that each kind of technology uses a master template, or framework, as its approach. This information has little to do with a specific build tool and everything to do with the organization’s “strategy” for build construction. That information becomes much more important than specific tool usage, because it affects “how” engineers use the tool according to company standards and practices. Training and creating a communications plan for reaching every member of your practitioner community on these items becomes critical to longer term success. This includes hiring new talent, departmental transfers and contractor augmentation.
The additional consideration here is how you want to manage your intellectual property. “How” your company constructs build automation may be a proprietary advantage for your firm. This is particularly true if your architecture team is top-notch and able to create structures in your tooling that less experienced practitioners would not have even considered. If you train outside contractors on your methods, you are in effect giving away some of the farm. Non-disclosure agreements may keep a contractor from purposely sharing your methods with a competitor, but it will not prevent the engineer from learning how to make a better mouse trap while working with you. The contractor leaves your employ, a much more well-educated engineer than when he or she started.
Once overall strategy education has been planned for and imparted to your practitioner community (another perpetual delivery method required), most companies focus on tooling proficiency. DevOps is still a relatively new phenomenon. And as such, certifications that are common in the networking world, for example, do not exist in the DevOps world. Gaining proficiency from vendor tools should be provided by those vendors as part of the licensing purchase agreement. If the vendor is unable to provide it in a formal delivery method, beware: The toolset is probably a new acquisition or too new in the market. If you are using open source tooling, a fully in-house model for training must be created and managed on an ongoing basis.
Impacts to the Bottom Line
Changing culture on a wide scale will require a focus of resources for training and education across your company. Engineers typically do not make the best communicators—that might be a DNA thing—so you may want to pair training and communication resource employees with the DevOps team to deliver what will be needed in an ongoing basis. The main consideration here is to realize that because DevOps services constantly will be evolving, communication plans need to keep pace with their evolution. And yes, I realize, this is additional overhead costs that almost no DevOps delivery person believes he or she needs when the services are first launched.
But like all things, an initial publication or announcement is not sufficient to keep track with something that changes on a highly frequent basis. Adoption either can be facilitated by a good communications plan or thwarted by the lack of one. If it takes your company 15 months longer to get fully onboarded to DevOps because of delays in the rate of adoption (based on poor or non-existent communication), you must consider the costs of that delay in contrast. If after onboarding to DevOps, your business audience is ill-informed about how to use the services to maximum effect, what will that inefficiency cost the company? If your practitioners are only exposed to tooling proficiency once and without architectural oversight, what will the cost of the variability they produce in their automation be to the company?
Investing in training and constant communication may not raise revenue, but it will certainly avoid costs. The measure of how much cost it avoids is difficult to track. Most companies who make the investment understand intrinsically what the alternative would be, and choose not to go down that road. The only admonition I would offer is that I have seen clients make this decision late in the cycle, and every one of them did so because the pain motivated it. Your strategies for DevOps should be comprehensive in perspective, if you need help crafting or improving yours, contact me—I am looking at the moment.
To continue the conversation, feel free to contact me.
Paul has been actively involved in the IT industry for more than 35 years. Fulfilling a wide range of roles ranging from computer operator to IT infrastructure operations manager. He was co-author of the ITIL publication, “Planning to Implement IT Service Management,” and was a member of the ITIL advisory group for ITIL Version 3, and the architects team for ITIL Practitioner. Paul is also co-director and owner of GamingWorks, the company that developed the internationally renowned “Apollo 13 – an ITSM case experience” ITSM simulation game and most recently the “Phoenix Project – DevOps business simulation,” which is based upon the Phoenix Project book . He was also co-author and developer of the “ABC of ICT (The Attitude, Behavior and Culture of ICT)” publications, having conducted ABC workshops and simulation workshops with delegates representing more than 4,000 organizations worldwide. Follow him on 
