Rethink Your Understanding

Transforming Software Delivery

Product Delivery

How Value Stream Management and Product Operating Models Complement Each Other

by

7 min read

“The future of software delivery isn’t about process versus structure; it’s about harmonizing both to deliver better, faster, and smarter.”

Next month, I am invited to meet with a senior leader from a large organization, who is also a respected industry figure, to discuss the Product Operating Model. I initially saw it as a good opportunity to prepare and share insights. Instead, it sparked an important realization.

In late 2020, I introduced Value Stream Management (VSM) to our organization, initiating the integration process in 2021. At the time, this marked the beginning of my understanding of VSM and our first attempt to implement it. Since then, we’ve gained more profound insights and valuable lessons, allowing us to refine our approach.

Recently, when asked about Value Stream Management (VSM), I explained that it helps make our Agile, Lean, and DevOps investments visible.
Now, with our VSM 1.5 approach, I highlight that it also makes our investments in Agile, Lean, DevOps, OKRs, and Outcomes more transparent.

Today, we are evolving our Value Stream Management (VSM) practices into what we now call VSM 1.5 (assuming we started at 0.9 or 1.0).

We took a more logical approach to redefining our Value Streams and aligning teams. We’ve also improved how we focus on metrics and hold discussions while requiring the anticipated outcomes of each Initiative or Epic to be documented in Jira. I outlined a strategy for leveraging team-level OKRs to align with broader business outcomes. I’ve also briefly touched on this concept in a few other articles.

As I prepared for this upcoming meeting, I came to a surprising realization:

We weren’t just implementing Value Stream Management, we were organically integrating Product Operating Model (POM) principles alongside it.

It wasn’t planned initially, but it’s now clear we weren’t choosing between two models. We were combining them, which became the foundation for our next level of operational maturity. This evolution reflects our commitment to continuously improving and aligning our methodologies to deliver greater customer and business impact.

Value Stream Management and the Product Operating Model

In software engineering, a value stream refers to the steps and activities involved in delivering a product or service to the customer. Value Stream Management (VSM) is the practice of optimizing this flow to improve speed, quality, and customer value.

A Product Operating Model (POM) serves as the blueprint for how a company designs, builds, and delivers software products. It ensures that teams, processes, and investments are aligned to maximize the customer’s value, driven by clear anticipated outcomes.

At first glance, Value Stream Management and the Product Operating Model are separate approaches, each with its terminology and focus. But when you look deeper, they share the same fundamental spirit: ensuring that our work creates meaningful value for customers and the business.

Despite this shared purpose, their emphasis differs slightly:

  • VSM focuses primarily on optimizing the flow of work, identifying bottlenecks, improving efficiency, and making work visible from idea to customer impact.
  • POM focuses on structuring teams and organizing ways of working, ensuring that ownership, funding, and decision-making are aligned to achieve clear, outcome-driven goals.

Together, they are not competing models but complementary disciplines: one sharpening how work flows, the other sharpening how teams are structured to deliver purposeful outcomes.

The key difference is where they start:

  • VSM starts with flow efficiency and system visibility.
  • POM starts with structure and ownership of the business outcome.

Why Combining POM and VSM Creates a Stronger Operating Model

Structure without optimized flow risks bureaucracy and stagnation.

Flow optimization without clear ownership and purpose risks fragmentation and, worse, the acceleration of delivering the wrong things faster.

Without aligning structure and flow to meaningful business and customer outcomes, organizations may become highly efficient at producing outputs that ultimately fail to drive real value.

Together, they provide what modern digital organizations need:

  • Product Operating Model (POM): Clear ownership, accountability, and alignment to expected business and customer outcomes.
  • Value Stream Management (VSM): Optimized, visible, and continuously improving flow of work across the organization.
  • Both combined: A complete operating model that structures teams around value and ensures that value flows efficiently to the customer.

When combined, POM and VSM offer a holistic view, structuring teams with purpose and optimizing how that purpose is realized through efficient delivery.

Industry Research: Reinforcing the Shift Toward Outcomes
Recent research reinforces the importance of this convergence. Planview’s 2024 Project to Product State of the Industry Report 1 found that elite-performing organizations are three times more likely to use cascading OKRs and measure success through business outcomes rather than output metrics. They are also twice as likely to regularly review Flow Metrics, confirming that outcome-driven practices combined with flow efficiency are becoming the new standard for high-performing organizations.

“Structure gives us ownership. Flow gives us visibility. Outcomes give us purpose. The strongest organizations master all three.”

Our Journey: VSM 1.5 as a Harmonization of POM and VSM

