In Part 1 and Part 2 of the DevOps Dojo – Lean Product series, we covered the why, what, and how of the product-centric model and lean product model as outlined in the White & Orange Belts of the DevOps Dojo.

In this third and last part of the Lean Product series, we will take on a view from 10,000 feet above and explore how adopting a Lean Product approach impacts three specific areas in large enterprises.

1. Lean Product impact on digital organizations’ operating model
2. Lean Product impact on digital organizations’ cloud transformation
3. Lean Product impact on leadership style in DevOps transformation

As it should be clear from the topics outlined above, Part 3 of the series is more targeted towards Business/IT digital leadership roles responsible for strategizing, planning, undergoing, or maturing DevOps and/or cloud transformations. Nonetheless, we think this is an important read for all stakeholders of such transformations, as being a change agent is a critical trait at all levels of such organizations. The topics covered in this blog are part of the DevOps Dojo C-level workshop.

I: Operating Model

One of the pitfalls many organizations fall into when experimenting/shifting from a project- and service centric model to a product-centric model, is underestimating the scope and impact of such a transformation. Let’s start from the fact that product centricity isn’t “just another way” of doing things, but rather a paradigm shift of how an organization structures itself, funds its efforts, grows its talents, manages the lifecycle of its value streams, maintains its relationships with its constituencies, and overall, how it delivers outcomes to its customers and its business.

Adopting the lean product approach requires some fundamental changes to the operating model. Operating models in traditional IT are primarily cost driven. Lean product centricity shifts the focus to value—discovering (i.e., experimenting and iterating) and rapidly delivering more innovative solutions with higher quality product features at a lower cost. To support this shift, CIOs must adjust the IT operating model, examining every component and modifying as needed to deliver business outcomes and customer satisfaction.

So, what is an IT operating model? According to Gartner, an IT operating model consists of the following components:

• Enterprise Governance
• Enterprise Culture
• Execute/Deliver to Strategy
  • Engage
    • Financials
    • Decision Rights
    • Performance
  • Enable
    • Talent
    • Sourcing and Alliance
    • Organizational Structure
  • Deliver
    • Place (Now more remote work)
    • Tools
    • Ways of working

Let’s take the lean product lens to look at the IT operating model in enterprise governance, decision rights, organizational structure, and ways of working components.

Traditional Enterprise IT Operating Model

The picture below visualizes the traditional enterprise IT operating model with separate blocks representing the split in responsibilities:

Business/IT split

Business stakeholders like the concrete certainty of targets for the features they need and request estimates from IT based on their backlogs.

IT operates in a project delivery model, releasing applications and features which are outputs for business. Since not all outputs bring the expected outcome, the business perceives their IT organization as slow and expensive.

As many organizations continue to pursue defensive central IT strategies, their business-IT relationships still result in partly adversarial experiences.

The lifecycle split

In IT organizations, there is a classic split of build versus run in the lifecycle management of workloads and the underlying platforms. Meaning that the team who has designed and developed the features is not the same as the one operating these. It is even common that different teams are responsible for coding, testing, deploying, and running the same product features resulting in more silos.

The layer split

Traditionally, there is a split between the technical application owners and the infrastructure team managing both the foundational infrastructure and the workload specific infrastructure. The divide between ownership of the application and the ownership of its dedicated underlying infrastructure and platform resources creates an additional silo that leads to more overhead and inefficiencies in the collaboration, communication, and overall productivity of the different stakeholders.

The shared resources split

Traditionally many resources are shared to optimize cost. To maintain business continuity, there may be multiple stakeholders contributing to the lifecycle of a workload such as enterprise architects at the inception of the project, the business owners of the workloads sporadically throughout the cycle, and security usually as part of the go-live checklist process.

Lean Product Enterprise IT Operating Model

The picture below visualizes the lean product operating model:

Business/IT Alignment

Instead of creating output-based roadmaps, business and IT work together to create outcome-based roadmaps. One way to do this is to plan a roadmap around the customer journey. With customer journey-based planning, business and IT can visualize what people do with products and visualize customer behavior.

