Onboarding a new hire into a live game economy safely

Someone joins the team and starts working on the economy. They are competent, they read the configs, and within a few weeks they have a list of things that look wrong.

Most of that list is genuinely wrong. Some of it is load-bearing, and the difficulty is that the two categories look identical from the outside.

Why a live economy looks worse than it is

An economy that has been running for years accumulates values that do not fit any clean scheme.

A price that breaks the pattern of its tier because of something that happened in one market. A reward rate that is oddly specific because it was tuned to hit a particular pacing target. A cap that exists because of an exploit two years ago. A currency that serves one feature and looks redundant but is deliberately non-fungible.

To someone who arrived last month, all of these read as mess. The impulse to tidy them is correct instinct applied to incomplete information, and acting on it reintroduces whatever each one was solving.

This is not a problem specific to economies, but economies make it worse in one respect: the consequences are delayed and diffuse. Tidying a confusing function produces a bug you find in testing. Tidying a price produces an economic drift you notice next quarter, by which time nobody connects it to the change.

The first thing to hand over

The single most valuable onboarding artefact is the list of deliberate oddities — the values that look wrong and are not, with one line each on why.

This is short. Most games have between ten and thirty of them. It takes an hour to write if someone who knows sits down and goes through the config asking "would this look wrong to a newcomer".

Handing that over on day one converts the new person's tidying instinct into something useful: they can tell the deliberate oddities from the genuine mess, and go after the genuine mess with confidence.

Without it, the safe behaviour is to change nothing, which wastes the hire, and the unsafe behaviour is to change everything, which costs more.

The order of exposure that works

The pattern that produces competence fastest is to move from observing to changing gradually, on a specific axis: reversibility.

Start with things that are fully reversible and low blast radius. Presentation changes, copy, offer placement. Mistakes here are visible fast and undone fast.

Then things that are reversible but affect state — offer contents, event configuration. Errors produce some players getting something unintended, which is recoverable.

Then things that produce irreversible state: reward rates, currency issuance, prices. These are the ones where a mistake persists after the fix, and they should come last, with someone reviewing.

Most onboarding does not think in this order because it thinks in terms of complexity rather than consequence. A reward rate change is a one-line edit and is far more dangerous than a substantial refactor of presentation logic.

See how we bound what a change can do →

Giving them a real first project

The failure mode on the other side is over-caution — the new person spends three months reading and changes nothing, and learns much less than they would have from doing.

A good first project has three properties. It is genuinely useful, so the work matters. It touches the economy enough to require understanding it. And its worst case is contained.

Analysis work fits this well: understanding a specific behaviour, tracking down why a particular metric moved, mapping where currency actually comes from. These force engagement with the whole system, produce something the team wants, and cannot break anything.

The other good first project is building the documentation that was missing. A newcomer is the only person who can accurately identify what is not obvious, because everyone else has lost the ability to see it. Having them write down what confused them, and getting those questions answered, produces the onboarding document for the next person and teaches the current one.

The thing to avoid is a first project that is a tuning task with a target attached. That combines maximum consequence with minimum context, and it is where the expensive mistakes come from.

It is also worth being explicit with the new person about the delayed-feedback problem itself. Someone who understands that an economy mistake shows up next quarter rather than next week calibrates their own caution appropriately, without needing to be supervised into it. Left unsaid, the natural assumption from other software work is that a bad change produces a fast signal — and that assumption is what makes an otherwise careful engineer comfortable shipping a rate adjustment on a Friday. Naming the difference once does more than any amount of process.

Talk to us about operating an economy safely →