As we’ve matured our approach, it’s become clear that many of the practices we are implementing through VSM 1.5 closely align with the core principles of the Product Operating Model:

  • Clear Value Stream Identity:
    Using Domain-Driven Design (DDD) to define real business domains mirrors POM’s emphasis on persistent product boundaries.
  • Outcome Ownership:
    Mandating anticipated and actual outcomes aligns directly with POM’s shift from measuring outputs to business impacts.
  • Cross-functional Accountability:
    Structuring teams around value streams, not just skills or departments mirrors the cross-functional empowerment central to POM.
  • Flow Visibility and Metrics:
    Monitoring flow efficiency, team health, and quality reflects VSM’s original intent and POM’s focus on systemic improvement.
  • Customer-Centric Thinking:
    Closing the loop to validate outcomes ensures that teams remain connected to customer value, not just internal delivery milestones.

In short, without realizing it at first, VSM 1.5 evolved into a model that harmonizes the structural clarity of the Product Operating Model with the operational discipline of Value Stream Management.

Recognizing Our Current Gaps

While VSM 1.5 represents a significant step forward, it is not the final destination. There are important areas where we are still evolving:

  • Mid-Level OKR Development: While we have mandated anticipated outcomes at the initiative level, consistently translating these into clear, mid-level OKRs and connecting team efforts explicitly to business outcomes remains a work in progress. Strengthening this bridge will be critical to our long-term success.
  • Funding by Product/Value Stream: Today, our funding models still follow more traditional structures. Based on my experience across the industry, evolving to product-based funding will require a longer-term cultural shift. However, we are laying the necessary foundation by focusing on outcome-driven initiatives, clear value stream ownership, and understanding the investment value of teams.

These gaps are not signs of failure. They prove we are building the muscle memory needed to achieve lasting, meaningful change.

The Practical Benefits We Are Seeing and Expect to See

  • Stronger alignment between Product, Architecture, and Delivery.
  • Reduced cognitive load for teams working within clear domain boundaries.
  • Clearer prioritization, alignment, and purpose based on customer and business value.
  • A cultural shift toward accountability not just for delivery but for results.
  • Faster, better-informed decisions from improved visibility and flow insights.
  • Sustained operational efficiency improvements through retrospectives, insights, and continuous experimentation.

Something to Think About for Leaders

If you’re leading digital transformation, don’t limit yourself to choosing a Product Operating Model or Value Stream Management.

The real transformation happens when you intentionally combine both:

  • Structure teams around customer and business value.
  • Optimize how work flows through those teams.
  • Hold teams accountable not just for delivery but for real, measurable outcomes.
  • Continuously learn and improve by leveraging data insights and closing the feedback loop.

The future of software delivery isn’t about process versus structure. It’s about harmonizing both to deliver better, faster, and smarter.

What We’ve Been Building

Preparing for this meeting has helped crystallize what we’ve been building: a modern operating model that combines ownership, flow, and outcomes, putting customer and business value at the center of everything we do.

While our journey continues, and some cultural shifts are still ahead, we have built the foundation for a more outcome-driven, operationally efficient, and scalable future.

While there’s still work to be done and cultural changes ahead, we’ve laid the groundwork for a future that is more focused on outcomes, efficient in operations, and ability to scale.

I’m looking forward to the upcoming conversation, which will walk through the Product Operating Model, learn from their approach, and explore how it aligns with, replaces, or complements our evolution with Value Stream Management. It’s a conversation about methods and how organizations are shifting from tracking outputs to delivering actual business impact.

Let’s keep the conversation going:
How is your organization evolving its operating model to drive outcomes over outputs, combining structure, flow, and purpose to create real value?

Related Articles

  1. From Feature Factory to Purpose-Driven Development: Why Anticipated Outcomes Are Non-Negotiable, April 12, 2025. Phil Clark.

References

  1. The 2024 Project to Product State of the Industry Report. Planview.

Poking Holes

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

Let’s talk: phil.clark@rethinkyourunderstanding.com

From Scrum Master to Agile Delivery Manager: Evolution in the Age of Flow

by

6 min read

This post was inspired by a LinkedIn post shared by Dave Westgarth.

In 2025, we formally changed the title of Scrum Master to Agile Delivery Manager (ADM) in our technology division. This renaming wasn’t a rebrand for the sake of optics. It reflected a deeper evolution already happening, rooted in the expanding scope of delivery leadership, the adoption of Flow Metrics and Value Stream Management, and our real-world shift from strict Scrum toward a more customized Kanban-based model.

It was this year that the name finally clicked. After assigning Value Stream Architect responsibilities to our Scrum Masters and giving them ownership of delivery metrics, team-level delivery health, and collaboration across roles within their Agile team, I realized the title “Scrum Master” no longer fit their role. I even considered Agile Value Stream Manager, but it felt too narrow and platform-specific.

