Rethink Your Understanding

Transforming Software Delivery

DevOps

Mindsets That Shape Software Delivery Team Structures

by

10 min read

Many tech companies follow modern delivery practices but still use outdated methods, especially in team structures and leadership roles. This article, inspired by a recent conversation with a senior technology leader, challenges a common belief: Engineering Managers must manage the delivery team members and lead as the top technical expert.

Drawing from real conversations, post-acquisition integration stories, and years of experience designing autonomous teams, I share why our division intentionally separates people management from delivery—and how this model scales, empowers teams, and builds a culture of high trust and performance.

This isn’t about right or wrong—it’s about being clear on the mindset you’re scaling.

In software engineering and digital product delivery, organizations usually choose between two main team structures:

  1. Engineering Manager Model: The EM model is a traditional hierarchy in which an Engineering Manager leads each delivery team, overseeing technical direction and people management. The EM collaborates with a Product Manager and supervises developers, holding accountability for the team’s performance and delivery. This model centralizes decision-making and technical expertise within the EM role.
  2. Autonomous Cross-Functional Teams: Inspired by frameworks like Team Topologies1 and the military philosophy behind Team of Teams2, this approach assembles small, self-sufficient teams with all the roles necessary to execute a plan—developers, designers, QA engineers, product managers, and more. These teams operate with a high degree of autonomy, fostering agility, ownership, and rapid decision-making.

The shift from the Engineering Manager Model to Autonomous Teams represents a larger change in leadership, moving away from strict hierarchies toward more flexible and empowered teams.

Let’s be clear: neither model is inherently right or wrong. They’re both valid choices. The key is being deliberate about which mindset you’re scaling.

I’ve chosen to invest in autonomous, cross-functional teams without embedded Engineering Managers because, in our context, this approach enables us to deliver more effectively. And I’m not alone. Others swear by the EM model. Now you know where I stand.

Comparing the Two Models: Pros & Cons

1. Engineering Manager Model

Pros:

  • Clear accountability from a single leader
  • Strong technical mentorship if the EM is highly skilled
  • Alignment between team performance and people management
  • Familiar structure for many leaders from traditional orgs

Cons:

  • Risks creating “unicorn” roles that are hard to fill
  • Can unintentionally reinforce top-down control
  • May discourage team autonomy or distributed leadership
  • Blurs lines between mentorship and authority, creating tension

2. Autonomous Cross-Functional Teams

Pros:

  • High autonomy and ownership at the team level
  • Encourages collaboration, experimentation, and collective leadership
  • Managers can focus on coaching and career development
  • More scalable for organizations that prioritize agility and flow

Cons:

  • Requires strong role clarity (e.g., Tech Lead vs. Product Manager vs. Agile Leader)
  • Needs a mature culture of trust and psychological safety
  • May be unfamiliar or uncomfortable for legacy-minded leaders
  • Tension may arise when interfacing with traditional models

A Moment of Misalignment

I encountered a situation that reminded me how deeply embedded traditional leadership models can influence even the most forward-thinking organizations.

I met this past week with an executive whom I respect and his other senior managers. He’s a smart, strategic leader deeply invested in modernizing his organization’s tech stack and advancing toward a cohesive platform vision. In many ways, he’s working toward the same goals I care about: better systems, aligned priorities, and modern delivery practices.

But during the conversation, the executive—knowing how I’ve structured my teams—politely but firmly challenged my approach. He said, “No disrespect, but I believe every team must have an Engineering Manager who is also a strong technical leader—at least at the Principal Engineer level.” His tone carried conviction and genuine passion for the model he believed in. And to be fair, he’s not alone—many seasoned leaders feel the same.

The executive explained his point with an example: Who would you rather have leading an accounting team—an accountant who learned the trade 10 years ago and now mainly manages people or an accountant who is fully up-to-date with the latest practices and at the top of their game? While the comparison isn’t exact, the message was clear and easy to understand.

Still, at that moment, it felt like a direct, if respectful, challenge to the model I’ve spent years building—a model rooted in autonomy, distributed leadership, and cross-functional collaboration. Our models agree on the value of highly skilled, technically exceptional people on the team. The difference is where that expertise lives. His model places that expectation on the manager, which risks promoting great engineers into management roles they aren’t suited for—simply because they’re the most technically talented.

In contrast, my model ensures that technical excellence exists within the team but not necessarily in the manager’s seat. I prioritize having one or two highly skilled engineers on each team who act as technical leads, role models, and mentors without requiring them to manage performance or careers. This distinction protects both the integrity of leadership and the team’s health.

I believe our chosen structure works better, but this discussion reminded me that leadership models are rooted in deeply held philosophies. When those philosophies clash, tensions can arise that aren’t always easy to resolve.

The Modern Trap of “Experts at the Top”

What stood out to me wasn’t just the team structure he advocates—it was his firm belief that every Engineering Manager should also be a highly skilled technical expert, ideally at the Principal level. According to him, these managers don’t simply “manage people”—they serve as the technical backbone of the team, providing guidance, support, and expertise that others can rely on and learn from.

At first glance, it sounds reasonable—even admirable. Who wouldn’t want strong technical leadership?

This belief highlights a bigger problem: it sets up an unrealistic expectation for someone to be a top-notch engineer and an excellent people manager. The truth is, those who excel at technical mastery often aren’t interested in managing others—and many who take on the role may struggle with the people-focused side of it. Being great at technical work doesn’t automatically make someone a great manager, nor should it have to.

“When we expect Engineering Managers to be both top-tier coders and top-tier people leaders, we create a unicorn role—rare to find and hard to sustain.”

Having highly skilled, possibly Principal-level engineers embedded in a team is a huge advantage. However, I strongly disagree that those individuals must also be the team’s manager. In most cases, the best technical experts shouldn’t be managing others—they should be teaching, mentoring, and building alongside team members. Often, these seasoned engineers serve as the team’s technical leaders and mentors.

His EM model asks that every engineering manager not only lead but also be the best practitioner on the team. But we don’t apply that expectation to every function. We don’t expect the best CFOs to reconcile spreadsheets, and we don’t require the best individual contributors to also manage careers.

“Just because someone is excellent at their craft doesn’t mean they should lead the team. And just because someone leads doesn’t mean they must be the best at the craft.”

“Having elite talent on the team is essential—but that doesn’t mean the most talented person should be the one managing people.”

We Took a Different Path: Separating Management from Delivery

Our division has consciously decided to separate the manager role from the delivery team.

Our delivery teams follow the principles of Team Topologies. They are small, autonomous, and cross-functional, equipped with the skills and roles to achieve a clear product goal. Each team consists of:

  • A Product Manager or Owner
  • An Agile Leader
  • 2–4 Software Developers, including one or two serving as the Technical Lead and Domain Architect
  • A UX designer (if the team’s product has a user front-end)
  • 1 QA Engineer
  • And liaisons from InfoSec, Production Engineering, and Data Engineering as needed

No one on that team is their direct manager. And that’s by design.

Our Software Engineering Managers work independently of the delivery team structure. Their focus is on mentorship, career development, coaching, and supporting the growth of their team members. They are responsible for engagement, retention, and the performance of their direct reports, but they are not measured by team performance, sprint velocity, or feature delivery.

