How to Lead Your Team When the House Is on Fire

This entire blog post assumes agency that you, the EM or Team lead, rarely have in an organisation that is on a "wartime" footing. It's cosplay.

Real wartime footing:

1. Direction and technical decisions are driven by priorities of board-level members and often arrive in email form late on Friday evening. The entire organisation is expected to pivot immediately. A new senior leadership team member starts scheduling daily read-outs on project progress, and half the organisation spends the weekend frantically hallucinating project plans into Google Sheets.

2. Engineering staff react with dull-eyed disbelief on Monday; they knew this was coming, because the same thing happened a month ago, and six weeks before that.

3. Emails come from HR that there are are new, even-more-labyrinthine approval processes for expenses, and shrinking budgets for anything not directly related to whatever the projet du jour, which will be fed enough to make it look like it's succeeding until the next Friday evening email kills it.

4. There is wide-spread burn-out across Engineering teams, and people are reduced to reactive, sarcastic automatons.

5. A creeping understanding seizes the better engineers that things cannot improve; they sign articles of Armistice, pretend to comply, and start interviewing elsewhere.

6. An email arrives on Friday night...

> Focus on the positive aspects of the job that can be taken for granted, like the opportunity to work on cutting-edge challenges, the company's still existing perks and benefits, the amazing team you have, the chance to work with a modern tech stack, or how your product is helping its users. Showing your team how you appreciate what's still good can help with morale.

If HN supported gifs, there'd be several in this spot.

It all feels like theatre. Been working in many companies in “war mode” and they all think that in order to become profitable (none of them were) you need to push the most “important” features out of the door asap, otherwise your competitors will eat you alive.

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.

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 normally hate sports metaphors, but as an alternative to war, framing a tough business situation as “fourth down and 10” or whatever is a lot healthier way to think about it.

Speaking as an engineering manager, this is wish-fulfillment. According to his own LinkedIn, the author has never been a first-level engineering manager. His blog is accordingly heavy on cliches and mostly free of actual work experience.

Taken at face value, the article is a recipe for burning out first-level managers, while the building is burning down. It neglects to focus on stopping the fire, because the author would rather his reports hustle around the fire instead.

I think leading in "wartime" is way easier than leading in peacetime. When you are in full panic mode with a clear goal, a lot of decisions are very clear and easy to make. And everybody knows you can't scrutinize every little thing. You take a risk and see if it works out.

In peacetime you have more time, goals are not that clear. So a lot of people suddenly have different opinions and they must somehow be negotiated. There is a huge risk of a bureaucracy to de developing that can't be constrained.

It's the same in politics. Wartime leaders like Churchill get a lot of credit but I think it's much harder to keep things running halfways efficiently when things are going well.

In my opinion there is a strong disconnect between the title and the advice. If in fact your house is on fire, there is a decision tree you can follow that goes something like this.

1. Are you or others in immediate danger? If so, get out and help others get out.

2. If not, then determine if someone addressing the fire. One would expect that higher ups are aware of the fire, but this is not always the case. Sometimes the higher ups are not aware. Sometimes they are too busy saving themselves to address the fire.

3. If someone is addressing the fire is there a way you can assist?

I do not mean to be snarky in this- there are real people who work for real companies that are not doing well. If you are a manager, your team's well being should be high on your list.

> 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 is...more awful advice. My startup has gone through COVID and the financial slowdown and the only reason we've succeeded is because we never stop measuring.

The very next paragraph after "decentralize everything and communicate heavily" is "allow your team to focus and centralize administrative duties."

And the the NEXT paragraph is "work closely with your team and even write some code."

This entire blog post is all over the place. It reads like each paragraph was written by a different person with completely different experiences.

If you want to manage your team while the house is on fire, don't change anything. Communicate clearly, ensure that the culture and philosophy of the team bend when necessary but don't break, and work on alleviating the real problem. One of: lack of product market fit, burning cash like it's going out of style, or no clear path to profitability or the next raise.

Your engineering team is probably not the problem if your startup is failing.

Wartime software is a disaster unless you mean it, and should be treated with extreme caution even if you do.

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.

The "Wartime Software" concept is bogus, and this article casually tosses out that you should have a high-performing team, which companies spend years trying to achieve and still not doing it.

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.

Never a bad time to remind yourself of what is at stake in a literal war, versus a company in survival mode.

Literal war: Many human lives - both combatant and non-combatant - and the future prosperity or collapse of all societies involved

Company in survival mode: for most employees, their income level this year.

Describing the operation of a software business as "Wartime" is nonsense.

When the house is on fire, you lead people OUT OF THE HOUSE.

Then you get help.

Then, if you can do it without putting yourself back in danger, you look for opportunities to help out.

If you don't know this, you failed childhood.

Now, on to the metaphor: emergencies don't last forever. If your emergency is lasting indefinitely, it's not an emergency and the house is not on fire. It is quite possible that you are being manipulated. If emergencies keep happening, senior management has a big problem, and it's up to them to fix it.

I've been leading a small, bootstrapped startup for the last four years. The team is a lot smaller these days than we were before. But we're not dead yet and I still enjoy working on our product. Things are actually looking pretty good at this point and we have some perspective on revenue growth and even team growth. Being bootstrapped means we can set our own pace.

The thing with fire fighting is that you 1) need to recognize that you are doing it. 2) put a stop to it.

Firefighting simply doesn't work. You have a 100 fires to put out and you put out 1 or 2. The house will still burn down. And you will be too stressed to do a good job at what little you are still actually doing. So you'll cause a few more fires in the process. Firefighting leads to more fire fighting. Also the constant context switching actually means you are less productive.