That’s when Agile Delivery Manager stood out, not only as a better label but also as a more accurate reflection of the mindset and mission.

I’m not alone in this. My wife, a Scrum Master, noticed a rise in Agile Delivery Manager roles. These roles are emerging as a natural evolution of the Scrum Master role, broader in scope but still grounded in servant leadership and Agile values. This shift is becoming more common across industries.

Why We Made the Change

This wasn’t an overnight decision—it was the culmination of years of observing the gap between traditional agile roles and modern delivery demands. I’ve written extensively about the evolving nature of delivery roles in the modern product and engineering ecosystem. In “Navigating the Digital Product Workflow Metrics Landscape,” I highlighted how organizations that have matured beyond Agile 101 practices shift their attention upstream toward value creation, flow efficiency, and business impact.

In that article, I shared:

“Organizations that have invested in high automation, eliminated waste, and accelerated CI/CD cycles are now shifting left—seeking broader visibility from idea to operation.”
– Navigating the Digital Product Workflow Metrics Landscape

Similarly, in “Dependencies Are Here to Stay,” I discussed why frameworks couldn’t box delivery leadership in:

“We can’t measure agility in isolation. Dependencies are part of the system, not a failure of it. Leadership roles must evolve to manage flow across those dependencies, not just within a team board.”

This evolution is what our former Scrum Masters were doing. They were coaching teams and guiding delivery conversations, navigating delivery risks, managing stakeholder expectations, and tracking systemic flow. The title needed to grow with the responsibility.

The Agile Role That Connects It All

Agile leadership roles and responsibilities vary across organizations. Some have Scrum Masters or Agile Leaders, while others use titles like Technical Project Manager or Agile Coach. In some cases, responsibilities shift to Engineering or Product Managers, and some companies distribute these duties among team members and eliminate the role entirely. Despite these differences, we believe a dedicated Agile leadership position is valuable. This role plays a key part in improving team performance, delivery efficiency, and optimizing workflows.


The Agile Delivery Manager role is unique in that it is the only role on the team not incentivized by a specific type of work.

  • Product Managers focus on growth and prioritize new features.
  • Technical Leads concentrate on architecture and managing technical debt.
  • Information Security leaders work to reduce security risks.
  • QA teams ensure defects are identified and fixed.

The Agile Delivery Manager operates at a higher level, overseeing workflow across the distribution of work types, including features, technical debt, risks, and defects. It fosters continuous team improvement while ensuring that deliveries consistently drive tangible business value.

Inside the Agile Delivery Manager Role

It’s worth clarifying: In our model, Agile Delivery Managers remain focused on their assigned Agile team or teams. While the title may sound broader, the role is not intended to operate across multiple delivery teams or coordinate program-level work. Instead, ADMs guide and improve the delivery flow within their own team context—coaching the team, optimizing its workflow, and partnering with product and engineering to ensure value is delivered efficiently.

Here’s how we now define the Agile Delivery Manager in our updated job description:

“As an Agile Delivery Manager, you’ll lead strategic transformation, champion Flow Metrics and VSM, and shape how teams deliver real business value.”

Key responsibilities include:

  • Agile Leadership & Flow-Based Delivery
    Coaching teams while enabling clarity, cadence, and sustainability in customized Kanban-style systems.
  • Team Collaboration & Dependency Management
    Collaborating with Product, QA, InfoSec, and Engineering roles within the team to resolve blockers, ensure quality, and maintain delivery flow.
  • Flow Metrics & Value Stream Optimization
    Leading metric reviews using Flow Time, Load, Efficiency, and Distribution to drive better delivery outcomes.
  • Value Stream Architecture
    Acting as system-level delivery architects, not of code, but of how work flows from concept to value.
  • Strategic Reporting & Outcome Alignment
    Building quarterly delivery reports that tie execution to business value, supporting leadership visibility and continuous improvement.

This role no longer fits the narrow scope that Scrum once offered. It combines delivery leadership, agile stewardship, and flow optimization.

What This Means for Scrum Masters

If you’re a Scrum Master wondering what’s next, you’re not alone. You’re likely doing many things, but this role demands time to widen the lens.

As Dave Westgarth shared on LinkedIn:

“You’re using the same core competencies: facilitation, servant leadership, coaching, and team empowerment. They just get applied at different levels and from different perspectives.”

This evolution isn’t about abandoning Agile. It’s about scaling its intent.

