The owner role as a job description

The job in one line

An owner is the person responsible for how the work is done in one domain — sales, finance, supply chain, the system itself.

The job is governance, not implementation: set the method, settle the calls, keep the knowledge right as the work evolves.

The owner doesn’t do all the work in the domain, and doesn’t build the machinery — the builder does that.

The owner is accountable for the domain staying coherent.

The three records you run on

Every domain keeps three records at its root, and the owner job is the discipline of keeping them current.

• ROADMAP.md — what the domain is building next, in order.
• You write the deeper machinery here for the builder to pick up.
• DECISIONS.md — the method calls you’ve made, dated, append-only.
• When the team disagrees on how the work should be done, you decide, and the decision lands here so it isn’t relitigated every month.
• FEEDBACK.md — the friction the domain has hit: corrections, gaps, things that drifted.
• This is the inbox you drain.

In the supply chain domain, two of those sit at the root already — ROADMAP.md and DECISIONS.md.

For a domain that keeps all three at its root, look at this curriculum’s own FEEDBACK.md, alongside its ROADMAP and DECISIONS.

The knowledge files are the fourth piece — the canonical method everyone’s work inherits.

You curate those too; the three records are where the running job lives.

The habits

Three habits keep those records honest, and they’re the same across every domain.

• Curate the knowledge. Everyone’s work is only as good as what’s written in the domain’s knowledge — keep it matching real practice.
• Make the method calls. Settle a disagreement and write it to DECISIONS, so the team stops asking the same question.
• Drain the feedback. Walk what’s drifting in FEEDBACK and fix it.

You hold the direction; I carry the detail.

The cadence

Drain FEEDBACK on a regular beat — weekly is the common one.

Each pass: read what came in, fix what’s a quick correction, and roadmap what’s a deeper build.

The cadence is the whole job.

Skip it and the knowledge falls behind real practice, and every answer the domain gives gets a little more wrong.

It takes domain judgment, not engineering

The owner is the person who already knows how the work should be done — how the company wins deals, how supply gets ordered.

The system supplies the engineering; the owner supplies the judgment about the craft.

What matters, in order:

• The judgment to tell good work from sloppy work in that domain.
• The decisiveness to settle a method call and move on.
• The instinct to notice when the written method has fallen behind, and to fix it.

The role does not require writing code, being on call, or holding every fact in your head.

To assign it, pick the person who already owns the craft

The right owner is usually the one the team already turns to for "how should we do this" questions.

You’re formalizing an existing reality more often than creating a new one.

Where you’re choosing between two people, the tiebreaker is judgment about the craft, not comfort with the technology.

Say it to me plainly:

"Patrick is the person the sales team asks how to handle a tricky renewal — does that make him the right owner for the sales domain?"

Then make it official through the roles model

Naming someone in conversation isn’t the grant.

The grant runs through a named part of the system — the roles model, the workspace’s record of who owns and builds each domain.

It’s enforced: when someone owns a domain, the system gives them write access to that domain’s knowledge and decisions and blocks everyone who doesn’t.

Three parts to making it official:

• Name one owner per domain. Co-ownership blurs the very decision rights the role exists to make clear — when two people own the method, "who decides" is exactly the question that goes unanswered.
• Grant it through the roles model so the write access is recorded and enforced, not assumed.
• Set up their profile. Their profile is the file that tunes how I behave for them — voice, priorities, defaults — so the system knows who it’s working for.

Say it to me as the leader assigning the role:

"Make Patrick the owner of the sales domain — grant it through the roles model, and set up his profile."

Set them up to learn it

For someone who already has the domain judgment, the role is learnable in about a month.

Hand it over in three moves:

• Point them at these Own modules — the role explained end to end.
• Pair them through their first review — sit with them the first time they drain FEEDBACK and make the calls.
• Let them run the second review solo — that’s where the role becomes theirs.

One person can own several domains, and can be both owner and builder on one.

When they wear both hats, switch hats out loud, so every call is made from a known role.

The one thing to remember

The owner brings domain judgment, not engineering, and the job is the discipline of three records — ROADMAP for what’s next, DECISIONS for the calls you’ve settled, FEEDBACK for the friction you drain on a cadence.

Name one owner per domain, grant it through the roles model so it’s enforced, set up their profile, and walk them through their first review.

Next: the boundary in practice