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

131–140 of 214 posts

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

#131

Post by koonsolo »

dijksterhuis wrote: post #121
0xbadcafebee wrote: post #104

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

First of all, thanks for writing this. I didn't want to put in the effort myself.

Secondly, you are downvoted right now, which comfirms why I didn't want to put in the effort ;D.

It's clear people don't want to talk to users. But in the end, it gives people like us an excellent advantage.

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

#132

Post by koonsolo »

greatgib wrote: post #127
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 think that almost no one from the community has any hate for "Agile" as in the manifesto. Quite the opposite. The problem is that the Agile that is pushed in the corporate world is nothing at all related to the spirit of the manifesto. Management took over to keep control over developers. So you have scrum, you have scrum masters, product owners, t-shirt sizes poker, ... All of that bringing more stress to devs tha…

That's why I stated the manifesto here. Because people complain about Agile, but in reality they complain about not being agile.

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

#133

Post by dijksterhuis »

koonsolo wrote: post #131
dijksterhuis wrote: post #121

Earlier quoted context omitted.

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

First of all, thanks for writing this. I didn't want to put in the effort myself. Secondly, you are downvoted right now, which comfirms why I didn't want to put in the effort ;D. It's clear people don't want to talk to users. But in the end, it gives people like us an excellent advantage.

Is fine. Imaginary internet points are just imaginary internet points.

> It's clear people don't want to talk to users. But in the end, it gives people like us an excellent advantage.

The best kind of user to me is the one who is convinced they’re “dumb” when it comes to software. I always get so much more useful info from them compared to the folks who think they know something.

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

#134

Post by koonsolo »

agos wrote: post #107
kombookcha wrote: post #105

Earlier quoted context omitted.

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

We should give it a different name, like FakeAgile. That way people can complain about FakeAgile and not Agile.

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

#135

Post by tsukikage »

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…

My main point of dislike is that I have never experienced the actual practices called "Agile" on the ground by the consultants/managers introducing them bearing any relation to the oft-quoted Agile manifesto.

"Value individuals and interactions over processes and tools", says the Agile consultant as they open the meeting; they then proceed to shut down any interaction between individuals that is not on the agenda, or that is on the agenda but takes longer than a sentence or two.

"Value working software over comprehensive documentation", says the Agile consultant as they open the sprint planning. "These tickets should contain enough detail that a new hire coming to them cold can pick up the work."

"Value customer collaboration over contract negotiation", says the Agile consultant. "Value responding to change over following a plan. Also, these items must be delivered by end of Q4; let's schedule some meetings with management to discuss why the team's burndown chart is going up and not down."

Agile is like true communism: always preached, never reached. It is a fig leaf for toxicity. The ideal true Agile practitioner cannot be faulted; and you will never encounter them. The word "Agile", when encountered in real-world corporate scenarios, does not mean the things described in the manifesto, though the manifesto will often be quoted; rather, hearing it invariably means the frog has reached boiling temperature and it is well past time for anyone who can still flee to flee.

"Agile consultant" is the modern term for an outsider that management have brought in to whip the thoroughbreds so that the resulting negativity falls on the outside party - which can then be let go again - and not anyone permanently employed by the company. We may want the word to mean nicer things, but that is not how it is actually used.

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

#136

Post by paulryanrogers »

ThrowawayR2 wrote: post #67
Aeolun wrote: post #39

Earlier quoted context omitted.

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.

Stack ranking may push you out long before a major layoff

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

#137

Post by lazide »

everdrive wrote: post #123
codeduck wrote: post #106

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…

They act that way because anyone who didn’t got fired, and those that did got promoted. So either the ‘smart ones’ started doing it, or the ‘dumb ones’ all got removed.

Either way, the effect tends to be the same.

The fish rots from the head.

But you’re still cashing their paychecks right?

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

#138

Post by pavel_lishin »

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…

What about what "this BS" does to morale and motivation? If a manager acknowledges dysfunction, I feel significantly better working for them than one who tries to convince me that everything is fine.

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

#139

Post by adammarples »

koonsolo wrote: post #132
greatgib wrote: post #127

Earlier quoted context omitted.

I think that almost no one from the community has any hate for "Agile" as in the manifesto. Quite the opposite. The problem is that the Agile that is pushed in the corporate world is nothing at all related to the spirit of the manifesto. Management took over to keep control over developers. So you have scrum, you have scrum masters, product owners, t-shirt sizes poker, ... All of that bringing more stress to devs tha…

That's why I stated the manifesto here. Because people complain about Agile, but in reality they complain about not being agile.

It's too late, the word means something else now

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

#140

Post by robertlagrant »

tsukikage wrote: post #135
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…

My main point of dislike is that I have never experienced the actual practices called "Agile" on the ground by the consultants/managers introducing them bearing any relation to the oft-quoted Agile manifesto. "Value individuals and interactions over processes and tools", says the Agile consultant as they open the meeting; they then proceed to shut down any interaction between individuals that is not on the agenda, or…

> "Value working software over comprehensive documentation", says the Agile consultant as they open the sprint planning. "These tickets should contain enough detail that a new hire coming to them cold can pick up the work."

A ticket that tells you what needs to be done / reviewed / tested is indeed in the pursuit of working software. Having detailed class diagrams drawn 18 months ago that you have to follow is what this point is talking about.

Post reply on HN