Many of our ADM team members still value their strong Scrum foundation. However, they’ve broadened their focus to improve delivery efficiency, enhance team coordination, manage delivery risks, and ensure smooth team workflows across competing work types and stakeholder needs.

If you’re already guiding delivery beyond team ceremonies, influencing system flow, and navigating complexity, this evolution is your next chapter.

Final Thoughts

The shift to an Agile Delivery Manager reflects a modern reality: frameworks alone don’t scale agility; people do. The ADM role honors the coaching mindset of the Scrum Master while embracing the delivery complexities of today’s hybrid, platform-heavy, and outcome-driven organizations.

For our division, the name change signaled to our teams and business stakeholders that delivery leadership had evolved. More importantly, it gave our people permission to grow into that evolution.

Poking Holes

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

Let’s talk: phil.clark@rethinkyourunderstanding.com

Beyond Frameworks: The Real Weight of Leading Transformation at Scale

by

9 min read

A leadership case study for those carrying the weight of transformation, when the change is working, but the friction won’t quit.

This isn’t about criticizing an organization; it’s about honoring the complexity of leading through change, even in highly successful environments.

Transformation fatigue: Is there light at the end of the tunnel? Yes, but just as things begin to brighten, change strikes again, and the path might grow dim once more.

This article was sparked by a quiet but revealing moment: a leader hesitated to define expected outcomes in Jira1. It reminded me that transformation fatigue doesn’t come from stalled progress but from something slower and more dangerous: the erosion of alignment when leadership philosophies diverge over time.

This article connects with thoughts shared by Willem-Jan Ageling, whose work I came across shortly after drafting this piece. Ageling highlights that team autonomy can only succeed when leadership supports it with genuine trust, demonstrated through actions, not just words. Building on that, I want to ask: What happens when the right frameworks are in place, the transformation progresses, yet trust begins to erode? Not because of outright failure but due to ongoing, subtle friction at scale.

You may know the feeling if you’re a senior leader navigating Agile, DevOps, or product transformation. The structures shift. The frameworks are adopted. But the mindset? That’s where the real work lives.

I’m incredibly proud of our organization’s transformation over the past decade. It’s not just a success story; it’s industry-leading in many respects. We’ve gone from legacy delivery models to empowered, product-focused teams aligned around value. We’ve modernized our technology stack, redefined our operating model, and adopted practices many organizations still strive to implement.

But let me be clear: I didn’t say perfect.

Transformation is not a box you check. It’s a system you nurture. And it’s a mindset you must defend, especially as leadership shifts, ownership changes, and misalignment creeps in.

One of the hardest lessons I’ve learned is that not everyone on the journey is aligned on the destination or how to get there. Some leaders have been at my side for years, yet comments or decisions occasionally reveal a superficial sense of agreement rather than true shared understanding. And those moments? They’re not setbacks. They’re opportunities to rethink, reconnect, and improve how we deliver work together.

This article isn’t a playbook. It’s a reflection. A case study. My own.

Willem-Jan Ageling recently wrote about the importance of trust in team autonomy. His article, Team autonomy only works when leadership shows trust 2, highlighted how quickly things can go off track when a leader reverts to control or bypasses key Agile roles. I see this all the time, not just in isolated teams, but in entire systems. One of the hardest parts of leading transformation is defending that trust across layers of leadership, especially when new leaders join the organization carrying different philosophies. Trust doesn’t scale automatically. Alignment doesn’t hold itself. And fatigue? It rarely comes from a lack of progress. It comes from the constant effort of holding it all together.

It’s what happens when the transformation is fundamental, yet the friction remains.

If you’ve felt that weight, you’re not alone.

Transformation doesn’t end. It evolves.

As organizations grow, so does the complexity of sustaining alignment. When you’re small, a startup, or a few hundred people, it’s easier to rally around shared goals, maintain tight communication loops, and stay close to your delivery model. But as headcount scales, layers are added, and teams diversify, the fatigue risk rises.

We aim for growth, but it’s a mixed blessing; it magnifies your strengths and weaknesses.

Fatigue is no longer isolated to individuals or pockets of teams. It becomes systemic when leadership philosophies diverge, alignment fades, or superficial agreement masks deeper disconnects.

Over the past decade, I’ve helped lead our organization from waterfall delivery to modern, empowered, product-focused teams. We’ve adopted Agile, DevOps, Lean, and Value Stream Management. We’ve moved from outputs to outcomes. We’ve rearchitected our application and modernized our platform.

And we’ve made real progress.

But no framework prepares you for the repetition, the re-explaining, and the relitigation of decisions you thought were long settled.

New executives arrive. Stakeholders change. Strategic direction pivots.

