DEVOPSdigest

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(link is external), 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.