I work for a European government-owned company and have been there for several years. I previously worked as a DevOps engineer across three product teams, where I regularly built local solutions for recurring problems that seemed better suited to a company-wide platform. I recently moved into a platform engineering role because I understand those teams' pain points and have experience with the relevant tooling.
I already have ideas that could reduce costs, improve security, and remove repetitive security work from product teams. The challenge is that senior leadership thinks in organizational and budget silos. Their attitude is often that one team's budget is separate from another's, and that the platform team should deliver exactly what was requested—nothing more or less. In some cases, we are even implementing solutions that do not seem to solve a real customer need, while lacking the autonomy to improve shared services or optimize inefficient usage.
How can I build credibility and make a case for broader, reusable platform improvements without overstepping? What approaches work when budgets, ownership, and decision-making are divided between departments?
4 Answers
A platform team needs to be treated as a product team, not just a pool of specialists assigned wherever someone has a request. The platform should provide clearly defined services to product teams, with measurable benefits such as lower operating costs, improved reliability, faster delivery, or reduced security risk. If teams are charged for usage or support, the platform has a natural incentive to make the shared service cheaper and better than every team building its own version.
Make governance part of the proposal, not an afterthought. Ask the team to explain the problem, compare possible solutions, identify the implementation owner, and define how success will be measured over time. Then review the plan with stakeholders and let them challenge the assumptions. This demonstrates that the platform team understands business constraints and is not simply asking for freedom to build whatever it wants.
We are preparing a presentation and have already discussed governance, but we may need to emphasize it more. Ideally, leadership would set the budget and expected outcomes while the platform team had autonomy over technical decisions that do not change the cost or business risk.
Frame proposals in terms of the organization’s priorities rather than engineering elegance. For every idea, show the current cost or risk, the expected benefit, the teams affected, the implementation effort, and who would own the result afterward. A small pilot can be more persuasive than a broad architectural presentation. Once you have evidence from one service or product team, it becomes easier to argue for a shared approach.
Start by delivering a few straightforward wins that are explicitly within your team’s mandate. A new role is a good time to observe how decisions, budgets, and relationships actually work before trying to redesign them. Government organizations often move slowly, so proving that you can deliver reliably will give you more influence later. Use that time to learn who benefits from each proposal, who pays for it, and who has the authority to approve it.
That makes sense. I’m already trying to understand the organization and learn from the team, but I also have the advantage of being able to return to my former department if this role turns out not to be a good fit. I’d still like to use that position carefully rather than simply accept inefficient decisions.
By that definition, we are currently more like a shared specialist team. We already have the usage data needed to show which teams consume excessive resources, but teams do not pay directly for that usage, so they have little motivation to optimize it. That is one of the structural changes I’d like to discuss.