These managers are not expected to be Principal-level engineers. Some are senior engineers, some have even grown into the role from mid-level positions, and others bring strong leadership and coaching skills without being the most technically advanced in the room. This approach is intentional—we understand that the skills needed for engineering are different from those needed to lead people.

Our line-level and mid-level managers join a delivery team as individual contributors, often as senior engineers. But they do so in a contributor role, not as “the manager on the team.” The team sees them as a contributor, not someone to report to.

“We don’t embed managers on teams because we want our teams to be safe, autonomous, and accountable together—not upward.”

Ensuring performance accountability is key. Teams and individuals are still responsible for delivering results. However, a detailed discussion of this is beyond the scope of this post to keep things brief. Some of my other articles address team accountability.

Why We Do This

This model encourages:

  • Psychological safety – Developers can challenge ideas, learn from each other, and take risks without worrying about upsetting their boss.
  • Distributed leadership – Roles like Tech Lead and Agile Leader provide delivery guidance without conflating it with performance management.
  • High-performing team culture – We believe the team owns the outcomes, not a single manager.

And the results speak for themselves.

Since we adopted this structure, our retention rate has remained above 90%—and often closer to 95%. When team members left, they told us they loved the team and the culture. They cited personal reasons or exciting opportunities—not their manager, not dysfunction, and not delivery failure. Nearly every exit interview included gratitude for how much they learned, how supported they felt, and how proud they were of the work the team delivered.

“When people leave your organization but say they’d return if the opportunity came around, that’s a sign that your structure is working.”

We also promote from within—and I’ve seen successful engineering managers grow from senior or even mid-level engineers. People leadership is a separate skill. Not all principal engineers want to manage people, and not all great managers need to be elite coders.

Inspired by Team Topologies by Manuel Pais and Matthew Skelton and Team of Teams by General Stanley McChrystal, our approach emphasizes a model that scales with greater efficiency and effectiveness. I don’t need to assign an Engineering Manager to every delivery team. Instead, one Software Engineering Manager may support five to eight direct reports across different teams. This team design allows us to grow delivery capacity without linearly increasing our management headcount.

Of course, there’s a valid counterpoint: If you need enough Engineering Managers to maintain a healthy number of individual contributors anyway, why not make them the team managers, too? Many organizations do. It’s a logical model.

But that model shifts the emphasis back toward hierarchy—toward delivery being owned by the manager rather than the team. Our structure allows delivery roles like Tech Leads and Agile Leaders to rise within the team itself. It protects the autonomy and cohesion of each unit while enabling us to scale sustainably and strategically.

A Real-World Example from a Post-Acquisition Integration

After our company acquired a major competitor, their engineering team—structured around the Engineering Manager model—came under my leadership. They were competent and used solid Agile practices, but the structure and management philosophy differences created friction.

The Engineering Manager who led those teams had previously operated in a model where he was responsible for both delivery and the people on the team. When he was asked to operate under our model—where people management and delivery leadership are separated—he struggled. His most frequent concern was understandable: “How can I effectively lead, coach, and evaluate my direct reports without being deeply embedded in their daily team activities?” That’s a fair question—and one that deserves its conversation. (Reach out if you want to talk about that.)

He and I had several conversations, including one where we talked directly about command and control versus autonomy and accountability. At the time, I don’t think he fully saw his model as command-and-control. And to be fair, he didn’t lead with rigidity or ego. However, his leadership reflexes were shaped by a model where the manager must be on the team and must be the technical north star.

Eventually, he chose to leave and accepted a role in another Agile organization—one that also followed the EM model. It was a better fit for how he believed teams should be led.

“That experience reminded me that leadership models don’t just define how we build software. They shape how we grow leaders, how we see performance, and how we interpret success.”

There was no villain in that story. These are just two different philosophies and mindsets.

What Mindset Are You Scaling?

The structures we choose are important—but the mindset behind them matters more.

Are you building your organization around trust, autonomy, and team-level decision-making? Or are you unintentionally reinforcing control, hierarchy, and individual dependency?

Most modern organizations have adopted Agile frameworks and DevOps but are still leading from the top down. This is not always obvious; sometimes, it’s just beneath the surface, wrapped in titles and org charts.

As experienced leaders, our leadership styles are often shaped by the methods we’ve used in the past. Mine was. But the job of a modern leader isn’t to replicate ourselves in every team. It’s to build systems where teams can thrive without needing us in the middle of everything.

“Legacy mindsets don’t always look outdated. Sometimes, they wear a modern title but still lead from the top.”

One More Thought

We all have preferences. And structures are just models. The goal isn’t to pick the perfect one—it’s to be honest about why we choose it.

I’ve chosen the non-EM model because it can lead to higher-performing teams. I’ve seen it in practice, and we’ve built the system around it. Others will passionately argue for the EM structure, and that’s okay. Just know where you stand, and be clear about the mindset you’re scaling.

I’ve learned to rethink my understanding of management and leadership. Every now and then, a meeting like yesterday reminds me why that matters.

References

  1. Skelton, M & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
  2. McChristal, S. (General) & Collins, T. & Silverman, D. & Fussell, C. (2015). Team of Teams: New Rules of Engagement for a Complex World. Portfolio.

Poking Holes

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

Let’s talk: [email protected]

Why Cutting Agile Leadership Hurts Teams More Than It Saves

by

8 min read

The Cost-Driven Decision That Many Companies Regret

Many organizations today are eliminating the Scrum Master or equivalent Agile leadership role—not to rebrand it, but to cut costs. Instead of keeping Agile leadership as a dedicated role, they distribute its responsibilities across existing team members:

  • Engineering Managers take on Agile execution and delivery oversight.
  • Product Managers absorb backlog management, facilitation, and team coordination.
  • Team members self-manage Agile ceremonies, tracking, and reporting.

At first glance, this is a logical cost-saving move. Mature teams should be able to self-organize. But the reality is far more complicated.

In our company, we’ve seen firsthand that keeping Agile leadership as a distinct role pays off significantly more than the salary it costs.

Why We Didn’t Eliminate This Role

Like many organizations, we’ve gone through multiple Agile transformations:

  • Waterfall → WaterScrumFall – Agile sprints, but still project-driven release cycles
  • Scrum → Kanban & Flow – Shifting toward continuous delivery and flow efficiency
  • Scrum Master → Agile Leader → Agile Delivery Manager – Evolving the role encompassing Flow Metrics, Value Stream Management (VSM), Flow Engineering, and continuous optimization.

Rather than eliminate the role, we adapted it to better match how our teams and technology operate today.

We’ve moved away from Scrum and now use a Kanban flow with a few Scrum ceremonies mixed in. As a result, we changed the role name from “Agile Leader” since neither “Agile Coach” nor “Scrum Master” fit the way we work or the responsibilities of the role.

Meanwhile, our parent company—which structured product teams differently—removed the Scrum Master and QA roles, pushing those responsibilities onto Product and Engineering Managers. This team design isn’t inherently wrong, but it does fundamentally change team dynamics—and, in our experience, weakens long-term effectiveness.

