[dead]
How to Lead Your Team When the House Is on Fire
11–20 of 214 posts
Re: How to Lead Your Team When the House Is on Fire
#12> 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.
Re: How to Lead Your Team When the House Is on Fire
#13> 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
Re: How to Lead Your Team When the House Is on Fire
#14That 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?
Re: How to Lead Your Team When the House Is on Fire
#15> 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
Facebook has a very thorough code review process, and their product is heavily data driven. They've even productized their code review process internally, and that product is also data driven.
Re: How to Lead Your Team When the House Is on Fire
#16> 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
While article is named "How to Lead Your Team When the House Is on Fire" - if your business is constantly on fire you are doing something terribly wrong, I don't think you understood the main points.
Re: How to Lead Your Team When the House Is on Fire
#17At the top we have 2 management posts - this and MrBeast. One is very specific and another is typical management bs-bingo.
Re: How to Lead Your Team When the House Is on Fire
#18Earlier quoted context omitted.
> 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
Facebook has a very thorough code review process, and their product is heavily data driven. They've even productized their code review process internally, and that product is also data driven.
The code review process is quite literally “you need a stamp from anyone because of some regulations we follow”. Definitely nothing thorough.
Re: How to Lead Your Team When the House Is on Fire
#19[dead]
Re: How to Lead Your Team When the House Is on Fire
#20> 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…
All the advice is very similar to the leadership advice that comes out of military special forces, like decentralized command, prioritize and execute, cover and move, and so on.
With the point being, if all of your team members are elite, then everyone ’yeeting into main’ can be wildly productive. But it’s not good general advice, as you say, where most organizations have a range of talent.