hckrnws

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.

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

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 think this is inevitable and unavoidable in a tech career, take heart in the fact that it's not!

I can second this, it is avoidable.

I have a pretty high threshold before pressure at work actually stresses me out, so I've stuck around for a while after seeing the warning signs before leaving a team on this path.

Warning signs are always there in my experience, you just have to pay attention. The real challenge is paying attention as the problems start to ramp up, its easy to get distracted fighting fires and not see the bigger picture.

Fähigkeitsanwendungssehnsuchtsunerfülltheitsgefühl?

I guess scrabble is really popular there:)

No, the board simply isn't wide enough.

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

[flagged]

What is worse, once you get promoted enough, you learn that throughout your career when these things happened, senior management often had some juicy completion bonus or other perk tied to delivery. Yet when you are doing this you are expected to just comply because the company is in trouble.

I told you to stop talking to my wife! She has 35 years engineering, now a quality manager, and the new boss has been hair on fire all weekend, cosplaying that a top down intense low bid culture can adapt, and uh, oracle is in the mix. This is not what we signed up for.

How does low-bid mash with Oracle?

Corp jumps into the trunk, Oracle slams shut the lid, and the usual story ensues. There's a process bug now, not Oracle's to be sure, and to fix it will cost real money.

Edit: make things more clear.

This gif would seem appropriate: https://imgur.com/a/T8q5oUg

the obvious follow-up to the obvious solution is you don't need to feed 2 extra horses after you're out and you end up with websites counting how many horses are suddenly starving.

Agency cosplay sounds like the right phrase. Everyone wants to believe they have the power and resources to achieve their potential. Even in dying & desperate departments warring with themselves. If a professional doesn't believe their actions get good outcomes, they quit or quiet-quit.

For the manager trapped between their hopes and reality, this blogpost is basically therapy. It comforts with a classic remedy: level up your game and you can win the game. Replace negativity with a "bias heavily toward action". Tell yourself and your reports: "perfection is the enemy of done", have "ruthless prioritization", be "laser-focused on shipping what matters most“. Believe in this all until you get a new position (with real agency), then you can discard this illusion along with your reports.

An older phrase for this phenomena, absent the management aspect, could be "hustle porn." If you ignore ethics, and work crazy hard and crazy smart, you'll win https://www.inc.com/serhat-pala/alexis-ohanian-says-hustle-p... . Though in my experience, you'll just end up crazy.

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 so pathetically servile to someone who is in a higher rung in a company? These executives don't have better ideas inherently, and due to being so far removed from the real work, are often a misinformed distraction. No one seems to think that an executive would want to be told that they are wrong, or misinformed, or missing the point. But, a worthwhile executive would want to hear exactly that. They would want to know if their ideas were actually going to disrupt work, make the firm worse off, etc. And I know what you're thinking: many executives are self-interested, and just want to see their ideas implemented, company health be damned. Yes, that's true. But then why does anyone give them the time of day? If an executive is nakedly self-interested they should be sidelined as aggressively as possible, both to neuter them and also to protect the company.

I had a bit of hope when companies started down the OKRs path.

That model could work really well when done bottom-up, with individuals defining what they see as most important in their context and managers rolling that up into coherent strategies at each level as it goes up. Effectively, managers should be puzzling together what those closest to the product and customer find rather than forcing down goals and metrics.

Unfortunately companies don't work that way and leadership fundamentally doesn't trust their employees, especially employees they are a few layers away from in the org chart. OKRs ended up being just another name for leadership slamming goals down the org, no different than the Company Pillars I would see at Microsoft 15 years ago.

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?

It's simple, at certain point at certain growth in a company, the "yes man" virus is going to infect the whole corporation. Why? Because there's one spot where the virus is going to spread, and around this spot only "yes men" will get promoted and they will only hire, reward and promote other "yes men".

It starts from a person or persons who don't know what they are doing, but are really good at selling themselves. So their only goal is to show themselves in a good light to leadership and fool them by surrounding themselves with people who will agree with everything they do.

Why do so many grown adults act so pathetically servile to someone who is in a higher rung in a company? - Because the alpha apes on the top of the pyramid got all the bananas and they will share it only with the ones they like. And it goes all the way down. Too bad tha apes have not come up with a better system because the apes have prioritized bananas over everything else. Peace.

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.

A lot of tech industry mythology is written from the perspective of a technical lead as imagined by an executive, or from the perspective of an executive who views themself as primarily a technical lead. In practice, this mythology is usually exactly just that

