Leadership

Beyond outcome-focused metrics: Connecting Work to Outcomes

February 4, 2025 by philc

5 min read

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

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

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

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

Applying Value Stream Thinking to a Culture of Value Measurement

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

When value streams are the core management approach:

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

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

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

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

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

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

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

Value Streams as the Foundation of a Culture of Value Measurement

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

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

Want to Go Deeper?

For further reading, check out these articles:

Metrics

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

Poking Holes

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

Let’s talk: [email protected]

References

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

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

February 2, 2025 by philc

5 min read

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

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

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

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

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

Technical Debt as a Loan: The Power of Minimum Payments

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

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

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

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

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

Integrating Minimum Payments into Daily Work

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

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

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

Balancing Technical Debt and Business Outcomes

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

Here’s how teams can assess technical debt:

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

For example:

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

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

Teaching Advocacy for Technical Debt

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

Here are some strategies for building that advocacy:

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

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

Poking Holes

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

Let’s talk: [email protected]

Advocating for Refactoring: Prioritization in the Context of Business Goals

January 19, 2025 by philc

7 min read

Refactoring often gets sidelined in favor of delivering features or fixing defects. However, its business value lies in enabling teams to work faster, reduce long-term costs, and provide better customer experiences. We must go beyond identifying its value to advocate for refactoring while integrating it effectively into broader prioritization frameworks. We must determine how to prioritize refactoring work against competing demands: features, defects, and risks.

“It’s not about perfect code; it’s about creating systems that adapt and deliver value as your business and customers evolve.”

This article explores the following:

The case for refactoring as a business priority.
How we get into situations requiring Refactoring.
The challenges of prioritizing refactoring alongside other types of work.
Tools and approaches to balance refactoring with business goals.
How Value Stream Management (VSM) and the Product Operating Model (POM) provide the foundation for prioritization.
Documenting technical debt agreements in Jira.

The Business Case for Refactoring

Refactoring improves the maintainability, scalability, and reliability of software systems. The outcomes directly tie back to business value in several ways:

• Faster Feature Delivery: Clean code enables quicker development of new features, allowing teams to respond to customer needs faster.

• Reduced Defect Rates: Simplified codebases decrease the likelihood of bugs, reducing operational costs and improving customer satisfaction.

• Scalability for Growth: Refactored code can handle growing user demands without performance degradation.

• Developer Productivity: Clearer, less complex code reduces onboarding time and empowers engineers to contribute more effectively.

As I’ve shared in past discussions, “Every sprint is an opportunity to balance speed with sustainability. Ignoring refactoring today compounds the cost of tomorrow’s delays.”

How We Get Into Situations Requiring Refactoring

The need for Refactoring arises from various common scenarios, most of which stem from trade-offs made during the software development lifecycle:

1. Corner-Cutting Due to Deadlines

Under tight deadlines, teams often implement workarounds or suboptimal solutions to meet delivery goals. They do this with the intention of revisiting the code later, but other priorities often take precedence, leaving technical debt unresolved.

2. Building to Learn Instead of Building to Scale

When products are in early development, the focus is on validating ideas rather than scalability or long-term maintainability. While this approach helps teams experiment and adapt quickly, it often results in code that requires significant Refactoring once the product matures.

3. Evolving Requirements and Legacy Code

As products grow, their requirements evolve, often leading to layers of new functionality added to an older codebase that was not designed to accommodate these changes. Over time, this creates tangled dependencies and poor maintainability.

4. Insufficient Testing Practices

Low test coverage or reliance on manual testing increases the risk of defects when refactoring or updating code. This creates resistance to Refactoring, as teams fear introducing bugs.

5. Lack of Team Discipline or Standards

Inconsistent coding practices, poor documentation, or lack of adherence to architectural guidelines can make it harder to maintain and understand code, making refactoring a necessity later.

6. Growth in Scale or User Base

As the user base grows, systems that are sufficient for small-scale use start to show performance bottlenecks. Refactoring becomes essential to scale effectively.

7. Engineers’ Evolving Skills and Knowledge

Engineers write the best code they can with their knowledge at the time. As they gain experience, they may revisit old code and see ways to improve it. The code they wrote at the time isn’t due to poor effort but reflects their growth. Many engineers can relate to looking back and thinking, “Wow, did I write this?” Refactoring helps align the code with their current skills. As I’ve often said, “We don’t regret the skills we had at the time, but we owe it to the future to evolve them.”

8. Ignoring Continuous Refactoring Practices

