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

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