My manager keeps insisting that every tool and platform we use should be upgraded to the newest available version immediately. We rely on several SaaS products built around open-source projects, but those services are currently many versions behind their upstream projects. We contacted the vendors, and they explained that our current versions still have around two years of long-term support remaining and that no upgrades are planned during that period.
Despite that, my manager wants us to appear cutting-edge to other teams. This has led to a lot of wasted effort investigating workarounds and repeatedly confirming that we are blocked by vendor release schedules. I understand the importance of security updates and planned upgrades, but constantly chasing versions we cannot control adds work without a clear benefit. How can I push back professionally and get my manager to focus on useful priorities?
4 Answers
The newest version is not automatically the best version. If the vendor supports your current release, upgrading early may add instability, testing effort, and downtime without delivering anything useful. Put the facts in writing: the current support window, the vendor's upgrade plans, the risks of workarounds, and the business benefit—if any—of moving sooner. That makes it easier to frame this as a risk and prioritization discussion instead of simply disagreeing with your manager.
There may be a terminology issue here. With a SaaS product, you often cannot upgrade the underlying service yourself; the provider controls the release. If you do have local components, separate those from the hosted platform and define exactly what can be upgraded and what cannot. That distinction may make the dependency and timeline clearer to your manager.
Have a direct one-on-one conversation, but keep it focused on engineering impact rather than your manager's motives. Explain that the team is spending time on an upgrade it cannot execute, while the supported release remains viable for years. Suggest a concrete alternative, such as tracking the vendor roadmap, reviewing security advisories, and scheduling an upgrade when the SaaS provider makes it available. If your concerns are dismissed or you are punished for raising them, document the situation and consider escalating through the appropriate management channel or looking for a healthier team.
Use your normal planning process to make the tradeoff explicit. If this work is not already planned, ask which existing priority should be delayed to make room for it. Also clarify what outcome is expected: a supported production upgrade, an investigation, or just a presentation about being ahead. A request to do something immediately should come with a corresponding priority and enough time for research, testing, and vendor coordination.
It can help to follow up after the conversation with a short summary: what was requested, what the vendor supports, the estimated effort, and which current task will move back. That creates a shared record and prevents the same investigation from being restarted repeatedly.