Rethink Your Understanding

Transforming Software Delivery

Metrics

Transforming Engineering: From Cost Center to Strategic Partner

by

7 min read

This article is the second in a three-part series exploring how software engineering can deliver measurable business value. If you missed the first article, start here.

A Leadership Epiphany

At the end of 2024, I reached a key moment in my career, reflecting on almost 30 years in technology leadership. In December, I published an article titled Crossroads: 2024 Reflections on Leadership, Legacy, and Modern Practices. The article explores my experiences with digital transformation, how leadership has evolved, and the changing role of technology in organizations.

The article covered key moments in my career, including my shift from improving engineering efficiency to focusing on delivering outcomes. It shared lessons I’ve learned about balancing workflow with value and the importance of aligning engineering efforts with organizational goals.

This article builds on those reflections, incorporating feedback and self-assessment to share the lessons I’ve learned and the changes I’ve made. It focuses on one key piece of feedback that changed how I approach leadership. My organization enrolled me and other senior leaders in a coaching program called The Extraordinary Leader. The program offered me a comprehensive 360-degree leadership assessment, which was both insightful and humbling. The results affirmed my commitment to a people-first leadership approach and my effort to develop my style. However, one piece of feedback stood out above the rest: “You should focus more on driving business results.”

At first, the feedback stung. We had spent years spearheading digital transformation initiatives—adopting Agile, DevOps, and Value Stream Management (VSM)—to improve operational efficiency, agility, and speed to market. These efforts enabled us to scale from $10 million to $110 million in revenue. Yet, it became clear that while our technology work was essential, we hadn’t effectively communicated its impact on the organization’s bottom line. My sales, marketing, and product peers had explicit metrics like revenue targets and customer growth, but engineering lacked a direct narrative linking its efforts to these outcomes.

We adopted Value Stream Management to bridge this gap and transitioned to a product operating model. VSM provided clear visibility into engineering workflows, from ideation to delivering measurable value, while the product operating model aligned teams with specific products or value streams. This shift empowered teams to understand the customer and business needs they support, iteratively improving outcomes over the product lifecycle. By focusing on products rather than temporary projects, teams developed subject matter expertise, drove innovation, and wholly owned their results, transforming engineering from a cost center into a strategic partner.

This realization led to a profound reflection on my leadership approach. While I had focused heavily on flow—ensuring work moved efficiently from idea to delivery—I hadn’t emphasized value realization: the tangible business impact of our efforts. This gap became a call to action: to redefine how technology aligns with and communicates its contribution to organizational success.

This Article at a Glance

Expanding on my earlier insights, this article explores:

  • Bridging the Gap: How feedback led me to revise our division’s mission, vision, and purpose to better align with business objectives.
  • Operational Efficiency vs. Value Realization: Balancing delivery speed with measurable outcomes is essential.
  • Embedding Outcomes Into Workflow: Practical steps for tying engineering work to organizational strategy and customer impact.
  • The Power of Language: Technology leaders must articulate the value of technical investments and technical debt in business-focused terms that align with priorities and resonate with key stakeholders.
  • A Call to Action: How technology teams can move from being seen as cost centers to strategic partners.

Engineering’s Philosophy: Code Is Not the Product

At the heart of our transformation lies a guiding philosophy: “Code is not the product. The value it brings is the product.”

This philosophy reshaped how we approach our work, from mission to execution. Our approach centers on two pillars:

  1. Flow: Improving the efficiency and quality of how work moves through teams and systems.
  2. Value Realization: Identifying and measuring the actual business and customer results of completed work.

Balancing these two pillars ensures that we deliver efficiently and create meaningful results.

Speaking the Language of Business

One of the greatest challenges for technology leaders is translating technical initiatives into terms the business understands. This communication requires reframing technical concepts—like reducing technical debt or implementing refactoring—regarding their impact on business outcomes. For example:

  • Instead of, “We need to address technical debt,” explain, “This initiative will reduce downtime risk and enable us to deliver features 30% faster.”
  • Rather than saying, “We’re optimizing the architecture,” highlight, “This change will scale our platform to support twice as many customers next year.”

Engineering becomes part of the strategic conversation by framing technical work regarding customer retention, revenue growth, or operational efficiency. By quantifying the return on investment (ROI) of addressing technical debt—such as projecting a 30% increase in delivery speed—we can demonstrate how these investments contribute to revenue growth and operational efficiency. This approach bridges the gap between technical efforts and business priorities, ensuring that engineering is seen as a strategic partner, not just a cost center.

Embedding Outcomes Into Engineering Work

Integrating expected outcomes into the team’s work and requiring every Epic to define a specific anticipated outcome helps bridge the divide between effort and impact. This approach ensures teams fully grasp the “why” behind their work and understand its alignment with organizational objectives. For each Epic, teams are encouraged to define the anticipated outcome and to consider key questions such as:

  • What problem are we solving?
  • What results do we expect, and how will we measure them?
  • What metrics define success?
  • How will we learn from the outcomes?

This clarity fosters accountability, focus, and a shift from delivering tasks to achieving meaningful results. By integrating Value Stream Management principles and the product operating model, we create a clear connection between technical initiatives and their business impact, aligning teams at every level.

OKRs further strengthen this alignment by linking engineering work to measurable outcomes. Team-level OKRs focus on delivering customer value while connecting day-to-day tasks to broader organizational goals. Embedding Outcomes in Epics and OKRs transforms engineering from a cost center to a strategic partner, demonstrating how every contribution drives customer impact and business success.

Every outcome or team-level OKR must have a clear owner—someone accountable for bringing the objective to the team, ensuring alignment, and seeing it through to completion. This owner, whether a Product Manager, technical lead, or another designated team member, is the point person for driving the initiative forward. They are responsible for defining the outcome and collaborating with the team to ensure it is achievable, measurable, and tied to organizational goals.

An accountable owner ensures that outcomes are not vague concepts but actionable goals with clear responsibility. This ownership fosters clarity, prevents ambiguity, and strengthens accountability within the team. For example, a Product Manager might own a customer-facing feature’s outcome, ensuring it improves user engagement by 15%, while a technical lead might own the outcome of reducing system downtime by 20%.

By assigning ownership, teams can better prioritize their efforts, align around shared goals, and deliver outcomes that matter. Ownership also reinforces the importance of closing the loop—documenting actual outcomes and reflecting on whether the objectives were achieved—ensuring a culture of accountability and continuous improvement.

Minimizing Layoffs and Rethinking Team Design

One of my long-term goals is to minimize layoffs as a cost-cutting measure by demonstrating the business value of engineering teams. Too often, layoffs are driven by salary costs, ignoring these teams’ contributions to revenue growth, customer retention, and operational efficiency.

Preventing layoffs begins with how we build and structure teams. Instead of defaulting to large, reactive hiring sprees, we can:

  1. Prioritize Outcomes Over Outputs: Build teams around clearly defined goals, ensuring their work aligns with business priorities.
  2. Right-Size Teams: Hire based on strategic needs, avoiding unnecessary headcount that creates inefficiencies.
  3. Focus on Sustainability: Scale deliberately, ensuring that teams are resilient, efficient, and aligned with organizational goals.

By calculating the cost of cross-functional teams and tying their contributions to measurable results, leaders can demonstrate the return on investment (ROI) of engineering investments. For instance, hiring two additional backend engineers and one data analyst might cost $X but could reduce customer onboarding time by 25%, leading to a 15% increase in customer retention—an outcome directly tied to the organization’s revenue growth.

A Commitment to Innovation

While this article focuses on aligning engineering with business outcomes, innovation remains a critical priority. Initiatives like “20% time” provide space for exploration and creativity, fostering long-term resilience and growth. Balancing immediate business needs with future-focused innovation is essential for staying competitive in a rapidly changing market.

A Call to Action