Fatigue doesn’t come from the frameworks but from the effort required to protect them when leadership philosophies keep shifting.

When done correctly, the effort doesn’t end. Transformation is not a one-time project; it’s a continuous journey and a mindset of leadership.

Even years in, the friction returns

By 2020–2021, we were six years into our transformation and hitting our stride. Then, leadership changed. A new technology leader arrived with a more hierarchical approach to Agile, rooted in functional oversight and centralized control. It wasn’t wrong; it was simply misaligned with the autonomous, cross-functional team structure we had built, grounded in Team Topologies 3, Team of Teams 4, and Turn the Ship Around! 5.

Where we embedded all roles necessary to deliver value in one team, this leader expected delivery to be driven by an Engineering Manager-led model, one where the EM managed both delivery and people. Both models are valid, but they are fundamentally different philosophies.

Around the same time, our private equity firm introduced the idea of tracking individual productivity units, a shift back toward legacy thinking like lines of code and activity-based metrics.

Fortunately, I had already introduced Value Stream Management and Flow Metrics, which emphasize outcomes, not output, especially not at the individual level.

We educated. We realigned. We defended the system.

We succeeded. But it was exhausting.

I’ve been that legacy leader

Earlier in my career, I led the traditional way: resource plans, Gantt charts, and command and control. Even as I started reading Agile literature and implementing new ceremonies, I hadn’t changed my thinking. I was doing Agile but not leading through it.

My fundamental shift came during a quiet moment of clarity when I realized I was in the way. That moment was the precursor to Rethink Your Understanding, not just a phrase but a mindset I committed to living and leading through. It’s been my compass ever since.

Resistance doesn’t always yell, it nods

The hardest resistance I’ve faced hasn’t been loud. It’s been polite, strategic, and sometimes even supportive on the surface.

One of the longest-running tensions came from a senior product leader I respect for product decisions. He believed in strong direction and centralized control. I believe in empowerment and team ownership.

He would express agreement in executive sessions, but the structures remained top-down. Product managers were not empowered. Roadmaps were handed out rather than co-created. And teams, even years into our transformation, still hadn’t been trained in Agile principles.

Not wrong, just not aligned.

And the cost? Quiet drag. Misunderstood roles. Fatigue.

A moment that made it clear

After our acquisition and the departure of our former CEO, I asked that same colleague for his thoughts on how our division’s executive team might change, a team I’ve been part of for the past few years.

“We’ll be focused on operations. We’ll bring in some senior managers from the business. I’m not sure this is the best use of your time.”

That moment hit hard, but it wasn’t personal. It was clarifying.

He still didn’t see engineering as strategic, and he still didn’t view my technology leadership as part of operational decision-making.

That’s when I realized that fatigue doesn’t come from open disagreement but from the illusion of alignment.

I’ve been writing this story for years

Many of my articles have tried to name this tension:

These weren’t rants. They were reflections, a way to process what it means to lead inside a transforming organization, even when not everyone is transforming with it.

Post-acquisition, two paths emerge

Today, I report to a senior leadership team that believes in transformation through a different model. They emphasize Engineering Managers embedded within teams, hands-on principal-level leadership, and individually oriented career frameworks built quickly based on experience.

It’s not a bad model. It’s simply different from ours, focusing on cross-functional autonomy, long-term capability building, and outcome orientation over individual output.

Neither approach is wrong. But this team operates from very different assumptions.

And reconciling them, that’s where the fatigue returns.

Industry conversations keep me grounded

Outside the walls of my org, I don’t need to explain why value streams matter or why DevOps is more than automation.

When I connect with other leaders at conferences or through advisory boards, I am reminded that I am not alone.

These conversations bring clarity, encouragement, and strength when the internal friction gets heavy.

And yes, sometimes I want to be right

Inside my team, we joke about “Phil Fridays,” when my conviction tends to spike after a week of hard conversations…

It’s not about ego. It’s about care.

I want to build the best teams on the field.

I want to give people purpose, clarity, and ownership.

I want to lead in a way that leaves systems better than I found them.

Others feel the same. And that’s why this isn’t about who’s right or wrong.

It’s about alignment and the emotional toll when it’s missing.

Agile isn’t failing. Leadership is

You’ve heard it: “Agile is failing.” “DevOps didn’t deliver.”

But it’s not the frameworks that fail; it’s how they’re implemented and, more specifically, how they’re led.

When Agile is used to mask command and control, or DevOps becomes just a reporting layer, don’t blame the model. In most cases, blame leadership, blame the mindset.

Leading transformation means choosing clarity, again and again

