Lesson 5 — Teams, cost and governance
The technical practices in lessons 2 to 4 fail when nobody owns them, when the cost model is misunderstood, or when the system cannot be explained to someone who has to sign off on it. This lesson is those three things.
Who does what
Roles vary by organisation, and the responsibilities are constant.
| Role | Owns |
|---|---|
| Data engineer | Pipelines, data quality, warehouse, availability and freshness |
| Data scientist | Problem framing, feature design, modelling, evaluation |
| ML engineer | Making the model deployable, serving it, performance, monitoring |
| Platform engineer | The infrastructure all of the above run on |
| Product owner | What decision this supports and whether it is working |
| Domain expert | Whether the labels and outputs are actually correct |
Three failure patterns recur:
The handover cliff. Data scientist finishes, throws a notebook over the wall, moves on. Nobody can retrain it. Fix by involving whoever will operate the model from the start, not at the end.
The lone data scientist. One person doing framing, engineering, deployment and monitoring, in an organisation with no infrastructure. They will do the interesting part well and the rest not at all, which is a predictable consequence of the assignment rather than a failing of the person.
Nobody owns the outcome. The model works, the metrics are fine, and nobody is accountable for whether the business result improved. This is how a technically successful project delivers nothing.
The arrangement that works reliably in small organisations is a pair: someone who owns the model and someone who owns the system it lives in, both present from the beginning.
Where the money goes
Teams consistently misjudge this, usually by focusing on the compute line.
Training compute is often the smallest item. A few hundred to a few thousand in cloud GPU time covers a great deal of experimentation, and fine-tuning existing models rather than training from scratch keeps it there.
Serving compute is where real-time deployments accumulate cost, because you provision for peak and pay while idle. Batch prediction avoids nearly all of this.
Data infrastructure — storage, pipelines, the warehouse — is frequently the largest line and is usually shared with the rest of the business, which makes it easy to overlook when scoping.
Labelling is the dominant cost in supervised projects, particularly for anything requiring expert judgement. A radiologist labelling scans is not a cheap hour.
Human time exceeds all of the above in most organisations. Investigation, retraining, monitoring, integration and the meetings that surround them.
The output review process, where a human checks predictions, is a permanent operational cost that gets left out of business cases with striking regularity.
Practical levers, in order of return: use batch where latency permits, use the smallest model that passes evaluation, cache aggressively, schedule training on cheaper interruptible capacity, and delete data and models you are not using.
The technical debt these systems create
A well-known paper on hidden technical debt in machine learning systems identified patterns that remain accurate. The ones worth recognising:
Entanglement. Change one input and everything shifts, because the model has no modular structure. There is no way to alter a feature in isolation, so every change requires full revalidation.
Undeclared consumers. Someone starts reading your predictions from a table without telling you. Now you cannot change the output format, and you do not know who breaks when you do. Access control and a documented interface prevent this cheaply.
Correction cascades. A model is wrong in a specific case, so a rule is added on top. Then another. Eighteen months later the behaviour is determined by forty rules nobody dares remove, and the model itself is nearly irrelevant.
Pipeline jungles. Data preparation grows by accretion into a graph nobody understands, where the only way to know what a step does is to run it.
Dead experimental paths. Code branches for experiments that ended, still executing, still needing maintenance.
Configuration debt. Dozens of parameters accumulated across versions, most untested, some contradictory.
The common remedy is the same as in ordinary software and applied less often: delete things, keep interfaces explicit, and treat the pipeline as a product with an owner rather than as an accumulation.
Governance, in proportion
The right amount of governance depends on what the model decides. Applied uniformly it becomes an obstacle everyone routes around, which is worse than none.
A useful tiering:
| Tier | Examples | What it needs |
|---|---|---|
| Low stakes | Internal search ranking, ticket routing | Basic documentation, an owner |
| Medium | Marketing targeting, demand forecasting | Model card, monitoring, review schedule |
| High | Credit, hiring, medical, safety | Full documentation, bias evaluation by subgroup, human review, audit trail, external sign-off |
For anything in the top tier, the requirements are increasingly legal rather than optional. What that generally means in practice:
Traceability. For any decision, identify the model version, the inputs and the training data. This is what lesson 2's versioning is ultimately for.
Explainability, proportionate to the decision. Not necessarily the model's internals, and at minimum the factors that drove a specific outcome. A person affected by an automated decision increasingly has a right to a reason.
Bias evaluation. Performance broken down by relevant group, documented, and re-evaluated after each retrain rather than once at launch.
Human review. For consequential decisions, a person who can override and whose override is recorded — and who has genuine authority rather than a rubber stamp.
Change control. A record of what changed, why, who approved it, and what the evaluation showed.
A maturity progression
Where teams realistically sit, and what to do next from each stage:
Stage 0 — Notebooks. Models trained manually, results copied by hand. Next: get one model deployed and reproducible.
Stage 1 — Deployed and versioned. Code in Git, training data stored with an identifier, model in a registry, deployed. Next: add data quality and prediction monitoring.
Stage 2 — Monitored. You know when something changes and can roll back. Next: automate training and evaluation, keep human promotion.
Stage 3 — Automated pipeline. Retraining and evaluation run on demand or on trigger, promotion is approved. Next: shared feature definitions, standardised release process across models.
Stage 4 — Platform. Many models, consistent tooling, self-service for teams. Next: keep it simple enough that people use it.
Most organisations get real value at stage 2 and try to reach stage 4 first. The order costs them a year.
Match your process to the consequence of being wrong. A ticket-routing model needs an owner and a dashboard. A credit model needs everything in this lesson. Applying credit-model governance to ticket routing teaches your organisation that governance is theatre, which is expensive later.
In three sentences
Machine learning systems fail organisationally through the handover cliff, the lone data scientist and the absence of anyone accountable for the outcome, and the arrangement that works is a pair — someone owning the model and someone owning the system it runs in — present from the start rather than at handover. Costs accumulate where teams do not look: labelling, data infrastructure, permanent human review of outputs and investigation time all typically exceed training compute, while real-time serving is expensive precisely because you provision for peak and pay while idle. These systems also generate a characteristic technical debt — undeclared consumers, correction cascades, pipeline jungles — and governance should be tiered to the consequence of being wrong, because uniform heavy process teaches an organisation that governance is theatre.
Next — Lesson 6: recap and FAQ →