The feedback I received this year reminded me that technology leadership isn’t just about technical and operational excellence—it’s about driving measurable business results. Moving forward, I’m committed to linking technology investments to business results through:

  1. Embedding outcomes into every level of work, from Epics to team-level OKRs.
  2. Communicating engineering efforts regarding anticipated business outcomes and business impact using clear, relatable language.
  3. Balancing operational efficiency with value realization, ensuring every initiative contributes to organizational goals.

This journey is about more than improving delivery; it’s about ensuring that every line of Code, every feature, and every initiative creates value for customers and drives business success. By embracing this mindset, we can transform engineering from a cost center into a strategic partner, proving that our work is essential to organizational growth and resilience.

Next in the Series

In the final article of this series, we’ll move from leadership insights to practical guidance on escaping the ‘build trap’ and creating meaningful outcomes for your team. Read Now →

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

Engineering’s Business Value: From Black Box to Clarity

by

6 min read

This post is the first installment of my three-part series on connecting technology to business outcomes. In this foundational article, I delve into how organizations can redefine the value of software engineering by aligning technical efforts with measurable business results and customer impact.

Introduction

As a software engineer and technology leader with 25 years of experience spanning both waterfall and agile eras, I’ve heard the same refrain: “Technology is a cost center.” I’ve participated in reduction-in-force initiatives, stacked ranking exercises, and engineering team cuts—all driven by this persistent mindset. This experience has shaped my mission today: fundamentally changing how organizations view technology investments by directly linking our work to business and customer outcomes.

The Problem to Solve

The fundamental challenge in technology leadership has remained constant through every era: how do we effectively link and communicate the ROI of our engineering investments? This challenge can be addressed as organizations shift to a product operating model and embrace Value Stream Management (VSM). These frameworks focus on aligning work with value streams that deliver measurable business and customer outcomes, ensuring that engineering efforts are tied directly to strategic priorities.

Technology roles, commanding some of the highest salaries in modern organizations, often become prime targets for cost reduction initiatives. The math seems simple on paper—reducing engineering headcount produces an immediate, significant impact on the bottom line. Yet calculating true costs and ROI becomes complex when team members are shared across multiple initiatives. Modern organizations are solving this through intentional team design: implementing stable, cross-functional teams with dedicated software engineers and selective sharing of specialized roles like Product Managers and Agile Leaders across a limited number of teams. By moving work to teams rather than moving people between teams, organizations can more accurately track costs, measure value delivery, and demonstrate ROI at the team and value stream or product level.

For many senior leaders, the world of digital products, systems, and software engineering can feel like an entirely foreign language—and for good reason. Despite its critical role, technology efficiency and performance are often treated as a “black box” within organizations. Meanwhile, departments like Marketing, Sales, and Product consistently align their efforts with measurable business outcomes.

This disconnect creates a significant gap in organizational insight and decision-making. Are we employing the right number of engineers within our budget? Are we simply hiring engineers without a clear plan for assigning work? By adopting smarter hiring and capacity management practices, we can minimize unnecessary overhead and avoid layoffs caused by poor resource planning. The key to closing this gap lies in establishing frameworks and improving visibility to clearly articulate the tangible value technology brings to the business. It all starts with defining clear, measurable outcomes.

Operational Efficiency, Realization, and Alignment

Until new solutions emerge, technology success stems from excelling in two core areas, seamlessly linked through strategic alignment.

  1. Flow: Operational efficiency in delivering value, from ideation to implementation
  2. Realization: Measurable business impact of technology initiatives

Well-structured OKRs bridge these areas by translating organizational strategy into team-level objectives, ensuring every technical effort connects directly to business outcomes.

Flow: Modern tools and practices have revolutionized measuring and improving performance. Agile methodologies, Team Topologies, DevOps strategies, value stream management, and advanced analytics now offer insights into operational workflows and delivery efficiency.  

Realization: Modern tracking and measurement tools empower teams to gather, organize, and analyze meaningful data, even when results take months or longer. The insights provided by these technologies “close the loop” by clearly connecting technical efforts to tangible business outcomes. Even when the results fall short of expectations, these insights empower teams to reflect, refine, or pivot their approach entirely.

Team alignment: Product Operating Model and OKRs

The shift to a product operating model is fundamental to linking engineering efforts to business outcomes. Organizations enable teams to own changes throughout the product lifecycle by aligning teams around products instead of projects. This ownership fosters expertise, accountability, and a long-term focus on delivering customer value. Unlike the traditional project-based approach, which often prioritizes short-term deliverables, the product model supports continuous improvement and meaningful outcomes over time.

OKRs are a powerful tool for bridging the gap between technology investments and business outcomes. When crafted effectively, OKRs should reflect your team’s primary responsibilities and stay within their span of control, ensuring alignment with the organization’s broader goals. This approach keeps everyone focused on the same mission while linking team efforts to delivering real customer value.

By creating a clear line of sight between your team’s work, customer value, and measurable business outcomes, OKRs provide a roadmap for demonstrating the tangible impact of technology investments. They turn abstract efforts into visible results, demystifying the role of engineering in driving success.

Start with Outcomes

Success in technology is often misunderstood. While delivering stories, releasing epics, or launching products signify progress, they fail to guarantee success. True success lies in whether the work delivered creates valuable outcomes. Even when outcomes fall short of expectations, success can be found in the insights gained—insights that help teams refine their approach and uncover overlooked factors. This shift in defining success is crucial for demonstrating technology’s business value.

Product managers are responsible for defining and measuring feature outcomes, while technical team members are accountable for articulating the anticipated results of addressing technical debt. This dual ownership ensures that both business features and technical investments are tied to measurable outcomes. When technical teams can link technical debt to specific business impacts, these investments transform from mysterious “maintenance work” into strategic initiatives with clear business value.

Alignment and Purpose

Starting with anticipated outcomes enables teams to develop meaningful OKRs that cascade from organizational strategy. By first defining the expected impact of their work, teams can craft team-level OKRs that naturally align with broader strategic objectives. This outcome-first approach ensures that every epic and initiative has a clearly defined, customer-centric goal and connects directly to the organization’s strategic direction. This approach prevents the common anti-pattern from creating OKRs, focusing solely on output rather than meaningful results.

By documenting both anticipated and actual outcomes at the epic level, teams can:

  • Track how their work contributes to business results over time
  • Make data-driven decisions about resource allocation
  • Better prioritize work based on expected impact
  • Build a straightforward narrative around technology investments
  • Bridge the communication gap between technical and business stakeholders
  • Leverage modern tools to provide visibility into both efficiency and impact

ROI for Engineering Teams

By evaluating the return on investment (ROI) of our cross-functional teams—comparing development costs with the financial benefits of improved features or business outcomes—we can make smarter decisions about resource allocation while showcasing the measurable impact of our engineering efforts.

Summary

It’s time to demystify technology’s role in business success. By adopting an outcome-based approach, defining actionable OKRs, and framing decisions regarding business value, we enable technology to drive growth. These practices don’t just justify investments—they link technology investments to business results and create a roadmap for long-term success.

This mission is personal to me: to reshape how organizations perceive technology—from a cost center to a catalyst for innovation, growth, and customer satisfaction. This transformation demands connecting technical decisions, code, and architectural choices to measurable outcomes. When we align technology with clear business and customer value, we not only bridge the gap between investment and impact—we close it entirely.

Next in the series

In the next article, I’ll share how a personal leadership epiphany can transform our engineering organization from a cost center into a strategic partner, with practical insights for driving business results. Read Now →

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

Profitable Engineering: Linking Software Engineering to Business Results

by

3 min read

From Code to Impact: A Leadership Series on Linking Software to Business Success

In late 2024, a 360-degree leadership assessment brought candid feedback from an executive peer outside the tech sphere that hit hard: “Focus more on driving business results.” After years of leading digital transformation—scaling our organization from $10 million to $110 million in revenue through changes in culture, team design, architecture, and modern practices like Agile, DevOps, and VSM—it became clear that we hadn’t effectively articulated how our technology initiatives contributed to the company’s bottom line. This series is my response—a thoughtful exploration of aligning engineering efforts with measurable outcomes and turning technology into a powerful engine for business success.

