Rethink Your Understanding

Transforming Software Delivery

DevOps

Advocating for Refactoring: Prioritization in the Context of Business Goals

by

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

by

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,” 1 offers an insightful foundation, outlining three common ways organizations handle dependencies. Here’s my interpretation and perspective on his ideas:

  1. 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.
  2. Institutionalize (Bureaucracy Approach): Drowning dependencies in processes and meetings, creating layers of oversight that slow progress.
  3. 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

  1. 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

by

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 Report1 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

  1. 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

by

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:

  1. 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.
  2. 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%.
  3. 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:

  1. Start with Outcomes: Define measurable, customer-centric outcomes for every initiative before beginning work.
  2. Align with OKRs: Use team-level OKRs to connect outcomes with broader organizational goals.
  3. Empower Teams: Provide clarity and purpose to help teams prioritize work that drives real value.
  4. Close the Loop: Track and evaluate actual outcomes, learning from both successes and shortfalls.
  5. 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?

Breaking Free from the Build Trap: Delivering Meaningful Outcomes

by

10 min read

This image has an empty alt attribute; its file name is FeatureFactory-1024x1015.jpg

This article is the final part of a series on linking software engineering to business success. If you missed the earlier articles, start here.

This Article at a Glance

This article explores how engineering teams can escape the “build trap” and move beyond a feature factory mindset by focusing on outcomes instead of outputs. It highlights the pitfalls of the build trap, the value of starting with outcomes, fostering accountability and alignment, and ensuring successful delivery. Aimed at technology leaders, Product Managers, and teams, it challenges them to adopt a mindset centered on meaningful outcomes—driving engagement, alignment, and impactful business results.

From Speed to Meaningful Value

Picture this: you’re leading a team of talented developers, launching features rapidly, but customer satisfaction isn’t improving, and the business impact is unclear. This happens when teams focus too much on output, a common issue in traditional project-based management. Switching to a product operating model and applying Value Stream Management can break this cycle. These approaches focus on outcomes instead of outputs, ensuring every effort is tied to measurable business value.

As a senior technology leader, I’ve been there. Early in my career, I focused on operational efficiency and rapid feedback, confident that speed and volume would drive success. But I learned the hard way: speed alone doesn’t guarantee value.

This realization highlighted a critical gap—the need for realization. Efficiently delivering work is only part of the puzzle; the priority must be ensuring that every effort contributes meaningful outcomes for both customers and the business.

To close this gap, I began asking:

  • What outcomes do we expect, how will we measure success, and what can we learn from the results?

By adopting value stream management (VSM) and objectives and key results (OKRs), we created a clear link between work and impact. VSM revealed how work flows through teams and where value is created, while OKRs provided a framework for aligning team goals with organizational priorities.

Escaping the build trap isn’t just about faster delivery—it’s about rethinking success. When efforts are tied to measurable results, teams and leaders work with clarity, purpose, and trust, transforming delivery into meaningful value for the business and its customers.

Defining Outcomes at Every Level

Anticipated Outcomes for Epics

In Agile software development, an initiative is a large, highest-level body of work representing a significant feature or functionality too extensive for a single sprint. Initiatives usually have Epics defined to support a piece of the Initiative. Defining anticipated outcomes for each Initiative or epic clarifies the value being delivered, the behavior being changed, and how success will be measured. This approach helps teams see their work’s purpose and anticipated impact and how it aligns with organizational goals, as well as create team-level OKRs within their focus areas.

Questions to define Initiative or Epic level outcomes:

  1. What problem are we solving, what behavior are we changing, or what opportunity are we addressing?
  2. What results do we expect, and how will we measure them?
  3. What metrics will define success?
  4. How will we close the loop by learning from actual outcomes?

Example: An initiative aimed at improving onboarding might define success metrics like:

  • Increasing customer retention by 10% within 30 days.
  • Reducing onboarding-related support tickets by 15%.
  • Receiving positive feedback from customer satisfaction surveys.

By defining these outcomes, teams can create Key Results that align with broader organizational objectives, ensuring their efforts directly support larger goals. These key results can become the objectives of supporting epics.

Outcomes-Driven Iterations

Initiatives or Epics provide the overarching product change or improvement, while sprints should center on value-driven outcomes, not merely task completion. Traditionally, sprints have prioritized finishing backlog tasks. However, by integrating Value Stream Management with a product operating model, the focus shifts toward delivering meaningful value. Instead of measuring success by completed tasks, sprints are now about achieving impactful results aligned with value streams. This approach ensures that every iteration targets tangible customer and business results.