Refactoring doesn’t always need to be a significant, disruptive event. A more sustainable approach is continuous refactoring, where developers clean up the areas of code they touch while working on other tasks. This practice prevents technical debt from accumulating to unmanageable levels.

By incorporating small, incremental improvements into daily work, teams can avoid the need for massive, time-consuming refactoring efforts later.
Think of it as weeding a garden: You can pull the weeds every time you’re in the garden, or you can wait until they overtake the garden, requiring significant effort to clean up.

The Four Types of Work in Software Development

Every engineering team must balance the following types of work:

Features: Adding new capabilities or value for customers.
Technical Debt: Addressing shortcuts or suboptimal code that slows teams down.
Defects: Fixing bugs that impact customer experience or system performance.
Risk: Mitigating potential security vulnerabilities or regulatory compliance gaps.

Refactoring, categorized under technical debt, often faces challenges in prioritization due to its indirect benefits. The difficulty lies in quantifying its immediate impact relative to features, defects, or risks.

Integrating VSM and POM into Refactoring Advocacy

Teams can use the frameworks of value stream management (VSM) and the product operating model (POM) to bridge the gap between identifying the value of Refactoring and effectively prioritizing it.

1. Visualize the Entire Value Stream

By mapping the entire value stream, teams can pinpoint bottlenecks and inefficiencies where technical debt impedes flow. As I shared in a recent article, “The power of VSM lies in its ability to connect engineering improvements to measurable business outcomes, making investments in refactoring an organizational priority, not just a technical one.”

Refactoring can then be prioritized where it delivers the most significant value:

High-Impact Refactoring: Focus on areas where complexity delays delivery or introduces recurring issues.
Alignment with Business Objectives: Ensure refactoring initiatives directly address bottlenecks that impact customer value or strategic goals.

2. Align Refactoring with the Product Operating Model

The POM emphasizes cross-functional teams focused on delivering end-to-end value. Refactoring fits seamlessly into this model:

Collaboration: Engineers, product managers, and stakeholders work together to identify refactoring needs that align with business priorities.
Outcome Orientation: Refactoring is viewed as a driver of faster delivery, better scalability, and reduced costs—outcomes directly tied to business success.

3. Use Flow Metrics for Prioritization

Flow metrics, as discussed in VSM, provide quantifiable insights into areas where technical debt hinders efficiency:

Flow Time: Highlight parts of the value stream where technical debt increases lead time.
Flow Efficiency: Identify opportunities where Refactoring could significantly boost the ratio of active work time to total time spent.

These metrics help teams prioritize refactoring efforts that will deliver the most significant improvements in flow and business results.

4. Establish a Feedback Loop for Continuous Improvement

To ensure Refactoring aligns with business outcomes, establish a cycle of regular evaluation and adjustment:

Monitor Key Metrics: Track deployment frequency, defect rates, and time-to-market improvements after refactoring.
Adjust Prioritization: Use data-driven insights to refine future sprints or quarter priorities.

Prioritization Framework: Outcome-Driven Decision-Making

To ensure Refactoring receives the attention it deserves, teams must prioritize all work based on outcomes and impact on business goals rather than categorizing tasks in silos. Here’s a framework to guide this process:

1. Measure the Business Impact

Evaluate each piece of work (feature, Refactoring, defect, or risk) based on how it contributes to:

Business goals: Revenue growth, market share, cost savings, or customer retention.
Customer value: Improved experience, performance, or satisfaction.

• Operational efficiency: Faster time-to-market, reduced downtime, or lower maintenance costs.

2. Use Weighted Scoring for Prioritization

Apply a prioritization matrix that scores tasks based on:

Impact: The anticipated outcome (e.g., faster delivery, fewer defects).
Effort: The time and resources required to complete the work.
Risk: The potential consequences of not addressing the issue (e.g., customer churn, security vulnerabilities).
Time-to-Value: How quickly the outcome can be realized.

3. Prioritize Quick Wins and High Impact

Sometimes, smaller tasks can deliver faster outcomes:

A small refactoring task might unblock multiple feature requests.
Addressing a piece of technical debt might prevent significant defects or downtime.

4. Incorporate Refactoring into Regular Work

I often advise, “Refactoring doesn’t have to derail your sprint—it can fuel your delivery. Incremental improvements sustain momentum and build long-term agility.”

