Skip to content

March 2, 2021

Culture and Leadership: The Seven Domains of Transformation

By IT Revolution

This is part of our Seven Domains of Transformation series, which has been adapted from the Project to Product Transformation white paper by Ross Clanton, Amy Walters, Jason Zubrick, Pat Birkeland, Mik Kersten, Alan Nance, and Anders Wallgren. You can download and read the white paper in its entirety here.


Why Is Culture and Leadership Important?

A product-centric operating model requires high levels of empowerment, collaboration, and experimentation. As Peter Drucker is widely attributed as saying, “Culture eats strategy for breakfast.”

It’s critical that you focus on leadership behaviors and fostering a culture to ensure that the organization can thrive as it moves to this new model. Core DevOps principles such as collaboration and empathy are necessary when an organization is striving to accelerate its ability to deliver highly targeted value to customers continually.

What Is Culture and Leadership?

The culture and leadership topics have been covered extensively in previous DevOps papers. However, in our interviews, we wanted to focus on a few key aspects of the culture and leadership domain that we felt were critical to address as part of an overall project to product transformation strategy. As a result, we primarily focused on two specific questions:

  1. What was done to align leadership and orient leadership behaviors?
  2. What actions did enterprises take to drive culture change and upskill their workforce given the changing operating model and expectations?

Effective leadership is critical to the success of any transformation. In this context, leadership includes technology executives, business executives, and middle management. In the interviews, we asked what was done to align these different stakeholder groups and what specific leadership behaviors were focused on.

Culture is a frequently discussed topic in the DevOps community. The levels of collaboration, sharing, and learning orientation needed to operate effectively when you are optimizing your organization for speed often requires a significant cultural change. There are a lot of great tactics in the DevOps Enterprise Forum paper Tactics for Leading Change that will help you on this journey. Additionally, we will identify some key tactics that enterprises have been leveraging to ignite and grow their project to product transformations.

How Are Enterprises Achieving Success?

The best examples we saw were when enterprises were able to simultaneously grow strong communities through a bottom-up transformation while also connecting with a clear, top-down drive to transform the organization.

In the incubation stage, the transformation would typically start with a bottom-up push for change. Pockets of change agents would start to connect within the organization and would band together to start challenging preconceived notions for how teams were supposed to work. In some cases, these groups would even take a bit of a rebellious approach—raging against the machine, so to speak—and attempt to distance themselves from the enterprise.

While that can be a good initial approach, bottom-up change can only go so far. A bottom-up movement is unlikely to reach all leaders and stakeholders across the organization. Successful transformations connect the bottom-up incubation with top-down, C-level buy-in.

The key is to find a transformational leader with significant political clout and savvy who is willing to sponsor and drive this transformational movement.

In some cases, enterprises were able to achieve this when new C-level leaders joined the company. Often when new executives join, they are looking to leave their mark on the company. If they are transformational leaders, they will typically look for a high-energy change initiative to sponsor and accelerate.

In one case, the chief technology officer who had joined one of the enterprises we interviewed had previously worked at a technology product company. She had a clear vision for the change she wanted to effect based on her previous experience. She personally led and sponsored the overall product transformation, including managing the expectations and commitments with her business counterparts, effectively pulling them in to be part of this change.

It was not uncommon to hear that before there was a driver for change, most of the companies we spoke with felt comfortable with the status quo. In some cases, this was coming from the top down. Some companies had extraordinary changes in market conditions which forced change onto them, but many of them were still content with their current state.

For some of the best change examples, this convergence of bottom-up and top-down transformation started to thaw the “frozen middle” that we referenced previously. In nearly all cases, we learned that one of the primary leadership challenges with transformation was middle management.

There are a lot of people in middle management roles in these large enterprises. These people have typically had success being operationally focused leaders. Additionally, they tend to face a lot of different demands in that they need to manage the expectations of the executives, their teams, and their clients. With everything they are responsible for, it shouldn’t be a surprise that this group is often slow to warm up to new ways of working. People are more open to change when they see the net benefit to that change. They need to see a pathway for future personal success. People are more likely to reject change if they perceive too much effort, time, or risk is required for the amount of value that will be returned.

