Communication patterns for literate decision making

You’re already working through a stacked backlog when you hear, "We need this deliverable by Friday.” Words that can put a team on edge. So how should technical leaders handle them? In my estimation, when you get potentially disruptive requests, your job isn’t to say no - your job is to get the right things done in the best way possible. Managing ad hoc requests is a function of good decision making. By the end of this post, you should glean both the philosophy guiding this approach and practical tactics for applying it.

A literate decision is one in which the factors that inform the decision as well as the decision itself are appropriately communicated with the people who are responsible for carrying it out. Previously, I'd written about making literate decisions. This piece is about enabling literate decisions to be made - even when you aren't the final decision maker - particularly in the context of managing ad hoc requests.

Audience: Managers may get the most out of this post, but I imagine that this is useful to anyone who needs to influence decision makers…which is probably everyone at some point.

I'll start with the actual tactics I use for effective communication. From there, I'll get into the principles and experiences that have shaped my thinking.

Tactic 1A: Articulate conditions

❌: No, we can’t/won’t do X because of reasons R1-Rn ✅: In order for us to do X, things T1, T2,…and Tn would have to be true. Making those things true would have costs C1, C2...Cn. I {do/don't} think we should pay that cost because reasons R1...Rn. How do you want to proceed?

Tactic 1B: Articulate costs

No, we can't do X → No, we shouldn't do X because Y → Doing X would have cost/implication Y. I don't think we should do it because Y. Are we willing to accept those trade-offs?

Considerations

This approach assumes that you're operating in an ecosystem of good faith actors. It doesn't protect against Byzantine faults (situations where some actors may be acting maliciously or otherwise in bad faith). That's a separate playbook.
This is not in reference to unethical or immoral requests. In those cases, your job is to say no.

Decision Tree

Example

Receive potentially disruptive request: “Can you add {new feature} before the {product/campaign/test} launch in {uncomfortably close timeframe}”?

Get curious, ask questions: “What are the implications of launching with the feature vs adding it post-launch? Would the experience be so much better/worse without it that it affects what we are trying to learn? What’s driving that hypothesis?”
Calculate costs and trade-offs: “We wouldn’t be able to get this in before launch without pulling {Data/Backend/Web/etc} Engineers from {planned work}. Is this more critical to success than {planned work}?”
Form opinion, enable literate decision: The options might range from maintaining current course, to swapping {planned work} for {new feature} to doing both on the same timeline. What I might recommend is context-dependent, but I might convey something along the lines of, “I don't think we should pay the context-switching costs right now because it risks delaying launch (feature has a highly variable estimate).” Would you like to add this to the top of the backlog, or should we reprioritize our current work?”

Guiding principle

💡

When a team is sufficiently skilled, communication becomes the leading factor in success or failure.

Context

Over the years, I’ve heard several EMs and PMs proclaim, “my job is to say no”. Now, I know that no one means this literally and it's meant to be tongue-in-cheek. But still, I’ve always found that strange at best and concerning at worst. I get it, you need to protect your team’s ability to focus in order to be effective. Constantly shuffling priorities before work is able to be completed, i.e. thrashing, is ineffective.

Your job is to get the right things done in the best way possible.

Sometimes, you are the best equipped with knowledge of the right thing or best way. In those cases, unexpected requests illustrate the need to convey that information and provide an opportunity to do so. A blanket "no" doesn't arm people with enough information to know if they agree or not.

Sometimes your view is outdated or you are missing new or critical context. A blanket "no" puts you at risk of a needless power struggle or of being a barrier to progress. Sometimes a mid-flight pivot, as frustrating/disruptive/wasteful as though they may be, is the right thing.

How can you tell if you are avoiding sunk cost fallacy (good pivot) vs thrashing (bad pivot)? By approaching with curiosity. Always. If you're missing the critical mass of information that allows you to distinguish between good and bad tactics, ask. Those questions may themselves shape the outcome.

Conclusion

When it comes to top-down and even lateral requests, unilateral “no”s are not always an option. And even when they are, they aren't necessarily the best way to get the best work done. Instead, I find it best to articulate the costs and trade-offs on a decision, have an informed opinion on whether those costs are worth it, and deliver on the final decision - whatever it may be. When this works well, stakeholders become partners as common goals and challenges become mutually understood.

By communicating trade-offs and constraints, people are more likely to feel heard, supported, and, most importantly empowered to deliver on decisions that benefit the whole even if they are inconvenienced individually.

Your job isn’t (usually) to say no: literate decision making for unexpected demands