Incremental Refactoring: Dedicate a percentage of sprint capacity (e.g., 10-20%) to Refactoring.
Bundled Refactoring: Tie refactoring to new feature development.
Refactoring Backlog: Maintain a prioritized backlog of technical debt items for continuous improvement.

Documenting Technical Debt Decisions in Jira (or equivalent)

Teams can use labels or custom fields in Jira to document technical debt agreements at the epic level to ensure that shortcuts and technical debt are visible, traceable, and manageable.

1. Create a “Technical Debt Agreement” Label

Add a label or custom field to epics that identifies when a shortcut has been taken, such as tech-debt-agreement.
Use the description field or a custom template to document:
The reason for the shortcut (e.g., tight deadlines, experimental approach).
The impact of the debt (e.g., increased complexity, scalability risks).
An estimated timeline or trigger for addressing the debt.

2. Tie the Agreement to Outcomes

Connect the technical debt to business goals, prioritizing it based on its impact on customer value or operational efficiency.

3. Use Jira Dashboards to Track Technical Debt

Set up a dashboard to track all epics labeled with tech-debt-agreement.

4. Create a Review Cadence

Review open technical debt agreements during backlog grooming or sprint planning.

Conclusion

Refactoring is not just a technical activity; it’s a strategic investment in the health of your product and its ability to deliver value to customers and the business. By understanding how we get into situations requiring Refactoring, integrating frameworks like VSM and POM, and applying prioritization tools, teams can ensure Refactoring is prioritized effectively.

As I’ve said in presentations and writing,

“Every improvement we make—whether in our code or our process—is a step toward becoming the winning team.”

Documenting decisions with tools like Jira and fostering a culture that values refactoring help build a foundation for sustainable delivery. This approach ensures that refactoring competes fairly with features, defects, and risks, driving long-term success.

Poking Holes

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

Let’s talk: [email protected]

Dependencies Are Here to Stay: From Challenges to Opportunities

January 11, 2025 by philc

8 min read

Setting the Stage: What This Article Is About

Dependencies—a word that can mean many things, but here, we’re talking about a specific kind: cross-cutting dependencies driven by large organizational initiatives or projects that require contributions from multiple teams. These aren’t the day-to-day functional dependencies resolved by moving to cross-functional teams. Instead, we’re addressing dependencies that arise when:

One team’s outcomes directly impact the success of another team’s efforts.
Platform or centralized teams require integration or alignment from product teams.
Teams rely on others to work on their behalf, such as completing a shared service task or enabling foundational capabilities.

This article presents a scalable prioritization framework to help teams balance external requests with core roadmap priorities like growth, performance, and security. Building on John Cutler’s insights on dependencies, it provides practical, outcome-focused strategies to stay aligned with business goals.

Audience:

This article is designed for leaders and practitioners in small businesses and mid-market to mid-sized enterprises—organizations where teams enjoy greater autonomy and operate with fewer bureaucratic layers. While the ideas here reflect my experiences and successes in these contexts, I recognize that no framework is universally applicable. Alternative approaches may be required for larger enterprises or organizations with deeply entrenched dependencies and highly distributed teams.

Dependencies—the word itself feels heavy, like an anchor holding teams back. Every organization faces this challenge, especially when juggling complex projects and cross-functional priorities. Yet dependencies are here to stay.

This became evident during a meeting earlier this week when a program manager reminded the engineering leaders to respond to the data privacy team’s request for integration work. The request is part of a larger initiative to improve data retention management. The effort required several product delivery teams to align their services—a substantial request for teams already juggling demanding and tightly packed roadmaps.

The meeting included only senior engineering and technology leaders, who leaned toward taking responsibility for deciding how to address the request, given their technical expertise. However, as a technology leader, I see this differently. We serve as subject matter experts who clarify and understand the request’s scope and implications. However, the ultimate decision on prioritization belongs to the respective delivery teams, who are best positioned to evaluate priorities based on anticipated outcomes and the potential impact on business results.

By chance, the very next day, John Cutler published an article on dependencies. His insights resonated deeply and aligned with many of the challenges we had been discussing. The timing was remarkable and inspired me to write this article—not to disagree with his ideas, but to build on them. In this piece, I’ll share how I encourage my teams to address this challenge, adding to his perspective with a complementary approach.

Dependencies: The Problem and the Opportunity

John Cutler’s article, “Some Thoughts on Dependencies,” ¹ offers an insightful foundation, outlining three common ways organizations handle dependencies. Here’s my interpretation and perspective on his ideas:

