Oh man. This is one of those things that's great when done well and terrible when done poorly. Miss the head-up memo until the following day? Too late, the author's already a day into the work and you'd be a jerk to make them back all that out. If it happens often, you have to constantly monitor communication channels or risk missing an important "heads-up," since that's how serious decisions are being made now. In the middle of your own work, but see a 10-page design doc go by in slack or email? Better drop everything and read it well enough to form an opinion because every minute that goes by it becomes harder to object to that change.

But, as you say, it can be a great way to overcome bikeshedding. It's a good way to speed up a ponderous decision-making culture. It works.

Like a lot of organizational tricks, the line between use and abuse is something that simply requires judgement.

I've actually seen this go pathologically bad. Heads-up emails, sent out 14, 7, and 1 day in advance. Similar set of Slack messages.

Somehow literally nobody has noticed until the change lands, at which point everyone has an opinion.

We used to have an engineer who used this maneuver. He abused it because it was effective. We do have an issue on our team with engineers being indifferent to new ideas, and our manager loves consensus. Regardless, this engineer thought his ideas were always "good ideas." They weren't. He was eventually chewed out by our manager because he was becoming a passive-aggressive tyrant. He left the company soon after that.

Nevertheless it goes to show that fortune does favor the bold, but that fortune might be at another company.

The challenge, as with many things in life, is to strike a good balance. In this case between being bold and being a good team player at the same time.

What I have tried to do in the past is:

1) Take an idea out to a "proof of concept" stage, whether that is a white paper or an actual functioning demo but no further. People often need to see something, not just hear it.

2) Have a cosponsor or two to work with you. At first you may think that you are not getting full credit for your idea but I believe it shows more leadership than just striking out on your own. Plus you don't want your team to despise you like that aforementioned engineer.

3) Be humble, solicit feedback, and really listen to it!

Just because you use this tactic doesn't mean it will work. Just like anything, you have to have the talent and skill to pull it off. But if you trust your abilities and judgment, it's very effective.

I second the your conclusion and GP's. "Flat" / "self-organizing" / etc. teams seam prone to different, not fewer, pathologies than teams with explicit hierarchies.

I suspect that the two approaches are vulnerable to different, but specific, mixes of personalities.

Another way to put this is "bias for action"