DevOps: The IT Leader's Guide
How does DevOps change IT leadership? Our comprehensive guide shares advice from CIOs and experts on DevOps culture change, DevOps metrics, the DevOps jobs outlook, and more
DevOps, an IT methodology and culture now about 10 years old, still feels new – and challenging – to many people in IT. That’s because DevOps methodology, tools, and cultural principles keep morphing and improving. “DevOps is a process, an algorithm,” Robert Reeves, CTO at Datical, recently told us. “Its entire purpose is to change and evolve over time.”
How can you keep up with the changes and stay aware of the latest lessons learned from DevOps practitioners? Our DevOps guide for IT leaders brings you the latest and best information from our ongoing coverage, so you can take a deep dive in one spot. Let’s delve into expert advice and analysis from DevOps experts and top CIOs.
DevOps continues to win fans in enterprise IT for some important reasons. This way of working prizes speed, experimentation, and collaboration, all happening on cross-functional teams. It breaks down traditional walls inside IT organizations between developers and operations teams, and speeds up the cadence of software releases.
All of these factors suit the business goals of the moment: Transform the business – so that it can quickly change to address customer needs or new competitive situations. Pick up the pace, so a manufacturing company can act more like a startup and less like a bureaucracy. Experiment and innovate. These goals are core to digital transformation – the top job of many a CEO right now.
And in the last few years, DevOps has fueled success when companies point small, nimble teams of developers at specific business problems and free them up from traditional organizational rules. This way of working has reshaped the way enterprise IT works (as well as key business processes) at companies such as Vanguard, Target, and Macquarie Bank, across many industries. (For more, see this case study on Macquarie Bank.)
For Vanguard CIO John Marcante, DevOps plays a critical role in his team’s shared goal: to “deliver business value at startup speed,” even at a global financial services giant. His team is “embracing DevOps principles in order to minimize the time between when code is checked into our version management system and when a feature is available to our clients,” he says.
To maximize speed, his team counts on DevOps methods used in combination with agile cloud infrastructure, a microservices approach, automation, and new testing methods. (For more detail on his team’s approach, see our related article, This transformation model enables Vanguard IT to increase speed and innovation.)
Three hallmarks of a great DevOps shop are speed, collaboration, and automation (because automating routine work frees people to tackle more challenging problems.)
You’ll also see a strong focus on culture: The DevOps style of working – quickly and across organizational borders – requires people to buy into fluid roles and accept failures as learning experiences.
DevOps is about much more than speed, of course. Truly great DevOps shops tie success to business outcomes. “DevOps isn't just about going haphazardly faster, but delivering value quicker,” says Red Hat’s Matt Micene, who frequently writes and speaks on DevOps culture. (See our related article, DevOps Jobs: How to spot a great DevOps shop.)
Should there be a dedicated “DevOps team”? This question creates great debate in the DevOps community. Some say yes; some even advocate creating a DevOps center of excellence.
Other people say DevOps is a way of working that must span the entire IT team, and a DevOps team is the hallmark of an immature DevOps organization. For more guidance, and opinion on both sides, see DevOps lessons learned: Advice for IT leaders.
DevOps does not just change the way IT leaders run software projects. “Make no mistake: DevOps represents a different way of thinking about IT – and requires a different leadership model,” as Mark Schwartz, former CIO of US Citizenship and Immigration Services, wrote.
DevOps changes fundamental IT leadership principles, he says, such as how you view requirements, governance, and risk. “The idea that IT is merely responsible for ‘delivering’ what the business says it wants or needs is an outdated one,” he says. “Instead, the CIO must step up and courageously take responsibility for driving corporate outcomes.”
You should be ready to travel outside your comfort zone – for quite a while. “The concepts of blended or shared responsibilities, blameless postmortems, and speed vs. stability often run counter to the principles you’ve been taught about leading IT,” as Brian Gracely, director of product strategy for Red Hat, wrote in our related article, 7 habits of highly effective DevOps.
Even articulating DevOps goals to the team proves hard. “You realize that the future of the business will be highly impacted by your ability to deliver software faster (via new features, new products, and new routes-to-market) – but you struggle to find a language or framework to communicate to your teams (and peers) about how to make DevOps and these results happen.” See Gracely’s article for practical advice on communicating just that.
Talk to IT leaders and one fact becomes clear quickly: The hardest part about DevOps is the associated culture change. You are tearing down boundaries that have existed for years, redistributing control, and challenging notions of expertise. This equals pain and stress for IT people.
Other top challenges include middle managers, who often put up fierce roadblocks to change, and dealing with the large amount of technical debt that exists in many IT organizations.
As Red Hat CIO Mike Kelly notes, “As their teams become more inclusive and collaborative, leaders must shift their strategies and tactics to harness the energy this new style of work generates. They need to perfect their methods for drawing multiple parties into dialog and ensuring everyone feels heard. And they need to hone their abilities to connect the work their teams are doing to their organization's values, aims, and goals – to make sure everyone in the department understands that they're part of something bigger than themselves (and their individual egos).”
Many companies succeed with a DevOps project for a specific problem, but later struggle to scale DevOps across the whole organization. Target CIO Mike McNamara says starting smart is key: “One vital part of Target’s process was the creation of an accelerated learning environment our teams call the ‘Dojo’,” he says.
“It’s an immersive, six-week session where teams execute their normal work with agile coaches on site to support them and provide anything they need from a DevOps point of view. The Dojo has been fantastic in getting teams engaged with agile and DevOps, removing the natural resistance and fear of change, and then supporting the team through the changes while maintaining productivity. It’s been a huge success for Target. And as we move through the journey, we continue to use the Dojo to refine, reinforce, and strengthen our engineering capabilities.” (See our related article, Target CIO explains how DevOps took root. )
As Matson CIO Peter Weis notes, the most gut-wrenching part of any transformation is the people part. With honesty and transparency, and clear support from business leadership, you can nurture culture change. But it requires great patience, says Ellucian CIO Lee Congdon, and perhaps a shared sense of ownership – an element he cites as key to his team’s culture change.
You may need to rethink titles and rewards as well. “If you need experimentation and speed, you need to change the way leaders are measured and the way and frequency in which they report progress,” says Bruno Guicardi, president and co-founder, CI&T. “If the way you measure success is demanding predictability (Mary must deliver project X by date Y), you are going to get neither speed nor experimentation.”
Some CIOs, like Adobe CIO Cynthia Stoddard, say a new physical environment can encourage collaboration, while Ellucian’s Congdon also stresses the value of communication tools, like Slack.
Above all, you need everyone’s buy-in to make DevOps culture change work, says Richard Li, who oversaw such a transformation as a co-founder at Datawire. You want an organic, bottom-up approach.
Li recommends you start small and solve specific, concrete problems using the DevOps style of working. “Perhaps it’s an engineer getting paged too frequently,” he says. “Perhaps an engineer is trying to get a database to be more resilient under an enormous load. Managers, ask your engineers what are the most annoying or painful problems: You’ll usually get an earful. Start there.”
You’ll also want to create forums to share the team’s successes and encourage engineers to engage outside your organization with other DevOps experts. For more advice, see Li’s article, 5 ways to nurture DevOps culture.
The best DevOps teams show their success in cold hard numbers – aligned to business goals. “It is entirely possible to have a team churning out software efficiently, but not adding real value to the enterprise,” Department of Homeland Security CTO Michael Hermus recently wrote. For this reason, his team is pursuing a suite of metrics that will include measures such as threat detection accuracy, which is key to his group’s mission.
Indeed, many teams will start DevOps metrics work by collecting data on efficiency and speed measures such as uptime, transactions per second, and bugs fixed. But that doesn’t make them metrics, says Red Hat technology evangelist Gordon Haff. “A metric is properly thought of as a key performance indicator for data – a measurement that’s important to you in some fundamental way,” he notes.
Seek to identify no more than 10 such metrics for your organization, ideally fewer, he says. “Consider metrics that can uncover broader organizational or process health issues in addition to more obvious operational and development data that you can collect from your computer systems.”
For example, your business is likely seeking boosts to both customer experience and operational efficiency. For customer experience, a metric such as Net Promoter Score might be appropriate. Customer ticket volume (as an indicator of overall customer satisfaction) and developer job satisfaction ratings (given how hard it is to attract and retain DevOps stars) are two other ratings to consider. For more advice, see our related article, DevOps metrics: Are you measuring what matters?
In short: No. DevOps discussions tend to focus on developers and operations teams, but project managers will survive and experience great change in the age of DevOps.
As our recent article, How to rethink project management for DevOps, noted: “DevOps fundamentally changes how IT teams approach projects, shifting away from monolithic, multi-month (or multi-year, in some cases) initiatives in pursuit of greater speed and agility in the software development lifecycle. That means changes for project managers. But make no mistake: Project managers can still be valuable in the DevOps age.”
“Traditionally, project management has been more monolithic and waterfall-methodology-driven,” says Mike Kail, co-founder and CTO at CYBRIC. “With DevOps transformation, the PMO function needs to take a ‘microservices’ approach that enables much higher velocity due to the smaller sub-projects.”
“As velocity of delivery increases, the importance of [shining a] spotlight on dependencies increases,” says Josh Collins, technology architect at Janeiro Digital. “There is now less time between deployments to integrate something from an upstream team or less time to get a full requirement from a stakeholder.” Scrum methodology and tools like Kanban boards can help here, he says. For more, see How to rethink project management for DevOps.
While introducing speed, DevOps teams must, of course, avoid introducing unwanted security risks. Thus the growing enterprise IT emphasis on “DevSecOps,” where teams build security into the whole software development lifecycle – beginning early.
“DevSecOps is not only tools, it is integrating a security mindset into development practices early on,” says Derek Weeks, VP and DevOps advocate at Sonatype.
This introduces another cultural challenge, says Red Hat security strategist Kirsten Newcomer.
“Security teams have historically been isolated from development teams – and each team has developed deep expertise in different areas of IT,” Newcomer says. “It doesn’t need to be this way. Enterprises that care deeply about security and also care deeply about their ability to quickly deliver business value through software are finding ways to move security left in their application development lifecycles. They’re adopting DevSecOps by integrating security practices, tooling, and automation throughout the CI/CD pipeline.”
“To do this well, they’re integrating their teams – security professionals are embedded with application development teams from inception (design) through to production deployment,” she says. “Both sides are seeing the value – each team expands their skill sets and knowledge base, making them more valuable technologists. DevOps done right – or DevSecOps – improves IT security.”
For detailed advice on how to beat the culture clash and tighten security, also see our related article, DevOps and security: 4 steps to end culture clash by DigiCert CTO Dan Timpson.
Where is DevOps heading in the enterprise? Our recent conversations with DevOps leaders surfaced several trends.
First, enterprises are using DevOps in combination with cloud services (for compute and storage power on demand), containers, and microservices.
“Containers, DevOps, and microservices all fit together to help CIOs achieve that goal of agility,” says Ashesh Badani, Red Hat’s VP and general manager, OpenShift. “In short, containers corral applications in a neat package, isolated from the host system on which they run. Developers can easily move them around during experimentation, which is a fundamental part of DevOps. Containers also prove helpful as you move quickly from development to production environments.” (For more, see our related article, 4 container adoption patterns: What you need to know.)
So teams need to understand the increasing interdependencies between containers, microservices, and cloud services – a combination that helps DevOps pros experiment and run quickly but safely. DevOps teams will need to manage and scale a microservices architecture, which is where orchestration tools like Kubernetes earn their keep.
Second, you can expect the DevOps way of working to spread beyond Dev, Ops, and security, into areas such as database teams, QA, and even potentially outside of IT altogether.
“This is a very DevOps thing to do: Identify areas of friction and resolve them,” says Datical's Reeves. “Security and databases are currently the big bottlenecks for companies that have previously adopted DevOps.”
Also, look for ROI measurement and success metrics to evolve for the better. “I believe that two of the core tenets of the DevOps culture, automation and measurement, are never ‘done,’” says Mike Kail, CTO at CYBRIC. “There will always be opportunities to automate a task or improve upon an already automated solution, and what is important to measure will likely change and expand over time. This maturation process is a continuous journey, not a destination or completed task.” For more, see our related article, What’s next in DevOps: 5 trends to watch. Also, see 5 DevOps leadership priorities in 2018.
In a word: Competitive. Companies looking to hire DevOps talent will find themselves lined up against many suitors. Sixty percent of hiring managers are looking to fill DevOps engineer positions, according to the 2017 Open Source Jobs Report, a study conducted by The Linux Foundation and tech jobs site Dice. That ranks second only to the broad category of “developers” (73 percent) as the most commonly sought-after roles in this year’s report.
Due to that level of competition, most companies find that training up talent in house, teaching eager people to adopt this new style of working, becomes mandatory. So does a new focus on talent retention.
While you’ll find plenty of job ads for “DevOps engineers,” many more people today work in a DevOps environment without having DevOps in their title.
Looking ahead, DevOps teams may involve more specialist roles. “As initially conceived, DevOps was often perceived (and sometimes implemented) as being about the elimination of specialist roles,” says Red Hat technology evangelist Gordon Haff. “Everyone does dev. Everyone does ops. Everyone carries a pager."
“But, especially in larger organizations, that’s not really right,” he explains. “Silos do have to be broken down. And it’s hard to argue against multidisciplinary teams. But there’s always going to be a need for specialists in areas like security and operating large-scale infrastructure. The key is for those specialists to effectively communicate with and provide tools for others to use.”
Especially as DevOps teams mature, they develop roles and processes that more specifically address their organization’s needs and business strategies, says Ben Newton, analytics lead at Sumo Logic. “I think the trend is for DevOps to just be a given for the modern organization, and the focus is then on figuring out what specializations are needed outside of the core developer/scrum teams that actually build and support their own code.”
He expects roles like site reliability engineers, security architects and specialists, and various iterations of QA/Testing engineers to increase in DevOps environments.
“We are also seeing more data science-oriented engineers driving development, since analytics is so key to being competitive today,” he adds. See our related article, DevOps Jobs: 4 trends to watch.
Also, check out our series for DevOps job hunters and hiring managers, for tips on transitioning into DevOps, tailoring your resume, and more.
Want to know even more? We’ve curated this list of articles and papers for IT leaders trying to build their DevOps expertise.
5 best practices for getting started with DevOps (Opensource.com)
Macquarie transforms digital banking with Red Hat OpenShift (Red Hat whitepaper)
What you should know about digital transformation (Red Hat video)
Teaching an elephant to dance (Red Hat ebook on DevOps culture change)
5 hurdles to adopting DevOps (CIO.com)
[ Also read: Hybrid Cloud: The IT Leader's Guide ]
Want more wisdom like this, IT leaders? Sign up for our weekly email newsletter.