[HN Gopher] How to Lead Your Team When the House Is on Fire
___________________________________________________________________
How to Lead Your Team When the House Is on Fire
Author : kiyanwang
Score : 86 points
Date : 2024-09-15 20:16 UTC (2 hours ago)
(HTM) web link (peterszasz.com)
(TXT) w3m dump (peterszasz.com)
| candiddevmike wrote:
| > 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.
| lumost wrote:
| on average, everyone will follow the path of maximum
| reward/lowest risk. Management has a job to do, but is aware
| that they may lack any choice or path to success. They still
| have a job to do in e.g. allocating engineers work, managing
| performance, promotions, and morale... so they do it, meanwhile
| they may also be looking for the exit.
|
| As an IC, never believe a manager at face value - they will
| promote you if it's good for them, they will pacify your
| concerns as it's what they are paid for, and they will fire you
| if its good for them. This is the nature of the relationship.
| Spivak wrote:
| Wild, I would literally never work for a company where I had
| this kind of relationship with my direct manager. My direct
| manager should be in my corner and on my side always. They
| will get me the highest pay, highest title, best perks,
| lowest amount of stress and work, most time off, best
| benefits they can and anything they ask me to do is in
| service of that. If I find out that my direct manager is the
| one gating a raise or promotion from me I'll just quit.
|
| I had one manager like this after an acquisition, he
| literally threw his head back laughing when I said I was up
| for a promotion and raise (documented prior to the
| acquisition) and said a number which was what everyone at
| $ex_company with that title made. He said no, and that he was
| the one who got to decide if I get a promotion-- I quit less
| than a month later for an actually good manger.
|
| They pay had better be incredible to make playing those kinds
| of political games worth having your soul drained.
| Simon_ORourke wrote:
| Absolutely this - management will do whatever it takes to help
| management get through whatever problem they currently have,
| and if that's outright lying to IC's, or stringing them along
| for a few months they will do that, and not even regret it for
| an instant.
|
| A really solid engineer I know was working with a failing
| mobile payments company, got an offer somewhere else and like a
| fool took it to his manager, who matched the new offer and the
| guy accepted... for 2 months until the company went bankrupt
| and he was back at square one looking for a job.
| talkingtab wrote:
| 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.
| Simon_ORourke wrote:
| > 1. Are you or others in immediate danger? If so, get out and
| help others get out.
|
| Wanting to help folks out is great, but if there's one role
| going in some related company, and there's a few on your team
| who are going to be out of work, then I don't think there's
| going to be too many advertising the job posting to others.
| ryanmcbride wrote:
| it's really common for people to form groups after a layoff
| to help each other get hired.
| johnea wrote:
| 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...
| TheAdamist wrote:
| I was hoping it was actually a treatise on leadership by a
| firefighter. But expecting it not to be.
| wrs wrote:
| 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.
| ddejohn wrote:
| The phrase "in the trenches" is used often, too. Always grosses
| me out.
| bitwize wrote:
| If you're 4th and 10, that's when you cut your losses and
| attempt to kick a field goal so you can at least score
| something before the ball changes hands. (My wife took me to a
| Saints game for my birthday, so I'm actually learning stuff
| about the game as she is actually played.)
|
| 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.
| willturman wrote:
| Those books about British science/engineering during WW2 sound
| interesting. Any recommendations?
| move-on-by wrote:
| I have an (actual) engineering buddy who occasionally has small
| fires flare up in the factory he works at. Ever since talking
| with him about it, I'm very much off put when someone at my
| cushy software company talks about 'a fire'. No, some system is
| down or throwing errors- there is no fire.
| Aeolun wrote:
| The executive reaction is the same as when a factory is on
| fire though. Whether we can't produce due to system down or
| due to hazardous environment makes little difference.
| giantg2 wrote:
| Most of what comes out of executives mouths is fantasy role
| play. It's always exaggerated to motivate.
| debacle wrote:
| > 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.
| herval wrote:
| > 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
| debacle wrote:
| 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.
| herval wrote:
| The code review process is quite literally "you need a
| stamp from anyone because of some regulations we follow".
| Definitely nothing thorough.
| XorNot wrote:
| The seriousness of any code review process can be
| determined by whether it diffuses liability from the
| original code author for any bugs.
|
| So far in my career this has never been the case.
| toast0 wrote:
| You can operate anyway you want if you have a printing press
| for money in the back. It's not a model to follow when you've
| got constraints.
| jajko wrote:
| > 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.
| halfcat wrote:
| 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.
| afro88 wrote:
| >> 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.
|
| 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.
| AdrianB1 wrote:
| The idea is that you should already have the decision in the
| right way, if you push more towards decentralization then you
| are already in the danger zone. Yes, you should not do that.
| drekipus wrote:
| 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?
| trhway wrote:
| At the top we have 2 management posts - this and MrBeast. One is
| very specific and another is typical management bs-bingo.
| dakiol wrote:
| 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.
| imetatroll wrote:
| Where do you work that you get to avoid agile, scrum, and war
| mode? I'm jealous. Then again I've always just been stuck
| working for startups my entire career. I have a family and
| desperately need something more stable.
| Aeolun wrote:
| Are BigCos any more stable in the US? At least in a startup
| they probably actually need _you_ because you already know
| their system.
|
| Overseas BigCo means permanent contracts and being very hard
| to let go, but that doesn't seem to be the case in the US
| (e.g. Elon Musk Twitter).
| benreesman wrote:
| 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.
| neilv wrote:
| > _" 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.
| 0xbadcafebee wrote:
| 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.
| getnormality wrote:
| > 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.
| neilv wrote:
| > _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_.
___________________________________________________________________
(page generated 2024-09-15 23:00 UTC)