The Hidden Tax of Saying Yes

Insight from Asana

Last week, my friend Tom called me, exhausted. "Remember that 'quick partnership' I mentioned? Three months in, and we've spent more time wrestling with compliance docs than writing actual code."

Unsurprisingly, I’ve faced the same problem as Tom.

In my last role as COO, I watched a "straightforward" product launch morph into a six-month odyssey.

After close to a decade in operations, you’d think that I’d have developed a sixth sense for these seemingly innocent requests that turn into organizational quicksand. But that’s not true! Turns out that relying simply on intuition is a recipe for disaster.

So I started an experiment. Every "yes" that I thought would trigger a cascade of unexpected decisions, I’d create a decision tree.

Not the neat ones you see in strategy presentations, but the messy, real-world kind where every branch spawns three more problems to solve.

Take manufacturing, for instance. "Should we build in-house or outsource?" sounds simple enough. But pull that thread, and suddenly you're facing an avalanche of questions:

• Where do we find specialized talent?

• How long is training?

• What happens if they leave?

• Who manages vendor relationships?

• How do we handle quality control?

• What's our backup plan when everything inevitably goes sideways?

Let me show you how these deceptive "quick yeses" play out in reality.

Our finance team once approached me about switching payment processors, excited about saving 2% per transaction. When we mapped out the decision tree, the true cost emerged:

• six months of engineering resources we didn't have

• three weeks of customer service retraining we couldn't spare

• a three-year contract with exit fees that made my palms sweat

So how do you map these decisions effectively?

When I'm staring at a whiteboard now, I start with three columns:

• What could go wrong (and how much it'll cost)

• What we need to pull this off (the real resource list, not the sanitized one)

• Where we hit the point of no return (because timing matters)

For the payment processor example, our "what could go wrong" list included integration bugs during Black Friday, support queues hitting four hours, and engineers struggling with legacy code - each carrying real costs in dollars, time, and team morale.

But here's the thing - sometimes mapping it all out shows you a better way forward. Maybe you phase the rollout instead of doing it all at once. Maybe you negotiate better terms. Or maybe you realize this isn't the right battle to fight right now.

The best operators I know don't just check for obvious risks. They ask the uncomfortable questions:

• What happens if our assumptions are wrong?

• What's our escape hatch if this goes sideways?

• Which team is going to eat the hidden costs we haven't spotted yet?

And if someone gives you grief about being too cautious? Show them the graveyard of "simple projects" that turned into organizational death marches.

We've all got those stories.