Live data from Hacker News

How to Lead Your Team When the House Is on Fire

peterszasz.com

161–170 of 214 posts

Re: How to Lead Your Team When the House Is on Fire

#161

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 d…

This is painfully accurate. I'm not sure how companies fall prey to these problems, but they seem to be incredibly hierarchical. What I means specifically is that the lower level employees and mid-level managers seem almost rabid to praise, cater to, and and be swept up by the useless whims of nearly anyone in the executive suite. It's sickening, and not because of the impacts on work. Why do so many grown adults act…

I mean, I think there are a lot of motivations for people who behave this way, but one of the core ones is less a matter of servitude or slavering desire to satisfy upper management and a lot more a result of the kind of language this article uses.

People want to believe the things that they do matter and are often willing to gussy up their jobs to make their contributions feel important, to make themselves feel important, to feel like the world needs them. It's the same thing that motivates mall security guards to dress up in tactical outfits. "If I spend all my time doing this thing that doesn't matter and isn't super important, then I don't matter, and I'm not super important." They convince themselves that whatever this current thing is Truly Does Matter, and then are willing to run themselves into the ground to prove the point that they contributed to the thing that matters.

I see the sort of self-aggrandizing "identifying as your job" behavior that leads to this mindset in software more than a lot of other jobs. People get into software and their personality becomes "I'm a software engineer" or "I'm a coder." They're better than the average - they're a highly-compensated expert who understands concepts like "UX" and "Architecture" and "Infrastructure" and they are going to run a Beta Test and Have To Stay Late To Deploy The New Version. They have an Important Deadline! The things they are doing Matter. I think lots of people in software had this idealized image of themselves as a core contributor to a product that's broadly loved and people care about and are unwilling to accept that they are toiling away to marginally reduce the time to first meaningful paint on yet another shopping cart page which only a few people use because the company they work for is niche, not particularly innovative, and not interesting.

I don't think a lot of people are doing this for the promotion - I think they're doing it for the validation. So they can believe that what they do actually matters. The sad reality is that 95% of software is bad and uninteresting and the people working on it are mashing together lego pieces to re-solve completely solved problems for management that doesn't get what they're doing and customers who don't like their work, and the desire to create importance where there isn't any is a self-defense mechanism more than anything.

Breaking out of this mindset was a key development in my career and I've not seen any less success but I am substantially more happy.

Re: How to Lead Your Team When the House Is on Fire

#162
post #88

Earlier quoted context omitted.

I'm also an engineering manager, currently working in a department that feels on fire, and I think there is good wisdom in the article. The part about not fostering a "us vs them" mentality was good food for thought, as I do find it tempting to build short term camaraderie. When faced with big picture issues that can't be changed (believe me, they can't) it's easy to reach for a "We all know that these exec decisions…

There is a middle around between seeking camaraderie by total bad-mouthing of the executives and singing praises of the management while wagging your tail vigorously. From the article: > When you receive a new headcount, you need to prioritize hiring experienced, self-sufficient, autonomous engineers who can tolerate (even better, strive) in high-stress environments and are experienced enough to contribute immediatel…

I think both things are true. If you're on the struggle bus then you should prioritise self-sufficiency in the hiring process (as the post suggests) and be honest about what people are walking into (as you kind of suggest). But I think no amount of honesty will help if you hire someone who needs some amount of hand-holding when your team doesn't have the bandwidth to provide it.

Seems obvious - don't hire people when you can't give them what they need to succeed in-role. But I think the blog author wasn't trying to say much more than that with the sentence you quoted.

Re: How to Lead Your Team When the House Is on Fire

#163

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 w…

> It neglects to focus on stopping the fire,

This can get pretty tricky when the fire is your very boss... (and honestly, been there and didn't know how to handle that, and still don't know (top management did, they fired my boss, but I burnt out before..)))))

Re: How to Lead Your Team When the House Is on Fire

