Would You Still Call 911 if it Ignored Your Escalations?
Try It: Escalations
In our Try It Series, we will explain a common Agile or company problem, and provide solutions that have worked for us in the past. We’ll also include complete job aides and coaching materials for our readers to experiment with their teams. We do this to help others and solicit feedback.
Caller: Hello 911? I smell smoke!
911: Please hold, we’re incredibly busy today.
911: (90 minutes later) I hear you have smoke! Don’t bring me problems, bring me solutions.
Caller: I think I need a firetruck? The smoke is a fire now! The instructions on the turkey said 4 hours…it began smoking an hour ago, so I need to wait 3 more hours before removing it from the oven, right?
911: It’s the 4th of July, why are you cooking a turkey? Why did you start the fire? Do you know how much a fire truck costs? Do you know what that will do to our timelines? Go to the neighbor’s house, get the garden hose, and start spraying the house.
Caller: Wait, I can’t! 451 Hazelwood burnt down!
911: What! That’s my house!
Caller: I was afraid to call about 451 Hazelwood, but now I’ll wait here in the living room to be rescued. Don’t worry, I’m watching a video on fire safety. When do you think you will have the available bandwidth for my rescue?
I have dinner plans; the guests arrive at 4pm.
Imagine a society where calling the fire department was ignored or met with retribution, people waited to be rescued, and rules were blindly followed. Absent a literal fire, does this seem like your daily organizational pattern? How would you even begin to make it better? Are you even empowered to make things better?
What does a developer, product owner, Scrum Master, or vice president have in common? Regardless of the organizational role, everyone will eventually need help. However, most organizations are missing a clear escalation path, a structure that makes escalations safe, ultimately uncovering the clear and transparent value escalations bring to a System of Delivery.
The majority of escalations within an organization exist from the lack of understanding of how the teams fit within the strategic goals of the organization. The problems to be solved, the hypotheses to be tested, and the assumptions and risks associated with those items are not made explicit to the teams. The teams are left in the smoky darkness. This darkness creates thrashing as others are deployed to fight the fire without centralized strategy or orchestration.
Since no one can see where they are going and no one understands the destination, team members trip and fall over everything, each other, and wait for the firefighters to rescue the team. This chaos is due to the current governance model. The current design is for teams to seek permission and approval, rather than be empowered to solve their own escalations. This confusion is amplified because teams do not understand their boundaries and objectives. This entire hot mess stops work as escalations pile up and are slowly processed. The traditional response to this entire problem is to hire better firefighters.
The ambiguity in mission and the delegation of decisions promotes a culture where escalation, which is simply asking for help, becomes a behavior that is punished or ignored, and those responses eventually stop all escalation. This creates a never-ending cycle of tamping down escalation, just to create more escalation, which is then tamped down, causing unpredictable results in the organization’s systems of delivery, resulting in the intense heat of organizational friction stopping the delivery of work. The teams just sit in the smoky darkness and wait as the fire gets closer. The firefighters grow weary and retire.
To tame escalations, the clarity and context of the mission must be given to the teams through a trustworthy governance model. The decision rights of the team must be transparent to all, the backlogs of work aligned, and the teams must be skilled, trusted, and empowered to resolve their own escalations within these boundaries. This structure is basic fire safety, it sounds simple enough, but it is a journey and might not be easy to execute due to the current organizational design.
In the meantime, to surface the lack of context and clarity of the mission, create an escalation path that is promoted, and made safe for participation. It is methodical. It is structured. It is required to be used early and often. Not using the escalation path is seen as the anti-pattern.
The Escalation Path should be a pathway that leads to the c-suite. When starting, this support might not be possible, so ensure the formal top of the escalation path is empowered to solve most escalations.
The escalations should be composed in a clear and concise format for communication and stored in a central location for organizational learning and reflection. This structure will allow all teams to learn from other resolutions, and the organization to make informed governance changes, which will ultimately reduce the number of escalations by driving visibility into the lack of centralized context and boundaries of the mission.
With these three items, escalation will no longer is perceived as “complaining” but just as simply asking for help. It will make pain points visible and provide rapid feedback to leadership about the true impediments within the system. It will allow the organization to focus on the centralized strategy by forcing impediment remediation. There are only so many fire trucks, and this normally leads to the organization developing and implementing a centralized governance model.
Definition and Operations of an Escalation Path
Ideally, the C-suite must be accountable for all escalations and the roll out of the escalation path. When the C-suite creates the escalation path it will do two foundational things: build the safety to escalate and delegate the authority to resolve the escalations.
A simple, short escalation path is required to promote escalations moving rapidly through the pathway. When an escalation is blocked within the escalation path, the next team accountable for escalation must be engaged without penalty to anyone.
Escalation pathways that consist of teams rather than individuals, promote resolving the impediment versus tamping it down. Individuals alone are prone to making bad decisions due to bias. The teams in the pathway meet frequently, aligned to corporate governance, and are empowered to remediate escalations.
Escalation should be encapsulated in a common, domain specific format. This format should include mechanisms that encourage the escalating team to explore potential resolutions. When the escalation is presented to a team in the escalation pathway, a complete context is provided, and clarity of solution is transparent.
Without visibility and ease of use, the escalation pathway will not take hold, and the tampering down cycle will continue. Escalations that are escalated outside of the pathway should be understood and rerouted to the pathways. Impediments escalated outside of the pathway should be discouraged to ensure the organization is still taking accountability for the impediments.
If this sounds like your organization, use the attached job aide to experiment. We would love to hear back from your learning. Does this work? What did you change? What would you do differently?