Top 5 Triggers of Leadership Friction

  1. Leadership turnover or strategic pivots that deprioritize transformation values.
  2. Conflicting ownership philosophies (e.g., empowerment vs. control).
  3. Introduction of metrics or standards that contradict autonomy.
  4. Rhetorical alignment masking structural or behavioral misalignment.
  5. Organizational scaling that stretches philosophical consistency.

As organizations scale, the stakes grow higher. Alignment becomes harder, and systems become more complex. That means transformation fatigue doesn’t just linger; it compounds. What once felt like a collaborative push for change at a smaller scale can start to feel like a grind as your influence spans more teams, departments, and philosophies.

Growth is a sign of success but also magnifies misalignment if we’re not actively checking for it. It’s not just the number of people that changes; it’s the number of assumptions.

Here’s what I’ve learned:

  • When you sign up to lead transformation, you’re not signing up for a framework. You’re signing up for a lifetime of rethinking your beliefs and inviting others to do the same.
  • You’re signing up for fatigue, not because you’re weak, but because the work is real.
  • You’re signing up for friction, not because people are bad, but because philosophies differ.
  • You’re signing up for progress, not perfection.

And if you’re still showing up, holding the line, listening, and learning while advocating for the path you’re leading.

And that’s the work.

Let’s be transparent and honest and stop pretending we’re aligned when we’re not. For those leading transformation: Don’t confuse alignment with agreement. Keep asking. Keep listening. Keep showing up.

References

  1. Clark, Phil (April 12, 2025). From Feature Factory to Purpose-Driven Development: Why Anticipated Outcomes Are Non-Negotiable. rethinkyourunderstanding.com.
  2. Ageling, Willem-Jan (April 06, 2025). Team autonomy only works when leadership shows trust. https://medium.com/@WJAgeling/team-autonomy-only-works-when-leadership-shows-trust-2ab59182f350.
  3. Skelton, M & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
  4. McChristal, S. (General) & Collins, T. & Silverman, D. & Fussell, C. (2015). Team of Teams: New Rules of Engagement for a Complex World. Portfolio.
  5. Marquet, David L. (2015). Turn the Ship Around! Penguin publishing.

Poking Holes

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

Let’s talk: phil.clark@rethinkyourunderstanding.com

From Feature Factory to Purpose-Driven Development: Why Anticipated Outcomes Are Non-Negotiable

by

9 min read

Connect the dots: Show how engineering efforts drive business impact by linking their work to key organization metrics and outcomes. Highlight their value and contribution to overall success.

When Sarcasm Reveals Misalignment

Last week, one of my Agile Delivery Leaders brought forward a concern from her team that spoke volumes, not just about an individual, but about the kind of tension that quietly persists in even the most mature organizations.

She asked her team to define the expected outcome for a new Jira Epic, a practice I’ve asked all teams to adopt to ensure software investments align with business goals. However, it seems they struggled to identify the anticipated outcome. On top of that, a senior team member who’s been part of our transformation for years dismissed the idea instead of contributing to the discussion. She found herself in a difficult position, torn between the leader’s authority and her own responsibilities. He commented something like:

“Why are we doing this? This is stupid. Phil read another book, and suddenly we’re all expected to jump on board.”

When I first heard that comment secondhand, I felt a wave of anger; it struck me as pure arrogance. This leader chose not to share his perspective with me directly, perhaps for reasons he deemed valid. But as I thought more about it, I realized it wasn’t arrogance at all, but ignorance. Not malicious ignorance, but the kind that comes from discomfort, uncertainty, or an unwillingness to admit they no longer understand or align with where things are going. Comments like that are often defense mechanisms. They mask deeper resistance, reveal a lack of clarity, or quietly question whether someone still fits into a system evolving beyond their comfort zone.

This wasn’t about rejecting change or progress; it was about pushing back against how we’re evolving. Moments like this remind us that true transformation isn’t just about forging ahead; it’s about fostering belief and alignment in mindset and actions as we move forward.

Purpose-Driven Development: My Approach to Sustainable Alignment

I asked teams to define anticipated outcomes not to add overhead but to protect the integrity of the way we build software.

Over the past decade, I’ve worked hard to lead engineering our teams and organization out of the “feature factory” trap, where the focus is on output volume, velocity, and shipping for the sake of shipping. Through that experience, I developed Purpose-Driven Development (PDD), my definition of this term.

Purpose-driven development might sound like a buzzword, but it’s how we bring Agile and Lean principles to life. It ensures delivery teams aren’t just writing code; they’re solving the right problems for the right reasons with clear goals and intentions.

PDD is built on one core idea: every initiative, epic, and sprint should be based on a clear understanding of why it matters.

Anticipated Outcomes: A Small Practice That Changes Everything

