Coaching Upward: How to Get Executives to Support Agile Transformation
The most common reason agile transformations fail is not that teams cannot learn agile practices. Teams adapt quickly — the ceremonies, the frameworks, the vocabulary are learnable within a few sprints. The reason transformations fail is that the organizational context in which teams operate does not change. Funding models remain project-based, which means teams are measured against delivery schedules rather than outcomes. Governance structures remain stage-gate, which means decisions that teams need to make at sprint-level speed get routed through approval processes that operate at quarterly speed. Leadership behaviors remain output-focused, which means teams get rewarded for shipping features and scrutinized for missing milestones, regardless of whether the features shipped drove measurable value.
Coaching upward — working with executives and senior leaders to change the organizational conditions that determine whether agile can function — is the highest-leverage and least practiced form of agile coaching. Most coaches are hired to work with teams, given access to teams, and measured on team-level outcomes. The organizational conditions that limit those outcomes are outside the scope of their engagement. This post argues for a different model: one in which agile coaching includes an explicit executive coaching component, focused on the specific leadership behaviors that either enable or undermine team-level agile practice.
Agile transformation requires leadership behavior change, not just team-level practice adoption.
The Executive Behaviors That Kill Agile at the Team Level
Executives who undermine agile transformation rarely intend to do so. They are applying management behaviors that were effective in a project-management context and have not yet recognized that these behaviors are incompatible with the agile operating model. The most common is sprint interrupt: the executive who contacts the product manager directly mid-sprint to request that a new priority be added to the current sprint's work. This behavior is often motivated by genuine urgency, but its effect is to demonstrate to the team that sprint commitments are not real commitments — that they can be renegotiated by any stakeholder with sufficient seniority at any time. When sprint commitments are not real, sprint planning becomes performance rather than actual commitment.
A second behavior is the output status request: the executive who asks the product manager for a weekly report on what was delivered last sprint, expressed in features shipped. This request trains the product manager to optimize for feature shipping and to communicate in output terms — and the product manager trains the team accordingly. A third behavior is the annual roadmap demand: the expectation that product teams will commit, at the start of the year, to a specific set of features that will be delivered at specific dates twelve months hence. This expectation is structurally incompatible with an agile practice built on the premise that learning should change direction — but it is extremely common in organizations that have adopted agile at the team level without changing their planning and governance processes.
Executive coaching starts with understanding the leader's own goals and frustrations, not with agile theory.
What Executive Coaching Looks Like in Practice
Executive coaching for agile transformation is not about convincing executives that their current behaviors are wrong. It is about helping them understand the gap between what they are trying to achieve (faster delivery, better products, more responsive teams) and what their current management behaviors actually produce. The coach's starting point is always the executive's own goals and frustrations — not the coach's theory of agile management.
In practice, this often begins with a conversation about what the executive currently measures and how they interpret what they measure. An executive who measures velocity is implicitly rewarding throughput. An executive who asks for feature roadmaps is implicitly rewarding predictability over learning. The coaching conversation is not 'stop measuring velocity' but rather 'what would you want to be true for velocity to be a meaningful indicator of team performance?' This question leads naturally to the distinction between output metrics (which measure activity) and outcome metrics (which measure impact), and opens the door to a discussion of what the executive actually cares about — which is almost always outcomes, not outputs.
Creating Structural Conditions for Agile Success
Beyond individual behavior change, executive coaching for agile includes advocacy for structural changes that teams cannot create for themselves. The most impactful structural changes are funding model redesign (moving from project-based to product-team-based funding, which eliminates the artificial project timelines that force output commitments), governance process streamlining (reducing the approval layers that introduce latency into team decision-making), and outcome-based accountability (shifting from 'did this team deliver the roadmap?' to 'did this team move the metrics they committed to?').
These structural changes require executive authority and organizational influence that team-level agile coaches do not typically have. The coach's role is to make the case for each change clearly — identifying the specific team-level dysfunction that each structural issue creates — and to support executives in understanding what change at their level is prerequisite to change at the team level. Jeff Gothelf and Josh Seiden's Lean UX identifies this organizational dimension as one of the three levels at which lean practice must operate: team practices, team rituals, and organizational shifts. Coaching exclusively at the first two levels, without addressing the third, produces teams that are trained in agile but operating in an environment that systematically undermines what they are trained to do.
The Bottom Line
Coaching upward is uncomfortable work. It requires challenging the assumptions and behaviors of people with more organizational power than the coach, in a context where the coach's continued engagement may depend on those people's goodwill. The temptation to limit coaching to the team level — where the coach has permission and where progress is more visible — is understandable. But a team-level agile coach who does not engage with the organizational conditions surrounding the team is treating the symptoms of a systemic dysfunction rather than the dysfunction itself. The most effective agile coaches understand that their real client is not the team. It is the organization.
Related Posts from Sense & Respond Learning
The Anti-Pattern Library: 10 Agile Dysfunctions and How to Coach Through Them
The Case Against Annual Roadmaps: Why Quarterly OKRs Serve Leaders Better
From Story Points to Outcomes: Coaching Teams to Measure What Matters
Cross-Functional Team Health: The Signals Every Agile Coach Should Monitor
Further Reading & External Resources
Lean UX — Gothelf & Seiden (O'Reilly) — Core text on organizational conditions for lean product team success
Team Topologies — Skelton & Pais — Essential reading on organizational design for fast-flowing software delivery
Accelerate — Nicole Forsgren et al. — Research-based evidence for what organizational factors drive software delivery performance
Want to go deeper? This post is part of the Sense & Respond Learning resource library — practical frameworks for product managers, transformation leads and executives who want to lead with outcomes, not outputs.
Explore the full library at https://www.senseandrespond.co/blog
