Leading by Example - Transformation Leadership Requires DevOps Chops
January 25, 2021

Jeanne Morain
iSpeak Cloud

Leading large Transformation efforts — that involve the creation of a Continuous Integration, Continuous Delivery Pipeline and practice — require knowledge of not only DevOps technology but how to operationalize it and scale it. According to CNBC, although two thirds of companies are undergoing transformation, 70% are still failing, equating to billions in losses. Although, CNBC attributes these losses to communication breakdown, there are more factors that contribute to failures that should not be overlooked. The breakdown in communication typically is that various siloes, leadership, and supporting teams are lost in translation.

Large Transformation initiatives require several layers of individuals — from Leaders to Support Desk — working together for the greater good of the company. More often than not the translation of information between the various layers is where the communication breakdown occurs. In order to truly lead Transformation leaders must have or surround themselves with those that can translate across the layers. One of my favorite quotes is "Vision without execution is hallucination." In order to truly lead these larger initiatives, one must understand what success looks like and lead the team across various levels through communicating, communicating, communicating.

It sounds easier than it is. Part of effective communication is for leaders to have a baseline understanding of not only the goal but what it really means and how you get there. For example, one CTO recently asked his peers if they knew what Cloud Native was. It was not to be condescending, but he was questioning if operations, development, and support understood not only the technology, but also what programmatic changes moving to Cloud Native and a container architecture meant for the company. Why? As a leader he understood that the people and process breakdowns result in large scale failure over technology. The best architecture and technology in the world cannot launch, support, and maintain itself.

The point this particular CTO was trying to make was DevOps goes beyond the CTO, architecture and technology. DecSecOps is the binding mindset across Dev, Security and Operations to deliver value to the Business. More often than not, you may have leaders and/or architects that understand the technology but do not understand the people or process required to actually succeed. DevSecOps starts with architecture but must permeate across the entire organization to succeed. DevSecOps does not just start with the edict from above but only succeeds with the right people and processes in place to translate vision to execution. Leaders at lower levels across Development, Security, Operations and Architecture that have been there, done that. Ones that not only know the technology but understand the implications of how to implement it at scale to reduce cost and increase velocity.

Key principles of DevOps Leaders at the lower levels are:

■ Know the business impact

■ Focus on automation for scale

■ Communicate up, out and down early and often

■ Security and compliance by design from inception until end of life

■ Identify and address risks (containers, processes, skillsets)

It is often too easy to point to senior leadership as the reason a large Transformation initiative failed or succeeded. However, few in DevSecOps speak of the part that contributed to that failure. Many seek the advice of expensive consultants that are no more experienced than the team members already in place. Or perhaps, they are just looking at it from their perspective but failing to see the larger picture of what is needed for that particular organization to be successful. Perspective is a powerful tool that can only be achieved by active listening.

What is an example of "lost in translation" perspective" Recently an architect pushed back on automating a process that would only be done once. When the product owner pushed back, they were shut down by the architect for not having a "DevOps" mindset. They were told that part of DevOps is Infrastructure as Code, and that it was perfectly acceptable to expect each development team to extend their code to include the setup on a per application basis. The DevOps architect believed that they were "shifting the mindset" because the developers were lazy and operations team was incompetent. The architect’s arrogance and inability to try to empathize with the request before saying it was the only solution prove to be short sighted.

Unfortunately, it was the DevOps architect that was blind to the business impact of their decision. This particular organization had 3000 applications to migrate to the Continuous Integration, Continuous Delivery Pipeline. The architect failed to consider the cost to the organization to train the application teams to add the code; for support teams to support the errors or mistakes in the process; for the creation of knowledge base articles, content to deal with ongoing security and compliance escalations. It was not that the developers were lazy, Support did not want to learn Kubernetes — the architecture did not make financial sense for the business.

