Story: “It would be career limiting..."

The skill of reading a room in this particular case - is to realize the kind of place this is and go elsewhere before going through all that effort for it be disregarded by bruised egos, not do even more unnecessary work to bail out incompetent managers.

Doesn't sound like that was the job of this little committee. As written, it was to review and particularly identify extra work. Presenting solutions to this kind of problem isn't explicitly and often implicitly the function of the developer(s), especially in a room full of managers. Whose job it is literally to identify solutions to this exact kind of problem.

That's just a fractal version of this same problem.

Most of us are here to get work done and earn a living, and not to role play palace intrigue.

But certainly it's my experience that this toxicity comes from the top down and I have sympathy with managers who are putting their reports under unreasonable pressure because they are themselves under unreasonable pressure.

> you don't go into a meeting like that to present problems, but to present solutions. And a 12 month delay on a $60 million contract isn't a solution, it's another problem

Honestly that's exactly what I'd expect out of a meeting like that, and with good leadership it'd be a collaborative exercise on how to solve the problem. There's not going to be a solution that has zero impact on anyone else, and that individual team doesn't have the authority to make the call on what impact the business can sustain. They came, presented their problem, and their ideal recommendation (a 12 month delay). There's plenty of options on how to deal with that: ask sales how much of a delay is actually tolerable, see if low-priority asks could be dropped to free up some additional time, etc etc.

It's leadership's job to mediate problems between "peer" groups, like engineering and sales.

My first role out of college was on a four person product team split across three projects on two OSes. We were overloaded and couldn't maintain the desired velocity that Management was asking for. So we scheduled a meeting with the VP of product development and the CEO (the joys of a midsize company), sat down, and shared the amount of effort in our backlog, the goals we'd committed to as a company for these projects, and the cost that context-switching. The CEO considered us for about 20 seconds, then said "Okay, which project should we drop?". She had the trust in her teams and her management to take them at their word about their inability to achieve the goals, understand it's because the goals were beyond the reasonable capability of the team and not because the team was underperforming, and understand the landscape of the choices available:

(1) continue underperforming on our existing goals and possibly upset customers due to not meeting stated expectations

(2) walk back our commitments, possibly upsetting customers

(3) cut the legacy product and focus on achieving and even exceeding our commitments for the modern product

(4) do nothing and shred team morale

More often than not "office politics" is really just shorthand for "low trust, low transparency environment". Yes, there's some amount of collaborative interpersonal skills necessary to be a good engineer, but if you don't trust me to do my job and tell you when our objectives are at risk then why did you hire me?