ADR 0001 — Loops over functional teams

Status

Accepted.

Context

Most marketplace businesses organise into functional teams: marketing, sales, customer success, ops, product, data. Each team optimises for its own metric. Handoffs between teams introduce blame seams (marketing blames sales, sales blames product, ops blames marketing) and make it structurally hard for anyone to own an end-to-end outcome.

Rentiful is small enough that functional organisation would actively slow it down. The work that matters — turning demand spend into signed, invoiced leases; turning operator supply into accurate, converting units — is a single chain in each case. Splitting that chain across three or four functions would re-introduce the exact handoffs that small companies can move without.

Decision

Organise Rentiful around loops: full accountable chains from signal to closed outcome, each owned by one person end-to-end. The loops are:

Primary (revenue-generating): Operator Loop, Renter Loop.
Secondary: Platform Loop, Financial Loop, Fundraise Loop, Strategy Loop.

A loop owner is accountable for the entire chain. No internal handoffs. Work is delegated through automation, agents, and contractors, but not by splitting accountability.

Where ownership is genuinely split — rare, and only justified by volume — a sub-loop is created. Sub-loops have their own accountable owner. The absence of a named owner means no sub-loop exists.

Consequences

Loop owners have broader remits than functional managers. Hiring and training target that breadth explicitly.
Metrics are loop-level. No loop can hide behind a handoff ("marketing hit its number, sales missed"). A missed signed-lease target is a loop failure, full stop.
Cross-loop dependencies are explicit and named. See cross-loop.md.
Sub-loops must be resisted until volume forces them. Premature splits recreate the problem this decision exists to solve.

Alternatives considered

Functional teams. Rejected: too slow, reintroduces blame seams, inappropriate for current scale.
Pod / squad model. Rejected as an unnecessary abstraction; "pod" is typically a loop by another name, with less explicit accountability.
Outcome-based teams with shared ownership. Rejected: shared ownership is no ownership.