9 min read
When Sarcasm Reveals Misalignment
Last week, one of my Agile Delivery Leaders brought forward a concern from her team that spoke volumes—not just about an individual, but about the kind of tension that quietly persists in even the most mature organizations.
She asked her team to define the expected outcome for a new Jira Epic—a practice I’ve asked for all teams to adopt to ensure software investments align with business goals. However, it seems they struggled to clearly identify the anticipated outcome. On top of that, a senior team member who’s been part of our transformation for years dismissed the idea instead of contributing to the discussion. She found herself in a difficult position, torn between the leader’s authority and her own responsibilities. He commented something like:
“Why are we doing this? This is stupid. Phil read another book, and suddenly we’re all expected to jump on board.”
When I first heard that comment secondhand, I felt a wave of anger—it struck me as pure arrogance. This leader chose not to share his perspective with me directly, perhaps for reasons he deemed valid. But as I thought more about it, I realized it wasn’t arrogance at all, but ignorance. Not malicious ignorance, but the kind that comes from discomfort, uncertainty, or an unwillingness to admit they no longer understand or align with where things are going. Comments like that are often defense mechanisms. They mask deeper resistance, reveal a lack of clarity, or quietly question whether someone still fits into a system evolving beyond their comfort zone.
This wasn’t about rejecting change or progress—it was about pushing back against the way we’re evolving right now. Moments like this serve as a reminder that true transformation isn’t just about forging ahead; it’s about fostering belief and alignment in mindset and actions as we move forward together.
Purpose-Driven Development: My Approach to Sustainable Alignment
I asked teams to define anticipated outcomes not to add overhead but to protect the integrity of the way we build software.
Over the past decade, I’ve worked hard to lead engineering our teams and organization out of the “feature factory” trap—where the focus is on output volume, velocity, and shipping for the sake of shipping. Through that experience, I developed Purpose-Driven Development (PDD), which is my definition of this term.
Purpose-Driven Development might sound like a buzzword, but it’s how we bring Agile and Lean principles to life. It ensures delivery teams aren’t just writing code—they’re solving the right problems, for the right reasons, with clear goals and intentions.
PDD is built on one core idea: every initiative, epic, and sprint should be based on a clear understanding of why it matters.
Anticipated Outcomes: A Small Practice That Changes Everything
To embed this philosophy into our day-to-day work, we introduced a simple yet powerful practice:
Every Epic or Initiative must include an “Anticipated Outcome.”
Just a sentence or two that answers:
- What are we hoping to achieve by doing this work?
- How will it impact the customer, the Business, or the platform?
We don’t expect perfection—we expect intention. The goal isn’t to guarantee results but to anchor the work in a hypothesis that can be revisited, challenged, or learned from.
This simple shift creates:
- Greater alignment between teams and strategy
- More meaningful prioritization
- Opportunities to reflect on outcomes, not just outputs
- Visibility across leadership into what we’re investing in
Who Might Push Back—and Why That’s Okay
When we ask teams to define anticipated outcomes, it’s not about creating friction—it’s about creating focus. And this shouldn’t feel like a burden to most of the team.
I believe engineers will welcome it. Whether they realize it at first or not, this clarity gives them purpose. It ties their daily work to something that matters beyond code.
The only two roles I truly expect might feel frustration when asked to define anticipated outcomes are:
Product Managers and Technical Leaders.
And even that frustration? It’s understandable.
Product Managers often experience pain from not being involved early enough in the ideation or problem-definition stage. If they’re handed priorities from a higher-level product team without the context or autonomy to shape the solution, they may not know the anticipated outcome. And that’s the problem—not the question itself, but the absence of trust and inclusion upstream.
For Technical Leaders, it often comes when advocating for tech debt work. They know the system needs investment but struggle to translate that into a clear business reason. I get it—it’s frustrating when you know the consequences of letting entropy creep in, but you haven’t been taught to describe that impact in terms of business value, customer experience, or system performance.
But that’s exactly why this practice matters.
Asking for an anticipated outcome isn’t a punishment. It’s an exercise in alignment and clarity. And if that exercise surfaces frustration, that’s not failure—it’s the first step toward better decision-making and stronger cross-functional trust.
Whether it’s advocating for feature delivery or tech sustainability, we can’t afford to work in a vacuum. Every initiative—whether shiny and new or buried in system debt—must have a reason and a result we’re aiming for.
Anticipated Outcomes First—But OKR Alignment Is the Future
When I introduced the practice of documenting anticipated outcomes in every Epic or Initiative, I also asked for something more ambitious: a new field in our templates to capture the parent OKR or Key Result driving the work.
The goal was simple but powerful:
If we claim to be an outcome-driven organization, we should know what outcome we’re aiming for and where it fits in our broader strategy.
I aimed to help teams recognize that their Initiatives or Epics could serve as team-level Key Results directly tied to overarching business objectives. After all, this work doesn’t appear by chance. It’s being prioritized—whether by Product, Operations, or the broader Business—for a deliberate purpose: to drive progress and advance the company’s goals.
But when I brought this to our Agile leadership group, the response was clear: this was too much to push simultaneously.
Some teams didn’t know the parent KR, and some initiatives weren’t tied to a clearly articulated OKR. In many cases, our organizational OKR structure was still incomplete—we were missing the connective tissue between top-level objectives and team-level execution.
And they were right.
We’re still maturing in how we connect strategy to delivery. For many teams, asking for the anticipated outcome and the parent OKR at once felt like a burden, not a bridge.
So we paused the push for now. My focus remains first on helping teams articulate the anticipated outcome. That alone is a leap forward. As we strengthen that muscle, I’ll help connect the dots upward—mapping team efforts to the business outcomes they’re driving, even if we don’t have the full OKR infrastructure in place yet.
Alignment starts with clarity. And right now, clarity begins with purpose.
Without an anticipated outcome, every initiative is a dart thrown in the dark.
It might land somewhere useful or waste weeks of productivity on something that doesn’t matter.
Documenting the outcome doesn’t just give us clarity—it gives us direction. It means we’re making strategic moves, not random ones. And it reduces the risk of high-output teams being incredibly productive… at the wrong thing.
Introducing the Feature Factory Ratio
To strengthen our focus on PDD and prioritize outcomes over outputs, we are introducing a new core insights metric as part of our internal diagnostics:
Feature Factory Ratio (FFR) =
(Number of Initiatives or Epics without Anticipated Outcomes / Total Number of Initiatives or Epics) × 100The higher the ratio, the greater the risk of operating like a feature factory—moving fast but potentially delivering little that matters.
The lower the ratio, the more confident we can be that our teams are connecting their work to value.
This ratio isn’t about micromanagement, it’s about organizational awareness. It tells us where alignment is breaking down and where we may need to revisit how we communicate the “why” behind our work.
Why We Call It the Feature Factory Ratio
When I introduced this metric, I considered several other names:
- Outcome Alignment Ratio – Clear and descriptive, but lacking urgency
- Clarity of Purpose Index – Insightful, but a bit abstract
- Value Connection Metric – Emphasizes intent, but sounds like another analytics KPI
Each option framed the idea well, but they didn’t hit the nerve I wanted to expose.
Ultimately, I chose the Feature Factory Ratio because it speaks directly to the cultural pattern we’re trying to break.
It’s provocative by design. It challenges teams and leaders to ask, “Are we doing valuable work—or are we just shipping features?” It turns an abstract concept into a visible metric and surfaces conversations we must have when our delivery drifts from our strategy.
Sometimes, naming things with impact helps us lead the behavior change that softer language can’t.
Sidebar: Superficial Alignment—The Silent Threat
One of the biggest leadership challenges in digital transformation isn’t open resistance, it’s superficial alignment.
These senior leaders attend the workshops, adopt the lingo, and show up to the town halls—but when asked to change how they work or lead, they bristle. They revert. They roll their eyes or make sarcastic comments.
But they’re really saying: I’m not sure I believe in this, or I don’t know how I fit anymore.
The danger is: superficial alignment looks like progress, but it blocks true transformation. It creates cultural drag. It confuses teams and weakens momentum.
Moments like the one I shared remind me that transformation isn’t a checkbox but a leadership posture. And sometimes, those sarcastic comments? They’re your clearest sign of where real work still needs to happen.
Start Where You Are—And Grow from There
The truth is, we’re all at different points in our transformation journeys—as individuals, teams, and organizations.
So, instead of reacting with frustration when someone can’t articulate an outcome or when a snide remark surfaces resistance, use it as a signal.
Meet your team where they are. Use every gap as a learning opportunity, not a leadership failure.
If a team can’t answer “What’s the anticipated outcome?” today, help them start asking it anyway. The point isn’t to have every answer right now—it’s to build the muscle so that someday, we will.
These questions aren’t meant to judge where we are. They’re meant to guide us toward where we’re trying to go, and this is the Work of Modern Software Leadership.
It’s easy to say we want to be outcome-driven. Embedding that belief into daily practice is harder, especially when senior voices or legacy habits push back.
But this is the work:
- Aligning delivery to strategy
- Teaching teams to think in terms of impact
- Holding the line on purpose—even when it’s uncomfortable
- Measuring not just what we ship but why we’re shipping it
Yes, I’ve read my fair share of books. Along the way, I’ve experienced key moments and expected outcomes that influenced my journey in adopting new initiatives within our division and organization, such as Value Stream Management and understanding what it means to deliver real value. I’ve led teams through transformation and seen what works. From my experience in our organization and working with other industry leaders, I’ve learned that software delivery with a clear purpose is more effective, empowering, and valuable—for the Business, our customers, and the teams doing the work.
Leader’s Checklist: Outcome Alignment in Agile Teams
Use this checklist to guide your teams—and yourself—toward delivering work that matters.
1. Intent Before Execution
- Is every Epic or Initiative anchored with a clear Anticipated Outcome?
- Have we stated why this work matters—to the customer, business, or platform?
- Are we avoiding the trap of “just delivering features” without a defined end state?
2. Strategic Connection
- Can this work be informally or explicitly tied to a higher-level Key Result, business goal, or product metric?
- Are we comfortable asking, “What is the business driver behind this work?” even if it’s not written down yet?
3. Team-Level Awareness
- Do developers, QA, and designers understand the purpose behind what they’re building?
- Can the team articulate what success looks like beyond “we delivered it”?
4. Product Owner Empowerment
- Has the Product Manager or Product Owner been involved in problem framing—or were they handed a solution from above?
- Is that a signal of upstream misalignment if they seem disconnected from the outcome?
5. Tech Debt with Purpose
- If the work is tech debt, have we articulated its impact on system reliability, scalability, or risk?
- Can we tie this work back to customer experience, transaction volume, or long-term business performance?
6. Measurement & Reflection
- Are we tracking how many Initiatives or Epics lack anticipated outcomes using the Feature Factory Ratio?
- Do we ever reflect on anticipated vs. actual outcomes once work is delivered?
7. Cultural Leadership
- Are we reinforcing that asking “What’s the anticipated outcome?” is about focus—not control?
- When we face resistance or discomfort, are we leading with curiosity instead of compliance?
Remember:
Clarity is a leadership responsibility.
If your teams don’t know why they’re doing the work, the real problem isn’t them—it’s upstream.
Poking Holes
I invite your perspective on my posts. What are your thoughts?
Let’s talk: [email protected]