Our support for this role deepened when we began adopting Value Stream Management in 2020 and 2021. As we learned more about optimizing the flow of work across the system, aligning delivery to OKRs and business outcomes, and using Flow Metrics to identify bottlenecks, we made a key decision: rather than hire a value stream architect or separate value delivery lead; we assigned that accountability to the Agile Leader. That move became a turning point. The role now included facilitation, value stream management, flow engineering, and cross-system delivery health. This expansion of responsibility led us to retitle the role of Agile Delivery Manager.

The Hidden Cost of Eliminating Agile Leadership

Many companies assume Agile execution can take care of itself. But what happens?

  • Engineering Managers are already stretched managing technical leadership, hiring, mentoring, and architecture. Adding Agile execution oversight creates competing priorities.
  • Product Managers are tasked with strategy, roadmap, and customer insight. When they absorb Agile execution, their ability to drive innovation and product-market fit suffers.
  • Teams default to feature-first work without someone to balance priorities across features, tech debt, security, and defects.
  • The erosion of Agile leadership often leads to a breakdown in psychological safety, team culture, and continuous improvement. Agile leaders aren’t just facilitators but team enablers who cultivate trust, alignment, and growth.

The impact of cutting or removing the dedicated agile leader role from teams isn’t a theoretical concern. We’ve seen organizations eliminate the role and reinstate it later after delivery slowed, burnout spiked, and alignment broke down.

What Happens When Agile Leadership Is Removed?

When Agile leadership is absorbed rather than owned, teams face:

1. Increased Cognitive Load for Engineering & Product Managers

  • Engineering Managers are expected to facilitate Agile ceremonies, track team health, and optimize delivery—on top of leading architecture and engineering excellence.
  • Product Managers now manage the backlog, facilitate delivery, and maintain customer alignment—all at once.

2. Reduced Flow Efficiency & Team Alignment

  • Work is optimized for speed over value, with more features and fewer strategic investments in quality, sustainability, or security.
  • No one is clearly accountable for balancing work types across the system.

3. Breakdown in Agile Practices, Psychological Safety & Team Culture

  • Retrospectives lose impact without consistent facilitation.
  • Process improvements stall without clear ownership.
  • Team culture and psychological safety erode, affecting engagement, retention, and long-term execution health.

The Agile Delivery Manager: More Than a Facilitator

As our practices evolved, the role titles and responsibilities changed as well. 2025, we’re updating it from Agile Leader to Agile Delivery Manager. The Agile Delivery Manager (ADM) is more than just a renamed Scrum Master—it’s an evolved form of Agile leadership designed to ensure:

  • Agile leadership is a focused role, not something to divide among the team  
  • Flow Metrics and Value Stream Management (VSM) help improve overall system delivery  
  • Teams prioritize both feature development and maintaining system health, technical debt, security, and fixing defects  
  • Psychological safety, collaboration, and a strong culture are actively maintained

Unlike Product Managers (incentivized to deliver features) or Engineering Managers (focused on technical excellence and delivery), the ADM has no stake in any single type of work. This neutrality is essential. They provide a holistic, unbiased lens on the system, ensuring balanced Flow Distribution and healthy delivery over time. Without this role, teams prioritize visible work and short-term wins, neglecting foundational needs.

What the Experts Say About Scrum Masters—and Why It Still Matters

Some well-known Agile voices have described the Scrum Master as a servant-leader, facilitator, and invisible guide:

“Great Scrum Masters don’t manage the team; they enable the team to manage themselves.”
— Gunther Verheyen, author of Scrum – A Pocket Guide

“A good Scrum Master is invisible. A great Scrum Master makes the team feel like they did it themselves.”
— Geoff Watts, Agile coach and author

“The role of the Scrum Master is not to ensure Scrum is implemented correctly—it’s to ensure that the team continuously improves and delivers value.”
— Scrum.org Blog

“Without a dedicated Scrum Master, teams often fall back into old habits—status reporting, command-and-control, and short-term delivery over long-term health.”
— Agile coach insight, echoed across retrospectives and forums

These quotes reflect the foundational role the Scrum Master plays in enabling self-managing teams, continuous improvement, and long-term value delivery.

However, the role must evolve as the team matures. When teams move beyond needing constant facilitation, the Agile leader doesn’t become unnecessary—they become more strategic. They step into a broader role: optimizing flow, supporting cross-functional alignment, stewarding system health, and driving outcome-based delivery.

Rather than disappearing, the Agile leader becomes even more critical—not as a passive servant, but as a system-level enabler of delivery efficiency and value.

Lessons from Inside: Comparing Team Models

I’m fortunate to work in an organization that supports both models: teams with dedicated Agile Delivery Managers and teams with responsibilities assigned to Engineering Managers. This side-by-side comparison has been revealing. Engineering managers in teams without an ADM often struggle to juggle architectural leadership, people management, Agile ceremonies, psychological safety coaching, and flow metrics. The burden is real, and it dilutes their impact across all fronts. What gets lost is not just ceremony facilitation but sustained attention to team health, value delivery, and process evolution. These teams tend to operate reactively without a clear guide focusing on system optimization.

That said, I also recognize that some long-lived, high-performing teams have matured to the point where they can self-manage without formal Agile leadership. These teams have developed strong cultures, embedded trust, and deep internal accountability. In those environments, the absence of a dedicated ADM may not be felt day-to-day.

However, this raises an important question: Who is responsible for reporting on delivery health, aligning with outcomes, and guiding continuous optimization across the system? That’s not a critique—it’s just something worth considering.

Different Models, Different Choices

To be clear, I’m not saying one model is right and the other is wrong. I’m sharing what I’ve seen work—and where I’ve seen things fall apart.

Different organizations, maturity levels, and team cultures will demand different approaches. But understanding the trade-offs is key. Eliminating Agile leadership may save salary dollars, but it can cost far more in lost alignment, missed improvement opportunities, and team degradation over time.

Key Responsibilities of the Agile Delivery Manager

  • Agile Leadership & Flow-Based Delivery
  • Facilitate planning, stand-ups, retrospectives, and production reviews
  • Align teams around roles and responsibilities and work across the value stream
  • Champion flow efficiency by removing bottlenecks and managing work intake
  • Foster psychological safety, trust, and continuous learning
  • Value Stream Management, Flow Engineering, and Flow Metrics Optimization
  • Lead monthly Flow Metrics reviews to help teams surface and resolve inefficiencies
  • Track Flow Time, Efficiency, Load, Velocity, and Distribution
  • Ensure investment in tech debt, security, and sustainability—not just features
  • Cross-Team Collaboration & Dependency Management
  • Align Product, Engineering, and Agile leadership
  • Coordinate across teams to manage dependencies and reduce delivery friction
  • Partner with Platform and Production Engineering teams for smoother execution

The Unicorn Problem: Why Overloading Other Roles Fails

Some argue that Product and Engineering Managers can take on these additional responsibilities—but at what cost?

