Below I detail my key discoveries from the DevOps Agile Skills Association (DASA) Enterprise Leadership Forum (ELF) round table discussion on, “How do you get the board to buy-in your DevOps transformation plans?”
A typical consulting answer to the question about how to gain board buy-in is, “That depends.” For my session, one-panel member represented a long-established organization, and another a strong hierarchical corporation. Both had different adoption approaches, business drivers, and levels of IT capabilities as starting points. Gaining buy-in depends on both the trust and credibility of IT to be a board-level partner and the level of board awareness as to what technology can mean to the business.
Unfortunately, there is no silver bullet solution.
While the original topic of the ELF was about achieving board buy-in, it morphed into a broader exploration of the various dimensions that need to come together in harmony to support and enable a transformation initiative. A key conclusion and a motto that sums it up for me is, “Bring your teams close to your customers to solve their problems. It is not about the ‘potential’ of what technology can deliver but the performance that the business needs.”
This article explores some observed dimensions and a few of the dilemmas and choices that leadership teams need to make.
Below is a short summary of the key highlights before I explore these in more detail in the following sections. The discussions started with changing mindsets (attitudes) towards the need for new ways of working (behaviors) and the new principles and values (cultures) that these represent. Leadership teams play critical roles as enablers or barriers requiring updated leadership styles and skills. Transformation will impact existing ways of working that have been dominated by processes and SILOs, adjusting these to new ways of working characterized more by flow and value streams. This shift requires craftsmanship, new skills such as end-to-end technology skills, and CI/CD technology to manage and enable the flow of products to production. Flow generates the need to consider the organization and structure of end-to-end teams and how these are aligned to shared goals as opposed to SILO’ed goals. Changing an organizational structure will ultimately lead to changes in hierarchical models and the way the organization is governed and directed. This change needs to focus on driving objectives and key results (OKRs) for both short- and longer-term transformation ambitions and must deal with conflicting KPIs between business, development, and operations. Leadership teams must recognize that these different dimensions must be transformed in a holistic way. As stated by one-panel member, “Boards may think it is all about adopting OKRs and hoping things will change. This is like buying a new weighing scale and expecting to simply lose weight.” Transformation requires effort; in this example, changing your diet, doing exercise, and changing your lifestyle.
One key success factor for gaining buy-in for a transformation effort is clearly mindsets—both in business and IT. This includes mindsets influenced by the benefits of ’what is in it for me’ and ‘removing the fear,’, especially in connection with the impact of agile ways of working on compliance. Ask, “What makes people unsure or insecure about transforming?”
Two ways of gaining the buy-in were ‘show me’ and ‘storytelling,’ like having other organizations come and tell success stories or visiting other companies to see the solutions in action.
“Use the 30% of early adopter mindsets to start experimenting with pilot opportunities for new ways of working.”
Look at small pilot innovations that will not have a high impact on compliance. Business managers can tell stories of the benefits they got from DevOps pilots. This means aligning pilots to specific business stakeholder needs in terms of value. For example, if a finance manager is a key stakeholder, demonstrate the impact on cost reduction.
“Approach stakeholders from the angle of motivators or drivers. Understand what is top of mind for them; what are the problems they need to solve.”
Changing onboarding procedures was cited as one example of how to create a mindset shift straight away by focusing on customer-facing, outputs to outcomes, and new ways of working, then rolling this onboarding concept out on a broad level throughout the organization to create buy-in and a desire to change.
“The key is not telling people they must change, but creating a desire for change.”
Top-down vs. bottom-up was a recurring theme in the discussions. In organizations where IT may not have the trust or credibility to influence the board or where there is no clear desire from the board to transform, one approach is to build experiments from the bottom up and have business leaders promote the benefits. This shows the value of creating a desire for broader change by answering the question, “What’s in it for me?”
One organization was driven by the leadership board; fear of losing to competition was driving the transformation top-down, including a sense of urgency and the question, “What if we don’t?”
“All stakeholders are concerned with ‘what is in it for me’ and ‘what if we don’t?’”
A key driver for transformation is the need for speed and faster end-to-end deployment. Agility is the industry buzzword underpinning transformation, while a key success factor identified was flow.
Idea to cash or idea to outcome were cited. This implies, on the one hand, knowing what the cash or outcome needs to be, and on the other hand, means creating the necessary end-to-end value streams to make this happen. If you have SILO’ed teams with conflicting KPIs (e.g, development wants speed as a measure while operations want stability), this can create friction, frustration, and ultimately risk. It was clear that this flow and these value streams need to be BizDevOps, not just with a narrow focus on DevOps (see this article, the State of the Union).
Building craftsmanship around flow was viewed as vital. An example was building engineering capabilities like CI/CD and technology skills. However, there was also a shift to focus on a collaborative culture underpinned and driven by shared goals. Managing this type of culture change also requires a different set of skills, the so-called soft skills, which are the hardest to generate. This recent article summarizing the global findings from the DASA DevOps Competence Quickscan reveals some new skills that need to be developed. The concept of shared goals brought us on to the discussion around OKRs.
A topic related to board buy-in naturally brings the discussion onto OKRs. There is a perpetual conflict between development with KPIs on speed and operations with KPIs on stability. What counts is collaboration, and that means working towards shared goals (see this article on collaboration). In a discussion on top-down vs. bottom-up, it was suggested to first create clear end-to-end goals and desired results, put responsible, accountable, consulted, and informed (RACIs) in place, and bring teams close to customers. When you have this horizontal arrangement, then shift it up vertically to align with strategic OKRs.
“Trying top-down waterfalls of OKRs without value stream capability and conflicting SILO KPIs won’t work and won’t foster empowered teams.”
If you want to measure, then measure the baseline, the start position for any initiative or pilot. Measure this also in terms of stakeholder concerns, e.g., if finance is the pilot stakeholder and costs are a concern, then show how much cost is wasted and how adopting DevOps will impact this. Demonstrate and show clear, measured improvement linked to business results. This DASA whitepaper explores the question about the business value of DevOps in more detail.
“Measures are not just about velocity and flow and traditional DevOps metrics; remember, the whole purpose of transforming is realizing business outcomes.”
Visual radiators to monitor end-to-end flow were seen as important enablers, showing status and progress and highlighting areas for improvement to flow and value.
“Situational awareness is critical to support roles, enabling decision making, and focusing on eradicating waste and increasing flow.”
Gaining clarity of business context is critical; DevOps is not the goal! One way is to identify qualified business problem statements and then work backward through flow and value streams. One example cited was an airline check-in team. Business and IT worked together in the basement to improve handling time, looking at systems and people interactions, going to the check-in to see how it was working, and monitoring the impacts of the improvements in real-time feedback.
“Getting close to the customer to really understand the problem to be solved is key.”
Structure: Should the whole organizational structure be changed? One perspective was to start with new ways of working, flow, and collaboration at both team and SILO levels, breaking down the walls of confusion and transforming the hierarchical model.
Another perspective was to change the hierarchical model at the same time by moving seats around the table at board-level. A statement was “there is no revolution without casualties,” the word casualties implying pain and suffering. Often transformations are experienced and seen this way. There will inevitably be change, and change is often perceived as painful, yet the changes to roles, positions, and responsibilities can also be positive.
“These perceptions also need to be recognized and managed as part of an organizational change management approach.”
It was clear that leadership is crucial, and not all managers have the leadership styles, skills, and behaviors for an agile transformation. Sometimes, management change is also needed. As Einstein was quoted as saying, “We cannot solve our problems with the same thinking we used when we created them.”
Yet, it was concluded that the same managers might have critical knowledge and vital context information about the business that cannot be lost. Giving people new and different roles to bring out the best in them in this new way of working is crucial.
“Transformation is also about good talent and skills management. Skills to make us fit-for-the future.”
As the discussions evolved, I identified many touchpoints with an analysis in this recent article about why 70% of transformation initiatives fail. The article looks at several industry reports to identify five common areas for failure, looked at primarily from a people and leadership angle. These areas have clear overlaps with the ELF discussion topics and identified success factors:
The DevOps Agile Skills Association working groups are currently working on a Digital Readiness Assessment that also helps organizations assess how well they tackle these areas. The readiness assessment explores:
There is no silver bullet best practice blueprint way of transforming. However it is approached, it needs to be done in a holistic way considering a variety of dimensions. The business context should drive the transformation, the “Why are we doing this?” These business drivers are different for different organizations. The adoption of new, agile ways of working represents a significant change in mindsets (attitudes, behaviors, and culture) and demands new skills and improved end-to-end collaboration, breaking down long-standing SILO and SILO’ed ways of doing things. Leadership plays a crucial role as an enabler or barrier to successful change.
The DASA ELF aims to explore and foster these new leadership capabilities.
Published at Devopsagileskills.org, written by Paul Wilkinson (GamingWorks)