Minimize (Ostrich Approach—head in the sand): Ignore dependencies and expect teams to figure it out independently. This method may work when dependencies are rare, but it often leads to frustration and inefficiency.
Institutionalize (Bureaucracy Approach): Drowning dependencies in processes and meetings, creating layers of oversight that slow progress.
Actively Address (Transformer Approach): Proactively tackling dependencies by re-architecting systems, introducing enabling teams, and creating scalable processes.

“Dependencies are not roadblocks—they’re connections. How we manage them determines our success.”

While the “Transformer” approach is ideal, not all organizations can invest in this approach, and not all dependencies are bad. Some are essential for creating cohesive work, like aligning teams on a marketing campaign to ensure consistent messaging. The real challenge lies in managing dependencies strategically to prevent over commitment, delays, and burnout.

Scaling and Context: Does This Work Everywhere?

Before diving into the framework, it’s essential to recognize the context in which it operates. My approach is tailored to small to mid-sized enterprises or mid-market companies. These organizations often have fewer layers of bureaucracy and smaller, more agile teams. This framework may not scale effectively for large enterprises or organizations with massive programs—such as building a fighter jet or managing deeply ingrained systems.

Large-scale organizations often face additional complexities, such as highly distributed teams, deeply entrenched dependencies, and competing definitions of success across departments. For such cases, a hybrid model with stricter organizational mandates may be required, and dependencies might be better addressed by re-architecting systems and rethinking organizational structures. This article focuses on solutions that work well for more flexible, mid-sized organizations, where teams have greater autonomy and can experiment with dynamic prioritization.

Tension and the Need for Scalability

“If everything is a priority, then nothing is.”

This dynamic tension highlights the need for a framework that evaluates all work—regardless of its source—through a consistent lens. Conversations with subject matter experts are essential to understanding the scope and impact of the work. Once that’s clear, teams must collaborate to prioritize their entire backlog holistically.

Dependencies don’t just come from cross-cutting initiatives. Within teams, conflicts often exist between competing types of work, including features, technical debt, risks, and defects. Some team members may prioritize technical debt, seeing it as crucial to maintaining long-term stability, while product managers push for new features to meet market demands. These internal tensions, compounded by external requests, create additional pressure.

Prioritizing “all types of requests” by outcomes and impact becomes essential when dealing with dependencies and conflicting work. A unified, outcome-based approach ensures that all work is evaluated consistently, empowering teams to focus on the most impactful work. This approach scales effectively across teams and initiatives by dynamically reprioritizing based on available information.

Adding to the friction, the team responsible for leading this product-wide or cross-cutting initiative found themselves in an unenviable position. It’s the initiating team’s role to champion the initiative and drive its progress, but this team also bears the burden of reporting back and aligning all the dependent teams. These dependencies are an inevitable part of their work, but they shouldn’t be punished or pressured to force teams into alignment.

Ultimately, alignment falls on the organization. When priorities clash, or deadlines don’t align, leadership must step in to resolve conflicts. Teams should prioritize based on anticipated outcomes aligned with business goals, but the organization is responsible for ensuring those priorities align and scale.

A Framework for Managing Dependencies

Dependencies are inevitable, but the way we address them defines our success. My recommended framework emphasizes three key strategies for effective management: prioritizing anticipated outcomes, optimizing capacity, and adapting through dynamic reprioritization.

1. Unified Prioritization Framework

All requests—whether your team’s roadmap, a cross-team dependency, or a last-minute request—should be prioritized using the same lens: anticipated outcomes. The question isn’t who owns the request or how urgent it feels but rather:

What is the impact of this work on the organization’s goals?
Does it move the needle?
How does it compare to our current commitments?

While prioritization focuses on anticipated outcomes and impact, teams must also consider the cost of delay. Cost of delay means evaluating how postponing a task affects its value and urgency. By incorporating the cost of delay, teams can flexibly sequence work within their capacity, sometimes opting to complete lower-priority tasks sooner to prevent value erosion.

This approach isn’t about perfection. Teams won’t always get it right. However, by applying a structured method, they reduce burnout risks, increase engagement, and focus on delivering measurable results.

2. Capacity Management

Teams need to be realistic about their capacity. In most cases, we will always have more work than resources. If a higher-priority request arises, teams should assess whether to pause or defer it. Prioritization isn’t about dropping commitments; it’s about making intentional trade-offs to focus on what matters most.

Respecting capacity doesn’t mean saying “no” to everything—it means having honest conversations about what’s feasible and prioritizing the highest-value items to the team’s capacity. This approach also ensures that we focus on the right value and do not waste efforts or produce the wrong things.