As the outcome is the behavior that drives business results, this approach makes it easy to identify and concentrate on outcomes. Once the customer behaviors are visualized, business and IT can work together to determine which behaviors they want to encourage or eliminate, or which ones are missing in the system. Business/IT alignment not only creates higher value but also removes waste in the system, lowering the overall product delivery cost.

The Lifecycle Alignment

In the lean product-centric approach, the cross-functional, end-to-end teams have complete ownership of the specific value stream the application is supposed to provide across the lifecycle (end-to-end) and the across layers (cross-functional). So, the motto for the team becomes, “You build it, you test it, you deploy it, you run it, you own it, and you love it!”

The cross-functionality doesn’t stop at the Dev & Ops functions but includes the whole set of skillsets required to deliver the value stream. That includes stakeholders such as business, architecture, UX design, and security to name a few functions.

The Layer Alignment

Beyond the application layers, in a lean product-centric model, the underlying global, non-app specific infrastructure and platforms teams also operate in a cross-functional, end-to-end model, which will be elaborated on in the next chapter on cloud operating models.

Transitional Operating Models

“Nothing is more permanent than a temporary solution.”

– Milton Fridman

The picture below visualizes the four models from the most classic enterprise IT operating model (project-centric) on the left to the lean product enterprise IT operating model (product-centric) on the right. The possible models in between are treated as part of one of these four models for simplicity.

Project-centric organizations mostly use Model A or B shown below.

Under Model A and Model B, IT departments primarily expect detailed project requirements, execute projects, and hand them off to business and operations after acceptance. After completion, most IT resources move on to other projects and are unconcerned about problems noted by customers or with the success of the delivered application. That is because in these models, IT’s task is to focus on independent projects to meet requirements without the opportunity to work with stakeholders to consider the desired business capability, potential business value, or other broader life cycle management concerns such as the application’s role in broader business ecosystems.

Product-centric organizations mostly use Model C or D shown below.

In Model C and Model D, the product management model helps business stakeholders and IT to collaborate more effectively to answer business and customer problems with agility. This model optimizes product effectiveness and value throughout the entire life cycle of the product. The product manager’s end-to-end responsibility begins with ideation and continues through to retirement. Product managers work closely with agile teams to deliver a product. Once business stakeholders and IT establish the need for the product, they then apply design thinking, empathy, experimentation, and iterations to fulfill the business outcomes they agreed on rather than expecting stakeholders to dictate a detailed list of requirements.

II: Cloud Transformation

As of May 2022, most enterprise grade IT organizations have been on their cloud journeys for some time. They have migrated some or most of their classic on-prem workloads into cloud configurations (public, private, or hybrid). They might have built one or multiple cloud-native workloads, taking advantage of modern architectural patterns leveraging advanced native cloud services.

However, even though most companies moved to the cloud, not all have changed their behaviors in the cloud. In this case, they simply moved from one data center to another and have not pivoted from a project-centric model to a product-centric model.

Unsurprisingly, when it comes to adopting a product-centric approach, the focus is mostly centered around the new customer-facing cloud-native workloads. That’s where we see a mindset gap. Adopting a real product-centric approach gives you a set of new lenses that allow you to see a wider set of modernization opportunities with less “intuitive” blocks of your digital stack.

Let’s discuss first the digital paradox all organizations are faced with in their digital modernization journeys. The traditional wisdom states that between speed and control, you must pick one! If you want to maximize speed, you’ll have to let go of quality and control. If you want to maximize quality and control, then you must go slowly.

DevOps disrupted the industry by bringing the promise of gaining both speed and quality at the same time by building fast feedback loops. But this requires an operating model change and thus mindset change to apply the new way of working. The new operating model does increase the speed of delivery and improve quality controls by leveraging engineered/automated controls that take human action out of repetitive tasks of the flow, thereby enabling scalability and scale.

For those organizations that didn’t embrace modern DevOps practices, the digital paradox is still very real and a daily pain point. Thus, when it comes to cloud operating models, we usually see organizations opting for one extreme or the other. We consider both to be anti-patterns for successful cloud transformation as discussed below.

Anti-pattern 1: Speed Maximalism