The other issue with this piece is that the vast majority of problems companies have in a more cash constrained environment are ultimately accounting problems.

No amount of "existential threat" pressure on teams to perform will replace leadership going through the balance sheet and figuring out where profits/growth/etc is getting it's highest return on investment and where it's not. Then planning for how to change that.

I was at a newly IPO'd company a few years back and it was almost laughable the gap between leadership's fantasies about profitability and the raw data in the earnings statement. Not a single decision planned or statement made addressed the mathematical reality of the balance sheet.

A simple "We need to get X% more out of this, and reduce the cost of that by Y% and we'll be good, here's our plan..." would have been endlessly more productive then feel good speeches and pressure on teams to improve performance in unspecified areas.

Also, war-time leaders usually make terrible peace time leaders and vice versa.

If your company finds itself in battle mode and the senior leadership doesn't move aside for a hired gun, be very worried and polish up that resume.

Once peace time arrives, same thing in reverse.

> Direction and technical decisions are driven by priorities of board-level members

This signifies a weak CEO.

I read it more as, nobody under the CEO, from the C-suite down, that isn’t also on the board, is setting direction.

Not that the board was collectively trying to be CEO.

But in a wartime/survival situation, I would hope the board had some opinionated members. If only to make sure the right CEO was in place.

Are you sitting behind me ?

I like your cologne today.

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.

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 generational glory. Otherwise, you're being fed koolaid.

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

I've told my direct reports something similar. "Don't stress out about this. If it were a real problem, someone would have noticed 3 months ago when it broke / was never completed before [employee] left." Most of these crises are painfully fake.

The crisis is orchestrated around someone in the middle layer who thinks they get fired if they don't deliver anything this quarter.

I also often say "this is the scope right now but we can cut portions of this if we need more time. These are the critical elements that we need before the deadline. But the rest of this stuff is us using this opportunity to not ship a pile of garbage we can't support. If we have to do that, we'll fix it as soon as the deadline passes." But also I actually have the mandate to do that.

> I've told my direct reports something similar. "Don't stress out about this."

I too do that often to my direct reports. Not worth the stress. But of course it helps to pretend that one is working hard and stressed :) .

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.

Kinda describes most of the people (loosers) in the corporate world I'm aware of.

Or you know, sometimes your boss just lies to you, you do the crunch time, then when you save their asses you get laid off because that's cheaper than the raises or bonuses and you're prolly burnt out anyway so you won't be that productive again for months

At will employment, baby

Do you think the privates trying to get off the boats on D-Day had the promise of millions of dollars if they made it off the beach?

Sometimes, the ‘amazing’ reward is not going bankrupt, and that is enough.

Well they got off the boat so that they could die a little further down the beach or if lucky down the road. Death slightly later is a big motivation.

yeah, and ‘Not going bankrupt right now’ is the economic equivalent.

It doesn’t have to be a nice juicy carrot to be sufficient motivation for things to happen.

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.

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.

Just sharing my own experience..I used to work for start-ups and now I am working for a seemingly boring, profitable company that is not venture funded. By boring I meant there is not alot of media news about them. They just bunker down and do the work. There's way less craziness - more focused, mature approach towards problems.

How do I find jobs like that?

These companies do the regular stuff such as advertising via the usual channels- job boards and LinkedIn. And sometimes with recruiters - not those fancy ones who recruit for start-ups.

Literally anywhere that isn't a startup.

nah, I work at a Fortune 100 company right now that is in "War Mode"

yea things are crazy now. We're in war mode but nobody knows why. We've been reliably profitable for a decade. And yet we're doing super high risk cost reduction projects that have significant risk of burning down the entire business and have already destroyed what used to be a very skilled and mature engineering team. I get the impression that's a fairly typical story now.

Have private equity types been seen entering the building?

The executives would never deign to enter the offices that house our unwashed technical worker selves.

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

Jobs at big companies are less stable and end with less notice than at small ones, at least in my experience. In a small company, particularly one with engaged and transparent leadership, everyone knows what’s working and what isn’t and about how long the latter can be endured. At a large company the vast majority of jobs are susceptible to the whims and whispers of a few (who likely aren’t engaged and feel they can’t be transparent).

Obviously this is just one person’s opinion.

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.

You can be in the wrong place at the wrong time anywhere--but, yeah, generally speaking given reasonable competence, you can ride a reasonable, if not spectacular, gravy train at most large organizations for a long time. Maybe that's not your thing--which is fine--but it's probably the case at a lot of large companies.