Burnout often arises when teams feel pressured to overcommit. If everything is a priority, then nothing is. By respecting work-in-progress (WIP) limits, teams can maintain focus, reduce stress, and deliver high-quality work.

However, prioritization by capacity isn’t perfect. Teams may feel frustrated when pausing existing work, but this keeps them aligned with their purpose—one of the key motivators of people. By seeing how changes drive business results, teams retain a sense of meaning in their work. This approach ensures the shift isn’t perceived as arbitrary but as a deliberate, outcome-driven decision.

3. Dynamic Reprioritization

Priorities aren’t static. They shift with new information, emerging risks, and evolving business needs. Dynamic reprioritization ensures teams can adapt when priorities change.

Dynamic prioritization doesn’t mean dropping everything when new requests come in. Instead, teams evaluate current commitments to determine how much work remains and plan when to address the new priority. Reprioritizing requests by anticipated outcome, current commitments, and in-progress efforts balances existing commitments with incoming demands, preventing reactive chaos.

Note: These images are from a slide deck I used last November in a presentation about managing work prioritization based on outcomes and team capacity. The visuals were inspired by Sebastian Borggrewe’s presentation.

Turning Dependencies into Opportunities

Dependencies don’t have to be a burden. When managed well, they enable alignment, collaboration, and innovation. Teams that adopt this framework foster trust, reduce friction, and turn dependencies into opportunities for meaningful progress.

Final Thoughts: A Favorable Framework, Not Perfection

John Cutler’s article provides valuable insights into the complexities of dependencies, though I approach the topic from a slightly different perspective.

Dependencies aren’t going away. This framework offers a favorable, scalable approach for smaller enterprises. However, no framework is perfect. There will always be trade-offs, frustrations, and evolving challenges. What matters is creating a system that fosters transparency, reduces burnout, and aligns teams with purpose-driven outcomes.

How does your organization approach dependencies today? Are there opportunities to apply this framework to foster better alignment and outcomes? Share your thoughts and experiences—I’m always open to exploring better approaches.

Poking Holes

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

Let’s talk: [email protected]

References

Some Thoughts on Dependencies” ,John Cutler, January 07, 2025, https://substack.com/@cutlefish/note/c-85026603.

Why Value Stream Management and the Product Operating Model Matter

January 5, 2025 by philc

5 min read

In 2021, as an evolution in our agile transformation efforts, I introduced Value Stream Management (VSM) to my organization and later advocated for the Product Operating Model (POM), but I never clearly explained why I believe these practices are so important. While I’ve shared their benefits in various writings and conversations with industry leaders, I failed to deliver a cohesive message to my department. This lack of clarity has sometimes created a misalignment between the technology and product teams, hindering our ability to adopt these practices fully.

Looking back, I realized that even before formally identifying the Product Operating Model as a framework, our team—and I—were already heading in that direction. By setting up cross-functional teams aligned to specific products, we naturally moved toward a product-focused approach without defining it explicitly. However, many teams still juggled tasks across multiple products, which exposed inefficiencies and reinforced the need for a clear, intentional strategy.

This experience taught me a vital lesson: adopting and communicating frameworks like the Product Operating Model and Value Stream Management is critical for team alignment, operational efficiency, and sustainable delivery.

Why Adopt Value Stream Management and a Product Operating Model?

In almost every organization, there is more work than capacity. This reality underscores the need for prioritization and a focus on outcomes over outputs. I advocate for adopting VSM and the POM because they address this challenge head-on, providing a framework to align teams, optimize workflows, and deliver maximum value.

The 2024 Project to Product State of the Industry Report¹ confirms this approach, showing that organizations that adopt these frameworks outperform their peers:

Elite organizations meet their quarterly objectives over 90% of the time, compared to less than 50% for low performers.
These elite organizations are 2x more likely to operate with a product-oriented approach, reducing wasted effort by 30%.
Yet, only 12% of organizations have fully operationalized the shift to a Product Operating Model, and most are still in the early stages of adoption.

These statistics highlight not only the opportunity but also the challenges organizations face when adopting these practices.

Aligning Teams to Deliver Maximum Value

A Product Operating Model allows teams to focus deeply on specific products, becoming subject matter experts while owning the product’s entire lifecycle. This ownership fosters alignment with business goals and eliminates inefficiencies caused by constant context switching.

The 2024 Project to Product State of the Industry Report reveals that in elite organizations:

