And quite often the person who causes these circumstantial stresses can be the same person for whom this guide is intended, but I'm not able to find a lot of acknowledgement of that fact in the guide.

I had a manager who pretended they could manage our product-consultancy team the same way they managed their previous research-code-monkey team. They had trouble because of their inability to do much besides say "replicate this paper". To them I probably looked like all of these archetypal "difficult engineers" at various times. From my perspective I wasn't getting the pay nor the time and respect from higher-ups to go through the hard slog of managing up, but I was getting paid enough to stick around, so I just ended up burning out super hard.

I guess my point is, sometimes managing others starts with managing yourself. This insight extends far beyond the context of a day job.

I can relate to this, especially as someone from a technical management position that has to fight such decisions frequently to try to protect my team from such pointless exercises in stress.

> I've also seen a lot of people give up on arguing with those non-technical people about scope and time, say "OK"

I understand why this happens, and it is extremely frustrating; consequently, this is why I really dislike the trend of complaining on social media about issues because at least with my company, this is an almost guaranteed way to ensure that a C-Level will "step in to correct this", which in fact just means that now the company needs to do what the C-Level said so the C-Level doesn't look stupid in public, even if the thing to do is absolutely disastrous.

The best advice I can give if you're in a technical leadership position and you know this kind of thing happens in your org is:

1. Figure out who these non-technical persons with the ability to make said bad calls actually are in your company; do a process review on the last few events that triggered poor decision processes and find out from whom those decisions actually came from

2. Understand how that person processes information, how they're getting alerted, and most importantly, just get to understand them and what makes them "tick." (e.g., one of our lead PMs, usually a very good PM, unfortunately has a huge ego. Arguing with them in any public fashion causes them to get very defensive out of fear of looking "stupid"; a quick chat with them in private usually is enough to convince them of their mistake, and then we get more reasonable reactions)

3. Become professionally friendly with the common reporters of the issues that usually prompt bad decisions; if a particular sales team is finding actual issues but representing them in a way that results in rushed/poor decisions, teach them another place to report the issues so that more necessary stakeholders are able to view the issue before it gets to the decision process

4. Develop strong and strict change management processes that will protect from the issues; don't attach these processes to specific incidents, but instead present it neutrally as a best practice in change management, and then use the process to protect against such rash changes. The first few times upholding the process might be rough, but just remind people why the process exists, that the goal isn't to stop all decisions, but instead to ensure you are properly vetting decisions on core elements

Implementing this is difficult, especially in orgs with poor discipline and process control already, but from experience with such orgs, most persons will pay lip-service to the initial neutral presentation, and won't realize that the bad behaviors they have which the process is meant to stop will be impacted. The goal here isn't to be dishonest with people, but instead to introduce a process-based prevention in a palatable way which makes future discussions easier as they'll carry a common point of agreement. At least with the C-Levels I've had to deal with, it was effective because they didn't want to look stupid in front of other C-Levels and higher management who were telling the C-Level "this breaks our internal processes, we need to review this first as last time we rushed decisions without the stakeholder input, we ended up with huge costs". It doesn't stop every C-Level, but it has greatly reduced the number of meetings I've had to have where I have to give "Explain it like I'm 5" presentations to non-technical decision makers to prevent disastrous decisions/changes.

Edit/Addendum: I am well aware that the "real" solution is that decision makers just stop making drastic and ridiculous decisions/promises, but I don't think it's reasonable to expect to change personalities/poor thinking skills in a person, much less to force changes of management. Instead, I'd rather just use process to enforce this and deal with the occasional raised voices.

Also Edit: fixed numbered list formatting.

Thanks for the thoughtful reply. Lots for me to mull over in that.

thats exactly what i do...theyll ask for a time estimate and then whether it can be cut by half because issues...i then say yes of course it can and proceed to delivery way past the deadline