To embed this philosophy into our day-to-day work, we introduced a simple yet powerful practice:

Every Epic or Initiative must include an “Anticipated Outcome.”

Just a sentence or two that answers:

  • What are we hoping to achieve by doing this work?
  • How will it impact the customer, the Business, or the platform?

We don’t expect perfection. We expect intention. The goal isn’t to guarantee results but to anchor the work in a hypothesis that can be revisited, challenged, or learned from.

This simple shift creates:

  • Greater alignment between teams and strategy
  • More meaningful prioritization
  • Opportunities to reflect on outcomes, not just outputs
  • Visibility across leadership into what we’re investing in

Who Might Push Back and Why That’s Okay

When we ask teams to define anticipated outcomes, it’s not about creating friction; it’s about creating focus. And this shouldn’t feel like a burden to most of the team.

I believe engineers will welcome it. Whether they realize it at first or not, this clarity gives them purpose. It ties their daily work to something that matters beyond code.

The only two roles I truly expect might feel frustration when asked to define anticipated outcomes are:

Product Managers and Technical Leaders.

And even that frustration? It’s understandable.

Product Managers often experience pain from not being involved early enough in the ideation or problem-definition stage. They may not know the anticipated outcome if they’re handed priorities from a higher-level product team without the context or autonomy to shape the solution. And that’s the problem, not the question itself, but the absence of trust and inclusion upstream.

For Technical Leaders, it often comes when advocating for tech debt work. They know the system needs investment but struggle to translate that into a clear business reason. I get it; it’s frustrating when you know the consequences of letting entropy creep in, but you haven’t been taught to describe that impact in terms of business value, customer experience, or system performance.

But that’s exactly why this practice matters.

Asking for an anticipated outcome isn’t a punishment. It’s an exercise in alignment and clarity. And if that exercise surfaces frustration, that’s not failure. It’s the first step toward better decision-making and stronger cross-functional trust.

Whether it’s advocating for feature delivery or tech sustainability, we can’t afford to work in a vacuum. Every initiative, whether shiny and new or buried in system debt, must have a reason and a result we’re aiming for.

Anticipated Outcomes First, But OKR Alignment Is the Future

When I introduced the practice of documenting anticipated outcomes in every Epic or Initiative, I also asked for something more ambitious: a new field in our templates to capture the parent OKR or Key Result driving the work.

The goal was simple but powerful:

If we claim to be an outcome-driven organization, we should know what outcome we’re aiming for and where it fits in our broader strategy.

I aimed to help teams recognize that their Initiatives or Epics could serve as team-level Key Results directly tied to overarching business objectives. After all, this work doesn’t appear by chance. It’s being prioritized by Product, Operations, or the broader Business for a deliberate purpose: to drive progress and advance the company’s goals.

But when I brought this to our Agile leadership group, the response was clear: this was too much to push simultaneously.

Some teams didn’t know the parent KR, and some initiatives weren’t tied to a clearly articulated OKR. Our organizational OKR structure was often incomplete, and we were missing the connective tissue between top-level objectives and team-level execution.

And they were right.

We’re still maturing in how we connect strategy to delivery. For many teams, asking for the anticipated outcome and the parent OKR at once felt like a burden, not a bridge.

So, we paused the push for now. My focus remains first on helping teams articulate the anticipated outcome. That alone is a leap forward. As we strengthen that muscle, I’ll help connect the dots upward, mapping team efforts to the business outcomes they drive, even if we don’t have the complete OKR infrastructure yet.

Alignment starts with clarity. And right now, clarity begins with purpose.

Without an anticipated outcome, every initiative is a dart thrown in the dark.

It might land somewhere useful or waste weeks of productivity on something that doesn’t matter.

Documenting the outcome gives us clarity and direction. It means we’re making strategic moves, not random ones. And it reduces the risk of high-output teams being incredibly productive… at the wrong thing.

Introducing the Feature Factory Ratio

To strengthen our focus on PDD and prioritize outcomes over outputs, we are introducing a new core insights metric as part of our internal diagnostics:

Feature Factory Ratio (FFR) =

(Number of Initiatives or Epics without Anticipated Outcomes / Total Number of Initiatives or Epics) × 100

The higher the ratio, the greater the risk of operating like a feature factory, moving fast but potentially delivering little that matters.

The lower the ratio, the more confident we can be that our teams are connecting their work to value.

This ratio isn’t about micromanagement, it’s about organizational awareness. It tells us where alignment is breaking down and where we may need to revisit how we communicate the “why” behind our work.

Why We Call It the Feature Factory Ratio

