The Invisible Hand of Scope Creep

4 min read

Every engineering team has felt it. You begin a project with a clean spec, a reasonable deadline, a well defined set of features. Three months later you are staring at a codebase that does twice what was asked for, half as well as it should, and you shipped three weeks late. The postmortem blames poor project management, weak product leadership, or a founder who could not say no.

But there is a deeper story. Scope creep is not just a process failure. It is a cultural phenomenon driven by incentives that nobody admits are there.

Adding scope feels like progress.

The person who suggests a new feature in a meeting is the one who sounds ambitious. They are thinking big. They are pushing the team to be more than it was yesterday. The person who pushes back, who says this is not the right time, who reminds everyone that the deadline has not moved, sounds like the opposite of ambitious. They sound cautious. Defensive. Small. And nobody wants to be the person who killed the exciting idea.

This asymmetry is the engine of scope creep. In any room of ten engineers and product people, the person who adds scope gets a momentary status boost. The person who subtracts scope gets nothing. Worse, they risk being remembered as the one who stood in the way. The credit for what you prevented is invisible. The credit for what you added is immediate and social.

Consider the launch dynamic. Organisations celebrate big launches. The splashy announcement. The press release. The product hunt spike. The person who delivered a massive feature set gets recognised, promoted, written about. The person who delivered a smaller set on time gets a quiet nod in a standup meeting if they are lucky. The asymmetry is baked into how we assign status.

The result is rational behaviour. Engineers and product managers learn that their career moves forward when they ship broad, not when they ship tight. So they add. They extend. They say yes to one more thing, then another, until the project has metastasized beyond what anyone intended.

This is not a bug in the individuals. It is a bug in the culture.

The best engineering cultures I have seen, the ones that consistently ship on time without burning out their teams, have solved this problem at the social level. They have built a safety net around the person who says no.

Basecamp made this famous with their doctrine of saying no by default. But it is not enough for one person to say no. The culture has to protect that person. The senior engineer who kills a feature because the timing is wrong needs to be celebrated, not side-eyed. The product manager who cuts scope to protect the deadline needs to be seen as strategic, not lazy.

Some teams do this with explicit rituals. At certain companies, the person who suggested a feature and the person who killed it both get recognised in the same retro. Strip decides that scope cuts are recorded and attributed, exactly like feature adds. When a project ships on time with fewer features than planned, the team that made those cuts gets the same visibility as a team that shipped something larger but later.

The fear of being the one who killed a good idea is powerful. It is social. It is emotional. It cannot be solved with better Jira workflows. You cannot configure a ticket field for please praise me for saying no. The solution has to be cultural. It has to come from the top, consistently, visibly, publicly. The CEO who thanks an engineer for killing a feature in a company all hands. The team lead who names the unsung hero of cutting scope at review time.

I remember watching a startup evolve through this. Early on, the founder celebrated every shipped feature and every launch. The team learned fast: more features meant more recognition. By year two, the product was a pile of half-finished experiments. The founder changed tack. She started celebrating ships that stuck to scope, not just ships that added features. Within six months, the team was cutting more and shipping better. The culture had shifted because the reward signal had shifted.

Scope creep is the invisible hand of cultural incentives. It does not happen because people are bad at managing projects. It happens because the social rewards point in the wrong direction. Fix the culture, and the process follows.