In terms of people management (including yourself), fire fighting is not sustainable for very long. It just makes people miserable, stresses them out, and eventually they leave, get burned out, etc. And that includes yourself. You have a breaking point and you want to stay on the right side of it. In my case, if I step out the company dies. It's that simple. So, I use my weekends to recover, not to work my ass off. Coming in well rested on Monday is more important than getting whatever done on a Sunday.

So, take the tough decisions you need to make (who gets to stay, which things to cut, etc.) and then stabilize at whatever level is sustainable. De-prioritize the things that won't get done anyway. Stop pretending that you are even doing them. Ruthlessly prioritize what needs doing and filter that list by do-ability and then by available resources and then by short term priority.

Smaller teams mean things actually get easier. Less need for meetings, less conflicts, etc. I'd run this thing differently if I had a ten person team. But I just don't. So a lot of management is just me freeing up time so I can actually do things myself.

> One major pitfall to avoid is letting an "us vs. them" mentality take hold on the team. Naturally, the stress of painful decisions can erode trust in leadership and other departments, but reinforcing a negative mindset will hurt you more than the temporary warm camaraderie you'll enjoy by joining the chorus of cynics.

Then proceeds to encourage managers to gaslight folks into believing leadership is fine in the next paragraph.

In my experience, during this "wartime" the author discusses, management knows the ship may be sinking/is sinking and are making their way towards the lifeboats. They still need to be seen as doing something though, so they string along the ICs hoping they can keep being "productive" even though management is completely checked out, and a lot of the ICs will be laid off or not survive the upcoming aquihire/turn down.

> For EMs, wartime means leading low-morale teams through ambiguity, hard constraints, frequently changing goals, and intense pressure to perform.

Why the assumption that goals are frequently changing? If you're making something that's actually valuable and not just looking good by surfing trends, I would think that the virtue would lie in having a clear vision and sticking to it.

At the top we have 2 management posts - this and MrBeast. One is very specific and another is typical management bs-bingo.

> Identify on-the-job learning opportunities, like giving someone the chance to lead an incident response or a high-visibility project. Critical mistakes can still be catastrophic, but because of the fast-changing nature of wartime work, it's easier to process smaller errors with a healthy learning mindset.

I don't understand how wartime makes this easier.

Pre-wartime, you could've also had short-turnaround tasks, and the realities of generous funding of nonviable businesses mean you'd have more luxury to rollback dropped balls.

Seems like wartime means that you have to be more responsive and successfully.

That actually reminds me of a great story, for when I had to do exactly what the title is suggesting.. back when I worked at Amazon as a software engineer, the CRAZIEST thing happened to me. Here’s the story… I was working from home with my girlfriend (at the time), when suddenly I get an urgent ping from my coworker: “Our service is experiencing a SEV 2! We need all hands on deck!” Uh oh, our team’s application has gone down! However, as I scrambled to figure out how to fix the issue, I smelled something burning from another room and heard a fire alarm go off. “Will! There’s a fire! Help!” I heard my girlfriend shout. Now I was stuck in a conundrum — restore a critical Amazon service, or put out the fire in my apartment? It was at that time I remembered Amazon’s famous leadership principle “Customer Obsession”. There are customers who depend on my team’s application — I can’t let them down! So I ignored the fire and my girlfriend’s pleas, and started debugging the production issue. But all of a sudden, the smoke in my apartment cleared and the fire alarm fell silent. My girlfriend walked into the room, and to my astonishment, peeled off a wig and revealed herself to be Jeff Bezos himself! “I’m proud of you for being obsessed with our customers,” he said, and gave me a $5 Amazon gift card. He then leaped out of my window and hopped into a waiting Amazon Prime delivery van that quickly peeled away. Even though I no longer work at Amazon, I’m so grateful for these experiences that taught me lessons I’ll never forget. Agree?

I think the main issue is consolidation in many industries. Companies get big and keep getting richer and bigger. They gobble up smaller companies to grow and often competitors too. They milk the industries dry and stiffle innovation. You get these poor run and bloated organizations as a result.

As a leader, your ability to stay calm is a fundamental one! It can directly impacts your team's confidence and effectiveness. By remaining steady, you set a tone of control and clarity that can help guide your team through chaos.

Funny because the last place I worked it was as if senior management were playing The Roof Is On Fire song non-stop through everybody's speakers. You know the song, "We don't need no water, let the MFer burn!"

Building businesses out of debt, starting with negative balance and when approaching out of money, asking employees for a last minute war time mode. That’s plain terrible business practice, don’t work there.

Simple: tell them to follow the fire exit signs.

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

No thanks? If the company is downtrending, and I as an engineer see options available... without a clear path of moving up and forward in the current company, I'll be looking. That's it. Objectively its the best thing to do as an individual, and we all know no company shows loyalty anymore. Your job is always one penny pincher away from being cut or shipped off to a low cost employment center, e.g. India.

Except the point around forgetting some of the long term improvement projects the rest are true anytime.

Why can't these wartime analogies go away? You're building just another CRUD. Nothing is at stake. Stop pretending you're a warrior. You're not. It's just pathetic.

> "Perfection is the enemy of done" [...] It's important to note that these wartime actions will probably increase tech debt in your code. With the emphasis on velocity over quality, architectural compromises and maintenance shortcuts are often taken.

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.

If you're building drones in Ukraine, you're in war mode.

If your business required zero interest rates, you're not in war mode. You're in stupid mode. It was never a successful business. (See WeWork, etc.) Get out.