Over 50% of work is product-oriented, while low performers remain stuck in project-based approaches.
Product-focused work leads to fewer canceled projects, less technical debt, and more business-aligned outcomes.

Value Stream Management complements the POM by making workflows visible, identifying bottlenecks, and optimizing delivery processes. Together, they enable teams to focus on what truly matters: delivering measurable value to the customer.

“Aligning teams to a product-focused approach ensures they not only deliver outputs but also realize outcomes, driving measurable impact for the business.”

Closing the Loop: Realization Matters

While flow ensures that work moves efficiently, realization connects delivery to outcomes. Realization is the critical second half of the equation: Did the work change customer behavior as intended? Was the desired outcome achieved?

The 2024 Project to Product State of the Industry Report highlights the gaps many organizations face:

Only 15% of organizations can incorporate customer feedback within weeks, meaning most teams lack the insights needed to close the loop.
30% of work in low-performing organizations remains over 90 days old, contributing to waste and inefficiency.

“Flow transforms effort into movement, but realization transforms movement into impact. Without closing the loop, we risk delivering outputs instead of outcomes.”

By linking flow metrics to customer behavior and business results, teams can measure the true value of their work. This feedback empowers teams and fosters a culture of continuous learning and adaptability.

Why Context Matters

Adopting frameworks like Value Stream Management or the Product Operating Model as a checklist of best practices is tempting. However, organizations that treat these as cookie-cutter solutions often struggle to realize their full potential. Context matters—the success of these practices depends on how well they are adapted to the organization’s unique challenges, culture, and goals.

“There is no one-size-fits-all approach to transformation. The true power of frameworks like VSM and the Product Operating Model lies in their flexibility to serve as blueprints rather than rigid rules.”

The 2024 Project to Product State of the Industry Report reinforces this, showing that elite organizations don’t merely implement practices—they adapt them to align with their structure, strategy, and customer needs.

By focusing on the core principles—alignment, flow, and realization—organizations can customize these practices to suit their context while achieving their desired outcomes.

Empowering Cross-Functional Teams

Empowerment isn’t just for product managers—it’s for the entire cross-functional delivery team. While the 2024 Project to Product State of the Industry Report highlights the role of product managers in driving vision and outcomes, the real magic happens when teams collectively own their work, informed by flow metrics and realization feedback.

“When teams understand how their work impacts customer behavior, they can make informed decisions, prioritize effectively, and adapt quickly to feedback.”

This shared empowerment enables teams to:

Collaborate more effectively.
Deliver higher-quality outcomes faster.
Build trust and alignment across roles and departments.

The Road Ahead

For 2025, this will be one of my primary focuses within my organization. This renewed focus stems from the feedback I received in late 2024 during a leadership program. In an anonymous 360-degree assessment from my peers at the executive level, one comment stood out: “You should focus more on business results as a technology leader.” That feedback hit hard but was also eye-opening. It made me realize that while our 10-year transformation from a monolithic waterfall process to a world-class Agile, continuous delivery, and microservices-based cloud solution was remarkable, we failed to communicate how this transformation drove measurable business results.

In response to this feedback, I am creating new tools and communication strategies for 2025 to enhance our approach to Value Stream Management and Product Operating Models:

Value Stream Templates: Helping teams realign or re-identify value streams, ensuring our work directly connects to business objectives.
Initiative and Epic-Level Definitions: Providing a template for improved initiative and epic-level descriptions in Jira (or similar tools) that emphasize anticipated outcomes and dependencies.
Team-Level OKRs: Establishing Objectives and Key Results tied to outcomes, ensuring alignment with business priorities.
Division Wiki Updates: Updating our internal documentation to emphasize outcomes over outputs, recognize dependencies, and reinforce our mission.

These efforts aim to bridge the gap between technology initiatives and business value, ensuring we deliver features and demonstrate their impact on growth, profitability, and customer success.

Finally, I welcome your insights and ideas for those leading similar changes. Let’s learn from one another and work together to align our efforts with the outcomes that matter most.

“The time to act is now. Let’s lead purposefully, ensuring our teams deliver meaningful, measurable value in 2025 and beyond.”

Poking Holes

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

Let’s talk: [email protected]

References

The 2024 Project to Product State of the Industry Report, Planview, https://info.planview.com/project-to-product-state-of-the-industry-_report_vsm_en_reg.html

From Good to Great: Shifting to Outcomes in 2025

January 2, 2025 by philc

7 min read

