My manager insists that every tool and dependency should be upgraded to the newest available version immediately. We use several SaaS products built on open-source projects, but the SaaS providers are often many versions behind upstream. In this case, our current versions still have about two years of LTS support, and the providers have no plans to upgrade during that period.
Despite that, my manager wants us to appear cutting-edge and show other teams that we are ahead. Since the upgrades depend on external vendors, we keep getting blocked and end up spending time researching workarounds or repeating investigations that confirm we simply have to wait.
I understand the value of staying current for security or important bug fixes, but this feels like pointless work driven by appearances. How can I explain the technical and business risks of forcing upgrades that provide no practical benefit, and get my manager to prioritize more useful work?
4 Answers
Have a direct one-on-one conversation and describe the impact on the team: repeated research, disrupted priorities, and work that cannot produce a usable result until the vendor moves. Suggest a written upgrade policy based on security fixes, end-of-support dates, critical bugs, and clear business benefits. If your concerns are dismissed or you are penalized for raising legitimate risks, that is a management problem rather than an upgrade problem.
Use your planning process to make the tradeoff explicit. If this work is not already planned, ask your manager which current priority should be delayed to make room for it. Explain that investigation, testing, rollout, and rollback planning all require time, and that an external dependency means the outcome is not even under your team's control. Making him choose the priority often exposes how little value the request actually has.
Newer does not automatically mean better, especially with production systems. If the current version is supported and meeting your needs, forcing an upgrade can add instability, compatibility problems, downtime, and unnecessary cost. Frame the discussion around business value and risk rather than arguing about whether the latest version is impressive. Document the support timeline, the vendor's upgrade plans, the effort involved, and the concrete benefit of upgrading now.
There may be a misunderstanding about what can actually be upgraded. With a SaaS product, the provider usually controls the service version, so your team may only be able to update local agents, integrations, configuration, or client libraries. Clarify exactly which component is under your control and what the vendor supports. That gives you a concrete answer instead of spending time trying to force an upgrade that is technically unavailable.
That makes sense. I think documenting the blocked dependencies and asking what should be deprioritized would make the cost much harder to ignore.