The industry already struggles to fill these roles with strong candidates. When you ask one person to manage delivery flow, facilitate team dynamics, coach culture, drive Agile execution, and lead strategy, you create what I call the “unicorn problem.”

  • T-Shaped Leaders = Deep expertise in one area + a broad understanding of others
  • V-Shaped Leaders = Deep expertise in everything (engineering, Agile, customer insight, facilitation, coaching, metrics, and more)

Unicorns exist—but rarely, and not for long. Overloading these roles doesn’t set anyone up for success.

Should You Drop the dedicated Scrum Master or Agile Leader Role?

Most organizations still have a Scrum Master or equivalent Agile role—but some are experimenting with eliminating it in favor of shared responsibilities.

While this can work in some instances, our experience proves that a dedicated Agile leadership role improves:

  • Delivery flow efficiency
  • Business alignment
  • Sustainable team execution
  • Psychological safety and culture

So before you eliminate the role, ask: Who on your team is incentivized to prioritize delivery balance across features, tech debt, security, and defects? If no one owns that responsibility, it’s likely no one is doing it well.

Again, I’m not prescribing a one-size-fits-all answer. I’m sharing what I’ve seen in practice—from teams that struggled without this role to high-performing teams that outgrew it to the evolution of the ADM as a critical driver of system-wide value delivery. The key is clarity of purpose and accountability, no matter the model.

“Agile leaders don’t just guide their teams—they protect and improve the entire delivery system. They play a key role in ensuring its integrity and success. They are the guardians of the delivery system.” – Phil Clark

What’s your experience?

  • Has your organization eliminated this role?
  • If so, what impact has it had?
  • Should Agile execution be absorbed by Engineering and Product Managers?

Let’s keep the conversation going.

Related Posts

Poking Holes

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

Let’s talk: [email protected]

Avoiding Flow Metric Confusion: Aligning Agile Work Hierarchy to Flow Items

by

10 min read

Adopting Flow Metrics without understanding Value Stream Management, Flow Items, and the Agile Work Hierarchy can create confusion and misalignment. Connecting Agile work to Flow Items becomes challenging without this foundation, making it harder to measure and improve value flow. This article simplifies these concepts to help teams and leaders align Agile work with Flow Metrics, enabling better visibility and greater efficiency.

A common issue I’ve noticed is misinterpreting Agile work elements when modeling Flow Items. Many organizations don’t fully understand or follow the standard Agile Work Hierarchy.

This article aims to guide leaders in understanding and applying a framework to align Flow Items while exploring essential Value Stream concepts. Drawing from my experience, I’ve crafted this guide to simplify and make these topics more accessible. I hope it will provide valuable insights and practical tools for others navigating similar challenges.

Misunderstanding Resulting in Confusion

Recently, I observed a Technology division new to Flow Metrics trying to map their Jira Issue types to Flow Items. It was clear they didn’t have a solid understanding of the scope and context of a Flow Item. On top of that, multiple product and platform teams had the freedom to structure and manage their Jira instances however they wanted, with no effort to follow even basic industry guidelines. The teams had so many custom types that some members even argued tasks were deliverables, causing confusion between hierarchy levels and Flow Items.

Clearing the Murky Waters

I created the following Agile Work Hierarchy model to help teams standardize their project tracking tools, have a common language, and better align with Flow Items:

The Agile Work Hierarchy as commonly defined by industry standards

  1. Theme: At the top of the hierarchy, themes represent broad organizational goals or focus areas. They align teams and ensure all work supports overall business objectives.
  2. Initiative: A business objective made up of multiple epics working together to achieve a broader organizational goal or outcome.
  3. Epic: A large body of work that support the initiative and that can be divided into multiple features or user stories.
  4. Feature: A product function or characteristic that delivers value to the user. It typically originates from an epic and is further broken down into user stories.
  5. User Story: A simple, user-centric description of a requirement or request that explains a specific feature or function needed by the user.
  6. Task: A granular unit of work necessary to complete a user story. These are actionable steps assigned to team members.

“”Theme” isn’t an official Scrum term but is commonly used in Agile practices. Whether you view Themes and Initiatives as the same or different doesn’t impact the focus of this discussion. The key is to identify the right level of work items for Flow Metrics and Flow Items, regardless of naming conventions, to effectively map core work items in your practice.

The names used for work types in delivery tracking can vary depending on the platform or tools. For example, our teams have worked with two popular tools: Jira and Rally. Rally and Jira use different terms and structures for Agile work items and workflows, particularly in their terminology and hierarchy.

Rally

  • Initiatives/Epics: Rally uses Portfolio Items to represent high-level work, such as initiatives or epics, that align with strategic goals.
  • Features: These are essentially lower-level Portfolio Items used to group related user stories.
  • User Stories: Rally uses user stories as a key work item, aligned with Agile principles.
  • Tasks: These are smaller parts of user stories, breaking the work into more manageable steps.

Jira

  • Initiatives/Epics: Jira uses Epics for large bodies of work and supports an additional layer (e.g., Initiatives) with advanced roadmaps in premium plans.
  • Features: Jira doesn’t specifically label items as “features.” Instead, it often uses Epics or custom issue types to serve a similar purpose.
  • User Stories: User stories are tracked as Issues and can be customized with different fields and workflows.
  • Tasks: Tasks are a basic issue type in Jira, with sub-tasks available for more detailed tracking.

This post isn’t about recommending a specific labeling structure. It’s about understanding your work hierarchy to align your flow items with the smallest deliverable unit that adds value to your customer or organization.

We use an initiative-epic-user story-task hierarchy to structure work. Teams organize epics, which break down into smaller user stories. These stories are the main work items, mapped to flow items and represent the smallest units of value delivered to production and customers. Our process doesn’t include a feature layer.

Addressing Release Misconceptions

Another common misunderstanding I encountered in a different division was how Product Managers using Aha! defined their work hierarchy. They categorized the highest-level program element as a “Release.” However, in the industry-standard hierarchy, a release is not a work item—it is a scheduled deployment of a set of features or functionalities to the customer. A release can include multiple features, which in turn contain user stories and tasks. Misusing this term can lead to confusion in workflow tracking and alignment across teams.You don’t need to change how you and your teams label your levels, but it’s important to have clear, aligned definitions to help identify Flow Items.

Flow Items in Flow Metrics

Flow Items In Project to Product, Dr. Mik Kersten defines Flow Items as the primary units of work that move through a software value stream. These items fall into four categories:

  • Features: New functionality delivering business value to the customer.
  • Defects: Work items addressing quality issues impacting the user experience.
  • Risks: Tasks focused on mitigating security, compliance, or governance concerns.
  • Debts: Efforts improving system health, such as code refactoring or infrastructure updates.

These categories ensure that all work flowing through a value stream is accounted for and measured effectively.1

Clarifying Flow Items in the Agile Work Hierarchy

In Agile methodologies, it’s common practice to decompose Epics, Features, and User Stories into the smallest units of work that can deliver value independently. For instance, teams often aim to deliver User Stories sized at three to five story points, ensuring each piece is manageable and valuable.

Drawing insights from Mik Kersten’s Project to Product and the concept of Flow Metrics, I define a Flow Item is the smallest unit of work that delivers meaningful value to the user or the business. Even if all other work stops, delivering this item will still result in a clear benefit. Whether your organization calls them Features or User Stories, the key is that each Flow Item must deliver value on its own.

