{"id":11814,"date":"2026-11-11T17:30:00","date_gmt":"2026-11-11T17:30:00","guid":{"rendered":"https:\/\/www.cotocus.com\/blog\/?p=11814"},"modified":"2026-11-11T17:30:00","modified_gmt":"2026-11-11T17:30:00","slug":"decision-rights-explained","status":"publish","type":"post","link":"https:\/\/www.cotocus.com\/blog\/decision-rights-explained\/","title":{"rendered":"Decision Rights Explained: Who Chooses in a Platform Change"},"content":{"rendered":"

“Decision rights” sounds like jargon from a management textbook, yet the idea is something every working team already feels. It simply means being clear about who gets to make which call, and how. When that clarity is missing, a technology change that should take a fortnight drifts for two months. This explainer describes decision rights in everyday language, shows how they apply to a platform change, and offers a small template you can adopt without any special software.<\/p>\n

The idea in plain terms<\/h2>\n

Imagine a team that has to choose between two ways of hosting a new internal service. One option is cheaper and one is easier to maintain. Four people have thoughtful opinions. Without decision rights, the conversation looks like this: each person explains their view, someone suggests collecting more data, the meeting ends, and the same four people meet again next week. With decision rights, one person was named in advance as the one who chooses, a date was agreed, and the group knows how input will be used. The same four opinions are heard, but the conversation ends.<\/p>\n

Nothing more complicated than that. It is not about taking power from anyone. It is about giving the discussion an exit.<\/p>\n

The three ingredients<\/h2>\n

An owner<\/h3>\n

One named person who will make the final choice. Not a committee, not “the architecture group” in the abstract. A committee can recommend, but a single human must be accountable for the outcome and able to say “we are going with option B.” Also name a deputy, so the call does not wait on a holiday.<\/p>\n

A deadline<\/h3>\n

A calendar date, ideally connected to an outside constraint such as a licence renewal or a release window. Without it, every consideration feels equally urgent and nothing closes. With it, people quickly sort what matters from what is merely interesting.<\/p>\n

A rule<\/h3>\n

The way input becomes a decision. There are three common rules. Consensus<\/strong> means everyone agrees or at least does not object strongly. Majority<\/strong> means a vote. Owner decides after consulting<\/strong> means the group is heard and then the owner chooses. The rule should be picked before the argument begins, because choosing it mid-debate invites a fight about method on top of the fight about substance.<\/p>\n

Why this matters more in technical work<\/h2>\n

Technology choices tend to look reversible but often are not. Once data has moved or a team has trained on a tool, backing out costs weeks. That makes teams cautious, and caution without structure becomes delay. Another factor is expertise: people with deep knowledge hold their views firmly, and rightly so. A clear rule allows those views to be honoured without making each of them a veto.<\/p>\n

Teams working on machine learning delivery run into this constantly, because model, data and infrastructure specialists must agree on shared pipelines. If that is your world, the stage-by-stage roadmap for data science and engineering groups<\/a> gives a sense of how many separate choices sit along the road, each with room for ambiguity about who decides.<\/p>\n

A worked example in words<\/h2>\n

Suppose a company wants to retire an older monitoring setup and move to a newer one. The choices include which product to adopt, when to cut over, who trains staff and what to do with historical records. A sensible set of decision rights might be:<\/p>\n