Who Owns What: Responsibility in a Growing Engineering Team

Quick answer: Code ownership in an engineering team works when every module or service has one named owner — a person, not a group. Ownership means quality, documentation, on-call and the right to refuse changes that damage the module. It only works if decision rights are written down: what the owner decides alone, consults on, and escalates. Back it with runbooks and architecture decision records, treat code review as shared standards rather than a gate, and run handover as a checklist when an owner leaves.

There is a size at which a team stops being able to hold the whole system in its collective head — usually between six and twelve engineers, earlier if the product spans currencies, providers and regulators. Before that point, "everyone owns everything" is true and useful. After it, the same sentence quietly becomes "nobody owns anything", and you find out on the worst possible night.

Our founder has run an engineering company since 2019, led a squad of four as tech lead on a real-time market surveillance platform for regulated markets, and spent two and a half years on Wise's core payment platform team. The running example here is a cross-border money transfer product.

Why does "the team owns it" mean nobody owns it?

Because responsibility addressed to a group is addressed to no one. When FX pricing starts returning stale rates at 02:00, "the team owns FX" produces four engineers each assuming a more qualified colleague is already looking — or four all looking at once, stepping on each other. And a group cannot hold a preference: a group cannot say "no, that change makes the payout retry logic unsafe". Only a person can, and only if the organisation agreed in advance that their no counts.

Named ownership is not territory, though. The owner is not the only person allowed to touch the code; they are the person accountable for the module being healthy, and the person a change has to convince.

What does owning a module actually include?

Ownership is a bundle, and handing over only the painful half of it is the fastest way to poison the idea.

• Quality. The owner sets the bar: what tests must exist, what the error budget is, what "done" means here — and holds it.
• Documentation. A current README, a runbook, and a record of significant decisions — the pages someone needs at 03:00 or in their first week, not a wiki nobody reads.
• On-call. In the rotation for their module, and the escalation point when the primary on-call engineer is out of depth.
• The right to say no. Power to reject a change that damages the module's integrity: an unsafe shortcut through the payout state machine, a schema change that breaks reconciliation, a dependency that makes the module untestable.

That last one separates ownership from blame. If someone is accountable for the ledger being correct but cannot refuse a change that makes it incorrect, you have not given them ownership — you have given them the incident review. Ownership without authority is just blame with extra steps. The owner's no should be overridable, but only explicitly, by a named person, in writing; a no that quietly gets routed around is not authority at all.

Ownership also needs real module boundaries to attach to, and a well-structured modular monolith already has them. If everything reaches into everything, you will argue about whose code broke more than you fix it.

Who decides what, and who has to ask?

Most delays in a growing team are not technical. They are a competent engineer sitting on a decision for three days because nobody told them whether they were allowed to make it. That is cheap to fix: write the decision rights down, once, on one page. Three buckets are enough.

Two rules make it work. Consult means consult, not obtain permission — the owner still decides after listening. And the default for anything unlisted is decide alone, then tell people. A table of sixty rows has stopped clarifying and started bureaucratising.

When does "you build it, you run it" work, and when does it become burnout?

It is the best feedback loop in software. The engineer woken by their own retry storm redesigns retries properly; the engineer who never hears about it ships the same design for years. In payments it matters more, because the failures that count — a stuck payout, a duplicate submission, a reconciliation break — are invisible from a backlog and obvious from a pager.

It becomes cruelty under three conditions, all of which the employer has to remove:

• The rotation is not real. One person permanently on call for their own service is not a rotation. A workable one needs enough people for meaningful time off it, secondary cover, and compensation or time back for night work.
• The alerts do not work. If half the pages are noise, on-call is punishment with no informational value. Every alert should be actionable and tied to something a customer or the money would notice; one nobody can act on should be deleted.
• They cannot fix the root cause. The demoralising version is being woken repeatedly by something you are never given time to fix, so the job becomes restarting a service at 04:00 forever. The right to spend a sprint fixing what pages you is part of ownership.

Below roughly six engineers, formal 24/7 on-call may not be staffable at all, and pretending otherwise burns people quietly. That constraint is a real input into when to hire engineers, and one reason teams extend capacity with a dedicated external team instead of stretching the people they have. On-call arrangements and compensation also vary by jurisdiction and contract, so confirm that side properly.

What are runbooks and ADRs, and why are they ownership artefacts?

Ownership that lives only in one head is a liability disguised as competence. Two artefacts turn it into something the company holds.

A runbook is the operational half: how the module is deployed and rolled back, what its alerts mean, the likeliest failures and the exact steps for each, who to call at the payment provider, and what must never be done — for example, never edit ledger rows directly. The test: can someone who does not own the module follow it at 03:00 without phoning the owner?

An ADR — architecture decision record — is the design half, and simpler than the acronym suggests. A short document, often under a page, written when a decision is made, saying four things: the context that forced it ("we must pay out in a country our provider does not cover"); the decision itself, plainly; the alternatives rejected and why — the part everyone skips and the part with all the value; and the consequences, what this makes easy, what it makes hard, what cost you accepted.