The product owner did the math, escalated to leadership and led to the CTO’s question. The number of tickets to implement the solution would have been at least 12,000 across support, deployment, site reliability engineering and the customers. The risk to audit alone by implementing a manual process was enough to shut it down from a leadership perspective. When the architect was questioned, his answer was he does not believe in merely counting tickets. He believes these pipelines take at least 5 years or more to build out (after 3 years into it).

As DevSecOps enthusiasts and leaders, we must not discount or discredit those that understand the business impact beyond the technology. Transformation must have leaders that not only understand Containers, Cloud and DevSecOps tools but also impact on People and Process. While failure is the cut of 1000 blades of ignorance — success is measured by the teams working together to breakdown the silos across technology teams and DevSecOps to enhance velocity, not impede it. True leaders will lead by example and work to unite the teams regardless of structure, appointment, and job description because ultimately if the company fails, the entire team does. It is better to win working together than to fail fighting.

I was recently a guest on AlchemistX: Innovators Inside, the podcast about why corporate innovation is hard. I spoke with @RachelChalmers of @alchemistxii about how I got to where I am today. Click the podcast player below to listen.

Jeanne Morain is an Author/Strategist with iSpeak Cloud
Share this

Industry News

December 06, 2021

Ascend.io announced support for Amazon Redshift Serverless powered on Amazon Web Services, Inc. (AWS), a fully managed petabyte-scale cloud data warehouse.

December 06, 2021

Neosec formed a strategic partnership with Kong Inc. to integrate its API security platform with Kong Gateway to provide a complete enterprise-class solution for managing and securing APIs and microservices.

December 02, 2021

Mirantis announced DevOpsCare, powered by Lens, a vendor-agnostic, fully-managed CI/CD (continuous integration/continuous deployment) product for any Kubernetes environment, offering developers higher levels of productivity more quickly.

December 02, 2021

The D2iQ Kubernetes Platform (DKP) is now available in AWS Marketplace, a digital catalog with thousands of software listings from independent software vendors that make it easy to find, test, buy, and deploy software that runs on Amazon Web Services, Inc. (AWS).

December 01, 2021

Bugcrowd announced the availability of Bugcrowd's cybersecurity solutions on the AWS Marketplace, providing customers with easy access, simplified billing, quick deployment, and streamlined license management.

December 01, 2021

Kublr received Microsoft Azure Arc-enabled Kubernetes validation, including for Azure Arc-enabled Kubernetes for Data Services.

December 01, 2021

CloudSphere achieved Amazon Web Services (AWS) Migration and Modernization Competency for discovering, planning, and helping enterprise customers move business services to AWS to reduce cost, increase agility and improve security.

November 30, 2021

JFrog introduced a new container registry and package manager for running JFrog Artifactory with Kubernetes clusters on-premises, in the cloud, or both.

November 30, 2021

Docker announced the availability of Docker Official Images directly from Amazon Web Services (AWS).

November 30, 2021

Weaveworks announced the general availability of Weave GitOps Enterprise, a GitOps platform that automates continuous application delivery and Kubernetes operations at any scale.

November 30, 2021

Amazon Web Services announced AWS Mainframe Modernization, a new service that makes it faster and easier for customers to migrate mainframe and legacy workloads to the cloud, and enjoy the superior agility, elasticity, and cost savings of AWS.

November 29, 2021

Quali announced the newest release of Torque Enterprise, which includes enhanced integration with Terraform, new custom tagging capabilities, and improved cost visibility dashboards, unleashing an entirely new level of self-service access to application environments on demand.

November 29, 2021

Vertical Relevance (VR), a financial services-focused consulting firm, achieved Amazon Web Services (AWS) DevOps Competency status.

November 18, 2021

Loft Labs announced the launch of Loft version 2 with a focus on ease of use that overcomes the major complaint that Kubernetes is complex and hard to set up.

November 18, 2021

Perforce Software announced new functionality to speed remediation of discovered defects in automated scans.