An anti-pattern to be cautious of involves breaking down work into segments that when delivered individually, don’t provide standalone value. For example, delivering only the URL endpoint for an API without its functional components doesn’t offer immediate value to the customer. Such practices can lead to misleading metrics, suggesting progress where the end-user perceives none.

To align Flow Items correctly with Agile work elements, I created a version of the Agile Work Hierarchy that follows the industry naming guidelines and highlights Features as the Flow Items (or User Stories depending on your context). Remember Flow Items should be the smallest units of work that deliver value to customers.

In the Agile hierarchy I’ve outlined, a Flow Item most closely aligns with a Feature. While User Stories are smaller, detailed requirements that contribute to a Feature, the Flow Framework operates at a higher level, focusing on the delivery of Features as complete units of value. 1

or depending on your context

or how we manage work

The goal is to choose one approach and stick with it. The key is to have a clear, standardized unit of work. It’s crucial to ensure that teams fully understand your definitions and how your work items align with Flow Items.

Clarifying Value Streams, Stages, and Mapping

This article does not aim to provide an in-depth education on Value Streams, as there are many excellent resources available to help you and your teams explore Value Streams and Value Stream Mapping. However, adopting Flow Metrics without first investing in this foundational knowledge can lead to significant challenges. Organizations often struggle to define a Value Stream, understand its components, and connect these elements to mapping efforts. Common difficulties tend to arise in four key areas:

  1. The Scope or Definition of a Value Stream
    • A Value Stream represents the entire end-to-end process from concept to cash (or value realization) of a Product.
    • A Value Stream should cover the entire product or product portfolio, including all teams and team members involved.
  2. The Stages or Phases of a Value Stream
    • Many teams confuse operational execution tasks with high-level Value Stream stages.
    • The Value Stream Model is typically presented as a series of distinct stages: Discovery, Delivery, Operation, and Support. Each stage represents a critical phase in the process of creating and delivering value.
  3. The Steps That Are Used to Create a Value Stream Map
    • Value Stream Mapping involves breaking down high-level stages into steps that contribute to the flow of value.
    • Steps such as Backlog, Planning, Development, Testing, Deployment, and Verification help identify where value is added and where inefficiencies occur.
    • These steps are different from granular tasks, which are the specific processes carried out within each step.
  4. The Confusion Between a Value Stream Mapping Step and a Process Mapping
    • One of the most common mistakes teams make is treating process mapping as value stream mapping.
    • Value Stream Mapping involves outlining the steps within a stage or phase of the Value Stream to identify delays, bottlenecks, and inefficiencies.
    • Process Mapping, on the other hand, is about detailing the specific activities within each step, such as coding, pull requests, code review, CI build, etc.

By addressing these four areas of confusion, teams can better align their understanding of Value Streams, ensuring Flow Metrics are applied correctly and effectively measured.

Value Stream Model

Value Stream Mapping

Process Mapping

Conclusion

When Agile work structures and Flow Items aren’t aligned, inefficiencies make measuring and improving value delivery with Flow Metrics harder. Linking Flow Items to the correct agile work item improves data quality and decision-making. Using a structured approach and best practices helps businesses maximize Flow Metrics and deliver results.

Bonus: Team Level OKRs

(Excerpt from Breaking Free from the Build Trap, Dec 25, 2024.)

OKRs align the team’s work with customer needs and organizational objectives. This alignment transforms sprints, epics, and initiatives from mere tasks into measurable milestones that drive meaningful business results.

OKRs bridge the gap between your team’s efforts and the outcomes that truly matter, encouraging a focus on value rather than speed. This mindset shift fosters intentional work and delivers impactful results.

Team Level OKRs tend to be either Initiatives or Epics.

Teams should define sprint goals based on outcomes, not tasks. Example: “Enhance system performance by improving response times by 5%” (outcome) versus “Complete three refactoring tickets” (task).

To develop a team-level OKR from a parent key result, you can use a method known as explicit alignment or cascading. This process transforms a higher-level key result into a focused objective for your team, ensuring clear alignment and purpose. Here’s an effective way to approach it:

  1. Define your desired outcome and ensure it aligns with a relevant Parent Key Result:
    Begin by reviewing the overarching OKRs at the company or department level. Identify a key result that aligns with your team’s responsibilities and can be directly influenced within your team’s scope.
  2. Transform the Key Result into an Objective:
    Reframe the parent key result as a clear objective for your team (the expected outcome). This objective will serve as the central focus of their efforts.
  3. Develop Supporting Key Results:
    Create 3-5 key results to help your team achieve this new objective. These should be specific, measurable, and aligned with the overall goal or outcome.
  4. Ensure Alignment:
    Make sure your team’s OKRs align with and support the higher-level objective they are based on. Set clear targets for each key result by defining what success looks like for your team about the parent key result. This will help keep your team focused and guide their efforts toward achieving the desired outcome.

References

  1. Project to Product: What Flows Through a Software Value Stream?, November 9, 2018 By Mik Kersten, https://blog.planview.com/what-flows-through-a-software-value-stream/

Poking Holes

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

Let’s talk: [email protected]

Decoding the Metrics Maze: How Platform Marketing Fuels Confusion Between SEI, VSM, and Metrics

by

9 min read

A Landscape of Confusion

By 2025, the tech industry will be more data-driven than ever, with engineering teams and leaders relying on metrics-driven insights to improve software delivery performance. However, the rise of Software Engineering Intelligence (SEI) platforms, existing Value Stream Management (VSM) platforms, and engineering metrics solutions have created a new challenge: marketing confusion.

Platform vendors, eager to differentiate their offerings, often blur the lines between these categories, making it increasingly difficult for technology leaders to distinguish between tools designed for engineering visibility versus those aimed at full-value stream optimization. This confusion leads to misaligned expectations, ineffective investments, and ultimately, frustration when organizations realize they’ve purchased a solution that doesn’t align with their needs.

This article serves as a follow-up to my August 2024 article:

Since that article, the landscape has continued to evolve. SEI platforms have gained significant momentum, the DX Core 4 framework has been introduced, and VSM platforms are still in the conversation—but with a shifting narrative.

Derek Holt, CEO of Digital.ai, has observed what he believes to be a major industry shift:

“While Value Stream Management continued to lose steam in 2024, we also saw the fast emergence of Software Engineering Intelligence (SEI) to take its place.”

— Derek Holt, CEO of Digital.ai (SD Times)

However, other experts argue that VSM remains critical for aligning technology with business outcomes. Heather Spring, a senior Product Marketing expert, highlights the enduring value of VSM:

“VSM is more than a process improvement tool—it’s a framework for achieving measurable business outcomes.”

— Heather Spring, Broadcom ValueOps (Broadcom Academy)

These contrasting viewpoints contribute to a growing problem:

  • Senior leaders struggle to distinguish between practices and platforms.
  • Different tools claim to offer “the future of software measurement,” but many serve only a narrow scope.
  • Organizations risk making misinformed investments based on incomplete narratives.