In this approach, organizations are optimizing speed by allowing each business unit (BU) digital team to have its own direct access to the cloud platform. This model allows BUs to innovate and iterate faster to take advantage of cloud flexibility. In such an approach, the central IT organization is at best a procurement channel for cloud contracts, and at worst not even in the picture or simply a support organization.

As one imagines, this approach does indeed allow the different business units to operate more freely on the cloud, but considerable inefficiencies and risks arise mainly around three areas: Cost, security, and consistency.

Cost

Each BU will focus on the specific profits and losses of their own workloads, hence optimizing for local optimums and missing global savings opportunities across the organization.

Security

In DevOps, security is the job of everyone, but in traditional organizations, the security function is primarily fulfilled by the CISO organization. BUs will be building their workloads, and when the time comes for launch, one of two scenarios will take place:

1. Shadow launch: This means to go live without going through the central security organization. This is a rare occurrence for business-critical workloads that need access to corporate or customer data. However, some workloads do pass the filter especially when their data layer isn’t centrally governed. Shadow launch creates considerable risks for exploitation due to the workload team underestimating the “sensitivity” of their workload’s data layer or underestimating the unknown attack surfaces that go beyond their application layer.

2. Security as a last-minute checkbox: The workload team approaches the security team as part of the go-live checklist well beyond “after the fact,” pressuring the security team to validate and approve a complex solution that has been in the making for months. This approach always results in frustration from both sides and, in the end, a compromise from the security team by accepting risks that should not have been accepted, at best adding a few rushed security feature additions to the workload due to the pressure of the go-live deadline. If a significant delay of the go-to-market occurs, security must go through for an acceptable review due to the significant assessment and discovery.

Consistency

As each BU has its own implementation in almost everything, enterprise architecture, which is normally accountable for the consistency among the workloads in the organization, simply becomes a governance body that doesn’t have much power to overwrite each BU’s priority.

This model usually doesn’t last long as sooner rather than later, either the cloud cost would get out of control and/or security and compliance issues would arise, so central IT organizations will take back the “rebels” into the other extreme of the spectrum, “Control land”.

Anti-pattern 2: Control Maximalism

This anti-pattern does not require a lot of elaboration since it is the most common approach and is probably well-known to everyone. When traditional IT operating models are “lifted and shifted” to the cloud along with the VMs, a central cloud operations team becomes responsible for provisioning and delivering to workload owners the different cloud resources required for their applications.

The more workloads that are onboarded to the cloud, the bigger the backlog of the central IT team that quickly becomes a bottleneck. This inevitably leads to the frustration of business stakeholders and IT leadership who don’t see the full speed and agility that was promised to them during the cloud strategy design phase of their transformation. Even worse, they don’t get the centralization benefits of cost efficiency and synergy as this central team struggles between provisioning workload resources and monitoring the underlying platform to design and build common cost and scalability controls.

That is when the business chooses shadow IT.

Research has shown that business-led IT (shadow IT) spending is, on average, 36% of the formal IT spending managed by the IT organization(s).

The Better Way: Aligned Autonomy

In the lean product world, we strive to achieve what we call at Microsoft, “aligned autonomy,” a sweet spot that balances between speed and control. But how do we do that?

In a lean product-centric operating model, all major cloud value streams are designed, delivered, and managed as digital products including:

• Cloud-native applications (both internal and customer facing)
• Classic applications (both internal and customer facing)
• Underlying Cloud Fabric powering all workloads on top of it as an internal platform product

In a nutshell, not only can the “classic” workloads (legacy migrated to cloud in IaaS architecture) be managed in a lean product-centric approach, but also the underlying Cloud Fabric itself can be managed as an internal lean product, which puts us in the sweet spot of the digital paradox (balancing between speed and control) and hence achieves what we call “governed agility.” This allows all internal cloud consuming teams to iterate and innovate fast without compromising on governance, security, and cost efficiency. Let’s explore how.

What is a Cloud Fabric product team?

The Cloud Fabric product team is an end-to-end cross-functional team that is responsible for offering the cloud platform as an internal product at scale. Its customers are all workload teams that want to use cloud services to build, deploy, and operate their applications whether legacy or cloud native.