#164
post #79
post #23

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…

It's easy to validate the veracity of 'War mode'. If survival hinges on a critical deliverable, then the promised reward must be in line with the stakes. You can't have an employer offering a 20% bonus for keeping them alive. It's an insultingly low payoff or the crisis was a lie. There is definitely such a thing as wartime software engineering. But such moments offer a clear path to millions of dollars or generation…

That is like young media professionals who think being stressed is a badge of honor that shows how important they are.

As a freelancer I had to interact with these people and was constantly annoyed by their lack of efficient communications. If you are a freelancer your own time is actually valuable to you, wasting time is not a luxury you might be willing and/or able to afford, depending on your agreement.

If your company/project is constantly in emergency mode you should reconsider the quality of that companies/projects managment. Personally most companies/projects where I have wittnessed emergency mode the emergency was not only self-inflicted by mismanagment, it was also routinely self-inflicted.

If your emergencies could have been avoided by a thin veneer of foresight that emergency is on you. If you routinely get into emergencies without learning: congrats you're stupid.

If you conjour emergencies out of thin air to squeeze more work out of your employees you suck as a human beings.

If you think working under emergency mode makes for quicker, cheaper or more reliable results you probably never witnessed how quick, cheap and reliable a well planned project can be finished.

Re: How to Lead Your Team When the House Is on Fire

#165

Earlier quoted context omitted.

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.

You're definitely not in mortal danger as a SWE, but FWIW, I've witnessed (2nd hand) datacenter servers literally catch on fire and entire datacenters go out because a critter got crispified on some power lines. Sometimes "the server's on fire" is metaphorical and sometimes it's literal. In the latter case, at least you can get some interesting pictures of the aftermath.

Yeah we've had to evacuate the office several times because our in-house "lab" DC started smoking.

Re: How to Lead Your Team When the House Is on Fire

#166

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 d…

Obviously, this all follows from Putt's Law [0].

"Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand."

[0] https://en.wikipedia.org/wiki/Putt's_Law_and_the_Successful_...

Re: How to Lead Your Team When the House Is on Fire

#167

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 d…

Is there a German word for the feeling you get where you want the opportunity to apply a hard-won skill, but also kind of don't? I feel that reading this all-too-accurate comment. Like many/most of us, I've been through this, but by virtue of luck and experience, haven't in a while. I think I've learned to spot the symptoms early enough that I avoid the companies/teams/projects that are on that path. For those who th…

I propose Prepper's Paradox. I was even able to dig up an existing usage https://www.reddit.com/r/preppers/comments/1domhjt/the_dooms...

Re: How to Lead Your Team When the House Is on Fire

#168

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 d…

[deleted]

Re: How to Lead Your Team When the House Is on Fire

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

Re: How to Lead Your Team When the House Is on Fire

#170

Earlier quoted context omitted.

Can you provide me an actual way to practice these things? Like, specific, exacting ways to execute each of these? Or any of these? Because they don't make any sense. "Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack? "Value working software over comprehensive documentation". So, never write documentation? And how do you de…

> “Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack? Stand up. Walk out of office. Get on train. Arrive at user’s office. Go sit next to user. Spend afternoon understanding how they use the software you are supposed to be building. Bin the sprint planning, retros, gantt charts, standup and whatever fucking sprint poker is.…

  >> So, never write documentation?
  >
  > Read the phrase again, with a slightly different word in place
I spent way too many years working at an Agile shop that had been doing Agile for a very long time. (This is me saying "This place definitely wasn't Doing Agile Wrong.".)

At that place, "Prefer working software over comprehensive documentation" ended up actually meaning "Do not write documentation. Go speak verbally to the SME for that thing or section of code if you ever have questions. Documentation maintenance is a cost that we never have time to pay. Ditto for code comments... all code MUST be self-documenting.".

It -uh- didn't work out so well.

> You’ve not been around much contract consultancy work then?

Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.

Post reply on HN