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

101–110 of 214 posts

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

#101

Post by koonsolo »

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 really don't understand the hate for Agile, so let's make it concrete: which things to you not like about the Agile manifesto?

1. Value individuals and interactions over processes and tools

2. Value working software over comprehensive documentation

3. Value customer collaboration over contract negotiation

4. Value responding to change over following a plan

And then there are the 12 principles:

1. Customer satisfaction by early and continuous delivery of valuable software.

2. Welcome changing requirements, even in late development.

3. Deliver working software frequently (weeks rather than months).

4. Close, daily cooperation between business people and developers.

5. Projects are built around motivated individuals, who should be trusted.

6. Face-to-face conversation is the best form of communication (co-location).

7. Working software is the primary measure of progress.

8. Sustainable development, able to maintain a constant pace.

9. Continuous attention to technical excellence and good design.

10, Simplicity—the art of maximizing the amount of work not done—is essential.

11. Best architectures, requirements, and designs emerge from self-organizing teams.

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.

So in total 16 points to cirisize! For everyone who hates Agile so much, please make it concrete.

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

#103

Post by 0xbadcafebee »

Wurdan wrote: post #88
hitekker wrote: post #72

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…

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…

It sounds like you are trying to rationalize a toxic environment.

Most of us don't actually have to stay at a company that is on fire. Plenty of companies (and managers) will try to convince us to stay at a company that "feels" on fire. That's what I hate about this "wartime software" bullshit. Like, if you enjoy being at war, cool, go at it. But if you don't want to feel horrible, find a different job. There is no prize to win for being a hero. Just a life of pain from an entity that will drop you as soon as is convenient.

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

#104

Post by 0xbadcafebee »

koonsolo wrote: post #101
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 really don't understand the hate for Agile, so let's make it concrete: which things to you not like about the Agile manifesto? 1. Value individuals and interactions over processes and tools 2. Value working software over comprehensive documentation 3. Value customer collaboration over contract negotiation 4. Value responding to change over following a plan And then there are the 12 principles: 1. Customer satisfact…

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 define "working" software? What about features in development? (etc)

"Value customer collaboration over contract negotiation". Lol. I have never talked to a customer, in my entire career. I have also only heard about contracts, and usually they are ridiculous. I guess this is supposed to be different... but kinda hard to make it different if you aren't allowed to get close to a customer or a contract negotiation. (Why the fuck is this in an engineering guideline?? Do you find a lot of developers doing contract negotiation?)

> Value responding to change over following a plan

?????????? Does anyone know what the fuck this means?

....

The rest of the "12 principles" are equally stupid and nonsensical. They only "seem right" if you don't think about them for more than 5 seconds, and you live in some kind of fantasy world. It is absolute bullshit, completely disconnected from reality. (But boy do executives love to eat this shit up, because they will never have to figure out how to implement it)

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

#105

Post by kombookcha »

koonsolo wrote: post #101
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 really don't understand the hate for Agile, so let's make it concrete: which things to you not like about the Agile manifesto? 1. Value individuals and interactions over processes and tools 2. Value working software over comprehensive documentation 3. Value customer collaboration over contract negotiation 4. Value responding to change over following a plan And then there are the 12 principles: 1. Customer satisfact…

I don't think people are really unhappy with the manifesto, but with applied Agile as it is experienced out in the world where you're having your workday ordered by high powered productivity consultants and LinkedIn-brained middle managers.

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

#106

Post by codeduck »

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.

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

#107

Post by agos »

kombookcha wrote: post #105
koonsolo wrote: post #101

Earlier quoted context omitted.

I really don't understand the hate for Agile, so let's make it concrete: which things to you not like about the Agile manifesto? 1. Value individuals and interactions over processes and tools 2. Value working software over comprehensive documentation 3. Value customer collaboration over contract negotiation 4. Value responding to change over following a plan And then there are the 12 principles: 1. Customer satisfact…

I don't think people are really unhappy with the manifesto, but with applied Agile as it is experienced out in the world where you're having your workday ordered by high powered productivity consultants and LinkedIn-brained middle managers.

so, things that are in no way agile but want to call themselves agile

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

#108

Post by InDubioProRubio »

joshuanapoli wrote: post #43
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…

There are definitely critical times where the engineering team can make a big swing in the success of their larger organization. I think that these intense periods naturally invite excitement. Going back to "normal" at the end of such a period is actually pretty hard; the work may not seem as important to the team, yet we have to rebuild some types of quality that were lost during the intense period.

These pivot-points are usually in luls after the storm, when the doomed project has no active-vampireempire on lead due to massive sinking ship jumps but there are suddenly fundings available due to being bought and sold.

Thats the moment you get a chance to re-engineer or develop new capabilities - the moment when the MBA outer bark layer holding us all back cracks and gives.

The above is mostly about times when all conversations start with "for the procto-cull: I was against this and that" and lots of ass covering.

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

#109

Post by jillesvangurp »

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.

Post reply on HN