Rethink Your Understanding

Transforming Software Delivery

philc

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 high-trust and high-performance culture.

This approach isn’t about right or wrong; it’s about being clear about 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 asembles 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. He’s not alone; many seasoned leaders feel the same way.

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 team members. 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 advocated. He firmly believed 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 but 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 mid-level roles, and others bring strong leadership and coaching skills without being the most technically advanced in the room. This approach is intentional, and we understand that the skills needed for engineering are different from those required 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, dysfunction, or 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 to 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.

However, that model shifts the emphasis back toward hierarchy, toward delivery owned by the manager rather than the team. Our structure allows delivery roles like Tech Leads and Agile Leaders to rise within the team. 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, I led their engineering team, which was structured around the Engineering Manager model. The team was competent and used solid Agile practices, but the differences in structure and management philosophy 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. He struggled when he was asked to operate under our model, where people management and delivery leadership are separated. 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]

Flow Retreat 2025: Practicing the Work Behind the Work

by

4 min read

The Flow Leadership Retreat was the vision of Steve Pereira, co-author of the recently released book Flow Engineering: From Value Stream Mapping to Effective Action, and Kristen Haennel, his partner in building communities rooted in learning, collaboration, and systems thinking. But this wasn’t a typical professional gathering. Rather than a conference packed with sessions and slides, they created an immersive experience designed to bring together professionals from diverse industries to step back, reflect, and practice what it truly means to improve the flow of work.

The setting, against the remote and stunning oceanfront of the Yucatán Peninsula, wasn’t just beautiful; it was intentional. Free from the usual distractions, it created space for focused thinking, deeper conversations, and clarity that rarely emerges in day-to-day operations.

When I joined this first-ever Flow Leadership Retreat in March 2025, I expected thoughtful discussions on delivery systems, value streams, and flow. What I didn’t expect was how much the environment, the people, and the open space to think differently would shift my entire perspective on how work works.

As someone who’s spent the last 4 years advocating for Value Stream Management (VSM) and building systems that improve visibility and flow, I came into the retreat hoping to sharpen those tools. I left with refined perspectives and a renewed appreciation for the power of stepping away from execution to examine the system itself.

Flow Before Framework

On Day 1, we didn’t jump straight into diagrams or frameworks. Instead, we challenged ourselves to define what flow really means, individually and collectively. Some participants reached for physics and nature metaphors; others spoke about momentum, energy, or alignment.

And that was the point.

We explored flow not just as a metric but also as a state of system performance, psychological readiness, and sometimes a barrier caused by misalignment between intention and execution.

We examined constraints, those visible and invisible forces that slow work down. We also examined interpersonal and systemic friction as a root cause of waste and a signal for improvement.

The Power of Shared Experience

Day 2 brought stories. Coaches, consultants, and enterprise leaders shared what it’s like to bring flow practices into environments shaped by legacy processes, functional silos, and outdated metrics.

We didn’t just talk about practices. We compared scars. We discussed what happens when flow improvements stall, how leadership inertia manifests, and why psychological safety is essential to sustain improvement.

The value wasn’t in finding a single answer but in hearing how others had wrestled with the same questions from different perspectives. We found resonance in our challenges and, more importantly, in our commitment to change.

Mapping the System: Day 3 and the Five Maps

It wasn’t until Day 3 that we thoroughly walked through the Five Flow Engineering Maps. By then, we had laid the foundation through shared language and intent. The maps weren’t theoretical. They became immediate tools for diagnosing where our systems break down.

Here’s how we practiced:

  • Outcome Mapping helped us clarify what improvement meant and what we are trying to change in the system.
  • Current State Mapping exposes how work flows through the system, where it waits, and why it doesn’t arrive where or when we expect it.
  • Dependency Mapping surfaced the invisible contracts between teams, the blockers that live upstream and downstream of us.
  • Constraint Mapping allowed us to dig deeper into patterns, policies, and structures that prevent meaningful flow.
  • Flow Roadmapping helped us prioritize where to start, what to address next, and how to keep system improvement from becoming another unmeasured initiative.

