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.

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.

Have been doing all my life and it has never backfired.

It’s not about breaking rules. It’s that I already know what you want.

If I buy you ice cream without asking you for the flavor, it’s because I already know what you want because I pay attention to you.

And it doesn’t matter when I get it wrong because you appreciated the 500 other times I cared about you.

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

For sure - actions before words and all that.

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.

Again, you’re just doing it for things that aren’t real rules.

Try:

- Intentionally violating a safety protocol in a hardware lab

- taking company property for yourself

- stealing from a vendor

- sexually harassing your direct reports

What this thread seems to be talking about is violating soft process norms.

> “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.

> 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.

> the rules you’re breaking are completely irrelevant.

This isn't for breaking rules. And definitely not for breaking ones that say "explicit approval needed".

Teamwork is complex and most of it is not covered by rules. If you are too biased towards asking vs just doing you get stuck.

> 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.

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..