My Perspective as of February 2025

This article represents my point of view, given the current state of these technologies in early 2025. Over the past few years, I’ve observed significant shifts in how software measurement platforms are marketed, adopted, and integrated into organizations.

Importantly, this article does not dive into specific frameworks such as DORA, SPACE, Flow Metrics, or team sentiment and developer experience qualitative metrics. Instead, it focuses on the platforms that integrate these various metrics and how their marketing narratives have confused senior leaders unfamiliar with this space.

The Growing Demand for Data-Driven Insights

A few years back, DORA metrics gained much attention, and early tools focused on providing dashboards to track them. Over time, these tools evolved and rebranded as Software Engineering Intelligence (SEI) solutions.

SEI platforms have gained significant traction recently as organizations recognize the importance of developer efficiency, software delivery performance, and engineering operational health. These platforms provide granular insights into pull request cycle times, deployment frequencies, mean time to recovery (MTTR), and engineering throughput, giving leaders a clear picture of how efficiently software is being built and delivered.

At their core, SEI platforms are designed to improve engineering operations, helping teams identify delivery bottlenecks, optimize workflow efficiency, and measure team health. For organizations still struggling to improve operational efficiency within delivery, SEI platforms make perfect sense—they provide immediate feedback on a team’s ability to ship high-quality software consistently.

However, SEI is not the same as Value Stream Management.

Understanding the Misconceptions Around SEI and VSM

The key difference between these platforms lies in their scope. While SEI focuses on engineering processes, VSM platforms aim to provide end-to-end visibility across the entire software development lifecycle—from ideation and discovery to delivery and operation. The challenge is that many platform vendors position SEI as interchangeable with VSM, when in reality, the two serve different yet complementary purposes.

This overlap often leads to misaligned expectations for companies adopting these tools. Organizations seeking deep engineering intelligence might mistakenly invest in a VSM platform. VSM platforms can be more expensive because they can gather and present data from all stages of the digital product lifecycle, and most vendors target the larger enterprise market. However, they may lack detailed data from the engineering delivery stage, or your organization may not be ready to handle this scope. Companies looking for full end-to-end visibility might purchase an SEI platform focusing only on software delivery, preventing them from improving efficiency in the other value stream stages.

I recommend using metrics that cover the entire Value Stream, but this might not be cost-effective for many companies. To avoid choosing the wrong platform, technology leaders should start by identifying their organization’s bottlenecks:

  • An SEI platform is likely the best investment if engineering teams struggle with delivery performance.
  • If the challenge extends beyond engineering—into product management, discovery, and business alignment—VSM becomes a stronger choice.

VSM Only Works If Other Departments Are Engaged

One of the companies’ biggest mistakes when adopting VSM platforms is assuming that technology alone can drive the initiative. The reality is that unless other departments—such as marketing, sales, or business leadership—see the value in tracking their processes, a VSM approach will not deliver full business impact.

VSM investment becomes effective when organizations use it to:  

  • Track and improve discovery workflows, such as how product teams validate ideas before passing them to engineering.  
  • Interest in capturing how the marketing and sales teams collaborate to support the discovery phase of the value stream by capturing these processes.
  • Provide visibility into how cross-functional collaboration impacts the creation and delivery of digital products.

If your leadership and other departments discuss process visibility and workflow optimization, a VSM solution can drive enterprise-wide improvements in parallel with software delivery improvements. However, if the initiative is primarily driven by engineering, then SEI is the better starting point, allowing teams to optimize delivery before expanding to broader value stream visibility.

My Journey Evaluating These Platforms in 2022

Between 2022 and 2023, before the term Software Engineering Intelligence (SEI) became widely known, I carried out a detailed evaluation of platforms for my organization including:

  • Digital.ai
  • ServiceNow
  • Planview (then Tasktop Viz)
  • Jellyfish
  • Broadcom
  • LinearB
  • Plutora
  • Pluralsight Flow
  • Sleuth

Most of these platforms have improved since I first evaluated them. At the time, to the best of my knowledge, tools like LinearB, Sleuth, and Jellyfish had not yet embraced the term SEI. They were engineering analytics tools focused on measuring software delivery performance. Meanwhile, Tasktop, Digital.ai, Broadcom, and ServiceNow identified their offerings as Value Stream Management (VSM) platforms.

Given our organization’s transformation stage, I narrowed the choices down to two platforms:

  1. Tasktop Viz (now Planview Viz) – A strong VSM platform offering broad value stream insights but lacking delivery-stage granularity.
  2. LinearB – A strong delivery-focused platform providing deep engineering analytics but lacked visibility for ideation-to-delivery.

At the time, I saw clear trade-offs:

  • VSM platforms were valuable for tracking end-to-end flow but lacked deep delivery insights.
  • Delivery-focused platforms had engineering visibility but provided no insight into ideation or operations and support stages of the Value Stream.

In 2024, my preferred VSM platform acquired an SEI platform, confirming my earlier belief that larger VSM platforms without detailed delivery integration would eventually seek to expand their capabilities through acquisitions.

The Emergence of DX Core 4

Contributing to the ever-changing landscape and array of choices, a major development is DX Core 4—a framework designed to unify existing developer productivity models. DX Core 4 brings together principles from DORA, SPACE, and DevEx, focusing on four key dimensions:

  • Speed – How quickly software moves through the system.
  • Effectiveness – The ability to deliver software that meets requirements.
  • Quality – Ensuring software meets standards while minimizing defects.
  • Impact – Measuring the business and customer impact of software delivery.

The intent behind DX Core 4 is to balance these metrics, preventing over-optimization in one area at the cost of another. GetDX’s announcement provides more details.

Breaking Down Marketing Myths

Myth 1: AI is Exclusive to SEI

The SEI Claim: SEI platforms are the future because they use AI for deep analytics and decision support, while VSM platforms do not.

The Reality: This is completely false. Leading VSM platforms, including Planview Viz and ServiceNow, have invested heavily in AI and generative AI-driven insights for deep data analysis, decision-making, and flow optimization.

SEI vs. VSM AI Capabilities

AI is not an SEI-exclusive feature. Instead, both SEI and VSM integrate AI-driven analytics—SEI for engineering delivery metrics, and VSM for end-to-end business value flow across the organization.

Additionally, Planview’s Viz (copilot), Broadcom’s ValueOps (The Future of Value Stream Management Will Be Powered by AI), and others have integrated AI-driven workflow automation, tool integration, and predictive analytics, further demonstrating that AI capabilities are not exclusive to SEI.

Myth 2: SEI Covers the Full Value Stream

The SEI Claim: SEI platforms provide comprehensive visibility into software engineering performance.

The Reality: SEI platforms focus on the delivery stage of digital product development. They analyze developer productivity, team and operational efficiency, and software engineering health—but they do not track the full lifecycle of a digital product from ideation to operation. The SEI platform might be exactly what your organization needs at its current stage or context.

Comparing Scope: SEI vs. VSM

The Main Takeaway