Stack ranking may push you out long before a major layoff

Don't know why you're getting downvotes, this is indeed a fact. (Edit: you don't have to be a bad performer to get shunted out by stack ranking. In a rotten enough organization, it is possible for a manager to write a performance review that acknowledges every goal that you've met, and still gives you a bad rating for any old excuse)

BigCo is less likely to give a sense of desperation in day-to-day work, but a layoff or forced stack-ranking can still fall out of the clear blue sky due to executive machinations.

Twitter is exceptional in the exception sense.

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.

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 than having empowered them to be trusted to deliver what the real client wants.

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

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)

Agile was a reaction to waterfall and other heavy-process software development practices. You have to understand the bigger picture to fit the Agile points in there.

For example your

>> Value responding to change over following a plan

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

In waterfall, once you start developing, it's very hard to change something during the process. Due to Agiles iterative and incremental approach (principles 1 & 3), it allows you to change priorities, features, integrations, etc, during development.

New technology also allowed this iterative approach. For example in the past, software was released on disk or CD-roms, which meant a huge release cycle. Nowadays with SaaS, you can constantly release and improve your products (using CI or CD for example, widely adopted now).

Maybe you have to look into other software development processes to really understand what sets Agile appart, for example Waterfall, Spiral, Incremental, Rational Unified Process, etc. A good overview is here: https://en.wikipedia.org/wiki/Software_development_process

That really doesn't answer GP's question

Maybe I'm not understanding it completely indeed. To make it more clear to me, can you explain what software development process you prefer so I can contrast it with the points of agile?

You are conflating the notion that some things are more important than others with completely throwing out things deemed not that important.

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

Go. Speak. To. User.

> “Value working software over comprehensive documentation".

> So, never write documentation?

Read the phrase again, with a slightly different word in place

Prefer working software over comprehensive documentation.

I.e. working on building the thing instead of obsessing about gant charts.

You can do a Gantt chart if you want. But focus primarily on the software. That’s more important.

> And how do you define "working" software? What about features in development?

Intentionally left vague. “Working”depends on many factors that only the people involved with the building of it can know.

Mainly by getting on a train and sitting down with your users to figure out exactly what they consider to be working software. See above.

> “Value customer collaboration over contract negotiation"

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

Hey, company X we’d like some software that does Y.

Do you

1. Enter into a lengthy process to establish exact requirements and agree on exactly what needs to be delivered up front, without having touched any software, and trying to cost it all out etc etc

2. Get on a train and sit with the user developing some proof of concepts quickly to figure out what the hell it is they want.

1 is waterfall and contract negotiation. 2 is responding to change. example is a user saying “oh, actually, could we try the page header in pink instead please” after asking for it to be blue last week.

> lol. I have never talked to a customer, in my entire career.

You’ve never spoken to a user?

You need to start.

Ideally right now.

Stand up. Walk away from your desk. Find a user to speak to. Ask them what they think of the software.

> Why the fuck is this in an engineering guideline?? Do you find a lot of developers doing contract negotiation?

Well it’s not in the contract so I’m not going to work on that feature because we won’t get paid for it.

Even though some enterprising engineer went and got on a train and sat with the user for a day and figured out “oh shit, we’re actually building the wrong fucking thing”.

Nope, not in the contract. User doesn’t get what they want because we negotiated a contract.

> Value responding to change over following a plan

Waterfall: We have an agreement and WILL ONLY BUILD ACCORDING TO THE PLAN. We will never deviate from the plan. The plan must never change. Ever.

agile: shit, I went and got on a train and sat with the user and we’ve been building the wrong thing. Time to rethink this.

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

A lot to unpack here.

No, they’re not stupid. They may be “of their time” but they’re definitely not stupid.

They seem more right the more I think about them. I think about agile a lot and how to teach the attitudes contained within the principles to my juniors.

Just to reiterate the important point there — the principles are a collection of attitudes. They are not explicit instructions.

No, it’s actually useful. Would I base an entire team methodology solely on this? No. But it informs a significant part of it.

Executives don’t care about by he agile manifesto. Mostly because no one posts about it on linked in and they’d rather pay someone ridiculous sums of money to make the team “Scrum” and fuck about doing whatever the fuck sprint poker is (execs always want to spend money instead of doing the work).

According to the LinkedIn post it made some other team really efficient. They read about it on linked in. It must be true.

—