My goal is to change how organizations view technology investments by showing a clear connection between our work and business or customer outcomes. In this three-part series, I draw from 25 years of experience in software engineering and technology leadership, where I’ve often seen technology labeled as just a cost center. These articles aim to provide practical insights and strategies to shift this perspective, highlighting how technology can drive innovation, growth, and customer satisfaction. By adopting modern practices, a product-driven operating model, and data-driven insights, we can create engaged teams that act as business partners rather than cost centers, delivering value more effectively.

This series is for technology leaders, Product Managers, and anyone looking to align engineering with organizational goals. We’ll cover how to clearly show the value of technology, integrate outcomes into workflows, and connect technical work to business success.

This series offers a comprehensive guide to aligning software engineering with business success, balancing foundational concepts with leadership insights and practical steps for transformation. Each article can stand alone but builds on the others—starting with the basics of technology’s role in business, advancing to leadership strategies for driving outcomes and concluding with actionable steps to empower teams. The intentional overlap reinforces key ideas, while the progression delivers a cohesive, engaging narrative that equips readers to drive meaningful change.

Series Summaries

1. Engineering’s Business Value: From Black Box to Clarity

This foundational article addresses the challenge of linking engineering efforts to business outcomes. It introduces shifting to a product operating model and Value Stream Management (VSM) as frameworks to align technical work with strategic priorities. The emphasis is on defining clear, measurable outcomes to articulate the tangible value technology brings to the business.
Read More →

2. Transforming Engineering: From Cost Center to Strategic Partner

This article builds on the first article and delves into the evolution of engineering roles within organizations. It reflects on leadership experiences and the importance of balancing operational efficiency with value realization. The article discusses embedding outcomes into workflows and the necessity for technology leaders to communicate the value of technical investments in business terms.
Read More →

3. Breaking Free from the Build Trap: Delivering Meaningful Outcomes

The final article focuses on moving beyond a feature factory mindset by concentrating on outcomes rather than outputs. It highlights the pitfalls of the build trap and underscores the value of starting with outcomes, fostering accountability, and ensuring successful delivery. The piece challenges technology leaders and teams to adopt a mindset centered on meaningful outcomes that drive engagement and impactful business results.
Read More →

This series encourages you to rethink your approach and join me in this transformation journey. Feel free to share your thoughts, experiences, or perspectives. I’m always up for a great conversation!

Navigating the Digital Product Workflow Metrics Landscape: From DORA to Comprehensive Value Stream Management Platform Solutions

by

19 min read

Using engineering metrics can greatly improve your work. Which metrics can help you and your teams improve practices and increase your ability to deliver value to customers more quickly, efficiently, and accurately?

This article is designed to empower senior leaders like you to navigate the landscape of digital product delivery metrics platforms and tools. It offers insights into the various options available and the rationale for selecting one solution over another when determining the most suitable metrics platform.

In the rapidly evolving landscape of software engineering and digital product delivery, leaders are increasingly reevaluating their approaches to team performance, productivity, and metrics. These leaders are turning to quantitative and qualitative data to make delivery teams’ performance and efficiency improvement efforts more transparent. Teams seek data-driven insights to identify bottlenecks, uncover root causes, and evaluate potential enhancements. They aim to eliminate or refine these obstacles by experimenting with various changes to achieve greater efficiency.

Assessing software engineering performance remains one of the most significant challenges for organizations and corporate enterprises alike.

“Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” – Charles Goodhart

“Goodhart’s Law tells us that ‘when a measure becomes a target, it ceases to be a good measure.” – Marilyn Strathern

Embracing new metrics for today’s work environment is not immune to Goodhart’s law and the potential pitfalls of gamification. Therefore, both leaders and delivery teams must embrace these metrics and distinguish between business discussions and team conversations when analyzing and utilizing them.

However, having data insights and optimizing the performance of your delivery team is not just a necessity but a gateway to capturing performance insights, maintaining competitiveness, and enhancing processes, practices, automation, and team design to deliver value effectively.

As a senior leader with extensive experience guiding technology teams through digital transformation, I have witnessed firsthand the vital role of selecting the right metrics platform. During 2020 and 2021, I faced a similar challenge while assessing and implementing a metrics platform to gain insights into our digital transformation efforts, team structure, and automation investments. Leveraging my background, I quickly gained a deeper understanding of modern metrics.

At that time, a senior leader in our division, much like some of you, struggled to grasp the various metrics options and their relevance to our current delivery capabilities, often fixating on vendor pricing—a legitimate concern given our tight budget. This misunderstanding led to friction as we aimed to identify the best solution. While I acknowledged the advantages of different platforms, the leader’s emphasis on cost over functionality complicated our decision-making process.

After more than eight years of investing in our architecture, team design, automation, and delivery processes, we arrived at a critical decision point: Should we invest in a Software Engineering Intelligence (SEI) platform tailored for delivery, or should we pursue a comprehensive Value Stream Management (VSM) solution that encompasses the entire lifecycle from ideation to production? It’s important to note that the concept of an SEI platform didn’t even exist three years ago when we began our evaluation. At that time, we only had DORA and various vendors offering metrics platforms that needed more coverage across all stages, focused solely on parts of the delivery process, or had notable gaps in delivery insights, even among holistic solutions. I aimed to compare all vendor options, assess their coverage and focus, identify gaps across each workflow phase, and select the best fit.

We initially assessed ten vendors and ultimately narrowed our options to two: our preferred SEI solution and our top choice for the VSM platform. If budget constraints had not been an issue, I would have acquired both solutions to seamlessly bridge the gaps between them. I even lightheartedly suggested a potential merger for both vendors! We chose a VSMP solution based on where we assessed our bottlenecks and stage. This experience also inspired one of my early articles on the subject – Finally, Metrics That Help. Contact me if you’d like to explore my experiences, methodologies, discussions, and presentations related to this evolution in metrics.

Fast forward to 2024, and we discover the inspiration behind this article. I learned about a senior technology leader tasked with transforming and enhancing the large technology team he inherited upon joining an enterprise company. His primary objective is to turn the department around and to improve digital product delivery. He aims to reintegrate QA and product delivery responsibilities into teams—responsibilities removed during previous cost-cutting measures implemented by earlier stakeholders before he arrived in the organization. Based on my understanding, part of his strategy includes adopting delivery performance metrics to establish team metrics that will create a baseline for current performance, offer valuable insights, and initiate a pathway to enhancing overall performance and efficiency. He has focused explicitly on or selected DORA metrics to better understand product delivery roles and processes. Although I didn’t have the opportunity to discuss this with the leader before his decision, I am intrigued by how he arrived at the choice of DORA metrics. This presents a unique opportunity for us to learn and grow in our understanding of metrics. Given that this enterprise technology team has been delivering work effectively in an agile environment for years, I wonder if his decision truly addresses the more significant challenges faced by his division in improving the delivery process. Are these the appropriate metrics and feedback mechanisms to resolve workflow bottlenecks?

Stages of the Product Delivery Workflow

Once you understand the workflow, you can analyze and pinpoint its bottlenecks. This understanding allows you to implement metrics that offer valuable feedback and insights on these bottlenecks. This feedback is crucial as it helps you identify areas for improvement in an iterative manner.

The stages of the digital product workflow, often discussed in frameworks such as Value Stream Management (VSM) and Flow Engineering, typically follow the journey from an initial idea to the moment the product delivers value to the customer. Understanding these phases is essential for grasping how work flows within an organization and identifying where value is created.

The key stages or phases of the digital product workflow are:

  • Ideation (or Discovery)
  • Delivery
  • Operations
  • Support

