Why we implemented an Urgent Task Parachute Protocol
As a remote-first company, we put a lot of weight in good, clear, respectful communication, but it’s often hard to articulate why something that feels off may be more corrosive. That presents the risk of missing or not addressing the root cause. That perhaps explains why this post by Cate Huston has stuck with me:
Conflicting context shows up when people communicate superficially, without considering the context held by the other party.
Example 1: Team A requires support from Team B on its top-priority project. But Team B considers this project low priority and drops it in favor of something else, leading to frustration from Team A.
We experience this problem frequently when urgent tasks parachute into an active a body of work. We’re motivated to make great software and experiences, so we’re more than inclined to make the necessary fixes.
But as time passes, and these events pile up, so sensitivities emerge that are rooted in the conflicting context problem identified in Cate’s post.
With the root of the growing tension exposed, we took steps to create an implement a protocol for urgent task parachutes, where sharing and communicating context and urgency is foundational.
Urgent Task Parachute Protocol Blueprint
- Capture, share and communicate context with a focus on impact and urgency — aimed at minimizing conflicting context
- Allow for open assessment of:
- who needs to be participant in fix
- the impact to individuals involved
- impact to other priorities and active work
- Share knowledge of issue and fix — distribute and democratize product knowledge and awareness
- Start process of assessing whether it’s possible to implement steps aimed at avoid similar parachutes in the future