What is the Cloud Fabric features/services?

The Cloud Fabric is primarily composed of two main layers:

• Managed Global Core Services such as Networking, Identity, Security. This layer is called the Landing Zones in the Microsoft Cloud Adoption Framework
• Engineered Global Governance Controls spanning Cost Management, Identity Baseline, Security Baseline, Resource Consistency, and Deployment Acceleration.

Engineered Governance, where more quality adds more speed!

The secret ingredient to make Cloud Fabric scalable is to develop “engineered” governance controls incrementally. As workloads are deployed to the cloud, the potential increases to introduce previously unidentified threats, business- and IT risks. These threats and risks can be addressed as they’re identified, providing a stable ongoing model for developing governance maturity. Next to scalability, this also allows the adoption of a product-centric operating model, where all workloads can be onboarded to the cloud in a secure, consistent, cost-effective way.

In the case of Azure, Microsoft designed all cloud governance and management services to be engineerable through automatable “controls as code” components ranging from Policies, to Access Controls, Cost Controls and so on. More information can be found in the Govern pillar of CAF.

For the purposes of this article, the main takeaway is that engineering the different governance and management controls of the underlying cloud platforms allows us to directly offer our enterprise cloud platform as an internal product that can be directly consumed by different workload teams in a scalable, consistent, secure, and cost-effective way without having to ask for permission or request resources from a centralized team, hence achieving the aligned autonomy that lies in the sweet spot between speed and control.

How does Microsoft implement aligned autonomy?

In Microsoft product groups, we created a 1ES (one engineering system) to enable aligned autonomy in three areas:

1. InnerSource everything—it is both a cultural and process change
2. Define mandatory functions such as security, risk, compliance, and repos in Git
3. Create the Center of Excellence (CoE) to enable and support product teams

III: Leadership Style

The lean product-centric model is the management of the complete life cycle of a product applying the principles and practices of lean startup, lean, customer-centricity, business modelling, financial viability, outcome-driven innovation, behavioral economics, and strategy. Lean Product is about establishing a culture that puts the user first and builds the organization and teams around that customer to ensure that you are building the best product possible. Therefore, lean product requires a different leadership style compared to classic leadership styles in DevOps transformation.

Leadership in the organizational context can take on several shapes and forms both colorful and monochrome with an inclination toward either hierarchical or heterarchical structures. Leadership has been characterized as the dyadic relationship between an individual and a group (Knickerbocker, 1948), the effort to change the behavior of others (Bass, 1961), a form of social influence (Pondy, 1989), and even the ability to start evolutionary change processes that are more adaptive (Schein, 1992).

One of the main pillars of modern leadership styles is that it transforms followers, creates visions of the goals that may be attained, and articulates the followers’ ways to attain those goals (Burns, 1978). Such traits are found in transformational leadership whereby leaders who possess those skills mobilize resources to arouse, engage, and satisfy the motives of followers. This leads to interactions where leaders can become agents of change whose acts affect other people more than other people’s acts affect them—leaders start acting as servants to groups of followers or teams to achieve a higher, more common purpose than that of the collection of the servant leader and the group. Thus, leadership has a unique role to play in the personal purposes and goals of symbiotic visions, i.e., teams of people that denote a mutually beneficial relationship between different individuals or teams.

The 2017 State of DevOps Report indicated that transformational leadership is what differentiates considerably low- and medium- from high-performing organizations. In fact, leadership in organizations that are self-characterized as DevOps-oriented have been an emergent theme for the past few years. The word, “leader,” and its extended wording, “leadership,” has just 6 mentions in the 2019 edition, 11 mentions in 2020, and 33 mentions in 2021.

Leadership buy-in for adoption of DevOps practices and principles is a key predictor of success for the entire organization, but a common question is, “How can leadership demonstrate their commitment to change?” Executive leadership may not have the ability to change the daily habits of teams or engineers, but they do have a lot of influence over organizational structure and value streams. The formation of a platform as a product and one or more teams to support that platform is an action that executive leadership can take to expand DevOps success beyond the pockets of a couple teams doing laps around others. However, this is not just renaming an operations function.