Ideation (or Discovery): This phase focuses on generating, prioritizing, and refining ideas. It involves understanding what should be developed based on customer needs, market demands, and strategic objectives. This stage lays the groundwork for all future efforts and encompasses market research, gathering user feedback, and creating early design prototypes.

Delivery: Once an idea is validated, it transitions into the delivery phase, where actual development occurs. Delivery includes coding, testing, and deploying the product. This phase emphasizes transforming ideas into tangible products ready for customer delivery. It also encompasses the CI/CD pipeline, where DORA metrics are often utilized.

Operations: Once the product is delivered, it transitions into the operations phase. This stage is crucial in maintaining and managing the product within a live environment. Your work in performance monitoring, infrastructure management, and ensuring the product operates smoothly and efficiently is key to the product’s quality.

Support: The final stage is support, encompassing customer service, incident management, and ongoing enhancements based on user feedback. Your continuous efforts in this phase ensure that customers derive continued value from the product while effectively addressing any issues arising after deployment.

Value Stream Management resources, Product Flow, and Flow Engineering often highlight these stages. They offer a structured framework for understanding the workflow, guiding it from the initial idea to continuously delivering value to customers. These stages enable organizations to grasp how value is generated and delivered, facilitating more effective management of the entire product lifecycle.

Understanding the Types of Metrics Platforms

Before exploring specific tools, it’s essential to grasp the three main categories of qualitative metrics platforms focused on delivery performance insights as I understand them: DORA metrics, DX Core 4, Software Engineering Intelligence (SEI) platforms, and Value Stream Management (VSM), along with flow metrics.

DORA Metrics

“The bottleneck is Deployment.” Focus is on a very narrow slice of the overall work flow.

DORA (DevOps Research and Assessment) metrics are designed to measure the effectiveness and efficiency of your software delivery process from code commit to deployment. These metrics include:

  • Change lead time
  • Deployment frequency
  • Change fail percentage (previously change failure rate)
  • Failed deployment recovery time (previously mean time to recovery or MTTR)

The information regarding throughput, stability, and metric definitions is sourced from the dora.dev website.1

Throughput

Throughput measures the velocity of changes that are being made. DORA assesses throughput using the following metrics:

  • Change lead time – This metric measures the time it takes for a code commit or change to be successfully deployed to production. It reflects the efficiency of your delivery pipeline.
  • Deployment frequency – This metric measures how often application changes are deployed to production. Higher deployment frequency indicates a more agile and responsive delivery process.

Stability

Stability measures the quality of the changes delivered and the team’s ability to repair failures. DORA assesses throughput using the following metrics:

  • Change fail percentage – This metric measures the percentage of deployments that cause failures in production, requiring hotfixes or rollbacks. A lower change failure rate indicates a more reliable delivery process.
  • Failed deployment recovery time – This metric measures the time it takes to recover from a failed deployment. A lower recovery time indicates a more resilient and responsive system.

Why Choose DORA?

Budget concerns. The bottleneck is deployment (release) and stability.

  • Focused on Deployment Efficiency: DORA metrics are ideal for organizations that need to optimize their CI/CD pipeline and improve deployment frequency and stability.
  • Narrow Scope, High Impact: DORA metrics can provide precise insights to drive improvements if your primary bottlenecks relate to deployment.

DX Core 4 Metrics

“The bottleneck is primarily deployment” and insights into team engagement.

The DX Core 4 is a new entrant in the metrics landscape for 2023 and 2024. This comprehensive framework aims to measure and enhance productivity among developers and delivery teams by focusing on four essential dimensions: speed, effectiveness, quality, and business impact. Designed to integrate insights from established frameworks such as DORA, SPACE, and DevEx, it provides organizations with actionable insights that bridge the gap from frontline teams to executive leadership.2 Similar to DORA, this framework emphasizes the Delivery phase of Flow.

Here are the four dimensions of the DX Core 4 framework:

Speed: Measures how quickly software is developed and delivered, from inception to production.

Key Metrics:

  • Cycle Time: How long a task or feature takes to move through the development pipeline.
  • Lead Time for Changes: Similar to DORA, this measures the time from code commit to production.

Effectiveness: Assess how well development processes achieve their intended outcomes.

Key Metrics:

  • Workflow Efficiency: How efficiently teams move work through different stages.
  • Goal Completion: The ability of the team to meet sprint or project objectives.

Quality: Evaluate the quality of the software being produced.

Key Metrics:

  • Defect Rate: The number of defects or issues found during or after deployment.
  • Code Quality: Measured by the percentage of code needing rework or post-deployment fixes.
  • User Satisfaction: User feedback, often through surveys or Net Promoter Scores (NPS).

Business Impact: Measures how well software development efforts align with and support overall business objectives.

Key Metrics:

  • Feature Adoption: Tracks how customers adopt new features.
  • Revenue Impact: How specific development activities contribute to business revenue or growth.
  • Alignment with Business Goals: Measures the percentage of development work directly contributing to strategic business objectives.

These four dimensions provide a balanced view of development performance, ensuring that teams deliver quickly and produce high-quality work that drives business outcomes. The DX Core 4 framework integrates well with other methodologies like DORA, SPACE, and DevEx, offering a holistic picture (quantitative and qualitative) of productivity.

Why Choose DX Core 4?

The bottleneck or focus is on Delivery performance and Team Sentiment.

Consider DX Core 4 if you aim to accelerate delivery while ensuring that your software meets high-quality standards and aligns with business objectives. This framework enables you to focus on both the technical and business dimensions of software development, providing a balanced approach to enhancing developer productivity in the organization.

Software Engineering Intelligence (SEI) Platforms

“Our bottleneck is Delivery.” Focus is on the Delivery stage.

In recent years, Software Engineering Intelligence (SEI) platforms have emerged as a distinct category, extending beyond traditional DORA metrics primarily focusing on the CI/CD pipeline. Additionally, some analysts, such as McKinsey and solution providers, refer to these as Engineering Management Platforms (EMPs). For the purpose of this post, I will refer to them as SEI platforms.

SEI platforms cover the entire delivery process, from when a work item enters the backlog to its deployment, incorporating metrics like cycle time, throughput, work-in-progress (WIP), and quality indicators such as pull request size and rework rates. These platforms excel by integrating various tools (e.g., Git, CI/CD, project management) to offer a unified view of the entire delivery pipeline.

Some SEI platforms focus on actionable insights and benchmarking, often utilizing data to compare team performance against industry standards. More importantly, these SEI solutions align engineering efforts with broader business objectives, a crucial aspect that traditional DORA metrics often overlook but is of strategic value to any organization.

Some SEI platforms also provide a comprehensive view of the development process, including visibility in developer experience (DX) by tracking productivity and team health, using metrics like WIP and burnout alerts. This holistic view makes them ideal for organizations looking to optimize workflows beyond just CI/CD, instilling confidence in the thoroughness of the approach.

While DORA metrics provide critical insights into deployment efficiency, SEI platforms offer a more comprehensive approach, ideal for organizations seeking to optimize the full delivery pipeline and align with business goals.

Gartner has recently published a market guide on SEI platforms for those interested in exploring this further3.

Here are some key types of metrics commonly found in some of the more known SEI platforms :

  • Cycle Time: Measures the time it takes for a work item to move from the backlog to deployment. This metric helps identify inefficiencies in the development process and highlights areas where delays occur.
  • Throughput: This metric tracks the number of work items completed over a specific period. It provides insight into team productivity and helps assess whether teams meet their delivery goals.
  • Work in Progress (WIP): Monitors the number of items being worked on or in progress. High WIP can indicate bottlenecks or overloading of the team, which can slow overall delivery.
  • Pull Request (PR) Size and Rework Rate: Evaluate the size of pull requests and the frequency of rework required. Smaller PRs with lower rework rates tend to be merged faster and with fewer issues, contributing to smoother deployments.
  • Planning Accuracy: This compares planned versus actual delivery timelines. It helps teams understand how well they estimate their work and whether they consistently meet their commitments.
  • Developer Experience (DX): SEI platforms often include metrics that assess developer satisfaction and efficiency, such as time spent in meetings versus coding and the overall impact of tools and processes on developer productivity.

