It’s really about (a) the wording (b) the level of risk.

For something that isn’t risky, I trust my reports to make reasonable decisions and wouldn’t benefit from the “I’m going to do this tomorrow unless you say no” approach. Instead, they can just tell me they’re doing it (or let me know after the fact, or add/FYI me on the code review, or not even mention it, depending on what it is).

For a decision that is more important/higher risk, they should get affirmative agreement rather than just hoping that I see the ultimatum and silently approve.

That’s why I’m with the GP that the ultimatum-with-deadline doesn’t seem like the best choice in any situation.

Thanks for the feedback. I guess I'd put the 'ultimatum-with-deadline' in between the two risk profiles you outline--something just on the edge of risk.

> Just hoping that I see the ultimatum and silently approve.

I never would have thought of this as an ultimatum--to me it's more like a 'default decision' that makes my manager's life easier while still looping them in and giving them control should they choose to exercise it.

But now I can definitely see how it might be seen as one, depending on the type of decision and the relationship between employee and manager. I should probably update the post to say that you need a degree of trust and alignment for this technique to work; you shouldn't roll this out on the first day.

The advice refers to situations where you, the report, are both able and (well-informedly) willing to take full responsibility. "Ability" here means that, if your decision backfires, you can revert it, and/or contain the damage otherwise. Otherwise, you may be willing to take responsibility, but are unable to. In other words, this piece of advice applies to things that are ultimately under your control.

The background is that, even when something is (mostly) in your control, you may be tempted to ask for permission, in advance, just to distribute the responsibility to others (shift the blame, cover your ass). That delays things, and usually the manager will sense that they got burdened with the request-for-permission somewhat needlessly. In those cases, it's better to take initiative, and be accountable later on, because the latter is in your power, in the end.

(Of course, if you and your manager have dedicated time slots anyway, then bringing the topic up is prudent, as it will not require them to scramble for otherwise unallocated time.)

Conversely, if containing the potential damage is indeed not in your power, then you shouldn't go ahead without explicit permission. For things where you simply can't bear responsibility, a timeout from the approver is not a default "yes", but a default "no". If you can't bear responsibility, then you need explicit signoff from someone higher up that, should shit hit the fan, they will bear responsibility on your behalf -- and so a timeout is meaningless (it doesn't give you what you responsibly need).

Whenever you can afford to interpret a timeout whichever way you want, then you don't need to ask the question in the first place (--> don't ask for permission, just revert/contain the damage, if needed). Otherwise (--> the potential damage is beyond you), you need an explicit "yes" (which is the only case when you're off the hook).

The problem with your suggestion is that it assumes that you, as a report, are in a position to set deadlines for your superior(s); in other words, to allocate their time and priorities. Usually the exact opposite is true (by contract): it's your manager who sets your priorities. You can consider their (repeated?) failure to respond timely a true failure, but that doesn't give you the right to do whatever you want; it would be in bad faith / a form of vigilantism. Your option is to leave that manager.