FYI — just because you don’t understand or see the value in something does not mean it isn’t valuable.

  >> So, never write documentation?
  >
  > Read the phrase again, with a slightly different word in place

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.

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

I disagree. Like, I was just working at a place that did both analytics consultancy and in-house products. Go. Speak. To. User. worked in both.

For consultancy, yeah we had to go off and sit with the customer and figure out with them exactly what they needed. Do iterative PoCs. Eventually work out, together, what the 'user'/customer wanted to get out of the project(s).

For product, I sat down with one of the lead scientists and asked her what she actually wants. Like, be real with me. It's me here. I don't care if you want to use the products or not. I want to help you do the job you want to do and help you solve those problems you face on a daily basis. What will help you do this.

Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (Benchling).

Repeated the same thing with Data Science.

(Eventual) Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (databricks).

Of course, that didn't fly with the management people who wanted their magical 'guaranteed revenue stream' (which didn't exist). They weren't Go. Speak. To. User.-ing. So they were divorced from the reality of what was going on and stuck in the blue sky management vision.

Agile-manifesto-agile doesn't just apply to engineering. You can apply the principles of Go. Speak. To. User. And. Stop. Making. Gantt. Charts. To. Solve. The. Real. Problem. to a lot of places.

> Go. Speak. To. User. worked in both.

Yes, but "Go speak to the fucking users so that you build the right thing" is such a tiny slice of Agile shit, and it's a product management rule that predates Agile by ages. This is like one of THE big things that Product and Field people are supposed to do, and has been for roughly forever.

As for the rest of Agile? Maybe the idealized Agile (just like the idealized Marxism) works great, but my personal experience at a place that very, very, very much was NOT Doing Agile Wrong[0], along with the personal experiences of an assload of others who work at Agile (and "Agile" shops) indicates that Agile as she is implemented in the real world is incompatible with long-running continuous [1] projects.

[0] I'm afraid you're just going to have to take my word that I know what I'm talking about here.

[1] "Continuous" as opposed to the "parachute in, mitigate the biggest problems, and then airlift out" engagements that are SOME of what contract shops are hired to do.

Wow. Someone who ACTUALLY understands the Agile Manifesto. This is one of the best comments I've ever read on HN.

It's mind-boggling that people can be confident that they're building the right software for their users without ever actually talking to their users.

<3

It's fairly easy for me to get to grips with agile tbh because I live daily with another 12 principles thing.

Had a big "oh shit, hell yeah, this makes perfect sense now!" moment when I re-read the manifesto one day.

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.

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

In my personal experience, pretty much. Theatrically feigned agile is extremely aggravating and grating. Actual agile is in my experience fine and doesn't produce that kind of strong aversion because it 'just is'.

Agile vs agile.

Manifesto is the one with a small a.

Big A Agile is an exercise in making management happy because they read about it on LinkedIn while having a poo. It usually involves paying several consultants a lot of money.

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

Wait until I tell you about SAFe...

No one criticizes the manifesto itself I believe. But there's a huge difference between the abstract idea and principles of the manifesto, and an actual implementation that usually differs from company to company. So, yeah, the idea of babies is nice and all (everyone loves the manifesto), but you need to change diapers and that gets dirty. No one likes to changes diapers (no one likes Agile).

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.

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

#6

Face to face communication as opposed to asynchronous communication brings less objectivity to the topic at hand.

Many, many, many, maybe most people have implemented Agile as a recipe. Without understanding how it could work or why. Since they have no idea what they are doing, people who are forced to use this cargo-cult implementation find it onerous. Just another stupidity forced on them.

The question is how can people collaborate? That is the question. Complex Adaptive Systems (CAS) begins to help us think about how we can do that. Simplistically we can just throw bodies at problems and we get "the mythical man month" mentality. Or we can do it with militarism - we all get marching orders. Unfortunately, good programmers do not do well with this mentality.

So is there another way? At this point, as a community, we do not really understand how people work together. Despite the face that millions of people can live in a large city, we have no clue as to the mechanism that allows this to happen. $. The city does not degrade as the Mythical Man Month predicts, nor are the people ordered about in a militaristic manner. So what gives? How does that work? $.

Why do I keep putting $ in this post? Because $ is a "messaging bus". (You tell me a better word - signalling system?). Everyone can read (get money) and write (spend money) on this messaging bus providing signals to other people.

Agile is a very fuzzy attempt to provide a messaging bus. But if you have no clue as to the mechanism, you can descend into madness - for example "If one scrums are good what if we do ten a day?".

