21–30 of 214 posts
I have a shelf full of histories of British science and engineering during WW2, so I feel like I have some remote idea of what being an engineer in an actual “wartime mode” is like. Think about, e.g., working in the lab trying to improve radar to be able to stop the daily bombing raids. It’s hard to imagine “wartime mode” as being an appropriate metaphor for any US company, other than as a sort of fantasy role play.…
I have a shelf full of histories of British science and engineering during WW2, so I feel like I have some remote idea of what being an engineer in an actual “wartime mode” is like. Think about, e.g., working in the lab trying to improve radar to be able to stop the daily bombing raids. It’s hard to imagine “wartime mode” as being an appropriate metaphor for any US company, other than as a sort of fantasy role play.…
It’s a lie. Executives and VPs and all those folks that earn 5x what a normal engineer earns, don’t really care about the company they work for. All they care about is to keep receiving the big pay checks until the ship sinks. Obviously you cannot just mandate “normal mode”, otherwise it wouldn’t look as if everyone is doing their best to keep the company afloat.
I hope in 10 years or so, we’ll see “wartime software engineering” with the same eyes we see today Agile and Scrum masters: snake oil.
Wartime is an in house propaganda shop running posters that say Carthago Delenda Est, mid-level product managers discreetly but reliably dispensing Adderal, Ritalin, and Modafinil, open disdain for people who leave the office two days in a row, and paying enough that your people are just in a meaningful sense smarter than anyone else.
Every company gets to pull that maybe once, so it has to count. And it’s a hell of a place and time to see.
But if you’re not going the whole way, you’re far better off doing reliably good engineering in a repeatable way and poorly served by analogies to war.
Pull the fire alarm and evacuate the building? Or, just stop using over-bloviated metaphors for first world marketing creating fictional scheduling crises. Not making you dev schedule is not a "fire", much less a "war". Maybe try getting outside once in awhile and clearing your head of this make believe bullshit...
> Decentralize decision-making authority as much as possible. Remove barriers in their way, slash approval layers, attack dependencies. This is awful advice. You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github. > Bias heavily toward action - it's better to decide and be wrong sometimes than to paralyze the team with analysis. This…
If that happens, you decentralised more than was possible ("as much as possible" doesn't mean "completely"). You removed too many important barriers. A bit more concretely, you gave authority to those that weren't capable of handling it, or weren't supported properly. You removed an approval layer without supporting your team to check these things for themselves.
I have a shelf full of histories of British science and engineering during WW2, so I feel like I have some remote idea of what being an engineer in an actual “wartime mode” is like. Think about, e.g., working in the lab trying to improve radar to be able to stop the daily bombing raids. It’s hard to imagine “wartime mode” as being an appropriate metaphor for any US company, other than as a sort of fantasy role play.…
I guess the equivalent in a software shop would be adjust expectations way lower and focus on what's achievable without running the team ragged and risking getting nothing done, postponing loftier goals until the team/business is in a better position to address them.
All those years of ZIRP investment scams, and sprint theatre, the industry generally wasn't doing "quality" (and, on average, wasn't capable of quality), so we were already posturing about "getting it done"...
Don't you need to tell a lot of people something *different* than before?
Maybe, when you have to deliver and can't afford huge mess-ups and delays and inefficient boondoggles, and people can't job-hop fast enough to escape their roosting chickens, what you actually need is *smart, aligned people*?
Not to give people permission to flail around incompetently, and make huge messes, pretty much just like before, but now rationalize it as "Getting It Done: Wartime Edition".
> [...] due to the current job market you have more luxury now than a few years ago. Consider allowing 2-3 candidates to pass through all rounds, and choose the best fit from them.
If that's what you need to hire smart, aligned people, then OK.
If it's just most of the same techbro flakiness, now dressed up as "Wartime", then not OK.
How do you lead your team when the house is on fire? However the hell you can. I'm sure a firefighter can chime in here and tell you that if you aren't trained for firefighting, you sure as hell won't learn how to do it right when the roof is caving in on you.
> Decentralize decision-making authority as much as possible. Remove barriers in their way, slash approval layers, attack dependencies. This is awful advice. You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github. > Bias heavily toward action - it's better to decide and be wrong sometimes than to paralyze the team with analysis. This…
> You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github FB is operating that way with tens of thousands of engineers. More approval layers don’t necessarily mean more order, but it always means slower processes