Why Choose SEI?

Your bottleneck remains in the workflow’s delivery phase, but you have the budget for an SEI solution and need insights beyond code commit to delivery.

  • Optimizing Planning, Development, Deployment, and Stability: SEI platforms are perfect for teams looking to streamline the development and delivery process from backlog to production, balancing speed with quality and introducing team health insights.
  • Broader Than DORA, Narrower Than VSM: SEI platforms offer a middle ground, providing insights into the development process without tracking the entire lifecycle.

Value Stream Management (VSM) Platforms and Flow Metrics

“The bottleneck is upstream.” Insights cover the entire Value Stream (work flow).

Value Stream Management Platforms (VSMP) optimizes the entire digital product lifecycle, from ideation to operation and support. It enables organizations to visualize, measure, and enhance the flow of value across complex systems, identifying inefficiencies and aligning technical and business objectives. Companies ready to adopt VSM typically have mature delivery practices and aim to improve collaboration across teams. VSM platforms provide insights into bottlenecks, work-in-progress limits, and metrics that help organizations assess ROI and align their efforts with business goals, ultimately enhancing predictability and efficiency in software delivery.

Enterprises and companies that have embraced agile and DevOps practices and seek to bridge the divide between business and technology will find these platforms especially beneficial for enhancing predictability, speeding up discovery and delivery, and achieving alignment with business goals across the organization. Like various SEI platform solutions, many top VSM platforms provide valuable insights into team health and metrics associated with developer and team experiences.

Here are some key business metrics commonly found in top VSM platforms today:

  • Flow Velocity: This metric tracks the number of flow items—such as features, defects, risks, and debts—completed within a defined time frame. It provides valuable insight into the amount of value being delivered.
  • Flow Efficiency: The ratio of active time to the total time a flow item spends in the value stream serves as a key metric for assessing the efficiency of work processing.
  • Flow Time: The total duration for a flow item to progress from ideation to completion is a vital metric for assessing time-to-market.
  • Flow Load: Tracks the number of flow items currently in progress. A high volume may signal potential bottlenecks or team overloads.
  • Flow Distribution: Tracks the balance among various types of work—features, defects, risks, and technical debt. This metric ensures that all efforts align with strategic priorities.
  • Cost of Delay: This approach assesses the financial consequences of postponing the delivery of features or projects, enabling organizations to prioritize tasks based on the potential business value lost due to these delays. By quantifying the cost of delay, companies can make informed decisions about which features to prioritize, ultimately maximizing their return on investment (ROI).
  • Value Stream ROI: This metric evaluates the return on investment for various value streams by comparing development costs with the business value generated from delivered features. It enables businesses to assess the financial effectiveness of their development processes, allowing them to adjust resources or priorities to optimize returns.

Why Choose VSM?

  • Holistic View of the Value Stream: VSM tools offer comprehensive visibility, insights, and feedback across the entire digital product workflow. They assist in optimizing each stage, from idea generation to production.
  • Alignment with Strategic Goals: These platforms help ensure that all phases of your software lifecycle are efficient and aligned with your business objectives.

Choosing a Platform

Selecting the appropriate metrics platform requires careful consideration of several factors, such as your budget, the locations of bottlenecks in your product workflow, the specific challenges you seek to resolve, the maturity or efficiencies of your current processes, and the readiness and awareness of your leadership team across the stages.

Identify Your Bottlenecks

  • Deployment Challenges: DORA metrics might be the ideal solution if you are on a tight budget and experience delays mainly after commits, characterized by lengthy lead times or frequent deployment failures. DORA-based tools and surveys can provide the insights necessary to enhance your CI/CD pipeline.
  • Development and Delivery Challenges: If inefficiencies arise during the development phase—such as extended cycle times or excessive work-in-progress—SEI platforms can help you identify and effectively address these challenges. Additionally, if you encounter deployment bottlenecks, including issues from code commit to deployment, while also having a favorable budget, leveraging an SEI platform can offer significant advantages over DORA.
  • Systemic Issues Across the Lifecycle: For organizations facing extensive inefficiencies from ideation to production, VSM platforms offer a comprehensive solution. These platforms adeptly identify and eliminate bottlenecks throughout the value stream, although they may also represent a significant budget investment.

Why Not Start with a Broad Scope VSM Solution?

While starting with a comprehensive Value Stream Mapping (VSM) solution for complete visibility across your value stream may appear logical, strategically targeting specific issues — namely, bottlenecks — can offer significant advantages. The rationale is straightforward: optimizing processes downstream of a bottleneck often leads to underutilization, while enhancing upstream operations without addressing the bottleneck can result in a backlog at that critical choke point. 

You can start by identifying and optimizing the bottleneck in your process. DORA metrics and SEI platforms can be considered for diagnosing CI/CD pipeline issues and delivery phase improvements. After resolving these challenges, you can broaden your focus using SEI or VSM platforms to optimize the broader scope of your value stream or product workflow. This comprehensive approach guarantees that your improvements yield significant and sustainable enhancements in overall efficiency.

Additionally, it is essential to consider various factors, such as the organization’s size, budget constraints associated with different solutions, the readiness of divisional leadership, and the overall comprehension of digital product delivery practices — not just within product and technology teams but across the entire organization.

When to Consider a Broader Scope Platform

Organizations that have invested in and optimized their delivery processes—by establishing highly automated CI/CD pipelines, minimizing waste, and reducing wait times between stages—are ideally positioned to embrace broader-scope platforms, provided they have the budget to support these tools. Here’s why:

  • Emphasize the Early and Late Stages: After optimizing delivery, the subsequent focus should be on refining the ideation, operational, and support phases. Comprehensive platforms ensure that only the most valuable ideas progress, operations run efficiently, and support remains proactive and effective.
  • Comprehensive Optimization: Platforms with a broader scope, such as VSM tools, offer the visibility required to optimize the entire lifecycle. This ensures that every stage—from ideation to support—remains aligned and efficient.
  • Maximizing ROI: These platforms enhance your return on investment by tackling inefficiencies upstream and downstream of delivery, optimizing your existing investments in CI/CD and delivery processes.

Team Sentiment

Team Sentiment: Incorporating team health and sentiment qualitative metrics into your metrics solutions or selections is crucial. Metrics like Developer Experience (DX) and Team Experience (TX) should prioritize team sentiment and well-being, highlighting their importance in fostering a positive work environment. Team health metrics complement the quantitative data from delivery metrics, creating a comprehensive view of software efficiency alongside team health. This combination ensures you optimize processes and nurture a motivated and effective team. While this topic could warrant a follow-up article, or you can read some of my related articles on adopting metrics, it’s essential to integrate qualitative and quantitative feedback into your overall strategy.


Summary

Whether your goal is to refine your CI/CD pipeline using DORA metrics, improve your development process with SEI platforms, or achieve comprehensive visibility with VSM tools, aligning your choice with your strategic objectives is essential. This post highlights the numerous options and solutions available when considering implementing a metrics platform.

By thoughtfully selecting an appropriate platform and pairing it with team health indicators, you can drive continuous improvement, enhance efficiency, and deliver exceptional value to your customers and business. Selecting the appropriate metrics platform for your software delivery process is a vital decision influenced by your organization’s size, specific requirements, and maturity level. Ultimately, it can come down to your organization’s context, budget, and leadership mindset.  

A combination of solutions or tools serves you best, as they can complement one another by filling the gaps left by individual platforms. This holds when finding a solution that offers quantitative performance and qualitative team health and engagement.

