Have you ever been in a meeting where leadership shares their latest great idea, and you can feel the anxiety spreading across the team? I have. The developers exchange knowing looks – they’re already struggling with an overloaded sprint, the backlog is growing, and now here comes another “high priority” initiative. You can almost hear their thoughts: “We’re already maxed out… how are we supposed to do this too? Does leadership even know what we’re working on?”
This scenario plays out in companies every day, slowly eroding the team’s trust in leadership’s ability to maintain focus and make realistic decisions. I’ve seen it happen, and it reminds me of what Rodrigo Sperb recently wrote about creating focus. He’s absolutely right, but there’s something deeper here that we need to understand.
Asking leaders to “stop wanting new things” is like asking fish to stop swimming. It’s not going to happen, and honestly, it shouldn’t! The real problem is much more interesting: leaders and engineering teams think about work in fundamentally different ways.
Why Leaders Seem to Ask for “Everything”
When engineering teams receive an “ask” from a leader, it feels like being told: “Do all of this, and do it ASAP.” But here’s what I’ve learned after years of working with both sides: that’s rarely the intention.
Leaders don’t view these asks as immovable mandates. Instead, they see them as options. Each idea represents a potential way to deliver value to a customer, a stakeholder, or the business. I mean, think about the leader’s perspective: leaders get bombarded with inputs from customer feedback, sales requests, competitive threats, stakeholder demands. These inputs turn into ideas, which then evolve into fully formed solutions, especially for leaders with technical backgrounds.
The excitement takes over, and leaders naturally share these ideas with their teams. But without clarity or a framework to manage these requests, we end up with what I call “roadmap churn”—that constant state of flux that leaves teams scrambling, confused, and frustrated (I’ll write about this later, stay tuned).
I’ve seen this dynamic destroy teams. It breeds inefficiency, burnout, and dissatisfaction. And worse, it usually leads to organizations failing to deliver!
The Root Cause: Misaligned Mental Models
The problem isn’t that leaders are asking for too much or that engineering teams are unresponsive. The problem is a mismatch in how leaders and teams interpret these “asks”:
- Leaders see asks as options—ideas to explore and validate because they’ve received signals these are valuable ideas for solutions
- Teams see asks as work—tasks to execute, often at the expense of their current priorities, leading to Roadmap Churn
This mismatch creates friction, wastes effort, and leads to missed opportunities. But there’s a solution.
The Software Leadership Workshop is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
The Solution: An Experiment-Driven Approach
What we need is a shared framework—a way to bridge the gap between leaders’ idea generation and teams’ execution mindset. I call this the experiment-driven approach to software development. This mindset helps teams validate ideas quickly, focusing on learning and value rather than jumping straight to delivery.
Here’s how I’ve seen it work in practice:
Step 1: Define the Option (aka Something we do That Has Value)
When a leader brings an ask to the team, start by clarifying the option it represents. Use this simple template:
- We believe that if we… [deliver something specific]
- Then… [the stakeholder/customer will get this benefit]
- And… [we our organization/product/team will achieve this value]
For example: “We believe that if we add this feature, the sales team will close more deals, and we’ll increase our revenue by X.”
This framing ensures everyone understands the potential value and the problem to solve. The detailing of the (value) option tries to shift the conversation from “do this now” to “is this worth doing?”
Step 2: Explore Contrasting Solutions (Really Contrasting!)
Once the option is clear, brainstorm multiple ways to address it. Focus on two contrasting approaches:
- Quick and dirty: A fast, low-effort way to test the idea and gather feedback (do you want a real-life example? Let me know in the comments)
- Full-fledged: A comprehensive solution that aligns with long-term goals but requires more effort
This step highlights the trade-offs between speed to market, quality, and impact on the Roadmap (Roadmap Churn). The goal here, is to help leaders articulate their appetite for risk.
Step 3: Align on Risk Appetite Before Starting Any Work
If the leader opts for the full-fledged solution, have a discussion about trade-offs. Be explicit: delivering this work means de-prioritizing other items on the roadmap. If that’s the case, we must make sure all stakeholders are aligned.
If they choose the quick-and-dirty approach, schedule it promptly but make sure you respect your existing plans. This helps teams maintain focus while still enabling leaders to explore new ideas, and validate the (value) options that naturally come up in any software development initiative.
Step 4: Keep It Lightweight
This process doesn’t need ceremonies or heavy documentation. Integrate it into your existing routines, like daily stand-ups or backlog refinement sessions. The key is establishing a rhythm that aligns leadership’s exploratory mindset with the team’s delivery-focused workflow.
Needless to say, this approach works better if you have shorter Sprints, or Release cycles. The longer the Sprints/Release cycles, the harder it will be to accommodate changes to the plan, and consequently the work for validating these value options.
Why This Works
The experiment-driven approach aligns two critical but often conflicting perspectives:
- Leaders feel empowered to explore options and validate value without overwhelming their teams
- Teams gain clarity and control, focusing on meaningful work while avoiding the chaos of constant change
This shared framework fosters collaboration, builds trust, and ultimately helps organizations deliver value more effectively.
Share Your Story
Have you struggled with “one more thing” requests from leadership? How did you handle it? Share your experiences in the comments. Let’s learn from each other and find better ways to work together.
—
🙌 Thank you for re-sharing this blog post and helping others reflect on how they can get their work lives back in control, and enjoy the wonderful privilege that we share of working with an amazing technology: software!
Thanks for reading The Software Development Today blog! This post is public so feel free to share it.