Some of the key indicators we saw enterprises follow when overcoming inertia were:

  • Define new incentives: Early in the transformation, often while still in the incubation stage, executives would start to define a new set of incentives for their management teams. Not only would these incentives focus on outcomes over outputs, but they would also enable cohesion and empowerment. Examples of this would be encouraging management to create space for their teams to participate in learning- and community-focused events. Another would be encouraging reuse and sharing of code through inner-sourcing versus everyone building their own code from scratch. Identify the behaviors that you want to see and communicate these expectations to your teams.
  • Accept and acknowledge failure as part of the transformation process: When scaling the transformation, leaders would publicly emphasize “failing fast” and team empowerment. These are often two very difficult behaviors to get leaders and teams to change. For many enterprises, people are not comfortable admitting failure. Executives need to highlight the learning opportunities that emerge from failure.
  • Teach new leadership behaviors through workshops: To drive toward more servant leadership and empowerment-oriented leadership behaviors, some enterprises established leadership immersion workshops to expose the frozen middle and executives to this new way of working. They emphasized how teams are expected to work in this new model and provided real-world insights into why teams needed to be empowered to experiment and learn. Teams must continually discover and adapt the product they are delivering and increase their understanding of the viability, desirability, and feasibility of their project’s value for their customers.

Use Community-Based Learning

Across the enterprises we interviewed, there was a clear theme of focusing on growing a continuous learning culture. It’s important to use community-based learning to educate workers on new practices. There are a few ways to do this:

  • Organize teaching workshops led personally by management: In the early incubation stage, companies need to teach their workers about DevOps, Lean, Agile, and product-oriented methods. Success was seen in multiple instances where leaders took on the role of teachers and didn’t simply mandate change. In one scenario, a middle manager personally facilitated and ran Lean workshops where he taught other middle managers how to behave and operate differently. By taking the time to teach them, he was able to achieve more alignment and commitment than if he had just asserted to people that they need to change. Don’t just tell people what to do; give them examples and tools to teach them how to think.
  • Organize external DevOps/Product conferences: These conferences are structured with the goal of encouraging people to connect, share, and learn by facilitating horizontal interactions across the company. Many companies modeled these conferences after the public DevOps Days, as these events have proven highly successful at building community. These internal events allow employees to present to each other in a fun, engaging, high-energy environment. Structures generally follow a more “unconference” format to make the events feel informal and inviting.
  • Host hackathons: These have become a common tactic for enterprises looking to strengthen their engineering culture. They are yet another powerful way to bring people together from across the organization and get them to connect, share, and learn from each other. They are often focused on innovating on a customer or business problem that could be solved. There are many forms of hackathons in the industry, but we won’t be covering that in this paper.
  • Utilize Dojos: While Dojos have already been discussed due to their role in upskilling talent on modern product and technology practices, they have also proven to be a powerful mechanism to change culture in the companies that have adopted this model. So, how do Dojos enable this culture change?
    • Space: You can create a space to specifically foster openness, collaboration, and sharing. You break down the walls and create a fun and engaging environment that inspires creativity. Create teaming spaces that encourage different groups to come together, demo, and share their learning with each other. In more than one company, Dojo participants commented that they feel like they are working at a different company due to the different experiences they have in the Dojo.
    •  Process: You can orient your processes in the Dojo to get teams comfortable making decisions for themselves. The Dojo can be a safe zone. People experiment, fail, and learn in an environment where such actions are explicitly allowed and encouraged.
    • Coaches: Dojo coaches are often cultural experts and evangelists. They know exactly what is wrong with the existing culture within the company and are very well positioned to guide participants through the things they need to do to change. They also become a voice of the teams in the Dojos and coach management on what they need to change to enable and empower their teams.

There were not many enterprises we talked to that had truly optimized their culture and leadership. However, the few that were had become thought leaders and influencers in the external community. They would tell their stories and share their successes externally through conferences or outreach with other companies. Additionally, they would invite others to their companies to participate in their events and experience new ways of working.