Teams should define sprint goals based on outcomes, not tasks.

Example: “Enhance system performance by improving response times by 5%” (outcome) versus “Complete three refactoring tickets” (task).

This mindset shifts how teams view their work:

  1. Collaboration over individual output: Team members who finish early should check if the sprint goal has been met and help others achieve it.
  2. Focus on shared success: Success is measured by achieving the outcome, not individual task completion.

When iteration goals align with epic outcomes, teams focus on delivering meaningful value at every level of work.

OKRs, focus on organization alignment

OKRs are essential for helping teams break free from the build trap by connecting their efforts to impactful outcomes. By focusing on work (features, technical debt, defects, and risks) within the team’s scope or control, OKRs align the team’s work with customer needs and organizational objectives. This alignment transforms sprints, epics, and initiatives from mere tasks into measurable milestones that drive meaningful business results.

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

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

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

Note: Escaping the build trap requires more than focusing on outcomes—it demands a structural shift to a product operating model. By aligning teams with specific products and value streams, organizations create an environment where teams are not just delivering features but owning the evolution of outcomes over time. This model encourages accountability and allows teams to iteratively refine their work, fostering alignment with customer needs and organizational goals. It also reduces handoffs and inefficiencies, enabling teams to focus on continuous delivery and improvement.

Accountability and Team Alignment

The Role of Product Managers

A strong product team is defined by the trust and partnership between engineers and their Product Manager—someone engineers would confidently “go to bat for.” To build this trust, Product Managers must prioritize technical debt, risks, and defects alongside new features, acknowledging their critical role in delivering a high-quality product.

Product Managers must also actively engage as part of the team. Their role involves:

  • Collaborating on priorities.
  • Participating in discussions.
  • Supporting the shared goal of delivering value to customers.

Ownership

Every outcome or team-level OKR needs a clear owner—someone who is accountable for defining, prioritizing, and ensuring its achievement. In Agile teams, this often means Product Managers own the outcomes tied to customer-facing features, while technical leads take responsibility for outcomes related to technical debt, scalability, or system performance. For example:

  • A Product Manager might own the outcome of increasing user retention by 10% through a new onboarding feature, ensuring the team understands the goal and tracks metrics like retention or onboarding completion rates.
  • A Technical Lead might own the outcome of reducing downtime by 15% by addressing key infrastructure improvements, ensuring technical debt is addressed in a way that aligns with broader organizational goals.

Ownership ensures clarity and accountability, preventing outcomes from falling through the cracks or becoming vague aspirations. The owner is also responsible for closing the loop—documenting the actual outcomes, sharing them with stakeholders, and reflecting on whether the actual outcomes were achieved.

Prioritizing by Anticipated Outcome or Impact

There’s always more work than resources. Your team is limited by the people you There’s always more work than resources. Your team is limited by the people you have and the time available. Capacity limits make it essential to prioritize based on outcomes. When new tasks arise, check if they align with your current objectives or OKRs. Don’t hesitate to push back if they don’t contribute to key objectives. Ask yourself:

  • Does this work align with our top priorities? If not, why should it take precedence?
  • What will we remove or deprioritize to maintain focus if we take on this work?
  • How does this impact our ability to achieve current targets and objectives?

When new work aligns with your objectives or introduces a higher-priority goal, something else must be deprioritized to make room. Collaborate as a team to identify and remove the lowest-priority work and communicate the updated goals or OKRs.

Prioritizing work based on anticipated return on investment (ROI) and anticipated outcomes ensures that engineering efforts focus on initiatives with the greatest potential for business impact. This approach balances short-term needs with long-term value creation, guiding teams to deliver meaningful results.

By recognizing capacity constraints and ensuring all stakeholders understand new requests’ significance and expected impact, teams can align their efforts with expected outcomes and ROI. This approach fosters collaboration, accountability, and a shared commitment to purposeful progress among Product Managers, engineers, and stakeholders.

Aligning Incentives

Teams must recognize the tensions created by differing role incentives:

  • Product Managers are often rewarded for growth and feature delivery.
  • Engineers focus on quality, performance, and resilience.

These priorities can clash, but alignment is achievable when both roles focus on shared outcomes. Product Managers who treat technical debt, quality, and security as essential aspects of the product—not competing concerns—foster trust and collaboration within their teams.

