How to Lead Your Team When the House Is on Fire

These things have merit, but increasingly less the more you move away from "whole" plans in which they make sense. These particular ones are troublesome because they fall closer on the spectrum to "reduce executives". If you're pushing decision-making downstream, it should also be reduced upstream. If you reduce it upstream, you have less (not zero) need for leadership there. That has to manifest either in fewer leaders or leaders doing a better job at their other duties. In particular, they need to be producing much clearer stronger vision for the downstream folks to align their decisions to. Vision is perhaps the hardest task in the org and when it's hard it's easy to shirk on. Often, when leaders talk about trying to move to a bottom up culture, they are (unconsciously?) trying to absolve themselves of the vision work. And they're usually doing it while still gatekeeping information and resources they were meant to have because they were decision makers.

This is going too far, but directionally: Leaders should largely not be advocating for delegation and bottom up decision-making. It's not that this can't be better for the company, it's that they could be executing the goal better by quitting or firing their peers. It's more of a catch-22/worst of both worlds situation—leaders shouldn't be advocating for it because they shouldn't be there to advocate for it.

In particular, Scrum is only there to establish rituals that enable empiricism in decision making. A sprint is a reporting period to keep the team from spending too much time in the weeds. A standup is there to keep the team working together. The andon cord (which is often missing I find) is there when the facts have changed so utterly profoundly that everyone needs to regroup.

Anyone who's been through RTC ("boot camp"), and even some who haven't but have lived vicariously through others, understand that being constantly yelled at by RDCs ("drill instructors") on how you make your racks and fold your clothes is all about building certain habits and only tenuously related to what you'll be doing after A-school. It all has more to do with building trust that the rest of the folks in your ship will help carry you when the going gets tough. Scrum, at its core, is kinda like that.

I really dislike the term "Scrum Master." They're a team captain. The more military-minded might be keener to use "gunnery sergeant" or "chief petty officer:" they're just the most senior person in the rating group^W^W^W^Won the team. (Though, I'd probably take more inspiration from the Marines than the Navy here: a culture of servant leadership seems to bring out the best in people.)

The most popular implementations of Scrum tend to come with a ridiculous amount of meeting and tool baggage, and it's so unnecessary.

Use Excel. Hold your standups at the close of the day so people can go home. Write your product backlog items in delivery order so that sprint planning is less about sitting in one room playing poker and more about just getting valuable shit done.

That said, what isn't unnecessary, however, is kneecapping command a little: the engineering officer of the watch has comparatively little understanding of the actual operation of the machine. They just know that they want operational excellence. However, that excellence also sometimes comes with the watch supervisor—a subordinate—publicly calling out mistakes that the watch officer makes.