I've worked in the industry for nearly 15 years and joined my current company about two years ago as an operations engineer on the platform team. Things were running smoothly until a new set of requirements led to a major architectural decision.
While I was out sick for two weeks, my manager and several other operations team members designed the solution. I believe they made the best decision they could with the information and experience available, but I also think a short proof of concept would have exposed many of the problems we're dealing with now.
When I returned, I reviewed the design, raised my concerns, and ultimately followed the decision under a "disagree and commit" approach. I implemented the solution as well as possible, even though the vendor's tools were not designed to be used this way.
The system now causes frequent access and integration problems, and nearly every issue involving this domain gets assigned to me. I'm not surprised by the problems because I documented my concerns beforehand, but the system has become a major maintenance burden. Fixing the underlying design is difficult because the vendor does not support this use case.
How would you approach getting this work off your plate or changing ownership, especially after the risks you identified turned out to be real?
3 Answers
Start by making the ownership problem explicit rather than informally trying to avoid tickets. Explain that you implemented the agreed design, but ongoing support requires a clearly named service owner and an agreed support model. Ask the manager who should be accountable for prioritizing fixes, handling escalations, and approving future changes. Keep the discussion focused on workload, operational risk, and responsibilities—not on proving that someone made a bad decision.
Create a documented improvement proposal for a supported alternative. Include the current failure rate, time spent maintaining the system, security or access risks, vendor limitations, and a rough estimate for replacing or redesigning it. Then ask management to prioritize that work against your existing responsibilities. If they choose not to fund the change, make the trade-off visible and get that decision recorded instead of quietly absorbing all the extra work.
A better platform could probably be built in a few weeks, but I already have a full workload. I’d need management to explicitly decide what current work should be delayed.
You may not be able to remove the system immediately, but you can stop treating every problem as an unplanned personal obligation. Establish a triage process, publish support boundaries, track recurring incidents, and require capacity or priority decisions for additional work. If the organization refuses to change ownership or allocate time for remediation, then the remaining options are to accept the burden as part of the role or look for a position where operational decisions and accountability are handled more effectively.
I only implemented it because management asked me to proceed after the decision had already been made. I’m concerned that the same decision will now leave me responsible for maintaining it indefinitely.