From my experience in guiding technology teams through digital transformation and my recent in-depth market evaluation and platform adoption, I’ve learned that readiness is paramount. While the appeal of a more extensive platform can be strong, it’s vital to ensure that your leadership and organizational mindset are prepared for the journey ahead. Without this alignment, even the most advanced metrics platform may fall short of its potential. Therefore, before making the leap, confirm that your team is on board and your organization is ready for the change. Know your constraints, list your anticipated results, and what you want to achieve. Then, pick a solution or combination to help you achieve your expected outcomes.

Options in the Market

I’ve conducted thorough research to choose the best solution for our specific context and have my preferred partners. Additionally, we spent a year exploring the build-versus-buy option, beginning our journey with an in-house solution. If you want to learn more about my experiences, please reach out.

Disclaimer: In this article, I will not endorse any specific vendor. I will provide a foundational understanding based on insights from various vendors and their websites. I do not claim that these mentions represent the only options available in the market or that they accurately capture the purpose of each vendor within their respective categories. Additionally, I need more insight to assess which platform might be superior, as I need to familiarize myself with your organization’s specific context. My aim is simply to give you a head start in your research.

DORA

Several platforms on the market leverage DORA (DevOps Research and Assessment) metrics to evaluate software delivery performance. These platforms emphasize key DORA metrics, including deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate. Below are some noteworthy platforms and vendor solutions:

DX Core 4

As the market’s newest framework, few platforms integrate the DX Core 4 metrics into their offerings to help organizations track developer productivity and experience across speed, effectiveness, quality, and business impact. The DX Platform is a primary example, designed by leading researchers behind DORA and SPACE, specifically created to measure developer experience and productivity through qualitative and quantitative insights.

Here are some notable platforms that utilize the DX Core 4 metrics:

  • DX Platform: The DX Platform was specifically designed to measure and improve developer productivity through the DX Core 4 framework.

Alternatives to consider that may not directly incorporate DX Core 4 metrics yet provide comparable insights include:

  • LinearB: Although LinearB does not explicitly use the DX Core 4 framework, it tracks several metrics aligned with speed, effectiveness, and quality, similar to the DX Core 4 dimensions.
  • Pluralsight Flow (formerly GitPrime): aligns with some DX Core 4 dimensions, especially in speed and quality.
  • GitLab: aligns with some of the core tenets of the DX Core 4 framework.

Software Engineering Intelligence (SEI) Platforms

Several platforms explicitly position themselves as Software Engineering Intelligence (SEI) platforms, offering metrics to help organizations optimize software delivery, developer productivity, and business alignment. These platforms go beyond traditional CI/CD metrics and provide deeper insights into development workflows, team efficiency, and alignment with business goals. Here are some leading SEI platforms available today:

Value Stream Management Platforms

Numerous platforms actively position themselves as Value Stream Management (VSM) solutions, offering metrics that track the flow of value throughout an organization’s discovery and development lifecycles. These platforms enable organizations to align software delivery with business objectives, streamline workflows, and reduce inefficiencies within the value stream. VSM platforms are particularly beneficial for enterprises requiring comprehensive governance and oversight in complex release management scenarios. Below, we highlight some of the leading VSM platforms currently available on the market:

Update: September 18, 2024 – Following the publication of this article, Planview has announced its acquisition of Plutora. Press Release.

This article aimed to help senior leaders or other product and technology managers navigate the landscape of performance metrics platforms and tools to measure the performance and engagement of software delivery teams. I hope this post offers valuable insights if you are contemplating the adoption of a metrics platform.

References

  1. DORA, https://dora.dev/guides/dora-metrics-four-keys/
  2. DX Core 4, https://getdx.com/research/measuring-developer-productivity-with-the-dx-core-4/
  3. Software Engineering Intelligence Platforms Reviews and Ratings, https://www.gartner.com/reviews/market/software-engineering-intelligence-platforms, Garnter.com

Related Posts

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

A Balanced Approach to Agile Metrics: Empowering Teams and Mitigating Risks

by

5 min read

Metrics can provide teams with insights and evidence where things are taking longer, are causing friction, and need attention to improve the flow of work. Focus on improving the most significant bottlenecks first.

I recently observed a discussion between an Agile team leader and a product owner. The Agile leader was worried about the business pressuring the product owner for delivery, who then used metrics to shift blame onto the team. Some of our Agile leaders see this product owner as authoritative and controlling. The product owner could benefit from dedicating more time to grasp agile delivery, team structure, roles, responsibilities, and the importance of metrics and team cohesion. However, that’s a separate matter.

After reviewing Flow Velocity, the product owner challenged the team’s work estimate, insinuating that the team’s velocity was not good enough and needed improvement. I sensed that this perturbed the agile leader. Post-discussion, I conversed with the agile leader, acknowledging the product owner’s valid points on velocity improvement. Every team should want to improve velocity. However, I noted the lack of concrete evidence behind the product owner’s critique. What data supported his assessment of the team’s efficiency? His comment seemed biased and lacked a factual basis. This interaction prompted me to create this post.

Introduction: The Foundation of Game-Changing Agile Practices

A strong focus on value stream management, flow metrics, and team structures are at the core of successful digital product delivery. When implemented across the system, these components bring significant changes that reshape agile software development. Over the past six years, my journey has closely involved these frameworks and practices, influencing the structure of my departments. This experience and a culture rooted in modern agile principles emphasize a fundamental belief: prioritizing people, processes, and tools in that specific order.

This philosophy guides our strategy and reflects how we operate. Modern agile principles help us navigate digital product delivery complexities, highlighting the vital role of human elements in achieving success. Our blend of advanced practices and dedication to agile values is the foundation for creating environments where teams excel, innovate, and provide exceptional value.

During a conference presentation last year, I showcased this approach as one of the most promising methods I’ve encountered in my over twenty years in software engineering and delivery. This synergy will help us, and you outperform other digital delivery teams stuck in outdated team structures and practices.

Delving into the intricacies of DORA, Flow Metrics, and Team Health metrics, it’s crucial to recognize that these tools and methods serve a broader mission. They aren’t just goals but pathways to enhance agility, efficiency, and team morale. With this fundamental insight, let’s dive into how a well-rounded metric strategy can empower teams, manage risks, and foster the constant improvement central to agile excellence.

Ensuring Team Metrics Empower, Not Impair

In pursuing agile excellence, embracing modern metrics like DORA, Flow Metrics, and Team Health metrics establishes a robust framework to evaluate and enhance software development practices. Yet, addressing the potential risks linked to the misapplication of these metrics is crucial. Drawing from 24 years of experience, it’s evident that without careful oversight and a profound grasp of their purpose, businesses could exploit these metrics, leading to gamification and focusing on manipulating metrics rather than genuine improvement.

Metrics are essential tools in the arsenal of engineering leaders and teams, providing necessary insights that guide teams toward continuous improvement. The value of these metrics lies not in their ability to compare teams or individuals but in their capacity to provide insights and feedback and foster growth and efficiency within the context of each team’s unique challenges and objectives (bottlenecks or friction). Also, one metric does not tell the story. You should rarely assess a team’s performance on one metric.

Understanding and Communication

Utilizing metrics effectively starts with engaging engineering teams in defining, communicating, and comprehending these metrics. This strategy ensures that teams grasp the significance of each metric about their processes and goals. It underscores the value of teams and recognizes that proficient delivery teams are crucial for successful software development. Embracing these metrics enables teams to identify bottlenecks and obstacles within their team, practices, and workflow.

Context and Comparison

Work context dramatically affects how metric values are interpreted and standardized. Comparing teams is dangerous. Comparing teams without factoring in their unique work elements and context can result in inaccurate productivity assessments. The key lies in evaluating a team based on its previous performance, tracking progress, and pinpointing improvement areas within their context.

Mitigating Risks: Gamification and Weaponization

The danger of metrics being misused by the business and turning team focus to gamification is significant and harmful. When teams worry about metrics being turned against them, their attention moves from getting better to just following rules. This worry can result in manipulating metrics, where teams try to beat the system to boost their stats without improving their productivity or the quality of their work.

