And decision fatigue is a real thing. Even if the ice cream flavour/engineering decision is maybe not perfectly optimal, there's some value in not having to make the decision myself
I think the context is different if you’ve shown you care twice a day for a year before screwing up. Most people interpret messages in light of their experience of you.
If you don’t have that track record, the words probably have a different flavor.
> “I’m going to do X in 5 days if you don’t respond” gives you absolutely no recourse if you do something that can result in reprimand.
Surely you wouldn't use this for any action that could result in a reprimand?
"Unless we receive objections, we're dropping the domain $X on March 1st and switching to the domain $Y instead" is not something you'd do.
OTOH, "Unless we receive objections from you, we're proceeding with (the current mocked-up UI|the last discussed tech-stack|deployment date|refactor|)" is not going to result in a reprimand.
this is a silver bullet for something that needs to be done on a specific timeframe, otherwise it'll be bad. Since the "Boss x do not give approval for it" won't cut in as a reason, and boss x needs to know this before you're doing it.
Of course criticality matters. The more critical it is, the more required for you to do a more personal message with said boss, like slack, dms, up to meeting face to face for approval.
This is an important insight. While the "bias towards action" approach works for smaller things, larger efforts may require change management protocols that capture explicit approvals. In regulated industries, you may have no choice but to capture approvals in some official manner (with ink sometimes).
Of course condition and situation matters, as you've said in regulated industries. Be selfish, if you taking action will net you a worse outcome for you, better wait for approval.
Well, definitely don't phrase it exactly like that.
Most decisions that would be made in the context where this is a useful technique are irrelevant and/or obvious. They should be made by someone lower down the chain, but organizational dysfunction requires tricks like this to get anything done.
> About the only place where this works is violating some internal design decisions that are irrelevant to the business.
I don’t know why you feel the need to put “design” in there, but what you are describing seems like all rules governing how teams work together in any organization.
if it is possible to do anything that causes irreversible damage as a single engineer, then the fault for any damage is shared with whoever gave a single engineer that much power.
This strategy should only be used for things that are "required". i.e _not_ doing it will cause you / your team / division more harm than attempting but failing or running into issues.
The only other acceptable situation is for things that are low risk, high reward but can be important: like clean up, refactoring, whatever..
> if you do something that can result in reprimand.
If it's not obvious if your actions can result in a reprimand, then you can't do the thing, simple as that. Either you have the ownership and can take responsibility, or your boss needs to step up.
“I’m going to do X in 5 days if you don’t respond” gives you absolutely no recourse if you do something that can result in reprimand.
About the only place where this works is violating some internal design decisions that are irrelevant to the business.