[HN Gopher] How to Lead Your Team When the House Is on Fire
___________________________________________________________________
How to Lead Your Team When the House Is on Fire
Author : kiyanwang
Score : 364 points
Date : 2024-09-15 20:16 UTC (1 days ago)
(HTM) web link (peterszasz.com)
(TXT) w3m dump (peterszasz.com)
| candiddevmike wrote:
| > 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.
| lumost wrote:
| 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.
| Spivak wrote:
| 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.
| Aeolun wrote:
| > 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.
| marcinzm wrote:
| > 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).
| Simon_ORourke wrote:
| 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.
| talkingtab wrote:
| 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.
| Simon_ORourke wrote:
| > 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.
| ryanmcbride wrote:
| it's really common for people to form groups after a layoff
| to help each other get hired.
| johnea wrote:
| 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...
| TheAdamist wrote:
| I was hoping it was actually a treatise on leadership by a
| firefighter. But expecting it not to be.
| agent327 wrote:
| 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.
| AllegedAlec wrote:
| 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"
| wrs wrote:
| 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.
| ddejohn wrote:
| The phrase "in the trenches" is used often, too. Always grosses
| me out.
| bitwize wrote:
| 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.
| jameshart wrote:
| 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.
| willturman wrote:
| Those books about British science/engineering during WW2 sound
| interesting. Any recommendations?
| wrs wrote:
| 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.
| hi_hi wrote:
| 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.
| wrs wrote:
| It's the same book, just a different title for the US
| version. (We don't have a "Most Secret" over here.)
| hi_hi wrote:
| Great to know, I was about to (re) purchase :-)
| lukan wrote:
| I found it on the Internetarchive and I just read a bit in
| it and it is delightful.
|
| https://archive.org/details/wizardwarbritish00jonerich
| move-on-by wrote:
| 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.
| Aeolun wrote:
| 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.
| move-on-by wrote:
| 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...
| settsu wrote:
| 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...
| foobazgt wrote:
| 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.
| noitpmeder wrote:
| Yeah we've had to evacuate the office several times because
| our in-house "lab" DC started smoking.
| ChiperSoft wrote:
| 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."
| giantg2 wrote:
| Most of what comes out of executives mouths is fantasy role
| play. It's always exaggerated to motivate.
| alexwasserman wrote:
| 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.
| biosprout wrote:
| 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"
| jamesfinlayson wrote:
| 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.
| esperent wrote:
| 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.
| mewpmewp2 wrote:
| 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.
| mlhpdx wrote:
| 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.
| CoastalCoder wrote:
| 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.
| kumarvvr wrote:
| Please do share some good ones, I am very interested in these
| sorts of stories.
| szszrk wrote:
| 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
| boogieknite wrote:
| "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
| pjc50 wrote:
| > 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.
| downut wrote:
| "universal healthcare"
|
| Not in the US. Only in BigCorps.
| robertlagrant wrote:
| > 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.
| jdiez17 wrote:
| The government definitely knew.
| pjc50 wrote:
| Reference to
| https://en.wikipedia.org/wiki/Beatrice_Shilling with a bit
| of hyperbole.
| debacle wrote:
| > 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.
| herval wrote:
| > 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
| debacle wrote:
| 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.
| herval wrote:
| The code review process is quite literally "you need a
| stamp from anyone because of some regulations we follow".
| Definitely nothing thorough.
| XorNot wrote:
| 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.
| Aeolun wrote:
| 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.
| toast0 wrote:
| 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.
| jajko wrote:
| > 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.
| halfcat wrote:
| 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.
| afro88 wrote:
| >> 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.
| AdrianB1 wrote:
| 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.
| lubujackson wrote:
| 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.
| afro88 wrote:
| 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.
| cm11 wrote:
| 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.
| aorloff wrote:
| Thank you.
|
| No amount of wartime valor is going to overcome a lack of
| product market fit.
| drekipus wrote:
| 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?
| langcss wrote:
| And that day, I was told I passed the Amazon interview and was
| offered a job as a L4 Software Engineer.
| oulu2006 wrote:
| not really a classic anecdote
| trhway wrote:
| At the top we have 2 management posts - this and MrBeast. One is
| very specific and another is typical management bs-bingo.
| dakiol wrote:
| 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.
| imetatroll wrote:
| 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.
| Aeolun wrote:
| 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).
| mlhpdx wrote:
| 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.
| ThrowawayR2 wrote:
| 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.
| ghaff wrote:
| 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.
| paulryanrogers wrote:
| Stack ranking may push you out long before a major layoff
| closeparen wrote:
| 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.
| __loam wrote:
| Twitter is exceptional in the exception sense.
| bongodongobob wrote:
| Literally anywhere that isn't a startup.
| ang_cire wrote:
| nah, I work at a Fortune 100 company right now that is in
| "War Mode"
| b_t_s wrote:
| 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.
| ShufflerL wrote:
| 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.
| __loam wrote:
| How do I find jobs like that?
| joshuanapoli wrote:
| 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.
| InDubioProRubio wrote:
| 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.
| vishalontheline wrote:
| 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.
| actionfromafar wrote:
| 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.
| nrr wrote:
| 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.
| tbrownaw wrote:
| > _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.
| nrr wrote:
| 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.
| mgkimsal wrote:
| 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.
| ransom1538 wrote:
| 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.
| ern wrote:
| 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.
| bazoom42 wrote:
| 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.
| p_l wrote:
| If that was what actually happened when corpos say "agile"...
| pjc50 wrote:
| 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.
| robertlagrant wrote:
| But that's the failure mode of anything. Why is Agile
| uniquely (and very consistently) blamed for management
| failures?
| tsukikage wrote:
| 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?
| InDubioProRubio wrote:
| There is no such a thing as a painfree meal when a big
| cooperation is devouring you..
| screye wrote:
| 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.
| advael wrote:
| 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
| everdrive wrote:
| >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.
| throwway120385 wrote:
| 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.
| mewpmewp2 wrote:
| The crisis is orchestrated around someone in the middle
| layer who thinks they get fired if they don't deliver
| anything this quarter.
| atoav wrote:
| 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.
| lazide wrote:
| 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.
| aorloff wrote:
| 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 ?"
| koonsolo wrote:
| 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.
| 0xbadcafebee wrote:
| 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)
| koonsolo wrote:
| 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
| rrr_oh_man wrote:
| That really doesn't answer GP's question
| koonsolo wrote:
| 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?
| dijksterhuis wrote:
| > "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.
| koonsolo wrote:
| 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.
| dijksterhuis wrote:
| 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.
| simoncion wrote:
| >> So, never write documentation? > > Read
| the phrase again, with a slightly different word in place
|
| I spent way too many years working at an Agile shop that
| had been doing Agile for a very long time. (This is me
| saying "This place definitely wasn't Doing Agile
| Wrong.".)
|
| At that place, "Prefer working software over
| comprehensive documentation" ended up actually meaning
| "Do not write documentation. Go speak verbally to the SME
| for that thing or section of code if you ever have
| questions. Documentation maintenance is a cost that we
| never have time to pay. Ditto for code comments... all
| code MUST be self-documenting.".
|
| It -uh- didn't work out so well.
|
| > You've not been around much contract consultancy work
| then?
|
| Honestly? IME, this is about the ONLY environment where
| the Agile stuff makes sense. It's just such a very, very,
| very poor fit for long-running projects that require
| continuous work that may extend for _decades_.
| WesolyKubeczek wrote:
| You are conflating the notion that some things are more
| important than others with completely throwing out things
| deemed not that important.
| kombookcha wrote:
| 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.
| agos wrote:
| so, things that are in no way agile but want to call
| themselves agile
| kombookcha wrote:
| 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'.
| dijksterhuis wrote:
| 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.
| koonsolo wrote:
| We should give it a different name, like FakeAgile. That
| way people can complain about FakeAgile and not Agile.
| soco wrote:
| Wait until I tell you about SAFe...
| albertP wrote:
| 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).
| greatgib wrote:
| 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.
| koonsolo wrote:
| That's why I stated the manifesto here. Because people
| complain about Agile, but in reality they complain about
| not being agile.
| adammarples wrote:
| It's too late, the word means something else now
| tsukikage wrote:
| 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.
| robertlagrant wrote:
| > "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.
| talkingtab wrote:
| 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?".
| la64710 wrote:
| #6
|
| Face to face communication as opposed to asynchronous
| communication brings less objectivity to the topic at hand.
| benreesman wrote:
| 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.
| neilv wrote:
| > _" 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.
| 0xbadcafebee wrote:
| 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.
| getnormality wrote:
| > 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.
| SpicyLemonZest wrote:
| 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.
| ang_cire wrote:
| 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.
| neilv wrote:
| > _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_.
| dsr_ wrote:
| 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.
| neverartful wrote:
| 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!"
| rqtwteye wrote:
| 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.
| thr0waway001 wrote:
| 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.
| romanows wrote:
| 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...
| veunes wrote:
| Maintaining and developing are the hardest
| hitekker wrote:
| 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.
| Wurdan wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
| Wurdan wrote:
| 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.
| pavel_lishin wrote:
| 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.
| noisy_boy wrote:
| 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.
| Wurdan wrote:
| 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.
| wiz21c wrote:
| > 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..)))))
| nitwit005 wrote:
| It's essentially an ad to promote their career.
| xeyownt wrote:
| Simple: tell them to follow the fire exit signs.
| niedbalski wrote:
| 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.
| veunes wrote:
| It's best to avoid working in such environments but this can,
| to some extent, give a boost to development
| gherkinnn wrote:
| 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.
| codeduck wrote:
| 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.
| xwolfi wrote:
| Are you sitting behind me ?
| codeduck wrote:
| I like your cologne today.
| everdrive wrote:
| 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.
| lazide wrote:
| 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?
| _heimdall wrote:
| 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.
| bangaroo wrote:
| 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.
| la64710 wrote:
| 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.
| mewpmewp2 wrote:
| 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.
| downut wrote:
| 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.
| tempodox wrote:
| How does low-bid mash with Oracle?
| downut wrote:
| 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.
| efsavage wrote:
| 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!
| _heimdall wrote:
| 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.
| laasda wrote:
| > s 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?
|
| Harterarbeitetefahigkeitanwendungsmoglichkeitszweifel.
| jdiez17 wrote:
| Fahigkeitsanwendungssehnsuchtsunerfulltheitsgefuhl?
| wkat4242 wrote:
| I guess scrabble is really popular there:)
| kibwen wrote:
| No, the board simply isn't wide enough.
| im3w1l wrote:
| I propose Prepper's Paradox. I was even able to dig up an
| existing usage https://www.reddit.com/r/preppers/comments/1do
| mhjt/the_dooms...
| wkat4242 wrote:
| This gif would seem appropriate: https://imgur.com/a/T8q5oUg
| engrmgr2024 wrote:
| 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.
| toolslive wrote:
| 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_...
| FuriouslyAdrift wrote:
| 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.
| hitekker wrote:
| 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.
| crystal_revenge wrote:
| 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.
| JumpCrisscross wrote:
| > _Direction and technical decisions are driven by priorities
| of board-level members_
|
| This signifies a weak CEO.
| jillesvangurp wrote:
| 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.
| veunes wrote:
| 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.
| bfrog wrote:
| 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.
| la64710 wrote:
| Except the point around forgetting some of the long term
| improvement projects the rest are true anytime.
| LikeBeans wrote:
| 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.
| Animats wrote:
| 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.
| davidashe wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-16 23:01 UTC)