Fast Is a Feature, and a Feature Needs an Owner

Here is the thesis. Speed behaves exactly like a feature: it is built deliberately, it decays without maintenance, it competes with other features for the same budget, and it dies when nobody owns it. But teams manage it like a virtue, praised in reviews and defended by nobody, and the difference between a virtue and a feature is that a feature has an owner, a budget and a line in the roadmap, and the virtue has none of the three, which is why the fast product gets slow while every individual change is defensible.

I am not arguing that performance is more important than other features. I am arguing that it is a feature, and that the management practices that keep other features alive, ownership, budgeting, review, are precisely the ones performance is denied, and the denial is the regression.

The accretion machine

The slow product is rarely the result of one bad change. It is the sum of hundreds of good ones, a dependency added for convenience, a query that fetches a little more, a script that runs a little earlier, each below the threshold of notice, each correct in isolation, and the threshold is the failure, because no single change owns the cumulative cost, and the cumulative cost is the product's speed, which nobody's change mentions.

This is the tragedy of the commons in a codebase: the main thread, the payload, the database's time are shared resources, and each feature spends a little of them, and the spending is free for the spender, and the bill arrives as the p99, which is a number, not a person, and cannot push back.

Why ownership is the missing mechanism

A feature survives because someone is answerable for it: the auth feature has an owner who notices when auth misbehaves, because the misbehaviour lands on their name. Speed has no such person, so its misbehaviour, the slow creep, lands on nobody, and the review that would catch it has no owner to ask, and the budget that would bound it has no one to defend it, and the roadmap that would restore it has no one to propose it.

The owner is not the person who fixes every regression, which would be a bottleneck and a tax. The owner is the person with the authority to say no to a change that spends the budget, to propose the work that restores it, and to be asked, quarterly, what the number is and why it moved, which is the same accountability every other feature gets, and the absence of which is the only difference between speed and the features that survive.

The counterargument, fairly

The honest defence of the status quo is that performance is everyone's job, and making it one person's job lets everyone else abdicate, which is a real risk, and a bad owner becomes a gate that slows every team, which is also real.

I accept both, and they argue for the design of the ownership, not against it. The owner owns the budget and the guardrails, the automated budgets that fail a build, per a performance budget that survives contact with a real store, not the approval of every change, so the spending is bounded by machinery and the owner tends the machinery, which scales, while "everyone's job" is the phrasing that produces no one's job, because everyone and everyone only diverge when there is a bill, and the bill is quarterly, and by then the accretion is a year old.

And the abdication risk is handled by making the budget visible to every team, so the spending is everyone's awareness and the defence is the owner's, which is the division that works: awareness distributed, authority named.

What owning it looks like

The teams that stay fast share practices, and each is a feature management practice applied to speed.

The budget is written and versioned, a number per milestone, load time, payload, p99, with the same status as a spec, because an unwritten budget is a hope, and the versioning makes the regression datable, which is the first property a feature needs, that its state is measured.

The budget is enforced in the pipeline, failing the build on exceedance, so the spending requires a deliberate override, and the override is logged, which is the price appearing at the point of sale, and the log of overrides is the owner's agenda.

The owner reports the number at the same cadence as other features report progress, so speed is in the same conversation as the roadmap, and the trade between a new feature and the budget is made visibly, by people, at planning time, which is where trades belong, rather than invisibly, by accretion, at merge time.

And the restoration work is scheduled like feature work, because the debt of speed, unlike the metaphorical kind, is measurable, per technical debt is the wrong metaphor, and the measurable debt gets a line in the roadmap when someone owns it.

The uncomfortable conclusion

The slow product is not a failure of engineering. It is a failure of management structure, the absence of an owner for a property that needs one, and the engineering is fine, which is why the product is slow despite good engineers, and will stay slow despite good intentions, until the structure changes.

Speed that is a virtue decays, because virtues are defended in speeches and features are defended in budgets, and the speech happens at the incident, when the number is already bad, while the budget happens at the merge, when the number is still saveable, and the difference between those two moments is the owner.

The thumb rule I use

Treat speed as a feature: name it, budget it, enforce the budget in the pipeline, and give it an owner with the authority to defend it and the cadence to report it, with awareness distributed and authority named.

The fast product is not the one with fast engineers. It is the one where the budget has a person, because the accretion is inevitable, the spending is rational, and the only thing that compounds against it is an owner, which is the least glamorous mechanism in this archive and the one the fast products all have.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud