Case file · Creative technology

No average viewers. No average engineers.

MIRA built a platform to abolish the average viewer — one creative idea becoming tens of thousands of variations, each assembled for the person about to watch it. Their engineering team was losing more than one in five people a year. The fix was the same idea pointed inward: a development plan drawn for each engineer from two things — the Belbin workstyle they cannot change, and the hard skills they still can.

  • 10,000sVariations per idea
  • 20%+Rotation before
  • 4 monthsTo reach zero
  • 34 monthsZero held

Most campaigns ship three versions of a spot. MIRA shipped tens of thousands.

One on-brand template goes in. Live and contextual data — location, weather, pricing, product feeds, live scores — assembles what comes out, and what comes out is not a batch of near-duplicates. It is a version built for the individual about to see it. The social platform supplies the profile; MIRA chooses the variation that fits and delivers it in the right format for the channel.

The clearest way to see it is to watch one campaign reach two people on the same afternoon.

Stockholm · snowing

A teenager scrolling between classes sees her own weather in the footage — snow on streets she recognises — and a QR code good for a free croissant at the coffee shop two blocks from where she is standing.

Miami · hot and clear

A man in his forties opens the same campaign and sees none of it. Different footage, different city, a cold drink instead of a pastry, an offer that makes sense in the weather he is actually in.

Same idea. Same brand. Same campaign. Not remotely the same film. MIRA's own stated ambition was to eliminate the concept of the average viewer entirely — and the product did exactly that, at a scale where a human editor could not have made the second version, let alone the ten-thousandth.

Meanwhile, one engineer in five was leaving every year

Engineering rotation was running above 20% a year, against a figure usually cited as the healthy ceiling of around 13%. On an ordinary team that is painful. On this one it was corrosive.

The reason is what the engineers were holding. Rendering pipelines that assemble video from live data, at tens of thousands of variations per campaign, are not a system anyone arrives already knowing. The knowledge is specific, deep, and largely undocumented because it lives in the people who built it. Every departure took a piece of it out of the building, and the replacement needed months before they were net positive.

The same idea, turned inward

The product's whole argument was that treating people as an average wastes both their attention and your money. Peerforce made the same argument about the engineering team, and the intervention followed directly from it.

A Belbin team-role profile for every engineer, beside their hard skills Not a personality label, and not a generic ladder every engineer climbs in the same order. A reading of how that specific person contributes inside a group — one of the two inputs every plan was built from.
Skill gap analysis against what the work actually required The gaps between what each engineer knew and what their role demanded were identified individually, and the training plan addressed those gaps — not the ones the team was assumed to have.

One input that cannot change, and one that can

Most engineering organisations offer exactly one destination, and it is management. The reward for being an outstanding engineer becomes a job that is not engineering — a dependable way to lose the people who were best at the work. MIRA did not answer that by offering two destinations instead of one. It stopped fixing the number at all.

What made that possible is that every plan was built from two inputs of completely different kinds.

Workstyle · fixed

A Belbin profile describes how a person contributes inside a group, and it does not move. Nobody is trained out of their workstyle. What can be done is amplify it and keep its downside in check — so a plan runs with the grain of the person instead of against it.

Hard skills · acquirable

Training, mentoring, certification. This is the half that moves, on a timescale you can actually plan around. It is what let an engineer change direction rather than only climb: some rebuilt their skill set outright and moved into new teams such as R&D, doing work their old skills could not have reached.

Build a plan on skills alone and you promote people into roles that will make them miserable. Build it on workstyle alone and you have written a horoscope with no route attached. Used together they produced a direction per person. Plants, Specialists and Implementers often went deeper into the technical work — software architect, principal engineer. Co-ordinators, Shapers and Monitor Evaluators often went where aligning a group and judging options is the job itself, into project and product management. Plenty went somewhere neither of those sentences describes. The point was never a set of tracks to be sorted into; it was that the route was drawn for the engineer standing there.

Three measurable goals a year

This is the part that turned a development plan from a statement of intent into something real. Every engineer carried three goals a year, each one concrete enough that come December it was either done or it was not.

Obtain a certification A named qualification with a date on it — not "get stronger at distributed systems", which no one can mark.
Rotate sprints into another team Deliberate exposure to the rest of the platform, so an engineer's picture of the system stops ending at the edge of their own component.
Deliver a workshop The fastest way to find out whether somebody genuinely knows a thing is to have them teach it to people who will ask.
Mentor a junior engineer Valuable for the mentor as much as the junior — it is the first management-shaped work most engineers ever do, and it reveals a great deal about whether that direction suits them.

Those are examples, not a checklist everyone received. Three goals, every year, chosen for that particular engineer out of what their workstyle already gave them and what their skills still lacked. No two plans on the team matched, which is the entire point — and it is also why the plans were credible. An engineer could look at theirs and see something specific enough to argue with.

Four months to zero

Implementation began in March 2020. The last engineer to leave did so that May. Four months in, the rotation rate had reached zero — and the interesting part is not that it got there, but what happened next.

It stayed there for thirty-four months

Not a quarter. Not a good year. From May 2020 until March 2023, not one engineer left. Then a change of ownership brought a different approach to staffing — people were let go and replaced — and rotation returned.

That ending is the most useful thing in this case study. A retention number that only ever goes up is easy to explain away as a good market, a lucky team, a calm year. This one held for as long as the practice was in place and returned when the practice stopped. Whatever else was going on, the plans were doing the work.

peerforce — chat Engineering
Who is most likely to leave this quarter, and what would keep them?
◆ Engineers ranked by stalled progression and unclosed skill gaps — each with the specific training that closes theirs, and the role it opens next.

An illustration of the kind of question the model can answer, not a record of a specific one.

MIRA already believed that the average viewer was a fiction worth abolishing — it was in their vision statement, and their entire product existed to prove it. The engineering result came from noticing that the average engineer is a fiction too, and that a company willing to build ten thousand versions of a film for ten thousand strangers could certainly build one plan for each of the engineers it already had.