We didn’t just learn to see the system. We refined our skills by applying real-world case examples to improve them.

An Environment That Made Learning Flow

The villa, tucked away on the Yucatán coast, offered more than scenery. It offered permission to slow down, think, walk away from laptops, and walk into reflection. It gave us the space to surface ideas and hold them up to the breeze as some of our Post-it notes blew away.

That environment became part of the learning. It reminded us that improving flow isn’t just about the process. It’s also about the conditions for thinking, collaborating, and creating clarity.

Final Reflections

This retreat wasn’t about doing more work. It focused on collaboration from different perspectives and experiences, understanding how work flows through our systems, and finding ways to improve it that are sustainable, practical, and measurable.

It reaffirmed something I’ve long believed:

We fix broken or inefficient systems, unlocking the full potential of our people, our products, and our performance.

I left with more than frameworks. I left with conversations I’ll be thinking about for months, new ways to approach problems I thought I understood, and the clarity that comes only when you step outside the system to study it fully.

I’m grateful for the experience and energized for what’s next.

References

  1. Pereira, S. & Davis, A. (2024). Flow Engineering: From Value Stream Mapping to Effective Action. IT Revolution Press.

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 to WaterScrumFall – Agile sprints, but still project-driven release cycles
  • Scrum to Kanban & Flow – Shifting toward continuous delivery and flow efficiency
  • Scrum Master to Agile Leader to 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 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]

Responsible Engineering: Beyond the Code, Owning the Impact

by

6 min read

A Dinner Conversation That Sparked a Deeper Discussion

Last night, I had dinner and great conversation with the CEO and partner of a global software engineering-as-a-service company. During our conversation, we discussed responsible engineering and its real meaning beyond the technical skills required to build software.

He shared an interaction he had with an intern at his company. When asked what responsible engineering meant, the intern answered, “A responsible engineer provides a solution that goes as deep as you can and ensures it operates effectively.” That definition, though simple, encapsulates a key part of what we often overlook in software engineering: the obligation to go beyond the immediate solution and fully own its impact.

I shared my thoughts during our conversation, and he suggested I write an article on the topic. That discussion sparked a realization: I had already created over half the material needed for such an article.

  1. I created an internal wiki page for my engineering teams to show how a lack of accountability can lead to costly mistakes in a SaaS organization. For instance, in late 2024, unmonitored logging after a production deployment caused expenses to spike by $15K–$20K in just one month. This was due to a coding error that generated excessive log volumes and related log statements that went unnoticed for a few weeks.
  2. I published an article in 2023 titled “Beyond Features: A Software Engineer’s Code of Conduct for Delivering Impactful Product Outcomes“ In it, I explored how engineers must take responsibility beyond simply writing and deploying code.

These resources are a great starting point for writing this post.

Engineering responsibility does not exist in a vacuum. It extends beyond individual engineers to entire teams and, ultimately, leadership. Another internal wiki post I shared focused on defining team standards for planning, quality, collaboration, and delivery. Responsibility isn’t just about engineers following their code; it’s about creating a team culture where expectations are clear, accountability is shared, and improvement is measurable.

Responsible engineering has been discussed in many ways over the years, but the real challenge isn’t just defining it; it’s making sure it becomes a genuine part of engineering practices, team culture, and leadership expectations.

What Responsible Engineering Means for Engineers and Engineering Teams

The Problem: Engineering Without Ownership Creates Unintended Consequences

We’ve seen what can happen when engineers fail to monitor their code after deployment. Even when tests like regression or smoke tests pass, they can miss issues like a significant increase in logging volume. There have been cases of AWS Lambda calls running unexpectedly or out of control, causing major expenses before a monitor stepped in to block them. These problems aren’t just about costs; they highlight a deeper issue of engineering responsibility.

When engineers don’t actively monitor their deployments, the business suffers:

  • Unplanned costs arise, burning through budgets.
  • System performance degrades without anyone noticing.
  • Technical debt accumulates because quick fixes introduce long-term inefficiencies.
  • Customers don’t receive the expected value or results.