They are fluff values with little actionability and the scrum/agile rituals seem unrelated to these anyways.

This is all BS baloney theater crap.

A real engineering manager, when the execs say "Its Wartime" says "Wonderful, is everyone on the c-suite taking on call rotations so the engineers can focus or just the CEO and CTO ?"

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 much time in the weeds. A standup is there to keep the team working together. The andon cord (which is often missing I find) is there when the facts have changed so utterly profoundly that everyone needs to regroup.

Anyone who's been through RTC ("boot camp"), and even some who haven't but have lived vicariously through others, understand that being constantly yelled at by RDCs ("drill instructors") on how you make your racks and fold your clothes is all about building certain habits and only tenuously related to what you'll be doing after A-school. It all has more to do with building trust that the rest of the folks in your ship will help carry you when the going gets tough. Scrum, at its core, is kinda like that.

I really dislike the term "Scrum Master." They're a team captain. The more military-minded might be keener to use "gunnery sergeant" or "chief petty officer:" they're just the most senior person in the rating group^W^W^W^Won the team. (Though, I'd probably take more inspiration from the Marines than the Navy here: a culture of servant leadership seems to bring out the best in people.)

The most popular implementations of Scrum tend to come with a ridiculous amount of meeting and tool baggage, and it's so unnecessary.

Use Excel. Hold your standups at the close of the day so people can go home. Write your product backlog items in delivery order so that sprint planning is less about sitting in one room playing poker and more about just getting valuable shit done.

That said, what isn't unnecessary, however, is kneecapping command a little: the engineering officer of the watch has comparatively little understanding of the actual operation of the machine. They just know that they want operational excellence. However, that excellence also sometimes comes with the watch supervisor—a subordinate—publicly calling out mistakes that the watch officer makes.

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

and... it would keep everyone on their toes a bit more, vs just having a group of folks that nod and say 'yes', 'no' or '3 points' a few times at the same time every day.

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.

If you don't know what a 5 month run way feels like, you haven't experienced life. It really helps you understand what is important to projects and wtf isn't.

I really don't understand the hate for Agile. Adaptation, empiricism, iteration self-managed teams etc...what's not to like?

I'm currently involved with two programs run by project managers who probably haven't written code for 30 years (if ever), and it's a nightmare.

Agile is great. The problem is “agile methodologies” like Scrum which create lots of overhead and ceremony. I have seen Scrum work well but it is the exception.

The failure mode of Agile is when the company says "we're going agile" but refuses to adapt or let the team manage itself, as well as having a fixed deadline, scope and budget which have been decided outside the team. In other words, you still have the clueless project managers, but you have to cosplay "agile" within that.

But that's the failure mode of anything. Why is Agile uniquely (and very consistently) blamed for management failures?

Because, consistently, management doubling down on failure is preceded/foreshadowed/accompanied by a full on theatrical performance of "we're going Agile".

I have no explanation for why /that/ is, mind; except - well, look at the result: the blame and hatred is aimed at Agile and its priests, not at management. Cui bono?

There is no such a thing as a painfree meal when a big cooperation is devouring you..

If that was what actually happened when corpos say "agile"...

There is such a thing as a first mover advantage, as long as one doesn't focus on competitors as much as unserved / underserved customers.

Pretty often people that heavily emphasize the competition and push arbitrary timelines have taken shortcuts, or at least aren't being transparent enough to satisfy the team. They may also just be competitive by nature and insecure due to a lack of experience, and bad at communicating - also, due to a lack of experience.

Agile / Scrum: people quickly realized that they had to give up control in order to be agile.

It's possible to do Agile and to structure a waterfall software project into smaller chunks that feel agile, but you need PM's who know how to do that, and they need to show their work to the team in order to get buy-in. It's too bad the jargon got abused to the point of garnering resentment.

At least it's a formalized way to plan and communicate using common terminology. Even this lowest common denominator is worth something. It doesn't have to be great to have some value. I have a hunch Agile can amplify both good a bad company culture.

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.

I had an ex-marine boss leading QA and Prod support. Every time someone would go nuts about incidents being the end of the world, especially our biz users, he'd just ask if anyone was at risk of getting shot. If not, focus up and solve the problem, but no need to run causing extra fuss and stress.

I've used a similar analogy a few times - do we make medical software where someone will literally die if we don't fix this in the next few hours? No? Then chill the hell out and we'll get it fixed without giving ourselves stress related diseases. In a week or a month no one will remember this particular "emergency" but we'll all remember the general level of stress we felt on this team for years.

I've said this out loud a few times. But I've said it quietly to myself far more often when someone is trying to make me feel stressed for no reason. It's very effective.

How would you handle something that is possible to put into monetary numbers, because technically certain amount of money could save a life.

E.g. this incident cost us $5 million - this type of money could be used to save many lives.

At most firms the money was never earmarked for saving lives and there's no expectation it ever would have.

By not earning the money (or losing it), you're not actually impacting anyone's life.

I like that - I've been at a company where a manager from a mining background would get panicked at a P2 incident, because in the mining industry a P2 incident meant that a person had been physically injured (and would probably be tomorrow's news) but where I was, a P2 meant some but not all revenue-generating systems were experiencing issues.