Audience and Purpose

This post is both a reflection and a vision. It’s a message for my team—who have been with me through challenges and successes—and a blog for leaders, peers, and anyone interested in the lessons we’ve learned and where we’re going next.

I chose to share this message as a blog post to reach my team and other leaders or organizations facing similar challenges. These insights encourage collaboration, spark new ideas, and help others navigate organizational transformation.

From Good to Great: Shifting to Outcomes in 2025

Today is January 1, 2025—a fresh start and a chance to reflect on the past year and plan for what’s ahead. During Thanksgiving, I shared my gratitude with my division and team for their hard work and achievements during a challenging time. However, I haven’t yet fully shared my vision for the future. As this new year begins, I’m reflecting on the significant changes ahead and our unique opportunities.

Our parent organization, which acquired us last year, is undergoing its transformative journey, driven by new investors and ambitious strategic plans. As they prepare to begin January with an inspiring company-wide message, it is equally important to focus on our division and the brand we have built together. This message is directed to our team as we navigate this period of change and improve the foundation for the future.

As we continue to grow and integrate, it is essential to maintain a long-term perspective. By 2026, we aim to become a stronger, unified organization with aligned practices, cohesive team structures, and a clear strategic direction. This year represents a pivotal phase in that process—a time to refine our identity, enhance our impact, and position ourselves for sustained success.

The perspectives and recommendations outlined here are based on my personal reflections and my understanding of where we currently stand and the potential paths forward. While I believe these steps represent meaningful progress, I want to stress that they are not the only way forward. If you have alternative ideas or cannot align with this vision, I encourage you to share your input. Collectively, our contributions will help shape the most effective path ahead.

A Journey of Growth and Transformation

Over the past decade, our team has faced its share of challenges—personality conflicts, shifting priorities, and growing pains—but we’ve also achieved remarkable transformations. Together, we’ve evolved from an unstable monolithic platform to a modern, scalable system powered by a culture of investment, innovation, and learning.

Ten years ago, we were constantly rebooting systems hosting a fragile monolithic solution. Back then, our releases were massive undertakings—twice a year, requiring months of preparation and leaving us with long downtimes and high risk. Today, we operate a cloud-based, microservices architecture, built on the principles of Agile, Lean, and DevOps. Our team has embraced automation, continuous delivery, and scalable design, enabling us to release updates 5 to 20 times a day with confidence and speed.

Additionally, 2024 marked yet another year of 99.99% system and platform uptime, a testament to the incredible work of our production engineering and platform teams. They’ve created a robust system that not only serves our customers seamlessly but also provides developers with a reliable, scalable foundation for innovation.

This transformation was about more than just technical changes. It required us to redefine our culture, leadership style, and design principles while investing in our people and processes. Along the way, I’ve realized that my passion as a leader hasn’t always been perfect—whether through my soapbox moments or the well-known “Phil Fridays,” where I’ve shared thoughts and emotions built up over the week (not to be confused with “50 Fridays,” which focuses on innovation). These moments, while not always polished, came from a genuine desire to see us succeed and continuously improve.

While we’ve said goodbye to a few team members who helped us kickstart this transformation, their contributions were vital in laying the groundwork for our progress. The baton has been passed, and the team has carried it forward, driving meaningful change and continuing to make strides. What inspires me most is that many of the people who helped lead this journey are still here, pushing us to new heights. Our success is not just about technological evolution—it’s also a testament to the strength of our culture and the dedication of our team.

The Challenges of Commitment: Moving to a Product Operating Model

Over the past few years, we’ve attempted to transition to a product operating model and embrace practices like value stream management. While the technology team introduced these concepts and championed them, my perception is that we’ve struggled to fully commit because product and technology have not been fully aligned.

Without full commitment from the product side, we’ve continued to treat teams like projects, prioritizing capacity demands across all products rather than focusing on the holistic value streams that underpin the product operating model. This fragmented approach has created inefficiencies and diluted the impact of our efforts.

In 2025, this must change. Both product and technology must align and fully commit to the product operating model. We need to reintroduce the reasons we’re practicing value stream management: to improve flow, align work to customer and business outcomes, and eliminate the inefficiencies of project-driven thinking. By embracing this approach together, we can build a stronger foundation for delivering value.

Again, this is my recommendation for moving forward. If you believe there’s a better way or cannot align with this vision, I encourage you to share your thoughts. Collaboration will help us shape the best possible future.

The Shift: Focusing on Outcomes

