Conveying urgency through data

One of the most common frustrations professionals face in growing organizations is the increased turnaround time on deliverables. Whether it’s an incident that wasn’t addressed fast enough, or a blocking project by another team that took longer than it should have, the perception is things move slower.

The perception of a decreased pace is not necessarily false. When there’s more people, more features, and more code, getting alignment across all facets takes more talking, thinking, and understanding than before. However, a gap in communication that can lead to an incorrect priority ranking of a to-do for a team or an individual.

It’s not uncommon for an engineer to get pinged by the boss with a message of “This feature is broken! It needs to get fixed ASAP!”. The priority is set by the boss: I have an exclamation point in every sentence — this must be important. The engineer will drop everything and focus on the issue at hand. This earns great respect and perception of understanding of what really is important.

But why? How many users does the issue impact? How much money is the company loosing? How many users and how much revenue does the work the engineer dropped to focus on this issue impact? What’s the cost of the context switch?

These are all great questions and the answers are excellent data points to convey urgency and get multiple individuals and teams on the same page.

I recently had a chat with a fellow engineering leader, who was having trouble conveying urgency to parallel teams responsible for implementing blocking components of a system that his team needed to resolve an issue impacting thousands of users. While the immediate issue was patched up, the band-aid solution was not going to hold for long.

We went through the above questions:

• the number of users impacted?
• resulting hit to revenue and the time the work would take?
• opportunity cost: what projects the teams were prioritizing above the blockers?
• how long it did it take to obtain the growth matching the impacted users and revenue?

It was very clear that the best thing the teams could be doing as their top priority was implementing the needed support to resolve the patched-up issue with a long term solution. Working on regaining that many users and that much revenue would take significantly longer.

An additional consideration that may be relevant in scenarios involving external clients is the potential of unlocking future opportunities. Will addressing a minor issue quickly build the trust and loyalty from customers to drive bigger commitments?

With this information in hand, the engineering leader was able to get all the teams on the same page by focusing on impact. Data is great at driving consensus and setting urgency. If you believe an individual or team is misaligned, make effort to understand what is being prioritized over what you believe to be most urgent. Then quantify the impact between the conflicting priorities. An apples-to-apples comparison leads to clarity in stack-urgency.