I think he eventually figured out not to sweat it so much.

had a similar experience early in my career in finance. 35 year old associate (old for the role), ex green beret, always so level, even when dealing with a lunatic VP. asked him why he was cool as the other side of the pillow: "nobody is shooting at me"

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

This is slightly OT, but I believe wartime in the UK and US forced a number of cultural changes towards egalitarianism and what would nowadays be called "diversity" because things had to actually work. Being upper class in the UK would not save you from German bombers. The normally exclusionary system had to let a gay man break codes and a woman design Spitfire engines because those were the best people actually available and the outcome mattered more than saving face. This also got us the postwar settlement of universal healthcare and education.

"universal healthcare"

Not in the US. Only in BigCorps.

> The normally exclusionary system had to let a gay man break codes and a woman design Spitfire engines because those were the best people actually available

I don't know enough about Spitfire engines to comment, but is that true about Turing? I thought he kept his sexuality a secret.

Reference to https://en.wikipedia.org/wiki/Beatrice_Shilling with a bit of hyperbole.

The government definitely knew.

Not arguing with your point but see also: https://en.wikipedia.org/wiki/Battle_of_Bamber_Bridge

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.

Our admin used to just prop the door open with a fan and blow the “something’s burning” smell out into the hall.

I’ve always heard the term “fire” being used ironically in this context. As in “everyone is panicking like the place is on fire, but its fine.”

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.

With an actual fire (or hazardous environment) people’s lives are at risk and it makes a big difference. Hopefully those executives act accordingly or they’ll face jail time for putting their employees in harm’s way. That is not the same as being unable to produce.

https://www.pbs.org/newshour/nation/ex-coal-chief-gets-one-y...

It's funny because I read "executive reaction" as pertaining to an individual's physiological response, not as "the actions taken by the organization's leadership", which then gave "Executive Dysfunction" a whole new meaning for me...

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.

The football metaphor for ‘war mode’ really might be switching to playing defense. 4th and ten was last quarter. Right now, we don’t have possession and we’re trying to minimize the risk of conceding points.

And maybe that means that now is the time for your star playmaking quarterback and receivers to be on the bench planning the play for when the pendulum swings back, and some different players should be center stage.

Or maybe metaphors are just metaphors.

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 even they aren’t.

I try not to fight these tides, and just accept them. Sometimes ignoring them.

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.

"It's like (violent_thing) on (hard_drug)!"

sadly i think im numb to ppl speaking this way. genuinely: thanks for the reminder this language is inappropriate

Most of what comes out of executives mouths is fantasy role play. It's always exaggerated to motivate.

The phrase "in the trenches" is used often, too. Always grosses me out.

Those books about British science/engineering during WW2 sound interesting. Any recommendations?

I’m traveling so can’t look on the shelf, but off the top of my head I’d recommend The Wizard War: British Scientific Intelligence 1939-1945, R. V. Jones, 1978.

I found it on the Internetarchive and I just read a bit in it and it is delightful.

https://archive.org/details/wizardwarbritish00jonerich

Amazing. I came here to specifically recommend another RV Jones book, the Most Secret War (https://www.amazon.com/Most-Secret-War-R-V-Jones/dp/01410428...). I wasn't aware of his other book, so very much looking forward to reading this.

I first read this book when I was starting out as a Dev some 20 years ago. It made a huge impression and is still relevant. Some things I remember off the top of my head.

- It was the first time I came across Occams Razor. This really helped me understand how to approach debugging issues and generally dealing with problems.

- It discusses the dangers of people who don't understand areas at a technical level being in charge of programs that depend on those technical things. Even more so when they have an inflated ego. Apparently Churchill was very good at seeing through this.

- If I'm remembering correctly, there was a section about a practical joke someone played on their apartment neighbour that involved swapping out their pet tortoise for gradually larger versions. I very recently read a Roald Dahl childrens book to my kid which had this exact story. Now I have no idea if this actually happened as RV Jones wrote, or if it was a well known story at the time that Roald Dahl also adapted.

- The dangers of making assumptions.

I'm sure there are more. It's a worthwhile and highly entertaining read regardless.

It’s the same book, just a different title for the US version. (We don’t have a “Most Secret” over here.)

Great to know, I was about to (re) purchase :-)

