Who delivers the work, and how the work becomes value we keep
In week one you will hear two things nobody has defined for you. Someone will ask which POD you are on. Someone else will say we are leaking value. A POD is the team that delivers one client. The value chain is how that delivery becomes value ORIGIN keeps. This section defines both.
Section 02 covers the House Framework, Section 03 the engagement models, Section 04 guardianship. This section sits beside them and does not repeat them.
What a POD is
A POD is a delivery unit. One POD is one client. There are no shared teams, so the client you work for never sits in a queue behind somebody else. That one rule is what most of the machinery below exists to protect.
POD stands for Product Oriented Delivery. Every POD is led by a Team Lead, the single point of accountability for delivery and for client satisfaction. A POD is built around the scope in front of it, not around whoever is free that month. If you do not know who decides something inside your POD, start with your Team Lead.
Source: Register tab 9 row 11; The ORIGIN POD Model Framework, version 1.0, January 2026
How a POD is staffed
Three kinds of people can sit in one POD: ORIGIN full time employees, freelancers, and agencies subcontracted for a defined scope. The mix is deliberate, and there are three standard shapes.
| Composition | When we use it |
|---|---|
| Fully internal, employees only | Sensitive data or IP, deep transformation, strategic accounts, all BOT work |
| Hybrid, employees plus freelancers or agencies | The most common shape. A specialist skill or extra capacity is needed. |
| Fully external, freelancers or agencies only | A specialist build, overflow, or testing a capability |
Three staffing rules that do not bend
- The Team Lead is always an ORIGIN full time hire. The client relationship, quality control and delivery accountability are never outsourced.
- You can work across more than one POD only if those PODs report to the same Team Lead. One person stays answerable for your workload, and you have one place to take clashing deadlines.
- Subject matter experts sit on the delivery side of the house, not under your Team Lead, and are borrowed into a POD when needed. Requests go through your Team Lead.
Source: POD Model Framework, January 2026; Register tab 9 row 24
The POD lifecycle, mobilisation to close
| Stage | What happens | Who owns it |
|---|---|---|
| 1. Proposal | A Team Lead is assigned on bandwidth first, expertise and timezone secondary. A preliminary team is scoped so the deal can be priced. | OS Team, then Team Lead |
| 2. Formation | Deal closes. The Growth Team hands over a documented package with a recorded debrief. The POD is named after the client, and Growth, OS and the Team Lead attend the kickoff. | OS Team and Team Lead |
| 3. Execution | The Team Lead runs daily work, client communication and quality. The OS Team gives oversight and expert support. | Team Lead |
| 4. Close | Completion, contract end or termination. Knowledge transfer done, client offboarded, talent released. | Team Lead |
Formation also builds your workspace: an internal WhatsApp group for the ORIGIN members, an external group including the client, and an Asana project named after the client. Asana is the single source of truth for tasks, timelines and deliverables. A decision made on a call or on WhatsApp is logged as an Asana comment within 24 hours. WhatsApp stays conversation only.
Source: POD Model Framework, January 2026; Register tab 9 row 22, tab 8 rows 4 and 10. BD and Sales retired as labels, 17 July 2026
What changes when a client arrives or leaves
A new client gets a new POD. Work is never bolted onto an existing team, because that breaks the one POD one client rule and puts two clients in one queue. Before delivery starts, a new client passes the client onboarding gate: a decision of start, start capped, or hold, plus the reconciliation checklist. Work before signature happens only under an approved cap.
A client leaving triggers the close stage above, not a quiet fade. A Team Lead changing is its own sequence: the OS Team decides, Asana access and documentation transfer from the outgoing Team Lead, the incoming Team Lead shadows, and the client is introduced with both present. The Head of OS owns the financial approval points on a POD, a role held on an interim basis by Marwan Arban until it is hired.
Source: Register tab 8 row 17, tab 10 row 7; POD Model Framework, January 2026
COMMERCIALS STAY IN THE REGISTER
Every POD carries a gross margin target and a cost escalation point. Those figures are not yours to quote, and the POD Model Framework of January 2026 carries a margin the register has since superseded. The live figures sit at Register tab 10 rows 3 and 13. Commercials go through your Team Lead.
The value chain, the sixth framework
The value chain explains why the other frameworks work: how ORIGIN creates value, captures it, and protects it. Creation runs in four stages, extending the three House Framework phases by one.
| Stage | House phase | Value created | Client says |
|---|---|---|---|
| Discover | Audit | Clarity | We know the path |
| Build | Fix | Foundation | We have the tools |
| Activate | Grow | Growth | We are growing |
| Sustain | Transfer | Continuity | It keeps working |
Five enablers power it: the POD model, the SME bench, the supplier hub, three level governance, and guardianship. They are drawn as a set, because removing one weakens the whole capability. Underneath sits the protection layer: methodology we own, the integration moat of strategy, brand and technology under one roof, accountability for execution, and leakage prevention.
Value capture is where the engagement models differ. Learn the order, not the numbers. Lowest margin to highest: Build, Build and Operate, Build and Guard, BOT. Build runs on efficiency and tight scope, Build and Operate on utilisation, Build and Guard is highest because it carries no execution burden, and BOT carries a premium for taking the risk of the transfer.
Source: Register tab 10 rows 11 and 12, tab 9 rows 12, 24, 25; value chain deck slides 4 to 7
Where value leaks
| Leak point, and what it costs | What stops it |
|---|---|
| Scope creep. Work done, never priced | Change request process, written scope, a Team Lead who pushes back |
| Weak Growth to OS handover. Wrong expectations, rework | Formal package, recorded debrief, authority to reject an incomplete brief |
| Underpriced deal. Squeezed from day one | Team Lead in the room at proposal stage; approval gates |
| Client delays. Timelines stretch, people idle | Dependency tracking, contract clauses, early escalation |
Why this matters to you
Three of those four leaks happen inside a task list, which is where you work. A request accepted in a WhatsApp message is scope creep. A deliverable that slips quietly is a stretched timeline. A dependency you did not flag becomes ORIGIN cost instead of client cost. Fewer than two scope creep incidents per engagement is the target, and one round of feedback per deliverable is the quality standard.
Source: Register tab 10 rows 13 and 14, tab 8 row 16; value chain deck slide 8
TO CONFIRM
Three things are unsettled, so do not quote them to a client until Marwan Arban rules. On time delivery: tab 10 row 13 targets above 90 percent, tab 8 row 16 gives 80 percent or above against the proposal. SME response: tab 9 row 24 and tab 10 row 13 both read under 48 hours, and neither says working or calendar hours, nor when the clock starts. Ask your Team Lead which reading your POD uses. Framework count: the register calls the value chain the sixth framework, the deck numbers it 05 of five, and the register governs until ruled.
A POD is not an org chart. It is a promise that one named person is accountable for one client, and the machinery above keeps that promise affordable.