Gold Plating Is Just Scope Creep With Better Intentions

Tuesday afternoon, about four. Your strongest engineer waves you over to her screen and shows you the thing she's been building for three days. It's genuinely lovely. Clean abstraction, proper test coverage, the sort of work you'd show a candidate to persuade them to join.

Nobody asked for it. It wasn't in the plan. And you're now standing behind her chair trying to arrange your face.

When a client asks for something extra, there's a process, and even if the process is clunky it exists. Someone writes it down. Someone prices it. There's a counterparty, a paper trail, and a moment where the word "no" is available.

When your own team adds something extra, there's none of that. No request, no counterparty, no record. The work simply appears inside the estimate, and the first anyone outside the team hears about it is when a date moves. That's why gold plating is the more dangerous of the two, despite the fact that everyone talks about client scope creep instead.

It's also harder to address, because the motive is good. The engineer isn't gaming anyone. She's applying craft, and she's right that the version she's built is better. Telling her to stop feels like punishing exactly the instinct you spend your hiring budget trying to find.

So people don't say anything. And the cost is real: every hour spent beyond what was needed came out of the same budget as the work that was, and every abstraction added is something the team maintains for years without ever having decided to take it on.

The thing that turns this from a running argument into a routine is having one rule, applied identically whether the change came from a client, a sponsor, an architect or your own best engineer.

Absorb it when all of these hold: it's under half a day, it adds nothing new to operate or maintain, and it doesn't touch a date, an interface or a test. That's a genuinely small change and treating it formally costs more than doing it.

Otherwise raise it. Even if it's cheap. Even if it's obviously a good idea. Raising something costs you one email and buys you a decision made by the person who's entitled to make it.

The bit people miss: raising it doesn't mean refusing it. Half the things you raise will be approved in an afternoon, and now they're in the plan with a date attached instead of quietly eating your contingency. The point isn't to stop the change. The point is that somebody other than the person doing the work knows it's happening.

Then write down the ones that get approved, and tell the stakeholders who care about the date. A scope change that's been agreed in a corridor and never appears in writing will be remembered differently by everyone in six weeks' time. Two lines in the plan and one line in the weekly note is enough.

Engineers gold plate partly because nobody ever told them where the finish line was. In the absence of a definition of done, a professional will keep improving the work, because that's what professionals do. The vagueness is a leadership failure long before it's an engineering one.

So define it, per piece of work, in a sentence, before the work starts. Not "build the reporting service". Something a person can hold you to: "done means a finance user can run last quarter's reconciliation without asking us for help, and it completes inside ten minutes".

That sentence does two useful things at once. It tells someone when to stop. And it makes anything beyond it visible as a proposal rather than invisible as a task.

Be honest with your team about the trade too. You're not asking them to do bad work. You're asking them to do the work that was actually needed, and to bring you the rest as a suggestion rather than a surprise. Most good engineers accept that immediately when it's put plainly. What they won't accept, and shouldn't, is a leader who demands speed and then complains about quality when something breaks.

A 20-person operations team at a rail operator, building an internal service catalogue. Six week estimate, a straightforward piece of work, one of those deliveries where the main risk is boredom.

An engineer decided, reasonably, that other teams would eventually want to integrate with it. So he built a plugin system: registration, lifecycle hooks, a small interface contract, documentation. Nobody asked for it, nobody objected, and it added nine days. The project came in about a week and a half late and the retrospective put it down to underestimation, which was not true.

Fourteen months later, three plugins existed. Two of them were broken and nobody had noticed, because the catalogue's own tests didn't cover them. Every new starter spent the better part of a week working out why the simple thing went through an abstraction layer. The team had been paying maintenance on a decision no one ever formally made.

The thing worth noticing: the engineer's instinct about future integrations was correct. Other teams did want to integrate. He was right about the need and wrong about the timing, and a ten minute conversation in week two would have produced either a funded decision to build it or a note in the backlog for when the demand was real. He never had that conversation because nobody had told him it was a conversation rather than a task.

At standup, ask everyone the same question: name one thing in your current work that nobody explicitly asked for.

You'll get a couple of shrugs and then, usually, two or three honest answers. Take each one and decide out loud, right there: keep it and put it in the plan with a size, or drop it. Don't leave any of them in the middle.

Write the dropped ones down somewhere visible as declined, with the date. Not because anybody will audit you, but because a list of things you deliberately chose not to build is the clearest evidence your team has that "good enough" is a real standard rather than something you say when a date is slipping.