As I wrote last week, we've recently had the opportunity to speak with 100s of Enterprise companies as part of the Culture, Containers and accelerating DevOps events with Gene Kim (@realgenekim). During those discussions, we've been able to learn about lessons since the Phoenix Project and the most important metrics for measuring DevOps success. We've also learned that DevOps can be difficult to achieve for business leaders.
One thing I've noticed about business leaders that attend DevOps events is that they tend to struggle with the Culture aspect more than anything else. The concepts of blended or shared responsibilities, blameless postmortems, and speed vs. stability can often run counter to the principles which they have been taught about leading their organizations in the past. They realize that the future of their business will be highly impacted by their ability to deliver software faster (via new features, new products, and new routes-to-market), but they struggle to find a language or framework to communicate to their teams (and peers) about how to make this happen. Far too often, we ask them to learn the language of lean manufacturing or the principles taught by W. Edward Deming. While these approaches are valuable, and can draw a parallel between the factories of physical goods and 21st-century bits factories, they require yet another learning curve before change can occur and take hold in an organization. So with that in mind, I thought it might be useful to adapt a popular business framework, Steven Covey's "The 7 Habits of Highly Effective People", into a model that can be used by business leaders trying to bring DevOps culture into their organizations.
#1 Be Proactive
Responsible for behavior, results and growth.
Let's start with the one constant in IT: Change happens, constantly. If you started 20 years ago, Client-Server was just beginning to gain momentum. If you started 10 years ago, the iPhone had barely been introduced and AWS had 2 services. If you started 5 years ago, Linux containers were still overly complicated to use and web-scale companies weren't open sourcing important frameworks.
We've seen massive changes over the last 50 years to which companies lead their respectively industries, and which market segments are the most valuable today (hint: technology). It is critical for business leaders to recognize that technology is driving these changes, at a more rapid pace than ever before, and to be proactive at internally being prepared for the next round(s) of changes. Be the change-agent that the business requires.
#2 Begin with the End in Mind
Focus time and energy on things that can be controlled.
No business executive wakes up and says, "We have a DevOps problem!" Instead, they lose sleep over reducing time-to-market for new capabilities, reducing security risks and other metrics that can be directly tied to the top or bottom line. This is why I said that "Confidence in Shipping Software into Production" is the most important DevOps metric. At it's core, it begins with the end in mind - Can we get software into production safely and reliably? From there, it works backwards to determine how frequently this can happen, which leads to an examination of existing skills (people), ability to manage deployment frequency (culture) and if the right tools and platforms are in place (technology).
#3 Put First Things First
Execute on most important priorities.
While it's easy to imagine what a greenfield organization would do to make "DevOps" their default technology culture, the reality is that this is not a immediate reality for most organizations. Their Org Charts are optimized for yesterday's business model and distribution strategy. They have many application platforms, often silo'd for different lines of business. And they need to adapt their applications to become mobile-native in order to address emerging customer expectations.
Putting first things first, these core elements need to be in place before the business can expect to be successful at rapidly deploying software into production.
- Automation - It is critical to build core competency in the skills and tools (e.g. Ansible) needed to automate repetitive tasks, both for applications and infrastructure. For many companies, it's valuable to begin with a focus on existing applications (both Linux and Windows) and infrastructure (e.g. networking, storage, DHCP/DNS), and then evolve to automating new applications and services.
- CI/CD Pipelines - Just as factories (since the early 1900s) have been built around assembly lines, building modern software is driven by automated pipelines that integrate source code repositories, automated testing, code analysis and security analysis. Building skills to manage pipelines and the process around frequent software updates is critical towards have the framework in place to manage frequently updated software applications.
- Application Platform - Once applications have been built, they need to be deployed into production. In today's world, customers expect to get updates to their software on a frequent basis (e.g. mobile app updates each week), so it's important to have a repetitive way to deploy application updates and scale to meet the business demands on the application. Managing the day-to-day activities of applications is the role of an application platform (e.g. OpenShift). For many years, companies tried to built and maintain their own application platforms, but that approach is rapidly changing as companies realize that their value-add is in the applications, not the platform.
Once these elements are in place, many IT teams are ready to start containerizing their existing and modern applications.
#4 Think Win-Win
Work effectively and efficiently with others to achieve optimal results.
Far too often, the DevOps discussion is framed as the tension and disconnect between Development and Operations teams. I often call it an “impedance mismatch” between the speed that developers can push new code and the speed that operators can accept the updates and make sure that production environments are ready.
Before we blame all the problems on operations being too slow, it’s important to look at why it’s believed that developers are so fast. From the 2017 State of DevOps report, we see that Gene Kim (and team) measure the speed at the point when developers push code into source control (e.g. Git, GitHub, etc.)
Source: Gene Kim; The DevOps Handbook
They aren’t measuring the speed of design and development. Even in a microservices environment, it can take several weeks or months to actually develop the software features.
So how do teams potentially get to a Win-Win scenario? Here are a few suggestions:
- For Operations teams, adopting automation tools (e.g. Ansible) and Infrastructure-as-Code principles (e.g. use source control for automation playbooks), both development and operations are beginning to use common practices and process.
- For Development teams, insist that Security people are embedded within the development process and code review. Security should not be an end-of-process step, but instead embedded in day-to-day development and testing.
- For both teams, require that automated testing are becoming part of normal updates. While many groups preach a “cloud-first” or “mobile-first” policy for new applications, they should also be embracing an “automated-always” policy.
#5 Seek first to Understand, then be Understood
Communicate effectively at all levels of the organization.
Six or seven years ago, nearly every CIO said that they wanted to try and emulate the output of web scale giants like Google in terms of operational efficiency (1000 servers per 1 engineer) and be more responsive to their developers and business. Unfortunately, at the time, it was difficult to find examples of companies outside of Silicon Valley that could actually execute at a similar level. And the technology Google used was not publicly available to these CIOs. But times have changed significantly over the last few years. Not only is Google (and other web scale technologies) readily available via open source projects, but the examples of Enterprise companies implementing similar success are plentiful (examples: here, here, here, here, here…and many more).
So before a CIO sends a few architects out to Silicon Valley to study with the masters, it might be more valuable to study similar companies to their own. It will allow them to bring back experience that is industry-specific, region-specific, and use-case-similar. It will also help in answering the question of, “But, how can we do that without hiring 100+ PhD-level engineers, or $1M+ salaried employees?”. Sometimes the right answer is to leverage the broad set of engineers that work on popular open source projects.
#6 Synergize
Innovate and problem solve with those who have a different point of view.
I’ve often said that everything someone needs to be successful in DevOps they learned in 1st grade. For example, “play nicely with others”, "share", "use your manners". The challenge with this is that org charts and financial incentives (e.g. salaries, bonuses, promotions) are often not aligned between Dev and Ops teams in order to accomplish these basic goals. This is where some knowledge of Conway’s Law comes in handy. If the goal is a specific output (e.g. faster deployment of software into production), make sure that the organizational model is not the top barrier to accomplishing this goal. To achieve this, it is critical for cross-pollination of ideas. Teams need to share their goals, challenges and resource availability with other teams.
#7 Sharpen the Saw
Seek continuous improvement and renewal professionally and personally.
It would be easy to say that IT organizations need to make sure that their teams are keeping up-to-date on training and new skills. But all too often, this becomes a budget line-item that sometimes get ignored. The proper way to address the need for "skills improvement" is not to think about it as "training" (e.g. attend a course, get a certification), but rather to incorporate it into an actual work activity. We're moving into an era in IT where all the rules and best practices that have been stable for the last 15-20 years are being re-written and changed. Because of this, it's important to leverage more modern ways to learn new skills (e.g. online, cloud-enabled, structured scenarios). Encourage employees to seek the best way for them to learn (e.g. side projects, meetups, online learning, etc.) and then have them bring those new skills back to the rest of the team. Make it a KPI to improve the skill levels and skill diversity of the entire team, with incentives for individuals and the overall team to get better.
The Importance of Storytelling
The 7 Habits framework is one that has proven to be successful in helping for individuals and groups to improve their interpersonal skills. Those skills are at the core of any cultural transformation.
Beyond the 7 habits, there is one more skill that should be on every leader's radar. One of the most important skills that IT leaders can leverage as they drive transformation within their DevOps journey is the ability to tell stories of success and change. We've seen this with the widespread success of The Phoenix Project, and we heard it from our customers at Red Hat Summit. The storytelling skill is important because it can inspire emotions and it can help spread successes from group to group. Storytelling allow groups to personalize their challenges, and align their solutions to the cultural nuances within their organization or group.
Categories
