Although the title sounds cynical, this is not intended to be a cynical post. In my role across integration, security, and general problem solving in architectural and IT spaces, “that’s not my responsibility” or “that’s not our department” is one of the most common responses I hear. It is also, in many cases, a perfectly reasonable one.
So it is worth taking a moment to understand why this response exists, and then look at how to work through it in a practical and human way.
Why does this happen?
In my experience, this response is very rarely driven by malice or laziness. It is usually a rational reaction to long term consequences.
Taking responsibility for something in a corporate environment often means owning it indefinitely. Processes and systems can live for decades. What looks like a small favour today can turn into an ongoing obligation that requires budget, support, and accountability years down the line.
There are also risks. If something goes wrong, particularly where there are compliance or legal implications, the person or team that accepted responsibility may be held accountable. That is a serious consideration, especially if they were not involved in shaping the original solution.
The more complex or unclear an issue is, the more likely it is that ownership is undefined. At that point, it effectively becomes a hot potato. People are not avoiding work, they are avoiding inheriting long term risk without the ability to properly manage it.
So how do you get things done?
When you need something fixed or owned, and everyone is stepping back, there are a few practical approaches that tend to work. None are perfect, but each has its place.
1. Escalation
This is the blunt instrument. Sometimes you need to escalate to someone who sits across both areas and can make a decision.
It works, but it should be used sparingly. Overuse damages trust and can give you a reputation for frankly being a bit of a d*** or only caring about your side of any problem.
2. Providing budget or resource
This is often the most effective and least confrontational approach.
If a team is constrained by time or funding, removing that constraint changes the conversation entirely. Offering budget, a cost centre, or even additional resource can turn a “no” into “when do you want it”.
Clarity helps. “I can fund this, when can it be delivered?” is a very different discussion to “can you do this for me?”
3. Removing competing pressure
Sometimes the issue is not the work itself, but competing demands.
If you can help reduce noise around a team by handling or deflecting other requests, you create space for your work to be considered properly. It also demonstrates that you are contributing, not just demanding.
4. Taking responsibility yourself
This works more often than it should.
By formally taking ownership, even temporarily, you remove the long term risk for others. A simple, clear statement of responsibility can be enough to unblock progress, especially if it protects the other team from future audit or support obligations.
It is about giving people confidence that they are not inheriting unknown liabilities.
5. Formalising ownership
This is the most sustainable option, but also the slowest.
If responsibility is unclear, define it properly. Get agreement, document it, and ensure it is recognised at an organisational level. This allows teams to plan, budget, and defend their position in future.
It also creates a repeatable process. Once something has been formalised once, it becomes easier to apply the same approach again.
The most important part
Whichever route you take, there is one thing that matters more than anything else.
Clean up after yourself.
Do not leave behind unclear ownership, unmanaged risk, or hidden technical debt. Do not put someone in a position where they will be questioned months or years later without context or support.
Reputations in this space last a long time. People remember who made their lives easier and who made them harder. The industry is smaller than it appears, and those impressions carry forward.
Solve the problem, but leave things in a better state than you found them.