Your comment reminded me instantly of book by PKD, Time out of joint. I think it shows very well the mental pressure of people trying to use science to stop a defeat at wartime.

[0] https://www.goodreads.com/book/show/698034.Time_Out_of_Joint

Please do share some good ones, I am very interested in these sorts of stories.

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 would rather his reports hustle around the fire instead.

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 don't make sense, but we can still do right for each other among this BS" type of conversation. But it's worth thinking about what that will do for the long term motivation of that team member at the company.

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.

Rationalise - maybe. Romanticise - definitely not. If people want to leave I wouldn't blame them at all, and will happily write them a reference. But there's no point in me optimising for that decision, I need to optimise for the scenario where they want to stay.

I can say that I'm staying because I hunted for this job last year through the "winter of tech" and that nearly broke me as much as this toxic workplace does. So I have reasons not to jump ship, and I can't imagine I'm the only one. So for anyone reporting to me who would also rather not leave, I should do what I can to reduce the shittiness for them as much as possible.

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

Yeah, such people would be able to spot and smell "this BS" from a mile and trying to sell it to them by re-packaging won't exactly help raise motivation. I would wager that most of them can probably appreciate the truth behind "this is what we are paid to do so we need to do the best we can for what needs to be done" - they are probably exercising that discipline in their personal lives too.

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.

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.

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

It's essentially an ad to promote their career.

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.

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.

I just got back from watching the movie Casa Bonita Mi Amor, about the South Park guys buying a beloved Denver restaurant and refurbishing it. Costs ballooned from an estimated $6 million to $30+ million because it had been owned by a company that deferred maintenance for 30 years. Not sure if the business types would see this as a cautionary tale or as validation for coasting, though. The company that ran it into the ground probably extracted a ridiculous amount of profit...

Maintaining and developing are the hardest

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.

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

it's really common for people to form groups after a layoff to help each other get hired.

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

Decentralize decision-making, delegate, bottom up culture, etc.

These things have merit, but increasingly less the more you move away from "whole" plans in which they make sense. These particular ones are troublesome because they fall closer on the spectrum to "reduce executives". If you're pushing decision-making downstream, it should also be reduced upstream. If you reduce it upstream, you have less (not zero) need for leadership there. That has to manifest either in fewer leaders or leaders doing a better job at their other duties. In particular, they need to be producing much clearer stronger vision for the downstream folks to align their decisions to. Vision is perhaps the hardest task in the org and when it's hard it's easy to shirk on. Often, when leaders talk about trying to move to a bottom up culture, they are (unconsciously?) trying to absolve themselves of the vision work. And they're usually doing it while still gatekeeping information and resources they were meant to have because they were decision makers.

This is going too far, but directionally: Leaders should largely not be advocating for delegation and bottom up decision-making. It's not that this can't be better for the company, it's that they could be executing the goal better by quitting or firing their peers. It's more of a catch-22/worst of both worlds situation—leaders shouldn't be advocating for it because they shouldn't be there to advocate for it.

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.

> 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

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.

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.

The code review process is quite literally “you need a stamp from anyone because of some regulations we follow”. Definitely nothing thorough.

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.

I think we do, to some extend. As the TL, when I’ve reviewed their PR I’m definitely not going to blame them for the bugs I missed during review. They’ll still have to fix them, because that’s just most efficient.

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

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

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.

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.

Thank you.

No amount of wartime valor is going to overcome a lack of product market fit.

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.

Never a bad time to remind yourself of what is at stake in a literal war, versus a company in survival mode.

Literal war: Many human lives - both combatant and non-combatant - and the future prosperity or collapse of all societies involved

Company in survival mode: for most employees, their income level this year.

Describing the operation of a software business as "Wartime" is nonsense.

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.

When the house is on fire, you lead people OUT OF THE HOUSE.

Then you get help.

