There are times in a corporate IT environment when the introduction of a new system or service requires input from other teams. This may include things like provisioning groups in active directory, making firewall changes, adding whitelists to the corporate proxies and all sorts of other small changes.
It can be tempting to split each of these functional components into different support teams, helping engineers and support analysts to specialise in a particular set of systems or processes. Indeed this may be necessary owing to the complexity of the systems or processes involved.
One downside of doing this can be that when project change is necessary (e.g. introduction of a new system), a large number of people have to be coordinated to get all the parts completed. Support teams who should be focusing on the continuous improvement of their set of systems or processes end up being tugged by ad hoc queries or project work, and having to coordinate their time around other people’s requests.
A way to minimise this disruption is to try and make platforms “self service”. What this means is that instead of a support team owning and running the process for changing their system configuration, they present the configuration in a way that can be inspected by any other engineers in the organisation (all who can reasonably be given permission). For example this could be done using github, with repos that hold a collection of configuration files and github actions which validate, test, then ultimately push changes into prod. If an engineer from another team can inspect the configuration they can make a good guess at what might need to change to meet their own goals. Even better if the engineer can see previous successful Pull Requests, and put in some work to make the existing tests pass, they can propose a change to configuration that they think will do the job. It is then up to the support team to review the suggested change; something that is much less cumbersome than taking in requirements and hand-cranking the change themselves.
To be successful this “self service” approach requires transparency, good quality tests, branch protection (with appropriate approvers), a good README, and a mechanism of deploying through UAT and PROD. While it may seem like a big upfront investment to get these things in place, it can relieve the frustration of the project team that want to make a change, and reduce the overhead on the support team allowing them to concentrate on their own priorities rather than being project led. Also it can help new joiners to learn how things work more quickly, because old pull requests provide templates for what good looks like: win, win, win.