Great engineers go beyond technical skills—they understand the product and its goals. They ask thoughtful questions to ensure their work meets customer and business needs. This understanding helps them propose pragmatic solutions, such as quickly delivering 80% of the value while planning to address the remaining 20% later. By balancing speed and quality, engineers with a product mindset help their teams avoid becoming a “feature factory” that builds without considering impact or value.

When teams hold all members—particularly Product Managers responsible for features—accountable for defining outcomes, measuring success, and closing the feedback loop, they achieve greater clarity and alignment. This accountability drives purposeful work, encourages shared ownership, and links meaningful outcomes directly to business goals.es, measuring success, and closing the feedback loop, they achieve greater clarity and alignment. This accountability drives purposeful work, encourages shared ownership, and links meaningful outcomes directly to business goals.

Closing the Loop

I am a huge fan of “closing the loop” or sharing the outcome of the team’s efforts with the team and organization. Success isn’t just about finishing tasks; it’s about creating meaningful results. Instead of focusing on whether something is “done,” the impact measures real success: Did our work lead to an apparent, positive, and measurable change in customer behavior? Closing the loop is a key part of this process, and Product Managers and technical leads need to prioritize it to achieve lasting outcomes.

Although it may take weeks, months, or longer to receive the data or feedback, documenting the actual outcomes—whether in the Initiative, Epic, or both—is essential to show how the team performed. Metrics like customer engagement, retention, or efficiency gains help determine if the work delivered its intended value. For instance, if a new feature was meant to reduce churn, tracking churn rate, customer feedback, or increased product usage can confirm if the goal was met. Without this step, teams lose an essential chance to learn from their work. It shows how well the team met its objectives, helps improve future decisions, and ensures continuous growth.

Incorporating “closing the loop” into workflows helps Product Managers and technical leads gain actionable insights from every project. It ensures teams receive feedback on their work, promoting accountability, alignment, and constructive improvement. This approach keeps the focus on achieving clear outcomes and measurable success.

From Delivery to Realization

We’re enhancing team performance and operational efficiency by adopting a Product Operating Model and incorporating Value Stream Management (VSM) and Objectives and Key Results (OKRs) into our processes. Unlike projects with a defined end date, products follow a lifecycle—we’re not finished until the product is retired. This approach allows us to align teams to products and continuously deliver updates and improvements throughout a product’s lifecycle.

Value Stream Management (VSM) enables us to visualize the entire flow of value delivery, helping us identify and address bottlenecks and inefficiencies. Meanwhile, OKRs provide a structured framework for setting and tracking team goals, ensuring alignment with the organization’s broader strategic objectives. Together, these tools drive focus, clarity, and measurable progress in delivering value to our customers.

Integrating these practices is transforming our culture. Success is no longer measured by speed or output alone—it’s defined by the value delivered. These practices empower teams to recognize their impact, align with shared goals, and clearly demonstrate how their efforts drive business performance.

Lead With Outcomes

The time for teams to focus on both delivery and realization is now.

Steps to transform your teams:

  1. Define outcomes first: Start every epic, sprint, and initiative with clear, measurable outcomes.
  2. Hold teams accountable: Ensure product managers and engineers align with outcomes, not just output.
  3. Close the loop: Measure actual results, share insights with the team, and learn from every outcome through retrospectives.

When teams align on outcomes and focus on delivering impactful value, they move beyond simply following orders. They gain clarity on their purpose and unlock their full potential. We can create products that provide meaningful customer value while demonstrating clear contributions to organizational success.

Let’s lead with expected outcomes and break free from the build trap—together.

Series Summary

  1. Profitable Engineering: Linking Software Engineering to Business Results

Related Posts: Metrics and Team Efficiency

Poking Holes

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

Let’s talk: [email protected]

Transforming Engineering: From Cost Center to Strategic Partner

by

7 min read

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

A Leadership Epiphany

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

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

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

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

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

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

This Article at a Glance

Expanding on my earlier insights, this article explores:

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

Engineering’s Philosophy: Code Is Not the Product

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

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

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

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

Speaking the Language of Business

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

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

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

Embedding Outcomes Into Engineering Work

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

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

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

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

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

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

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

Minimizing Layoffs and Rethinking Team Design

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

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

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

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

A Commitment to Innovation

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

A Call to Action

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

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

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

Next in the Series

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

Poking Holes

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

Let’s talk: [email protected]