Ownership versus Compliance

Separating business conversations from team conversations about metrics is crucial to mitigate these risks. Teams must feel ownership over their metrics, viewing them as valuable feedback mechanisms that align with their goals and aspirations. This sense of ownership encourages teams to care about their metrics, using them to identify bottlenecks, improve processes, and enhance delivery.

The Example of Velocity

I spoke with one delivery team member regarding velocity, or flow velocity. This conversation was a poignant example of how metrics can be gamed. Teams may break down tasks into smaller units to artificially inflate their velocity without necessarily delivering more value. We want teams to break down work into the smallest value possible. But this team’s manipulation to improve velocity underscores the need for a nuanced approach to metrics that prioritizes genuine improvement and meaningful output over numerical targets.

Conclusion

By strategically harnessing tools like DORA, Flow Metrics, Team Experience, and engagement metrics, focusing on empowerment and thoughtful metrics management, teams can revolutionize their path to improvement and agile excellence. Embrace a culture where metrics drive team feedback, insights, and growth, propelling your organization toward continuous improvement, efficiency, and improved team performance. Keeping team metrics conversations separate from business and team-level discussions uplifts software delivery and can sustain team commitment, motivation, and dedication to improvement. When teams unlock the power of metrics for enhanced efficiency and well-being, watch the separate business conversations around the same metrics naturally align.

Poking Holes

I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others. What are your thoughts?.

Let’s talk: phil.clark@rethinkyourunderstanding.

Related Posts

Agile Era Leadership: Overcoming Legacy Leadership Friction and Four Industry Conversations

by

11 min read

The world has fundamentally changed in the past few decades. The rise of knowledge work and complex digital systems has shifted how we operate and compete. The practices needed to manage these new ways of working are different. Past success does not guarantee future success. Clinging to past mastery can hinder progress. Whether through bottom-up or top-down approaches, it is widely observed that the success of your transformation greatly depends on having a sponsor who comprehends it at the highest level possible. Ultimately, an organization’s success or failure depends on how much effort those with the most power put into learning the practical models they have chosen to use. This article targets digital delivery and operations leaders.

“We shape our buildings, and afterward, our buildings shape us.” Similarly, we shape the architecture of our organizations (how they are wired), which then shapes the behavior of the people within them.”

Winston Churchill

I am thrilled to witness a growing number of organizations within the Agile, Lean, and DevOps global IT and software delivery communities making remarkable progress in culture, successful delivery practices, and overall advancement. However, it is disheartening to observe the prevalence of negative leadership stories and discussions among older, more experienced leaders, which hinder the transition from the previous era of large projects, function-based teams, handoffs, and waterfall methodologies to the modern practices we embrace today. This friction impacts the transformation of work and the realization of its potential.

What problem are we attempting to solve? 

The negative impact of leaders who adhere to obsolete practices and metrics on contemporary agile work methodologies is apparent. Leaders who have previously achieved success are encountering challenges in obtaining a profound comprehension or achieving success in the constantly evolving realm of digital delivery practices.

Outdated models and a lack of understanding of leadership can lead to conflicts and unsuccessful change attempts. To drive this change, new or current executives need to clearly understand modern practices and operations and the rationale for change to take charge. These individuals must also have the authority to implement the required transformations.

Friction from Giants

Senior leaders who cling to outdated practices and metrics often create friction within their organizations, particularly when their decisions, based on legacy knowledge and amplified by their rank, undermine progress and innovation. While assuming positive intent, these leaders must recognize that their reliance on antiquated expertise is causing friction and hindering collective efforts. Leaders must invest time in acquiring new skills and applying modern methods to achieve positive outcomes. It is crucial for individuals to distinguish between purpose, outcomes, and alignment and to recognize the disruptive consequences that arise from prioritizing outdated metrics and egos. As seasoned professionals in their respective domains, these leaders must enhance their performance and grasp the strategies and metrics their teams utilize.

Consider this a belated follow-up to my article from December 2021, titled “Established Organizations, Digital Literacy, Mindset, and the 4th Industrial Revolution.”

Digging in

The shift in senior leadership mindsets from traditional, pre-agile methodologies to modern practices like Agile, Lean, and DevOps must be addressed in the evolving landscape of software development and organizational management. This resistance, especially among senior leaders familiar with legacy systems, stems from a deeply rooted adherence to outdated metrics and methods. It’s a scenario that poses challenges for digital transformation and threatens the fabric of collaborative, cross-functional teams. It is astonishing how many individuals continue to encounter this issue.

Failed agile transformations are often traced to misalignment and senior leadership friction. I have personally encountered this challenge. Once, we had a senior stakeholder who championed new ways of working and challenged the incumbent mindset. However, when that leader retired, the responsibility fell on me and our teams. Without my knowledge, a series of discussions awaited me after his departure, along with the integration of new owners and C-level team members with traditional success mindsets and limited familiarity with agile practices and organizational team structure.

Why Leadership Adaptation Matters

Coming from a background of successful leadership in the software delivery realm, I unintentionally encountered challenges when embracing agility during our digital transformation. However, November 2018 marked a turning point in my career. Then, I realized the need to revise the strategies that had previously led to my success to align with new practices, methodologies, models, and cultures. It was time for a shift in my understanding and approach. I needed to unlearn, relearn, and rethink my understanding.

In recent years, the impact of entrenched mindsets on modern practices has emerged as a prominent focus in my writing, conference presentations, and personal and executive discussions.

Personal Struggles with Resistance

From my experience, confronting resistance from new C-Level team members, board members, and other executives who may need more experience or knowledge in agile, lean, and DevOps principles can be daunting. The risk of job security is a significant concern, as it could impede the progress of transformative efforts. Striking the right balance between advocating for change and navigating the complexities of organizational power dynamics is crucial.

Leadership Challenges: Four Real-World Conversations

I am presenting four instances of conversations with individuals who have contacted me, expressing their challenges with senior leadership and adjusting to change.

Case One: Transforming the Top

Most recently, a colleague in my network who works for a large telecom organization reached out to me, sharing their struggles, which align closely with the challenges I have been discussing in my talks on legacy senior mindsets, team structures and roles, productivity metrics, and the recent hurdles I have encountered.

I recently gave two talks at conferences about my organization’s digital transformation, sharing insights from my career journey and experience with metrics. I recounted my challenges when new C-level executives and board members pressured me to measure “productivity units” from my engineering team. These expectations were similar to what my Sales, Marketing, and Customer Support counterparts were delivering. I have shared our journey from focusing solely on individual output to prioritizing team productivity, impact, and outcomes. The effectiveness of software engineers can vary depending on their roles within teams. Engineers on small cross-functional teams must recognize that the responsibility for delivering software lies with the entire team, not just individual members. While writing code is an important task, engineers on these teams have a broader range of responsibilities. The recent introduction of Value Stream Management and Flow Metrics has played a critical role in facilitating discussions and driving changes in metric expectations that focus on team productivity.

“Hi, Phil! I encounter similar challenges with upper-level management, who resist discussing new ideas and suggestions for improving our processes. The prevailing status quo overwhelms and stresses my colleagues. I actively seek connections with enlightened stakeholders to join an initiative fostering constructive discussions, but it remains an uphill battle. I observe a reluctance to speak up and voice our concerns, and maintaining a proactive and adaptable mindset while practicing patience is crucial. I derive this insight from your own experiences as well. How did you handle resistance from senior leadership during this transition? And did you use roles like agile coaches or value stream managers to help you?”

My response was, “Handling resistance was no walk in the park. I often stood alone against new C-Level team members and board members. The key was to confront challenges logically and professionally. I relied heavily on my ability to present compelling examples and a clear vision of the desired outcomes based on the models and measures that properly match the practices. If you can, it’s crucial to stay proactive and adaptable. Find those enlightened stakeholders; their support can be a game-changer.”

