Here is a situation many DevOps support teams will recognise. The queue is never empty, the people are tired, and yet when the quarter ends, the improvements everyone promised did not happen. Each day was spent answering what arrived. Nobody had time left to fix the reasons things kept arriving. If your support or managed-services desk feels like that, the trouble may not be headcount or tooling. It may be that nothing is ever formally declined. Let us diagnose it together and walk through a fix that costs nothing but a few honest conversations.
The symptom: busy all day, nothing changes
A support function without a decline list behaves like an open door. Every kind of request is welcome: genuine faults, how-to questions, favours from colleagues, requests for custom reports, invitations to meetings about topics nobody on the desk owns. Because everything is accepted, everything competes, and the loudest voice wins rather than the most important need.
You can check for the symptom quickly. Look at the last two weeks of work and mark each item as one of three types: requests that fit your service, requests that only look like they fit, and requests that clearly do not. Teams are often startled by the size of the second and third groups.
The diagnosis: nobody wrote down what the service excludes
Service descriptions tend to list what is covered. They rarely list what is not. As a result, the edges are negotiated one ticket at a time, usually by whoever is on shift and least able to say no. Over months, the service boundary drifts outward and the team inherits duties nobody agreed to.
The deeper cause is attention. A person who handles forty small interruptions a day has no energy for a deep fix. The diagnosis is therefore simple to state: the team is spending its limited focus on things it never chose to do.
The fix, part one: write the exclusions
Sit down with the team and draft a short list headed “We do not”. Keep each item concrete. Typical entries from support teams include:
- We do not troubleshoot software we did not deploy or were not asked to run.
- We do not produce bespoke reports without a named requester and a stated purpose.
- We do not attend meetings without an agenda that mentions our service.
- We do not give status updates outside the agreed channel.
- We do not make out-of-hours changes for convenience; only for agreed reasons.
Your list will differ; the point is to write it with the people who will have to apply it. If the principles behind your service are shaky, rereading the DevOps ideas that underpin dependable shipping of software can help the group agree what is truly in scope.
The fix, part two: decide the polite answer in advance
A list helps nobody if each refusal requires courage in the moment. Prepare a few standard replies. One might say: “That falls outside our service, but here is who can help.” Another: “We can look at it if you raise it as a planned request with a date.” Having words ready transforms refusing from a confrontation into a routine step, and customers tend to respect clarity far more than a slow reluctant yes.
The fix, part three: route, do not absorb
Declining is not the same as abandoning. For each excluded category, name where the request should go: a self-service guide, a different team, a vendor or a scheduled planning session. This is how the policy stays friendly. Engineers who understand the wider operations picture are better at routing, and the progression described in this article on operations engineers moving toward infrastructure as code and reliability work shows why the redirecting skill grows with experience.
A short side trip for the people behind the desk
Support staff also carry personal inboxes of professional advice, courses and job-board nudges. The same method applies there. If you are weighing where your own career should go, a guide to the many DevOps role titles and the careers behind them may help you decide what to pursue and, just as usefully, which titles to stop worrying about.
Handling the awkward objections
“Customers will be unhappy.” Some will, briefly. The alternative is a team that responds slowly to everyone because it accepted everything. Clear boundaries usually improve satisfaction over time because the covered work gets done better.
“What if the excluded request is actually urgent?” Include an escape valve. Give a named person the right to approve exceptions, and log each one. If the same exception keeps appearing, it is evidence that the boundary should move, and you will have the record to justify it.
“Our manager asks us to do everything.” Bring the two-week sample of requests as data. Show what the team did and what it could have done with the hours recovered. Managers respond to a concrete trade better than to a general plea.
A parallel from everyday buying
Teams making equipment or software purchases can borrow the habit. A reader browsing True Review Now, a blog of reviews and articles about gadgets, software and local services, might first list the claims and extras they will not let influence the decision. It keeps shopping from turning into another endless inbox.
What to measure afterwards
After a month, compare the sample again. How many requests were declined or redirected? How much planned improvement work happened? Did customer complaints rise or fall? You are not seeking perfection; you are checking that the list is doing its job. Adjust wording, add an exclusion or retire one that proved unnecessary.
The remedy for an overloaded support desk is rarely a heroic sprint. It is a short document, agreed by the people who live with it, that says what the service will not do. Once written, the same hours that went into reacting can go into the repairs that make future requests rarer.