When I introduced this metric, I considered several other names:

  • Outcome Alignment Ratio – Clear and descriptive, but lacking urgency
  • Clarity of Purpose Index – Insightful, but a bit abstract
  • Value Connection Metric – Emphasizes intent, but sounds like another analytics KPI

Each option framed the idea well, but they didn’t hit the nerve I wanted to expose.

Ultimately, I chose the Feature Factory Ratio because it speaks directly to the cultural pattern we’re trying to break.

It’s provocative by design. It challenges teams and leaders to ask, “Are we doing valuable work or just shipping features?” It turns an abstract concept into a visible metric and surfaces conversations we must have when our delivery drifts from our strategy.

Sometimes, naming things with impact helps us lead the behavior change that softer language can’t.

Sidebar: Superficial Alignment, The Silent Threat

One of the biggest leadership challenges in digital transformation isn’t open resistance, it’s superficial alignment.

These senior leaders attend the workshops, adopt the lingo, and show up to the town halls, but when asked to change how they work or lead, they bristle. They revert. They roll their eyes or make sarcastic comments.

But they’re really saying: I’m not sure I believe in this, or I don’t know how I fit anymore.

The danger is: superficial alignment looks like progress, but it blocks true transformation. It creates cultural drag. It confuses teams and weakens momentum.

Moments like the one I shared remind me that transformation isn’t a checkbox but a leadership posture. And sometimes, those sarcastic comments? They’re your clearest sign of where real work still needs to happen.

Start Where You Are and Grow from There

We’re all at different points in our transformation journeys as individuals, teams, and organizations.

So, instead of reacting with frustration when someone can’t articulate an outcome or when a snide remark surfaces resistance, use it as a signal.

Meet your team where they are. Use every gap as a learning opportunity, not a leadership failure.

If a team can’t answer “What’s the anticipated outcome?” today, help them start asking it anyway. The point isn’t to have every answer right now. It’s to build the muscle so that someday, we will.

These questions aren’t meant to judge where we are. They’re meant to guide us toward where we’re trying to go, and this is the Work of Modern Software Leadership.

It’s easy to say we want to be outcome-driven. Embedding that belief into daily practice is harder, especially when senior voices or legacy habits push back.

But this is the work:

  • Aligning delivery to strategy
  • Teaching teams to think in terms of impact
  • Holding the line on purpose—even when it’s uncomfortable
  • Measuring not just what we ship but why we’re shipping it

Yes, I’ve read my fair share of books. Along the way, I’ve experienced key moments and expected outcomes that influenced my journey in adopting new initiatives within our division and organization, such as Value Stream Management and understanding what it means to deliver real value. I’ve led teams through transformation and seen what works. From my experience in our organization and working with other industry leaders, I’ve learned that software delivery with a clear purpose is more effective, empowering, and valuable for the Business, our customers, and the teams doing the work.

Leader’s Checklist: Outcome Alignment in Agile Teams

Use this checklist to guide your teams and yourself toward delivering work that matters.

1. Intent Before Execution

  • Is every Epic or Initiative anchored with a clear Anticipated Outcome?
  • Have we stated why this work matters to the customer, business, or platform?
  • Are we avoiding the trap of “just delivering features” without a defined end state?

2. Strategic Connection

  • Can this work be informally or explicitly tied to a higher-level Key Result, business goal, or product metric?
  • Are we comfortable asking, “What is the business driver behind this work?” even if it’s not written down yet?

3. Team-Level Awareness

  • Do developers, QA, and designers understand the purpose behind what they’re building?
  • Can the team articulate what success looks like beyond “we delivered it”?

4. Product Owner Empowerment

  • Has the Product Manager or Product Owner been involved in problem framing, or were they handed a solution from above?
  • Is that a signal of upstream misalignment if they seem disconnected from the outcome?

5. Tech Debt with Purpose

  • If the work is tech debt, have we articulated its impact on system reliability, scalability, or risk?
  • Can we tie this work back to customer experience, transaction volume, or long-term business performance?

6. Measurement & Reflection

  • Are we tracking how many Initiatives or Epics lack anticipated outcomes using the Feature Factory Ratio?
  • Do we ever reflect on anticipated vs. actual outcomes once work is delivered?

7. Cultural Leadership

  • Are we reinforcing that asking, “What’s the anticipated outcome?” is about focus, not control?
  • When we face resistance or discomfort, are we leading with curiosity instead of compliance?

Remember:

Clarity is a leadership responsibility.

If your teams don’t know why they’re doing the work, the real problem is upstream, not them.

Poking Holes

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

Let’s talk: phil.clark@rethinkyourunderstanding.com

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: phil.clark@rethinkyourunderstanding.com

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.