---
id: KB-PS-015
url: https://app.codecontract.io/help/getting-started/who-should-own-this-internally
idioma: en
categoria: primeros-pasos
subcategoria: configuracion-inicial
audiencia: administrador
nivel: basico
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-PS-005, KB-CR-011]
citadoPor: [KB-PS-019]
---

# Who should own this internally

_The person who makes it work is not the most technical: it is whoever suffers the problem today._

**Responde a:** who should own the platform internally · internal rollout owner · should it be IT or the department · who administers the tool

It is the least considered decision and the one that most determines whether this sticks or gets abandoned. It usually gets settled by elimination — "let IT handle it", "let whoever has time handle it" — and both outcomes fail for the same reason: whoever owns it is not whoever has the problem.

## The three usual profiles

| Profile | What they bring | Why it fails if they are the only one |
| --- | --- | --- |
| Whoever suffers the problem | Knows what has to happen and notices when it works | May lack backing for decisions that affect everyone |
| IT | Solves access, domain, integrations | Does not know what documentation you require or why, and should not decide it |
| Management | Unblocks decisions and budget | Alone, nobody uses it day to day |

> [!IMPORTANT]
> The combination that works is the first with occasional support from the other two: **the owner is whoever chases documents today**, IT steps in for domain or access work, and management appears to decide what crosses departments. Making IT the owner is the commonest and costliest mistake: they end up administering a tool whose purpose they do not live.

## What the owner must be able to do

**En corto**

- Decide what is requested and from whom, without asking permission each time.
- Change a template or an alert the same day it turns out not to fit.
- And say no to adding things before the basics work.

The third is most underestimated. As soon as something starts working, requests arrive from other departments, and an owner who cannot say "that comes later" ends up with five half-built processes instead of one finished.

## The mistake of sharing it out

> [!WARNING]
> Two people "owning it together" without one being responsible is the most reliable formula for nobody owning it: each assumes the other reviews what is pending, and neither decides when a decision is needed. One is responsible and the others help — and that is said out loud on day one, not inferred.

## How much time it really takes

1. **The first two weeks: a few hours** — Building the process, testing it, correcting it. That is when it is most needed.
2. **The first quarter: a while each week** — Checking what is stuck, tuning alerts, answering the team's questions.
3. **Afterwards: half an hour a month** — The tidy-up and the access review. If it needs much more, something is built more elaborately than necessary.

> [!NOTE]
> If that person leaves or changes role, the handover is explicit: who picks up the owner's role, by name. An owner who disappears with no successor is the commonest reason a rollout that was going well fades within three months.

**What if we are too few to name anyone?**

Then the owner is whoever chases documents most, even if that is the manager.

**Can an external adviser own it?**

They can operate it, but the decision owner has to be inside.

**Does it have to be someone technical?**

No. The technical part is small and occasional.

## Ejemplos

**A company hands the rollout to IT and two months later nobody uses it.**

- Names the person who chased documentation as owner
- Keeps IT for domain and access work

→ The process adapts to what actually happens and usage rises with no extra training.

**The named owner has no time allocated for it.**

- Reserves fixed hours each week during the rollout

→ The project stops competing with the day's urgencies.

**Someone is named who cannot decide how the work is done.**

- Picks someone who can change the procedure, not only run it

→ Adjustments are applied without asking permission each time.

**The owner leaves and nobody knows how it was set up.**

- Documents decisions inside the process itself
- Keeps a second person with access from the start

→ One person leaving does not freeze usage.

**IT builds the process and whoever uses it does not recognise their work in it.**

- Has it designed by whoever chases the documentation today

→ The process resembles the real work from the first version.

**Nobody knows who to ask when something does not fit.**

- Announces who the owner is and how to reach them

→ Questions reach somebody instead of becoming excuses.