The Approach — Section 03

Role Transformation

From a dedicated owner for every task, to stewards who can work anywhere

The Pattern You Want to Change

Dedicated people for every task. A sensible response to an unwritten codebase, and a hard ceiling.

Work settles into ownership. One engineer knows the calculation engine. Another knows alerting. A third knows the back-office integration. That is not bad management. When the knowledge needed to work safely in an area lives in someone's head, concentrating that area in one person is the fastest arrangement available.

What the ceiling looks like

Two requests land in the same fortnight, both in the same module Request A Request B ONE PERSON the only safe route in One goes first the other waits Adding an engineer does not help the constraint is knowledge, not hours Bus factor of one Leave, illness or resignation in the wrong week turns a normal delivery into a crisis Reviews are nominal If one person understands the area, their PRs get approved, not reviewed Knowledge decays Undocumented context fades even in the owner's head. Why a threshold was set: lost The actual cause Context is not written down anywhere fix that first

Dedicated ownership is the symptom, not the disease

The disease is that the context needed to work safely in an area is not written down. Reorganising the team without fixing that would be worse than doing nothing — you would remove the one thing currently making the work safe. That is why the knowledge base comes in Stage 1, and the role change follows in Stages 4 and 5, once there is something for a non-owner to lean on.

Owner → Steward

One change in what the role means. It moves throughput a lot.

Module owner — today
  • Does all the work in their area
  • Is the only safe route into that code
  • Holds the context privately, because there is no other option
  • Becomes the bottleneck when demand spikes
  • Cannot take clean leave without risk
→
Module steward — target
  • Owns the quality bar and the written context for the area
  • Reviews and approves. Does not have to author everything
  • Keeps the module's memory current — a named duty
  • Any engineer plus the fleet can author. The steward gates it
  • Leave is survivable, because the context is in the repo

Not a headcount argument

Nothing in this plan proposes reducing the team. In a boutique firm the constraint is delivery capacity against a growing book of client requests and regulatory obligations. The goal is to raise what the current team can absorb, and to remove the single-person dependencies that make certain weeks fragile. If this works, the same people ship more, and nobody spends their week on the parts of the job they would happily never do again.

Role by Role

What each role drops, picks up, and keeps

RoleStops doingStarts doingKeeps, fully
Product / BA Writing every spec from blank; chasing scope by asking around Editing drafted specs and answering the open questions the agent raises What gets built, for whom, in what order
Developer Boilerplate controllers, view models, mappers, CRUD; reading code to find what a change touches Reviewing and correcting drafts; designing the hard parts; working outside their usual module Every line that reaches a branch under their name. The code is theirs, however it was drafted
QA Engineer Hand-writing routine cases; repeating the same regression every release Strengthening generated cases; exploratory testing; owning the golden datasets What correct means, and whether something is ready
Tech Lead Being the human index of what lives where; manual impact analysis Guarding the API contract; approving designs and breaking changes; keeping the standards real Architectural direction and the integrity of the product
Domain Owner — this plan formalises the role rather than changing it Curating golden datasets; signing off every restricted-zone change Correctness of the numbers n.tasc produces. This never moves to an agent
DBA Writing routine migration and rollback scripts from scratch Reviewing generated scripts, plans and index implications; running them All execution against any environment. Agents hold no write credentials
Release Manager Assembling release notes and working out what is in a build by hand Reviewing the assembled UAT pack; running one standard pipeline The go / no-go call on every release
Support Escalating every bug to the one engineer who knows that module Filing into a triage flow that locates and reproduces it first The client relationship and what was promised in it

How the Transition Happens

Four moves, in this order. Skipping one is how these things fail.

Sequence
Each step depends on the one before it
1
Write it down
Stage 1. Module docs, domain glossary, code patterns, past decisions. Agents draft it. Owners review it — they are the source.
2
Prove a non-owner can
Stage 3. One change goes to an engineer who does not own the module. Where they get stuck is the list of what memory is missing.
3
Name the stewards
Stage 4. Each module gets a steward with a written remit: keep the memory current, review changes, do not be the only author.
4
Route by capacity
Stage 5. Once two engineers have shipped in an area, work goes to whoever is free. Bus factor becomes a monthly number.
1
Engineers who can ship in a module — today
2–3
Target after Stage 5
Monthly
Bus factor reported to leadership

What the current owners get

Worth saying to them directly and early: nobody is being replaced or diluted. The engineer who owns the calculation engine today stops being interrupted for every small change in it, gets a real reviewer, and can take leave without writing a handover at midnight. Being the only person who can touch an area is a career risk as much as an organisational one.