The key takeaway in the SEI vs. VSM discussion isn’t which toolset is gaining momentum—it’s about scope. Don’t let marketing hype or opinions mislead you. While they can guide your decision, it’s crucial to understand the framework or label: SEI focuses on software delivery performance metrics within the build and deployment pipeline, while VSM spans the entire digital product lifecycle—discovery, delivery, operations, and support.

SEI tools offer limited insights into how efficiently code moves through development and deployment, but VSM goes further by asking: Are we delivering the right value efficiently across the entire product journey? When evaluating a VSM platform, consider both the quality of development and deployment metrics and the broader data they use to provide visibility across the value stream and organizational impact.

Rather than viewing SEI as a competitor to VSM, see it as a specialized tool for the delivery stage, while VSM ensures visibility, optimization, and continuous improvement across the entire value stream.

Choose the Right Metrics for Your Needs

Instead of asking, “Which platform is winning?” the better question is:

Which platform works best for your needs and provides the best visibility—whether for a specific part of your value stream or the entire one?

Organization and Engineering leaders should focus on what matters: selecting the right tools to address the correct problems. The question isn’t just about SEI vs. VSM—it’s about clearly understanding:

  • Where your organization’s bottlenecks exist
  • Who is driving the initiative
  • What level of visibility will drive the most impact

A few years ago, I started working with modern metrics like DORA. Since then, I’ve become a board member of the Value Stream Management Consortium, a champion for VSM implementation at my current organization, and an advocate for aligning software delivery metrics with business outcomes. This has given me the chance to explore the growing world of value stream management (VSM) and software engineering intelligence (SEI) platforms. Interestingly, a former colleague of mine is now a co-founder of one of these emerging platforms.

Vendors often use persuasive marketing to grab your attention and budget, but it’s important not to get caught up in the hype. Focus on your organization’s specific needs and the scope of the solutions offered. VSM and SEI platforms can differ greatly in features and cost, so finding the right fit means balancing your budget with your business priorities. Take the time to assess what truly matches your goals before making a decision.

Poking Holes

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

Let’s talk: [email protected]

Beyond outcome-focused metrics: Connecting Work to Outcomes

by

5 min read

In her recent article, Measuring What Matters: Using Outcome-Focused Metrics to Build High-Performing Teams in 2025 1, Leah Brown from IT Revolution—an industry-leading resource on digital transformation strategies—emphasizes prioritizing real business value over purely technical outputs. She highlights that truly effective value measurement requires:

  • Clear alignment on strategic direction and goals
  • Regular communication of value across stakeholders
  • Built-in feedback loops to validate assumptions
  • Focus on outcomes over outputs
  • Willingness to adjust based on learning

This approach aligns with IT Revolution’s research, which has been instrumental in shaping modern software delivery practices. These principles align closely with my mission—to bridge the gap between technology investments and business outcomes through better flow, business alignment, and leadership accountability.

A key challenge in many organizations is that software development and platform investments are often seen as black boxes—necessary costs disconnected from measurable business value. By structuring measurement around value streams and outcome-driven metrics, we can connect technology investments directly to business results and make the value of software delivery transparent.

Applying Value Stream Thinking to a Culture of Value Measurement

Shifting the organization’s focus to customer value streams is a key way to reinforce strategic alignment, feedback loops, and outcome-driven measurement.

When value streams are the core management approach:

  • Customers get the immediate benefit of priority at the organizational level – In addition to internal teams optimizing for efficiency, the entire organization prioritizes work that directly improves customer outcomes.
  • The organization becomes more responsive to customer needs and value creation, aligning outcomes over outputs. A value-driven operating model ensures that teams measure success not by what they produce but by how it improves customer experience, revenue, or retention.
  • Problems surface earlier, and solutions are faster and more sustainable. Value streams highlight bottlenecks and inefficiencies in delivering customer value while supporting built-in feedback loops, ensuring that delays, hand-offs, and friction points are made visible before they become significant issues.
  • Collaboration, continuous improvement, and problem-solving become natural outcomes – Instead of forcing teams into siloed KPIs, a value stream focus encourages alignment across departments, reducing hand-offs and friction, enabling faster decision-making, more iterative feedback, and fewer artificial constraints.
  • There is a clear and transparent connection between work and value – In many organizations, software teams are seen as cost centers rather than strategic enablers. When work is structured around value streams, there is greater transparency into how investments in software development and platforms contribute to business goals. This alignment reinforces regular communication of value across stakeholders.
  • All initiatives must be tied back to a customer or business metric. This principle directly supports outcome-driven measurement. By tying all work to business metrics, organizations avoid point optimizations (improving one team’s efficiency at the expense of customer value) and instead focus on work that improves a few critical metrics.
  • Cross-company cultural initiatives become easier to implement – Many organizations struggle with broad transformation efforts because they are optimized for vertical silos, not horizontal value delivery. Value stream management connects teams across functions, making it easier to align priorities, drive enterprise-wide change, and improve strategic execution.
  • Bureaucracy and process inefficiencies become visible – One of the most significant benefits of value stream-based measurement is that it exposes where excessive approvals, dependencies, and misaligned goals slow delivery. By tracking work across the value stream, organizations can see where bureaucracy blocks flow and make data-driven improvements.

Value Streams & Flow Metrics: Unclogging the Arteries of an Organization

In Value Stream Management conversations, the highway analogy regarding the greater volume on a highway, the more restricted cars travel (referring to work in progress or WIP), or if roadwork is slowing the flow is common (friction). Recently, I came across an analogy comparing Value Stream Management to clogged arteries. Most organizations operate like clogged arteries—value streams are blocked by excessive hand-offs, approval processes, and misaligned priorities. Instead of measuring and improving flow, they optimize for vertical efficiency in isolated teams, much like focusing on individual organs rather than blood circulation.

  • The heart keeps blood flowing freely in a healthy body, ensuring oxygen and nutrients reach every part of the system.
  • Value Stream Management keeps work flowing freely in a healthy organization, ensuring value reaches customers and reducing delays.

However, many organizations suffer from congested workflows, unnecessary approvals, long hand-offs, and fragmented ownership—like arteries clogged with plaque leading to:

  • Work stalling in queues instead of moving efficiently.
  • Teams focus on local optimizations rather than system-wide flow.
  • Decision-making being slowed by too much bureaucracy.
  • Business leaders are unable to see where the real problems are.

Instead of waiting for a heart attack (a major failure or missed market opportunity), organizations should treat flow efficiency as a leading indicator of business health. Just as doctors track blood pressure and cholesterol to prevent heart disease, organizations should track Flow Metrics to avoid workflow breakdowns.

Value Streams as the Foundation of a Culture of Value Measurement

Building a true culture of value measurement requires structuring the entire organization around outcomes and customer value streams, not internal projects or siloed optimizations. Organizations can reinforce a culture of Outcome focus and Value Measurement using Value Stream Management.

  • Start with Clear Alignment on Strategic Direction – Each value stream team should define or be clear on the expected outcomes before starting work.
  • Regularly Communicate Value Across Stakeholders – Track progress using OKRs and periodic metric reports. Consistently evaluate performance to highlight progress, small achievements, or course corrections.
  • Implement Feedback Loops to Validate Assumptions – Capture and reflect on Flow, DORA, and related Metrics across the entire value stream, not just engineering velocity.
  • Focus on Outcomes, Not Just Outputs – Use Value Stream Thinking to ensure teams optimize for business results rather than just completing tasks.
  • Be Willing to Adjust Based on Learning – If a team’s work isn’t improving a key customer metric, be willing to pivot and shift priorities based on real-world feedback.
  • Make Technology Value Visible – Stop treating software and platform engineering as an invisible backend function. Instead, connect technology investments directly to business goals like revenue, customer retention, and agility.

