"Can we just move the button to the other side? Small change." Four words, and a developer's stomach drops a little, because "small" was never a description of the work. It was a description of how the request looks from outside the codebase.
The button is never just the button
Moving a button sounds like moving a button. Then it turns out the button's position was load-bearing: an A/B test is keyed to its DOM location, a screen reader flow assumes it's the third focusable element, a CSS grid that was never meant to flex now needs to flex, and the mobile layout — built separately, six months ago, by someone who left — breaks in a way nobody notices until a support ticket comes in from a user on an old Android phone. None of that was visible from the outside. All of it was real.
This is the actual shape of most "small changes": the visible part is small, and the invisible part — everything the visible part quietly depends on — is not. The size of a request and the size of the system it touches are two different numbers, and only one of them is on the ticket.
Why the estimate always undersells it
Ask for a time estimate on something that sounds small, and you'll usually get a small number back, because the person answering is estimating the thing you described, not the thing that will actually happen. They haven't opened the file yet. They don't know that the button lives inside a component used in four other places, three of which have their own edge cases nobody documented. Nobody's lying here — the estimate is honest, it's just an estimate of the wrong scope.
The fix isn't a bigger buffer on every ticket. It's separating "how long will the visible change take" from "how much of the system does this touch," and asking the second question before answering the first. A one-line CSS tweak to a component used in one place really is small. The same tweak to a component used in twelve places, some of which override its styles in ways nobody remembers writing, is a different task wearing the same description.
What it costs when nobody asks
Skip that question enough times and the pattern compounds. Small changes get approved without review because they're "just small changes." They ship without tests because writing a test for something small feels like overkill. They pile up, each one plausible on its own, until the system is held together by a dozen changes that were each five minutes of work and collectively nobody fully understands anymore. That's usually the moment someone asks why a routine deploy now takes all afternoon and three people to sign off on.
The one habit that actually helps
Before answering "how long will this take," answer a different question first: what does this touch that isn't visible in the request? Not exhaustively — just enough to know whether "small" is actually small, or just small-looking. That habit alone catches most of the surprises before they become surprises, and it costs about thirty seconds more than answering on reflex.
The phrase itself isn't the problem. Someone asking for a small change is usually right that it looks small — that's not a mistake on their part, it's just the view from outside the system. The expensive part is treating "it looks small" and "it is small" as the same claim, when they're only the same claim about half the time.