As a middle manager a typical feedback that you would hear from your senior management is that you are not challenging your team enough to achieve the goals. You are a lot closer to your team than your manager and so you have a good feel of your team. You may be hesitant to challenge the team as you know that the team is already stretched. You want to be seen as a manager who challenges the team, and at the same time you don't want to come across as an unreasonable leader in front of your team. Does this situation ring a bell? So what should you do as a leader to manage this catch-22 situation?
There are few techniques that you can try:
1. Challenge the assumptions and not the commitment: Let's say the team says it needs 4 weeks to accomplish a task. Merely challenging them to do it in say 2 or 3 weeks to pull in the schedule doesn't help. It means that you don't trust their judgement. The better strategy is to challenge the assumptions that led them to make their commitment. Go a few levels deeper in your assessment. Maybe sequencing the order of the tasks, or limiting the scope of the task, or assigning a different resource, or prioritising their other project commitments, or providing extra help could be different ways to address the challenge of the schedule pull-in. As a leader you need to question the assumptions recursively till you know all options are exhausted.
2. Challenge the norm/status-quo : Many a time we stick to the norm. We hear "this is the way it was always done". Doing it the same way and expecting different result is foolish. Recently in one of the products, the quality team wanted 4000 hours of qualification for the chip as we were using few components which were not qualified. My manager challenged the team, and so we had few calls with the process team to understand what is needed to reduce the #hours of qualification. We were asked to do a few specific simulations of the components, and if they pass, they were willing to reduce the requirement. If we were not challenged by our manager, we would have blindly followed the process mentioned by the quality team, which would have impacted our schedule for this product.
3. Create " Push to a corner" situation : When a person is in a comfort zone, he is not challenged enough. By creating a situation where he is pushed to a corner, he needs to come out of the comfort zone to solve the problem. He will stop thinking linearly and think out of the box to solve the problem. This situation will make him voluntarily do the above two steps : challenging the assumptions & norms. Recently, in one of the projects, we were working towards an aggressive schedule. There was a new design that had to be done which didn't require a very experienced resource. In the usual situation (comfort zone), to not affect the ego of the experienced person, this task would have been assigned to a junior engineer. But given that we were pushed to the corner to meet the schedule, we had to assign this task to the senior engineer. This turned out to be the right strategy for the project. The fact that this senior engineer was sensible and professional, made it easy for us to make this assignment.
Why This Matters
Organizations that fail to distinguish between productive challenge and destructive pressure systematically underperform and hemorrhage talent. When middle managers simply transmit executive pressure without adding analytical value, they create cultures where teams pad estimates defensively, hide problems proactively, and optimize for appearing busy rather than achieving breakthroughs. The business cost is profound: slower innovation cycles, higher employee turnover, and the gradual calcification of 'safe' thinking that prevents organizations from adapting to market disruption. Leaders who master assumption-based challenge unlock discretionary effort while building organizational resilience.
Leadership in Practice
A leading e-commerce and cloud company's famous 'two-pizza team' structure emerged from the founder and CEO challenging a fundamental assumption about how software development scaled. In the early 2000s, the company's growth was slowing as teams expanded and communication overhead exploded. The conventional wisdom suggested that bigger, more complex challenges required proportionally larger teams. The founder questioned this assumption relentlessly, asking why coordination costs had to increase exponentially with team size. His team discovered that small, autonomous teams with clear ownership could actually move faster on complex problems than large, coordinated groups. This insight led to a complete restructuring of the company's engineering organization around small, independent teams-each small enough to be fed with two pizzas. But the breakthrough wasn't just about team size; it was about challenging the assumptions around dependencies, communication protocols, and decision rights. By questioning why teams needed extensive coordination, the company identified architectural changes (service-oriented architecture, API-first design) that enabled true autonomy. The result wasn't just faster delivery; it was a competitive advantage that powered the company's expansion from e-commerce into their cloud services division, devices, media, and beyond. This transformation didn't happen by telling teams to 'work harder'-it happened by systematically challenging the assumptions that made their work difficult.
Leadership Framework
**The Assumption Excavation Framework**
**Step 1: Separate Commitment from Constraints**
When receiving an estimate or assessment, explicitly acknowledge the team's expertise and effort before exploring assumptions. Begin with: 'I trust your judgment and commitment. Help me understand the constraints you're working within.' This framing establishes psychological safety for the exploration ahead.
**Step 2: Map the Assumption Layers**
Systematically identify assumptions at multiple levels:
- Scope assumptions: What must be included versus what could be phased?
- Sequence assumptions: What dependencies are technical versus conventional?
- Resource assumptions: What skills are truly required versus traditionally assigned?
- Quality assumptions: What standards are regulatory versus preferential?
- Process assumptions: What steps are value-adding versus inherited practice?
**Step 3: Test Each Assumption with 'What Would Have to Be True?'**
For each assumption, ask: 'What would have to be true to do this differently?' This question shifts from defending the status quo to exploring possibilities. Document which assumptions are immovable constraints versus challengeable conventions.
**Step 4: Co-Create Alternative Scenarios**
With assumptions exposed, collaborate on alternatives: 'If we reduced scope by X, how does that change the timeline? If we sequenced differently, what becomes possible?' Generate multiple scenarios rather than forcing a single 'stretch goal.'
**Step 5: Commit with Transparency**
Choose a path forward with clear visibility into which assumptions you're changing and what risks you're accepting. Document learning for future estimates.
**Critical Success Factor**: This framework fails if used manipulatively to get predetermined answers. It succeeds when leaders genuinely seek understanding and accept that some constraints are real. **Warning**: Never use this approach in crisis mode when time pressure prevents proper analysis-that erodes trust in the method.
"The quality of a leader is reflected in the standards they set for themselves." - Ray Kroc
Comments