Want to Go Deeper?

For further reading, check out these articles:

Metrics

Let’s continue the conversation—how is your organization shifting from output tracking to true business impact using value streams?

Poking Holes

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

Let’s talk: [email protected]

References

  1. Measuring What Matters: Using Outcome-Focused Metrics to Build High-Performing Teams in 2025, Leah Brown, IT Revolution, https://itrevolution.com/articles/measuring-what-matters-using-outcome-focused-metrics-to-build-high-performing-teams-in-2025/

Managing Technical Debt: Interest Rates, Impact, and Continuous Payments

by

5 min read

In my earlier article, Advocating for Refactoring Prioritization in the Context of Business Goals, I discussed the importance of aligning refactoring efforts with business objectives. As I continue working with cross-functional software delivery teams, a persistent challenge remains: How do we prioritize technical debt alongside feature work?

One of the challenges many of us experience across software delivery teams is balancing technical debt work with feature development, defect resolution, and risk mitigation. Too often, technical debt becomes a “later problem”—a looming burden that teams only address during rare, large-scale cleanups. This reactive approach is costly, time-consuming, and disruptive. What if teams treated refactoring like paying down a car loan or mortgage instead? By making continuous, small payments, teams can manage their technical debt effectively, avoid major disruptions, and maintain a healthier codebase.

This topic resurfaced for me while listening to Martin Fowler’s recent conversation on a podcast on technical debt1. Fowler discussed how the metaphor of technical debt as financial debt helps teams decide when to “pay interest” (live with the consequences of cruft) versus when to “pay down the principal” (refactor and improve maintainability). He emphasized that the real power of this metaphor lies in evaluating the cost of inaction—understanding how much harder it becomes to work within a debt-ridden system and deciding when the trade-off is no longer sustainable.

One idea that resonated with me is the importance of treating technical debt like financial debt in a more structured way. Not all debt is equal—some accrue high interest (actively slowing down teams and introducing defects), while other debts have low interest (minor inefficiencies that don’t immediately impact delivery).

As a software engineer and leader, I strongly support a simple approach many in the industry advocate: regularly addressing small amounts of technical debt instead of letting it build up into a bigger problem. As Martin Fowler warns about letting cruft pile up, teams must proactively incorporate refactoring into their daily work. Instead of waiting for large-scale cleanup efforts, we should treat refactoring like making the minimum payments on a loan—ensuring that technical debt never compounds to an unmanageable state.

Technical Debt as a Loan: The Power of Minimum Payments

To extend the metaphor of technical debt as financial debt, let’s consider how we approach paying off a loan:

  • Minimum payments: Even if you can’t pay off your entire loan right now, making regular minimum payments ensures the debt doesn’t spiral out of control.
  • Lump sum payments: Occasionally, you might have the opportunity to pay down a large chunk of principal, significantly reducing future interest.

When applied to software development, these concepts offer a useful lens for managing technical debt:

  • Minimum payments: Every time a team touches a section of code, they should commit to improving it incrementally—whether through refactoring, improving test coverage, or simplifying logic. Minimum payments is akin to pulling small weeds in a garden whenever you see them, preventing them from growing into a tangled mess.
  • Lump sum payments: Occasionally, teams may need to dedicate focused effort to resolving high-interest debt, such as a major architectural refactor or addressing systemic issues in a critical module.

By regularly making small improvements, teams can prevent technical debt from accumulating to the point where it requires costly interventions.

Integrating Minimum Payments into Daily Work

Refactoring should not be a separate project or deferred until a “later” that rarely arrives. Instead, it should be a continuous part of the development process woven into every task. Here’s how teams can make this mindset part of their daily work:

  1. Adopt the “Boy Scout Rule”: Leave the codebase better than you found it. Each time a team touches a file, they should look for opportunities to simplify or improve it, even if it’s just removing a small piece of cruft or adding a meaningful test.
  2. Refactor within feature work: When building a new feature, allocate time to clean up the surrounding code. For example, if adding functionality to a poorly written class, take the opportunity to refactor it into a more maintainable structure.
  3. Set aside capacity for improvement: As teams plan for feature work, defects, and risks, they should explicitly allocate capacity for technical debt. Allocating capacity doesn’t always mean large refactoring efforts—it could simply mean committing to small, meaningful improvements during sprint planning.
  4. Make refactoring visible: Use tools like Jira or technical debt registries to track and prioritize technical debt. By making this work visible, teams can demonstrate its value and ensure it’s considered during planning.

These practices ensure that teams always make minimum payments on their technical debt, reducing the risk of accumulation.

Balancing Technical Debt and Business Outcomes

While continuous payments are vital, teams must prioritize technical debt work based on its impact. Just as interest rates guide financial decisions, teams can evaluate technical debt’s “interest rate” to decide when and where to focus their efforts.

Here’s how teams can assess technical debt:

  1. Interest rate: What is the cost of maintaining this debt? Does it slow development, increase defect rates, or create deployment risks?
  2. Impact of repayment: What business or customer outcomes will this debt improve? For example, will it accelerate feature delivery or enhance customer reliability?
  3. Visibility: How often does this debt surface? If it’s in a rarely used module, it may be a lower priority than debt in a core system.

For example:

  • A low-interest debt might involve minor inefficiencies in logging frameworks, which can be deprioritized in favor of high-impact features.
  • A high-interest debt, such as a tightly coupled architecture that slows feature delivery, should take priority because it can significantly impact productivity and customer outcomes.

These criteria allow teams to decide how much effort to allocate to technical debt versus other priorities.

Teaching Advocacy for Technical Debt

One of the challenges I’ve seen is that technical leads and managers often struggle to advocate for technical debt. Product owners naturally excel at framing features in terms of business outcomes, such as increased revenue or customer satisfaction. Technical leads must develop a similar skill: speaking the business language to articulate the value of addressing technical debt.

Here are some strategies for building that advocacy:

  1. Focus on outcomes, not processes: Instead of saying, “We need to refactor this code,” say, “Refactoring will reduce our lead time by 20%, enabling us to deliver features faster.”
  2. Leverage metrics: Quantify the impact of technical debt using cycle time, defect rates, or other engineering metrics.
  3. Collaborate with product owners: Work with product owners to align resolving technical debt with roadmap goals. For example, focus on fixing critical debt before major feature launches to allow enough time for resolution and keep the efforts on track.

Technical debt management is not about waiting for a perfect moment to act. It’s about weaving continuous improvement into the fabric of daily work, balancing short-term business goals with long-term sustainability. With the right mindset and advocacy, we can ensure that technical excellence and business outcomes go hand in hand.

Poking Holes

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

Let’s talk: [email protected]