Clear accountability for the technology decisions that shape your business

Take a technology decision your organisation has decided to hold constant and ask a simple question: if somebody proposed changing it next month, who would be asked first?

Most organisations answer with a team. Platform would raise it. Security would push back. Compliance would want a word. Each answer sounds like there is someone responsible for protecting the decision. But when a decision is actually challenged, that responsibility may not be as clear as it appears.

This matters because technology decisions rarely stay isolated. A security control can affect how a system is built. An architectural principle can influence cost and performance. A governance requirement can shape how teams work. Over time, decisions that began as technical choices can become part of how the business operates.

When priorities change or deadlines tighten, someone has to recognise when an agreed decision is being challenged and decide whether it should hold or change.

Who is that person?

 

Shared ownership strengthens execution, but accountability still needs clarity

There is a good reason organisations share responsibility for their technology environments. People leave, priorities change and important knowledge can disappear with them. If a critical responsibility sits with one person, their absence can create a gap. Shared ownership provides cover, preserves knowledge and helps work continue when people or priorities change.

It is particularly effective for execution. Several people can contribute, review decisions, identify problems and support one another. The contributions add up.

Defending a decision is different.

When a proposed change conflicts with an agreed security control, architectural principle or governance requirement, someone has to recognise the conflict and speak. This usually happens at a specific moment, often when a project is under pressure and everyone is focused on delivering.

At that moment, the contributions do not add up in the same way. Someone has to make the decision to speak.

Having several people who could speak does not necessarily mean that someone will.

 

Pressure reveals whether ownership is clear

Consider a team preparing to deploy a new workload. The deadline is approaching, and someone proposes bypassing an agreed security control to get the deployment completed faster.

Security knows the control is important. The platform team knows it exists. The architect understands why it was introduced.

But who is responsible for challenging the change?

The security lead may assume the architect will raise it. The architect may expect the platform team to flag it. The platform team may assume security will object if the change is serious.

Nobody is necessarily being careless. Each person is making a reasonable assumption.

That is what makes the problem difficult to see.

When a commitment is shared by everyone, each person who could raise it can also assume that someone better placed will. That assumption costs nothing. It is usually reasonable, and it is available to everyone in the room at the same time.

Speaking up is different. It can slow the discussion, challenge the direction of travel and create friction when a team is working towards a deadline. Under pressure, it can feel easier to wait for somebody else to raise the issue.

So everyone waits.

The change goes through.

Afterwards, each person can honestly say they thought somebody else had it covered.

 

A documented owner is not always an accountable owner

There is another version of the problem, and it can exist even when the organisation has already documented ownership.

A person's name may sit in an architecture decision record, governance framework or operating model. The name may be correct. But the person may never have been told that this is the decision they are expected to protect.

Someone who does not know they are defending something behaves much like someone who is not. They are in the room, the change is proposed, and nothing tells them that this one is theirs to challenge.

The document is correct, but the ownership is not active.

This distinction matters because technology decisions rarely stay isolated. A change to architecture can affect cost. A change to a security control can affect delivery. A decision made to solve a short-term operational problem can become part of the environment for years.

Ownership therefore requires more than documenting a name. The person needs to understand what they are responsible for, what they are expected to protect and when they are expected to speak.

That gap can often be closed with a simple conversation.

 

What to do this week

Take three commitments your organisation means to keep. Beside each one, write a single person's name.

Not a team. Not a role. Not two people, because two people can each wait for the other exactly as a team does.

Then tell each of those three that they are the person, in those words, and say what they are being asked to protect. That is the whole intervention.

Two things usually come out of it. One of the three will turn out to be genuinely contested, and the argument about who owns it is the argument the organisation had been avoiding. At least one person will also be surprised to learn that they are expected to defend an important technology decision.

That surprise is the finding.

Of the things your organisation holds constant, how many have a person who knows their name is on it?