Ownership instead of roles: who is really accountable after go-live

Ownership is the silent assumption behind every organisational design. It suggests that someone is accountable simply because a position is named a certain way. In practice, a role without clear authority, resources and availability often means nothing. Accountability only arises when a person or a small team says: "This system, this process, this decision — that is on me."

What distinguishes ownership

Ownership has four properties that roles do not automatically bring:

• Named: A concrete person or a concrete team, not an anonymous function.
• Empowered: The person may make decisions without passing through committees.
• Resourced: There is time, budget and competence to exercise the responsibility.
• Measurable: It is clear what success of ownership looks like.

A role may have all of this, but it does not have to. Especially in small and medium-sized companies where one person wears several hats, the boundary between "responsible for" and "informed about" quickly blurs. The result is an organisational structure that looks neat on paper and leaves gaps in operations.

Where ownership is missing most

The most critical places are the transitions: from architecture to delivery, from delivery to operations, from operations to adoption. At each of these points responsibility changes owner — and if that is not spoken out loud, it gets dropped.

The transition into operations is especially underestimated. A system that technically runs but belongs to nobody ages faster than expected. Security updates, adjustments to new business processes, fixing errors that are not immediately visible — all of this does not happen because nobody has an incentive to do it.

Adoption is the most expensive transition. Here the question is whether people actually work with the system. This is not a training issue; it is a connection issue. The person in the business unit who represents the system must speak the department's language, know its processes and have enough authority to clarify questions and address resistance.

The ownership map

A simple tool we use during the initial phase is the ownership map. It answers four questions for an initiative:

1. Who decides? Who has the final word on architecture, priority and budget questions?
2. Who builds? Who is responsible for technical implementation and quality?
3. Who operates? Who looks after monitoring, incidents, updates and maintenance?
4. Who explains? Who is the contact person for the business unit and users, who represents the system?

This map takes an hour and later answers the questions that would otherwise circle for weeks. It belongs in every major initiative, and it is reviewed with every significant change.

Ownership and vendors

When an external partner builds a system, the ownership question becomes even more important. Many projects end with a handover that is documented but not lived. The vendor leaves, and the company is left with a system that nobody internally understands.

That is why we plan the ownership handover from day one. That means the future operations team is involved early, decisions are documented, and the handover is not a single event but a process that runs over weeks. Our ownership and team setup is designed for exactly that.

How to cultivate ownership

Ownership cannot simply be assigned. It arises when three things come together:

• Understanding: The person understands the system, its value and its limits. That takes time and involvement.
• Authority: They may make decisions without having to escalate every detail.
• Backing: The organisation stands behind the decision, even when it is inconvenient.

If these three are not brought together, you get responsibility without power — the classic recipe for frustration and flight.

Short version

Roles describe who should do what. Ownership says who actually stands for it. After go-live, only the latter counts. The transitions between architecture, delivery, operations and adoption are where ownership is most easily lost. An ownership map that names from the start who decides, who builds, who operates and who explains closes those gaps — and is the difference between a system that runs and one that lands.

Why teams need to be able to carry this in the first place is covered in teams that carry transformation.