What does “transformational” mean?

To further develop the aforementioned leadership style, it is necessary to set a clear path for what “transformational” means and how the following four pillars constitute its essence:

Intellectual Stimulation (IS)

• Challenge the status quo
• Encourage followers to learn, be creative, and explore new ways of doing things
• Decentralize decision making
• Expect relentless improvement
• Encourage innovative thinking
• Adaptive leadership
• Unlock intrinsic motivation

Individualized Consideration (IC)

• Offer personalized support, coaching, and encouragement
• Keep lines of communication open
• Offer direct recognition of individual and team contributions
• Exhibit genuine care and concern
• Be empathetic (linkage to servant leadership)
• Develop leaders to empower others

Inspirational Motivation (IM)

• Inspire and align with a mission (linkage to charismatic leadership)
• Articulate a clear vision and intent
• Inspire passion and motivation to achieve goals
• Drive organizational alignment
• Encourage others

Idealized Influence (IIA/IIB)

• Lead and foster change
• Know the way (linkage to authentic and charismatic leadership)
• Be a role model—set an example
• Be a lifelong learner—gain the knowledge required for change
• Create an environment of trust and respect through transparency
• Act with integrity

Additionally, the State of DevOps Report conveys that DevOps leaders with a servant leadership mentality inspired better team performance. The leader is essentially serving rather than being served and this renewed approach creates an environment of trust, collaboration, and reciprocal service which ultimately leads to higher performance. Servant leadership was developed as a theory of ethical leadership that is comprised of values such as integrity, altruism, humility, empathy and healing, personal growth, fairness, justice, and empowerment. “Servant leadership is a holistic leadership approach that engages followers in multiple dimensions such as relational, ethical, emotional, spiritual in order to empower them to grow into what they are capable of becoming”.

Cultural enablers used to promote the adoption of DevOps practices are leadership, focus on decision-making, customer focus, engineering practices, learning and development, team recognition, innovation, guilds, and performance feedback. According to the State of DevOps Report (Puppet, 2021), there is an increasing inclusion of IT team members in DevOps teams and up until 2018, there was an increasing inclusion of respondents identifying themselves as working in DevOps teams, which deflated slightly in 2019 and for the past three years it has stabilized at 2016 levels.

Which leadership styles enable lean product adoption?

What is fascinating in the research of leadership and its linkage to human psychology is that there is an emerging set of personal dispositions associated with leadership including cognitive ability, cognitive load, persistence, and sense of responsibility in the organizational environment. Bass (1960) concluded that, “No matter where you put some people, they will emerge and succeed as leaders.” In other words, leadership traits will be exposed in cross-regional and cross-industry situations where we are likely to witness more determination in the personality of transformational leaders than those who are transactional. Variance does exist in the aforementioned cases, but it is attributed to different cultures and organizations (Bass & Riggio, 2006).

The top leadership skills identified are as follows:

1. Communication and collaboration
2. Active listening
3. Customer-centric mindset
4. Technical background
5. Empathetic
6. Multicultural mindset
7. Influential
8. Agile management
9. Strategic thinking
10. Project management

Which factors slow down Lean Product adoption?

In general, organizations and industry IT practitioners place the product-centric model and DevOps in high regard, but lean product practices and principles adoption is associated with some challenges. The most predominant lean product adoption inhibitors are:

1. Communication barriers
2. Lack of cross-functional collaboration
3. Lack of senior management buy-in
4. Lack of leadership
5. Lack of cross-functional leadership
6. Lack of enterprise-wide DevOps adoption
7. Plethora of IT systems coupled with numerous IT support roles
8. Lack of cross-functional collaboration
9. Lack of commitment by customers
10. Lack of organizational practice adoption capability

Among those inhibitors, the top three challenges are organizational culture, lack of leadership, and talents/skills.