ADRs are dated and never edited; if the decision changes, you write a new one superseding it. Without them, someone eighteen months later "fixes" an odd-looking design and reintroduces the problem it was there to solve. Keep both artefacts in the repository next to the code; documentation stored elsewhere drifts.

Is code review a control gate or a way to share standards?

Review is how one owner's standards become the team's. Treated as a gate — permission requested from a superior — it produces resentment upstream and rubber stamps downstream.

Good review: the reviewer reads the change against the module's real constraints, asks questions rather than issuing verdicts, and distinguishes "this is wrong" from "I would have done it differently". Comments are specific and actionable, and the reviewer understands the change well enough to be a second person who could operate it. Turnaround is fast, because a day-long wait is the surest way to stop people asking for review at all. Review theatre is the opposite: approvals in ninety seconds on four-hundred-line diffs, nitpicks a linter should catch, one senior engineer as mandatory approver until they become the bottleneck.

One addition earns its cost: require the owner's review specifically for the sensitive core — ledger entries, money movement, anything touching customer funds — and let any competent colleague review the rest.

What do you do when an owner leaves?

An owner leaving is a normal event, not a crisis, if handover is a process rather than a farewell email. Start it the day notice is given and give it real hours.

• Name the successor first, and announce it. Handing over to "the team" repeats the original mistake.
• Walk them through the runbook by doing it — a real deploy, a real rollback, a real alert response, with the leaver watching and not touching.
• Put the successor on call for that module while the leaver is still there as backup.
• Capture the undocumented decisions. Ask what would surprise someone about this module, and write the answers as ADRs, even retroactively.
• Transfer the relationships — the contact at the payment provider, the person in finance who reads the reconciliation break report.
• List known debt and pending decisions, with the leaver's honest recommendation on each.
• Do the access review: credentials, provider dashboards, production access, signing keys, escalation lists. In payments that is a control, not housekeeping.
• Update the ownership map and decision-rights table so the new name appears wherever the old one did.

The signal that it worked is not a document. It is the successor handling one real incident unaided while the leaver is still contactable and does not need to be contacted.

What is different when the incident involves money?

A normal outage costs availability. A payments incident can move money incorrectly, and every hour of ambiguity increases the amount that has to be unwound. Decide the roles in advance, in writing, before the first bad night.

• Who may halt processing. The on-call engineer must be able to stop processing immediately, without approval, and be thanked afterwards even when the alarm was false. Requiring a founder to be woken first means it happens too late. Make the kill switch explicit, tested and documented — a payments system without a rehearsed stop cannot be stopped safely.
• Who quantifies exposure. One person owns the answer to "how much money, how many customers, over what window, in which direction" — a number with a stated method and confidence, not a guess in a chat thread. Customer messaging, provider conversations and reporting all depend on it.
• Who talks to customers. Never the person debugging. Engineers under pressure promise timings they cannot keep, and an inaccurate reassurance about money is worse than silence. Name a communications owner, agree a holding message, and agree what may not be said before exposure is known.
• Who signs off that money is whole again. Restoring service is not the end. Someone confirms the ledger balances, that reconciliation against the provider's statement is clean for the affected window, that every duplicate or missing movement has a correcting entry, and that corrections went through the normal code path rather than manual database edits. Until they sign off, the incident is open.

One caveat matters more than the rest: in regulated contexts, obligations around incident reporting, customer notification, safeguarding of client funds and record-keeping vary by jurisdiction and licence, and can carry deadlines measured in hours. Nothing here is legal advice — draft the protocol with your engineers, then have a compliance officer or lawyer who knows your licence confirm it, before you need it.

FAQ

How many people should own a module?
One. Have several able to work in it, and a named deputy for holidays, but exactly one person accountable for its health. Two owners recreates the problem you were solving, because each assumes the other is handling it.

Doesn't named ownership create silos and bus factor risk?
Only if ownership is treated as exclusivity. It means accountability, not a lock on the file. The countermeasures are built in: anyone may propose changes, review is cross-team, and runbooks and ADRs exist precisely so knowledge does not live in one head.

At what team size does this become necessary?
Often between six and twelve engineers, but the reliable signal is behavioural: recurring "I thought you were handling that", and the same one or two people absorbing every incident.

What is an ADR, in one sentence?
A short, dated note recording what was decided, what alternatives were rejected and why, and what it costs — written when the decision is made, never edited, superseded if the decision changes.

Who should own the ledger in a payments product?
Your most senior engineer with the strongest appetite for correctness — and it should be the module where the owner's right to say no is least negotiable. The cost of being wrong there is not measured in downtime.

Do we need on-call before we have real volume?
You need someone reachable and a documented path for what they do, which is not the same as a formal 24/7 rotation. Be explicit about the coverage you provide rather than implying one you cannot staff.

Get the ownership map right before you scale the team

Most teams write their ownership map after the incident that exposed its absence. It is a two-hour exercise: list the modules, put one name against each, write the decision-rights table, and agree what happens when the money is wrong.

Tell us how your team and system are structured, and we will review the ownership and on-call model with you — or build the missing half of the team. Request a quote → or book a call with our engineers →.

GPO-Tech designs and builds connected products and commercial software end to end — from one team in Tallinn, Estonia.

Request a quote →