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.

Never underestimate the per-user cost spike.

The full title of this post should really have been “Do not underestimate the cost per user on a small, well-planned project versus both a proof of concept and a ‘at scale’ system”, but that would have just looked silly.

One thing that is overlooked time and time again,        and eventually catches up with every project,        is that there is a jump in costs per active user when you go from a proof of concept to something that can work at scale before the advantages of a large-scale project starts bringing the costs back down.

Let me explain.

A proof of concept exists to answer a simple question. Will this work? Whether it is an application, a migration, or any other kind of system, particularly in a corporate environment, the aim is validation rather than longevity. The challenge comes when moving from that early validation to a solution that is robust, commercially sensible, and capable of operating at scale with a reasonable cost per user.

Between those two points sits a significant and often underestimated investment. It is the cost of building proper foundations.

This tends to appear most clearly in two common scenarios.

The first is the seemingly small project. For example, moving a limited number of users from one system to another, or implementing a narrowly scoped solution. The proof of concept is completed, the demonstration goes well, and confidence is high. Then the implementation costs are presented, and everyone has a heart attack. It only has ten users, so why does it cost so much?

The answer is that the cost is not driven by the number of users. It is driven by the need to build something correctly. Even for a small user base, the underlying architecture, security, supportability, and operational processes still need to be in place if the solution is to be reliable.

The second scenario is more subtle but ultimately more disruptive. A proof of concept is seen to work well, and the decision is made to move it directly into production. Initially, this can appear successful. It may run for months, sometimes even years, without major issues. However, without those foundational elements being in place, sooner or later things are going to go bang, and always at the least convenient moment.

When they do, they are rarely simple to fix. It is not a case of adding a little more budget or introducing a small process improvement. Instead, it often requires going back and rebuilding the core of the solution properly. By that point, the cost is usually higher than if it had been done correctly from the outset, as there is the added complexity of undoing or reworking what is already in place.

In effect, the cost has not been avoided, only delayed and now with interest.

When moving from a proof of concept to a production system, it is important to anticipate this increase in cost and to communicate it clearly to stakeholders. Likewise, when delivering something that appears small today but has the potential to scale in the future, the investment in solid foundations can seem disproportionate.

It is natural for that to prompt questions and resistance. However, it is worth being clear that reducing that investment rarely removes the cost. More often, it shifts it into the future, where it becomes more expensive and more disruptive to address.