This year, our focus is on outcomes over outputs. It’s a simple but powerful shift: instead of measuring success by the features we deliver or the tasks we complete, we’ll measure it by the impact we create for our customers and the business.

This outcomes-first approach will give teams clarity and purpose, ensuring that every initiative has a measurable goal tied to a business or customer result. Importantly, this applies to both features and technical debt. Each type of work should have an anticipated outcome and clearly articulate the value it will bring to the customer and the results it will deliver for the organization. Here’s how we’re implementing this shift:

Anticipated Outcomes: Every epic will start with a clearly defined, measurable outcome, documented in our tools like Jira.
- Example (Feature): Launch a new onboarding feature for learners.
- Outcome: 80% of new users complete onboarding within 7 days, leading to a 25% increase in first-month retention by Q3 2025.
- Example (Technical Debt): Refactor the search service to improve scalability.
- Outcome: Search success rate increases from 70% to 90%, resulting in a 15% boost in user engagement by June 2025.
Alignment Through OKRs: Teams will translate these anticipated outcomes into team-level OKRs (Objectives and Key Results) that align with broader organizational goals.
- Example:
  - Division Objective: Expand access to dual enrollment opportunities.
    - Key Result: 10,000 learners use the new onboarding feature by August 2025.
    - Team Objective: Improve onboarding for new learners.
      - Key Result: 80% of new users complete onboarding within 7 days, increasing retention by 25%.
Closing the Loop: Measuring outcomes doesn’t end at delivery. Even if final metrics take a month, three months, or six months to materialize, we must go back and document the actual outcomes of our work. This step is critical for understanding whether our efforts moved the needle and for learning what adjustments might be needed in the future. Closing the loop ensures that we evolve based on data, not assumptions, and continuously improve how we deliver value.

By aligning outcomes with OKRs and closing the loop, we will create a system where every effort is purposeful, measurable, and connected to a larger vision. This approach will reduce chaos, improve clarity, and foster deeper engagement across teams, ensuring everyone understands not just what they are working on, but why it matters and how it contributes to our shared goals.

Balancing Progress with Organization Integration

While we focus on outcomes in 2025, we’re also navigating the complexities of post-acquisition integration. Aligning with our parent company and managing our brand presents its own challenges, but it also offers opportunities to grow and unify our practices.

In 2025, we’ll deepen our integration efforts while maintaining our commitment to improving how we work. This dual focus will prepare us for a seamless transition into a unified operating model in 2026 and beyond.

Key Takeaways for Leaders

Here are the key elements of our approach—ideas that I hope other leaders can use to improve alignment, engagement, and impact within their own teams:

Start with Outcomes: Define measurable, customer-centric outcomes for every initiative before beginning work.
Align with OKRs: Use team-level OKRs to connect outcomes with broader organizational goals.
Empower Teams: Provide clarity and purpose to help teams prioritize work that drives real value.
Close the Loop: Track and evaluate actual outcomes, learning from both successes and shortfalls.
Commit to Product Thinking: Transition fully to a product operating model and align product and technology teams on shared goals.

Looking Ahead: Making 2025 Count

2025 is our opportunity to go from good to great. By shifting to outcomes, fully committing to the product operating model, and reintroducing value stream management, we’re not just improving how we measure success—we’re creating a stronger connection between our work, our customers, and our business goals.

To other leaders reading this: Software engineers and technical leaders who only focus on technical topics—like technical debt, infrastructure upgrades, code quality, and development processes—risk losing relevance. Why? Succeeding in today’s tech world requires more than technical skills. It requires understanding customer experiences, business goals, and the value of technical investments. Clear communication and alignment on shared goals are essential to achieving meaningful outcomes by connecting technical investments to business results.

The most successful engineering professionals and technical leaders will explain how technology investments can:

Expand market opportunities through better performance and innovation
Drive stronger customer impact
Deliver measurable business results
Create strategic advantages

Those who don’t adapt to this change are falling behind. In the future, knowing how to build technology won’t be enough. The key will be understanding why it’s being built—and making sure every decision, feature, or technical investment adds value for both the customer and the business.

This journey is about creating a lasting impact—for our customers, business, and teams. Linking technical investments to business outcomes is the adjustment that will improve our team in 2025, but it is just a choice. I welcome you—and my own team—to bring forward alternatives if you cannot align with this approach or have a better one in mind.

For more on this topic, check out my three-part series, “Profitable Engineering: Connecting Software Development to Business Outcomes.”

Poking Holes

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