First, cultural behaviors that make organizational group distinctions of defining responsibility, especially in terms of “us” and “them,” are immensely detrimental to the cross-functional team collaboration mode and the cross-functional leadership lean product aims to achieve. In essence, this inhibitor leads the enterprise-wide adoption of lean product towards failure from the start of such an initiative, which implies that it is important to first let the cultural character within the IT organization take form and shape and then aim for adoption at a wider scale outside the IT organization.

Second, a “lack of leadership” to an organization’s employees can simply mean lacking “walk-the-talk” attitudes, leadership-by-example, confrontation with undesirable behaviors, or reward of new behaviors depending on the hierarchical or heterarchical degree of the organization’s leaders.

Finally, talent seeking should be co-owned and considered an important characteristic of the lean product adoption leader and not left to the exclusive ownership of Human Resources. In fact, the perception that Lean Product teams and their leaders should not engage or engage minimally with talent seeking opportunities could affect the future membership and talent diversity of those teams.

What are the key metrics for lean product adoption leadership?

Metrics in traditional highly structured corporate environments produce development cycles that focus a lot on defect density of the software product, yet this is not the most effective way to measure quality in the context of software product development. The effect that traditional approaches have had on product development is that “surrogation” (hbr.org/2019/09/dont-let-metrics-undermine-your-business/) can lead to enterprise strategy being replaced with metrics, with employees consciously aiming to contribute to local optima rather than global corporate optima to increase flow in the value stream.

Let’s first look at the key metrics for DevOps adoption leadership. In a survey conducted by Maroukian and Gulliver (2020), 250 participants with 90% from the EMEA region indicated that DevOps adoption leadership practices should still be governed by traditional approaches such as critical success factors (CSF), key performance indicators (KPI), and time-to-market.

However, agile, and lean metrics formed a significant part of the wider picture with the top five most popular being: (1) deployment frequency; (2) deployment duration; (3) time to detect defect; (4) time to recover; (5) behavioral metrics.

The DevOps-oriented metrics (1) to (4) indicate software product development measurements that can apply to a DevOps team structure as well as to the DevOps leadership role. From the cultural perspective, point (5) behavioral metrics can refer to behaviors and attitudes that aim to increase knowledge sharing in a cross-functional fashion as well as the frequency that a leader performs one-to-ones with DevOps teams and their members to understand what is going on in their minds. The DevOps adoption leadership role should be associated with and have ownership of these metrics in order to facilitate the DevOps team members’ efforts in the adoption of practices and principles to achieve those very metrics.

Let’s then look at the key metrics for lean product adoption leadership.

Ultimately, the way we deliver on a company’s mission is to develop products and services for our customers. The product vision is how we hope to do that. OKRs unfold from the vision, mission, and strategy. The OKRs are a way to articulate the strategy into actions (objectives) and establish metrics that will prove whether the strategy is being executed (key results). Strategy provides the initial context for the creation of OKRs and OKRs should be directly translated from your strategy. Strategy should be in place before embarking on your OKR implementation. Strategy should be widely communicated and understood as it helps determine what not to do and can align your entire organization.

OKRs have a soul and directionality to them. Your objective is what you want to accomplish. Your key results are how you get there. Since KPIs are measures, they make great key results. In our next blog, we will discuss the challenges and our learnings of adopting OKRs in the Dojo community. We will discuss outputs, outcomes, and impact in the context of OKRs.

IV: Final Thoughts

Recently, McKinsey, Microsoft, GitHub and HashiCorp developed a paper called “Developer Velocity.” Of the more than 57 drivers tested, four were considered to be the most important drivers for business performance: Product management, culture, developer tools, and talent management.

We hope our lean product blogs give you food for thought in your DevOps transformation journey. We would love to hear about your experience and learnings in adopting Lean Product in your organizations.

V: Special Dedications

This blog was written and reviewed by the following authors in the Dojo Community.

• April Edwards April.Edwards@microsoft.com
• Amine Rahmouni Amine.Rahmouni@microsoft.com
• Krikor Maroukian krmaro@microsoft.com
• Beste Altinay Beste.Altinay@microsoft.com
• Paul Fijnvandraat Paul.Fijnvandraat@microsoft.com
• Reggie Best rebest@microsoft.com
• Kan Tang kan.tang@microsoft.com