I recently finished deploying a gateway configuration across every environment, from development through production. The client had previously approved the setup, and it had worked for about a year, but they suddenly insisted that it was fundamentally wrong and that the frontend and backend should never communicate through that gateway.
This has been part of a much larger pattern. Most of my time has gone into opening and responding to tickets, explaining what others should write, waiting for client decisions, repairing changes made by the client, dealing with supposedly transparent upgrades that caused outages, and answering calls about timeouts originating in systems we do not control. The client also makes infrastructure changes without notifying us, such as moving a database node without updating listeners, then expects us to restore everything when the environment breaks.
I have been busy constantly, but it feels like I have produced nothing meaningful. Aside from changing a few policies and server variables, deploying applications, clearing blocked pipelines, and fixing issues caused by other teams, there is no obvious result to show for the work. How do you deal with clients who change direction, break their own systems, or reject designs they previously approved without feeling like you are failing or wasting your time?
3 Answers
If the client paid for the service and is making the decisions, explain the risks and recommend the safer approach, but document the final decision when they choose something else. Keep records of approvals, requested changes, warnings, outages, and who owns each action. That protects you and makes it clear that you are implementing a decision rather than secretly endorsing it.
You are not doing nothing—you are doing operations work. Keeping an unstable environment running, restoring pipelines, coordinating changes, and preventing outages may not create a visible feature, but it is still valuable work. The problem is that the value is mostly invisible until someone stops doing it.
This sounds like a constant firefight caused by poor change management. Set boundaries around notification, maintenance windows, rollback plans, and architectural approvals. If they change a dependency without telling you, treat it as an unplanned change with a documented impact—not as a normal support request that your team is expected to absorb silently.
The difficult part is that management often only sees the recovery time, not the unannounced change that caused the outage. Tracking those incidents is probably the only way to make the pattern visible.
That makes sense. I think the lack of written ownership is what makes every client decision feel like it becomes my responsibility later.