I have about 15 years of experience and currently work in operations on a platform team that supports developers. Around two years ago, a new set of requirements led to an architecture discussion while I was away on sick leave. My manager and several other operations team members chose an approach that, in my view, did not fit the vendor tools or account for the likely access and maintenance problems.
When I returned, I explained my concerns, but the decision had already been made. I followed the direction and implemented the solution as well as possible, despite having to use the vendor product in a way it was not designed to support. As expected, we now deal with recurring access issues and a large maintenance burden. The vendor is unwilling to help because the product is being used incorrectly.
I am not upset that my concerns were ignored as much as I am frustrated that nearly every issue in this area is now assigned to me. I accepted the decision at the time, but I do not want to be the permanent owner of a design I did not choose and had already warned about. How would you handle this and move the ongoing support responsibility elsewhere, especially when fixing the underlying design would take weeks and the current workload is already heavy?
4 Answers
You may not be able to escape the system immediately, but you can stop accepting unlimited responsibility for it. Respond to new requests with the documented impact and ask the manager to prioritize them against your other work. Avoid becoming the person who fixes every symptom while nobody funds the root cause. If leadership refuses to change ownership, capacity, or design after the risks are clearly documented, that tells you the problem is organizational rather than technical.
A replacement platform may be the right long-term answer, but it still needs to be planned work. Do not build it on top of your existing responsibilities for free. Present it as a project with an estimate, milestones, and trade-offs, then ask what current work should be paused. You can also request that another engineer shadow the existing system so the knowledge and ticket load are no longer concentrated on you.
Make ownership explicit instead of trying to quietly redirect individual tickets. Document the architecture, the known failure modes, the warnings you raised, the vendor limitations, and the estimated cost of fixing or replacing it. Then take that to your manager and ask for a formal decision: either give you capacity and authority to redesign it, or assign a named service owner and support team. Until ownership is agreed, the work will keep falling to the person who knows the system best.
That makes sense. I should frame this as an ownership and capacity problem rather than simply saying I dislike the design.
Do not make this personal or try to prove that the original decision was stupid. Treat it as a risk-management issue. Prepare a short document showing the recurring incidents, time spent supporting them, business impact, vendor guidance, and realistic remediation options. Ask leadership to prioritize one of those options. If they choose to keep the current design, get that acceptance and the associated support expectations recorded.
The replacement would probably take several weeks, so getting agreement on what gets deprioritized is the difficult part.