Constraints That Need to Be Overcome

Culture and leadership are incredibly difficult aspects to change during a large-scale transformation because at their core these aspects deal with people and the interesting and challenging ways they react to change. While there can be a lot of constraints to work through in this domain, here are a few key ones:

  • Executive behaviors contradict cultural aspirations: This can be a very difficult problem to solve. Sometimes executives will communicate the goals of the transformation, such as “we are looking to empower teams to make more decisions” or “we need to start embracing failure so we can improve learning.” However, the behaviors of these executives don’t change to support these goals. Examples of this include executives still making technology decisions without engaging their tech workforce, or overcommitting delivery for their teams while expecting teams to do “death march” releases, leaving no time for community engagement and learning. This is a huge barrier to change as employees don’t believe the executives and stop listening to what they say. Instead, they watch what they do. It can be especially frustrating for employees when an executive’s words are not in sync with their actions. The best way to address this is toget transformational leaders in place who will model the behaviors needed for the transformation. When a change in leadership is not possible, invest in executive-level coaching to help identify when these behaviors are happening and to guide executives on how to act differently. It’s also beneficial to define new leadership behaviors and expectations for the organization.
  • Middle management resists change (the “frozen middle”) and is not addressed: This stakeholder group loses a lot of control in these new operating models. Technology tends to become much more transparent in a product-centric model. Not all leaders appreciate this transparency and would prefer that IT stay a black box to the business. Special attention should be placed on middle management to help them understand the value of these transformations, what their roles will entail, and how they can still thrive and be successful in the future model. You can leverage some of the tactics we already described in this section. When you’re incubating your transformation, focus on leaders who want to change and help them. As you build momentum, you can pivot more of the later adopters who want to see some success before they jump on board. However, even after all your best efforts, there might still be some that refuse to change. Build enough change momentum for leaders to realize that they need to decide to either get on board or leave the company. Some will leave, and that’s okay.
  • Existing talent does not participate in the new processes, leading to attrition: A big aspect of this change from project to product is the move to full-stack teams who build and run products. This has a few implications on people. First, in traditional enterprises people focused on building depth of expertise in one or two skills. If things fell outside of their knowledge, it was some other person’s responsibility. In a product-centric model, a team is collectively responsible for the end-to-end product. This means people sometimes step out of their comfort zone to learn and contribute in an area of delivering the product that isn’t their primary expertise. Second, in this model teams typically are responsible for running and supporting the products that they build and deliver. This means developers may start carrying pagers, which isn’t something many have had to deal with in the past. Don’t underestimate people’s resistance to change. Some may even choose to leave as they don’t want to sign up for these responsibilities. The biggest step you can take to help people through this change journey is to invest in them. Help them learn new practices, like how to engineer quality into the product they are building. Once they learn how much better the product outcomes can be following modern engineering practices and they feel proficient in doing these things, many will feel much more comfortable with the change.

In the continuing posts in this series, we will explore each of the Seven Domains of Transformation in more detail. 


In the full white paper, The Project to Product Transformation, you will find not only the guidance indicators to create, increase, and sustain velocity, but also the negative force learnings that should help you avoid pitfalls in your transformational journey.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Mitigating Unbundling’s Biggest Risk
    By Stephen Fishman , Matt McLarty

    If you haven’t already read Unbundling the Enterprise: APIs, Optionality, and the Science of…

    Navigating Cloud Decisions: Debunking Myths and Mitigating Risks
    By Summary by IT Revolution

    Organizations face critical decisions when selecting cloud service providers (CSPs). A recent paper titled…

    The Phoenix Project Comes to Life: Graphic Novel Adaptation Now Available!
    By IT Revolution

    We're thrilled to announce the release of The Phoenix Project: A Graphic Novel (Volume…

    Embracing Uncertainty: GenAI and Unbundling the Enterprise
    By Matt McLarty , Stephen Fishman

    The following post is an excerpt from the book Unbundling the Enterprise: APIs, Optionality, and…