Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Lead Your Team When the House Is on Fire

peterszasz.com

Post reply on HN
Print view View original

61–70 of 214 posts

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

#61

Post by bongodongobob »

imetatroll wrote: post #34
dakiol wrote: 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…

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.

Literally anywhere that isn't a startup.

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

#62

Post by tbrownaw »

nrr wrote: post #54
dakiol wrote: 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…

I'll push back in defense of Scrum, but it probably bears a little explanation because my conceptualization of that framework is very likely a lot different from yours. (As something of a bonus: I'll bring in the military given the whole "wartime" trope.) In particular, Scrum is only there to establish rituals that enable empiricism in decision making. A sprint is a reporting period to keep the team from spending too…

> I really dislike the term "Scrum Master." They're a team captain.

Originally that term was supposed to be a temporary role that someone (rotated each time) would take on during a scrum meeting, and referred to them being charged with keeping the meeting on track.

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

#63

Post by lubujackson »

afro88 wrote: post #26
debacle wrote: post #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…

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

Makes sense, but at some point this advice boils down to "have the perfect amount of centralized control" which doesn't say anything useful at all.

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

#64

Post by CoastalCoder »

mlhpdx wrote: post #59
wrs wrote: post #8

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

The healthy way to frame it, in my opinion, is that it’s business as usual. I know that isn’t motivational (or fun) for a lot of people, but the pragmatism is something to always have in mind. Top-down influences have and always will drift from topic to topic and resources will follow. Demand for any given approach will wax and wane and wax again over a career. Often, some core fundamentals will seem in-volatile but…

I've been a developer for just under 30 years. One of the pleasant surprises in my skill development was learning how much I can ignore various fads, policies, and people.

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

#65

Post by rqtwteye »

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.

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

#66

Post by nrr »

tbrownaw wrote: post #62
nrr wrote: post #54

Earlier quoted context omitted.

I'll push back in defense of Scrum, but it probably bears a little explanation because my conceptualization of that framework is very likely a lot different from yours. (As something of a bonus: I'll bring in the military given the whole "wartime" trope.) In particular, Scrum is only there to establish rituals that enable empiricism in decision making. A sprint is a reporting period to keep the team from spending too…

> I really dislike the term "Scrum Master." They're a team captain. Originally that term was supposed to be a temporary role that someone (rotated each time) would take on during a scrum meeting, and referred to them being charged with keeping the meeting on track.

It was! I've, however, gotten way more use out of saddling whoever is most senior with the role of making sure the team as a whole is on track. This way, it's a little more familiar with the way Western management hierarchy operates without turning it too much on its head. It's something of a leadership billet without removing the ability to be technical, which is important for a lot of folks.

It tends to work pretty well in an environment that both lacks a bug tracker (so that individual people aren't assigned things) and has a culture of pairing or mobbing.

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

#67

Post by ThrowawayR2 »

Aeolun wrote: post #39
imetatroll wrote: post #34

Earlier quoted context omitted.

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.

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

IBM didn't have it's first round of major layoffs until the 1990s, Google and Microsoft didn't have their first major layoffs until 2008-2009, Facebook/Meta didn't have its first major layoffs until 2022, etc. Even then, only a fraction of their employees were affected. People can last quite a long time at such places with a little luck.

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

#69

Post by afro88 »

lubujackson wrote: post #63
afro88 wrote: post #26

Earlier quoted context omitted.

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

Makes sense, but at some point this advice boils down to "have the perfect amount of centralized control" which doesn't say anything useful at all.

I think the advice is based on "peace time" management, during more comfortable profitable times, leaning towards more centralised control. There's no appetite for the risk of moving faster by removing approval bottlenecks or changing processes.

The advice here is to challenge what actually needs to be centralised.

Identify things that could be safely delegated. For example, why does a list of managers and an exec need to approve a $10 per month subscription that saves a bunch of engineering time by managing cascading PR merges?

And identify safe ways to delegate. For example, if we move container image vuln scanning into CI/CD pipelines, the dev team can update dependencies themselves without a security team being involved to do it for them and approve.

These might seem like silly examples to someone working at a half decent start up or tech first org. But these kinds of centralised control structures are the norm for most large organisations until they are very strongly challenged.

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

#70

Post by thr0waway001 »

rqtwteye wrote: post #65

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

Well said. Nobody is willing to take risks and change things up when things are going well.

I've found myself warning the people I work with that we need to do things to stabilize the core of our software and infrastructure.

When things are going well it's hard to get buy-in and the time to do any necessary, and sometimes radical changes.

And you probably may say at this point: "well if things are going well why would you do anything radical?" but I generally mean well as in not falling apart, but not ideal, as in every week we keep seeing the same issues reported in our day-to-day. Cause eventually, it only takes something else to go wrong to expose major issues and vulnerabilities with the operation.

Nevertheless, when shit goes sideways, as it usually tends to happen especially when you don't slow down and maintain enough, people then just want you to fix the problem, and do whatever it takes, including those aforementioned risky things you were proposing to avoid the shitty times to begin with.

Post reply on HN