This conversation highlights the difficulties of leadership during times of organizational change. It underscores the significance of being resilient, thinking strategically, and having the courage to advocate for change, even when facing opposition from top management, who may require more comprehension or be hesitant to adopt new approaches.

Case Two: Purpose over Process

I spoke with an experienced leader in agile transformation at a well-known global beverage company. During our conversation, we discussed our experiences with digital transformation. She shared a challenge she encountered with a senior leader who became frustrated with their agile transformation and the use of Scrum for software delivery. To address this, the leader switched their approach to Kanban, focusing more on tools to overcome the obstacles hindering their shift to agile delivery methods rather than dwelling on the reasons behind the struggle.

“Thank you once again for your time yesterday. I hope it’s all right if I email you now while it’s still fresh in my mind. During our conversation, you mentioned that you were a few years into the transformation when you faced a major disruption. You also mentioned that most, if not all, teams start with Scrum before transitioning to a version of Kanban. I would like to know how long your teams typically use Scrum before transitioning. Additionally, I’m interested in learning about the deciding factors for the transition to Kanban, especially if they vary. Most importantly, we also discussed some leaders’ challenges in embracing agile and letting go of command and control. I would appreciate any recommendations or resources you may have to help bring them along.”

The executive leader’s challenges in adopting Agile stem from focusing on tools rather than addressing underlying issues. A better understanding of Agile principles is necessary. They should explore the root causes behind the struggles with Scrum, uncertainties in transitioning, and the difficulty of shifting away from a command-and-control mindset. Furthermore, effective navigation of these obstacles requires more leadership support and education.

Case Three:  Beyond Misconceptions

In 2020, a Scrum Master shared her experience working at a prominent for-profit educational institution that adopted SAFe as their guiding framework. There was friction coming from the CIO who was driving the initiative. She recounted instances where team members were reassigned to new roles without adequate training, resulting in their struggles to embrace agility. The most surprising aspect of our conversations was when she disclosed that the CIO attributed a failing or struggling transformation to a lack of understanding of the developer role among all team members. Instead of investing in targeted training for each team role, he mandated everyone attend a several-week coding boot camp. Even a product owner in her 60s was forced to learn coding instead of being offered additional training for her particular role. This training was expensive in cost and time.

The CIO believed that a need for more understanding of the developer role among team members caused the struggling transformation. However, this reflects a narrow interpretation of agility. Agile transformations are not just about technical skills or specific roles. They are about embracing collaboration, continuous improvement, and customer-centricity. The CIO’s misunderstanding of the Agile mindset, inadequate role-specific training, one-size-fits-all approach, neglect of the human aspect of transformation, resource misallocation, and lack of Agile leadership all contributed to the failure of the Agile transformation in this scenario.

This ineffective approach hinders  progress by excessively focusing on tools and roles, disconnecting from the true essence of agility. Led by an authoritative leader and an unconventional version of Scrum, it demonstrates a lack of respect for team members. Unfortunately, this behavior is observed in many leaders within larger organizations.

Case Four: Productivity Fallacy

The recent McKenzie article on measuring developer performance, released in August, has ignited a heated debate. It raises concerns that senior leaders, who may need more familiarity and experience with modern delivery practices, must be more discerning when interpreting this article. The emphasis on individual metrics aligns differently with a team-oriented, outcome-driven approach. An interesting point is that the McKenzie article was published about a week after I submitted my first two summer talks on team productivity over individual output focus, as referenced in the abovementioned example.

Recently, I experienced an organization undergoing valuation efforts to secure next-level funding or attract investment through acquisition from a larger organization. As part of the valuation, the investors mandated a Sema code scan (from the Sema website: Serving CTOs, CIOs, and other Senior Engineering leaders, plus the C-Suite and Boards of Directors, with comprehensive codebase metrics).

The main concern was how assessors perceived the team’s capability and productivity. The analysis focused on identifying key team members based on code commits. This data only considers coding contributions. The list of “top developers” or valuable team members, as perceived by the investor, was inaccurate. Several crucial team members essential to the organization were ranked outside the top 10. I have been discussing the impact of evaluating performance solely based on code commits and similar metrics over the past few years. Today, cross-functional teams deliver solutions, not individual developers. The key is team productivity and outcomes over individual output.

When businesses are presented with metrics, they are often misused, with a tendency to prioritize individual performance over team results. This poses a risk as team members may prioritize actions that boost their numbers rather than focusing on team outcomes and overall improvements. Consequently, this can lead to subpar output being delivered.

If your organization still operates in functional groups, it may be acceptable. However, focusing more on metrics related to the system, flow of work, and team performance is essential. Acknowledging that developers contribute through code commits and mentoring, collaboration, design, architecture, and problem-solving discussions is crucial. In today’s cross-functional agile teams, developers have broader responsibilities beyond just writing code. In such cases, the team collectively delivers software and value rather than individual contributions.

Understanding the Legacy Leaders’ Dilemma

Experienced leaders occupying critical senior leadership, executive, and board roles have succeeded and found solace in traditional methods (refer to the supplement at the end of this article for a detailed explanation of these traditional methods). Familiar with their mastered ways of working, they need assistance navigating the paradigm shift brought by Agile and DevOps. Their resistance is not just a matter of preference but is deeply intertwined with ego, vulnerability (they are supposed to be the experts), and a fear of the unknown. This reluctance to embrace change becomes a significant roadblock in the journey toward digital transformation.

The Detrimental Impact of Legacy Metrics

Much of my experience and conversations surface the demand to use legacy metrics that do not fit team-based practices and models. The insistence on using metrics that focus on individual productivity, tailored for past practices, has a cascading negative effect on modern teams:

  • Eroding Team Dynamics: Modern roles like software engineers in cross-functional teams rely on collaboration. Evaluating individuals based on outdated productivity metrics undermines this collective effort.
  • Misaligned Incentives: Old metrics create misaligned incentives, leading to a competitive atmosphere that damages morale and team spirit.
  • Stifling Innovation: Focusing on narrow, output-focused metrics discourages experimentation and adaptability, hindering personal growth and team innovation.
  • Inaccurate Assessment: Roles crucial in enabling the team, like agile coaches or value stream managers, are undervalued as their contributions don’t fit traditional productivity metrics.
  • Resistance to Change: Using outdated metrics fuels resistance, creating friction and potentially derailing transformation efforts.
  • Impeding Talent Retention: Adherence to outdated metrics makes an organization less attractive, potentially leading to losing talent who seek dynamic and collaborative work environments.

The Humbling Journey of Adaptation

Adapting to new methods requires leaders to embark on a humbling journey of unlearning and relearning. It’s a process that can bruise egos but is essential for growth and development. This adaptation is about acquiring new skills and reshaping one’s understanding of leadership and success.

The Crucial Role of Senior Stakeholder Commitment

Unsuccessful Agile transformations often highlight the importance of more substantial commitment from senior stakeholders in fostering emerging knowledge and skills. This lack of alignment not only slows down progress but also creates unnecessary friction within the organization.

Conclusion

Without enlightened leadership at the top, there is little hope for change. The cases in this article are just a small example of dysfunctional leadership and a misinterpretation of agile principles. It’s challenging to feel like we’re progressing or improving the situation under such leadership.

Adapting to change can be challenging, especially when legacy senior leaders create friction in modern digital transformation practices. It’s surprising how often this conversation comes up, even after over a decade of digital transformation. The fact that these conversations still happen today highlights the importance of continuous learning and the crucial role of professionals in guiding this transition.

For a transformation to succeed, leaders must be willing to evolve and embrace new paradigms while letting go of outdated practices. Thriving in this dynamic landscape requires committed and adaptable leadership eager to acquire new knowledge and support transformative efforts from the top down. Only then can we fully unleash the true potential of Agile, Lean, and DevOps practices.

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]