Then, if you can do it without putting yourself back in danger, you look for opportunities to help out.

If you don't know this, you failed childhood.

Now, on to the metaphor: emergencies don't last forever. If your emergency is lasting indefinitely, it's not an emergency and the house is not on fire. It is quite possible that you are being manipulated. If emergencies keep happening, senior management has a big problem, and it's up to them to fix it.

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.

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

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.

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.

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.

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

Nothing is infinite and managers are both people and have their own constraints. In my experience, expecting otherwise will just select for either managers who work really hard but fail to get you much (due to lack of political skills), or those that are very good liars that say they're helping you but never do (and you never realize otherwise).

> They pay had better be incredible to make playing those kinds of political games worth having your soul drained.

In my experience, pay increases linearly with soul drainage. As I started working for larger and larger companies the amount of nonsense and pay increase by the same order.

Responsibility decreases by the same magnitude, so while I was responsible for the whole IT operation/decisions of a small company for the lowest pay I ever had, I’d now be able to coast for half a year without anyone really noticing. BigCo is fucking weird.

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

There's a lot of virtue in that, and managers prefer that just as much as engineers do. But sometimes it's as the article says: "Your organization might not have the luxury of years of runway, and the environment you're operating in is rapidly changing". If you've got a big customer making 20% of your revenue who's threatening to jump ship (not an uncommon scenario for small to medium sized companies), you simply have to deliver whatever they want as fast as you can and worry about your vision later.

Either your product is at its core useful, or its not. If the environment is rapidly changing, either your product is still relevant, and you should be focusing on stability, or it's no longer useful and it's too late to change that.

> If you've got a big customer making 20% of your revenue who's threatening to jump ship (not an uncommon scenario for small to medium sized companies), you simply have to deliver whatever they want as fast as you can and worry about your vision later.

But that's one new requirement (or set of), not a changing environment. If that customer is changing their requirements as they go, so that you're constantly shifting focus, you need to either pin them down to one goal, or cut them loose and deal with the fallout. They don't see or care about the "war mode" they've created, and placating them will just invite more demands, and you can't keep it up forever.

The one time I've seen a "war mode" succeed was making a change that was a precondition for acquisition, when a set of requirements was laid out in the acquisition offer. It couldn't be altered once it was accepted, so the "war mode" had a fixed goal and deadline. Apart from something like that, it's just going to result in a spiral.

At the top we have 2 management posts - this and MrBeast. One is very specific and another is typical management bs-bingo.

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

I think the main issue is consolidation in many industries. Companies get big and keep getting richer and bigger. They gobble up smaller companies to grow and often competitors too. They milk the industries dry and stiffle innovation. You get these poor run and bloated organizations as a result.

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?

And that day, I was told I passed the Amazon interview and was offered a job as a L4 Software Engineer.

not really a classic anecdote

As a leader, your ability to stay calm is a fundamental one! It can directly impacts your team's confidence and effectiveness. By remaining steady, you set a tone of control and clarity that can help guide your team through chaos.

Building businesses out of debt, starting with negative balance and when approaching out of money, asking employees for a last minute war time mode. That’s plain terrible business practice, don’t work there.

It’s best to avoid working in such environments but this can, to some extent, give a boost to development

Funny because the last place I worked it was as if senior management were playing The Roof Is On Fire song non-stop through everybody's speakers. You know the song, "We don't need no water, let the MFer burn!"

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.

Except the point around forgetting some of the long term improvement projects the rest are true anytime.

Simple: tell them to follow the fire exit signs.

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

The whole point is convincing developers that they are in a 'war' and that making the ultimate sacrifice (i.e. giving up their life just so the delivery date can be made) is acceptable, even heroic.

It's a vile way to treat people.

As someone working for defense it's hilarious how civilians use this kind of wording without any real understanding of what it means. The constant use of the term in the Phoenix Project bugs the hell out of me too.

It's yet another attempt for software enginerds and managerial bullshitters to make themselves feel more important than they are, because god forbid they say it like it is and just call it "how to lead a team when the cushy years stop"

I was hoping it was actually a treatise on leadership by a firefighter. But expecting it not to be.

Why can't these wartime analogies go away? You're building just another CRUD. Nothing is at stake. Stop pretending you're a warrior. You're not. It's just pathetic.

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

If you're building drones in Ukraine, you're in war mode.

If your business required zero interest rates, you're not in war mode. You're in stupid mode. It was never a successful business. (See WeWork, etc.) Get out.

[dead]

[dead]