The Engineer’s Role in Responsible Development

1. Own Your Code Beyond Deployment

A “Follow Your Code” culture means engineers don’t just ship code. They track, verify, and own its impact.

  • Done doesn’t mean merged. It means verified in production.
  • Engineers must proactively check logs, system metrics, and performance impact after deployment.
  • If your code introduces inefficiencies or waste, it’s not “working.”
  • Can you answer the following? “My changes are working as expected in <environment name here>, and I haven’t noticed any issues after deployment.“

2. Observability & Monitoring as a Core Engineering Discipline

  • Use monitoring tools to detect unintended spikes in usage, logs, or errors.
  • Compare logs before and after deployment to ensure no wasteful changes were introduced.
  • Treat system performance issues as functional bugs; if your code makes the system slower, it’s broken.

3. Write Cost-Conscious and Efficient Code

  • Be aware of the financial impact of logging, API calls, and inefficient queries.
  • Optimize code to reduce unnecessary compute, storage, and external service costs.
  • Avoid quick fixes that introduce long-term inefficiencies or hidden costs.

4. Build with Long-Term Impact in Mind

  • Consider scalability, maintainability, and total cost of ownership for every change.
  • Engineering isn’t just about shipping features. It’s about ensuring the business remains viable.
  • Avoid band-aid solutions that create future complexity.

What Responsible Engineering Means for Leaders and Management

For senior technology leaders, this is not just an engineering conversation. It’s a leadership conversation.

The challenge for leadership is not simply to set expectations but to create an environment where responsible engineering is the norm. The best leaders don’t just demand accountability from their teams. They teach what it means, model the behavior, and make it a shared responsibility.

How Senior Leaders Can Guide This Conversation with Engineering Teams

  • Frame responsibility as professional integrity, not fear.
  • Ask engineers questions that spark ownership.
  • Ensure engineering accountability is built into the team culture.
  • Recognize and celebrate responsible engineering.

Leaders can inspire engineers to embrace responsibility by making it a point of pride rather than fear.

RACI Example

This example might not fit your team structure or role responsibilities exactly. It’s meant to be used as a reference.

Diligence Over Complacency, Responsibility Over Negligence

I recognize that most software engineering is complex and difficult. It is a great skill to have, and yet again, I know we will make mistakes.

However, responsible engineering is not about eliminating every error. It’s about your approach and accepting responsibility. While it’s OK that there will be an occasional error, there is no room for complacency or negligence.

If you are not willing to take ownership, if you are content with cutting corners, or if you approach software with indifference toward its impact, then this job is not for you.

But this is not about fear; it’s about self-reflection.

Given my current skill set, capabilities, insight, and tools and practices, did I do everything possible to deliver the best code?

That is the mindset of a responsible engineer.

The Software Engineer’s Oath

“I recognize that great engineering is not just about writing code. It is about delivering something that truly makes a difference while honoring the trust placed in me to do so responsibly.”

I commit to:

  • Building with diligence, not complacency.
  • Respecting the responsibility I hold.
  • Minimizing harm and avoiding preventable failures.
  • Prioritizing quality, accountability, and long-term impact.
  • Acting with integrity and not compromising security or stability.
  • Delivering value without judgment of its significance to the user.

Being a software engineer is both a privilege and a responsibility. The joy of building and solving problems brings us into the field, but the trust placed in us by businesses, customers, and users defines us as professionals.

Given the significant changes AI is introducing, I can’t tell you what this profession will look like six months, a year, or two years from now. But that does not prevent us from being responsible engineers as we reshape this industry and how we deliver software.

Until then, have you and your team discussed and defined what it means to be a responsible engineer?

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, a release is not a work item in the industry-standard hierarchy. 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 and provide immediate feedback on a team’s ability to consistently ship high-quality software.

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 will become a stronger choice.

VSM Only Works If Other Departments Are Engaged

One of the biggest mistakes companies make 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 significant 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, 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 just 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]