Change Capacity

For most of the time I’ve been writing software, the thing that decided what actually shipped was how fast the team could build it. Engineering capacity — the throughput of design, build, test, and release — was the ceiling. It’s why engineering leadership tended to end up as the de facto gatekeepers of the roadmap: the constraint on what reached customers was the engineering org’s constraint. If you wanted more out the door, you argued for more engineers, or you argued about priorities inside a fixed budget of engineering-weeks.

Agents are quietly removing that ceiling, and I don’t think we’ve fully reckoned with what replaces it.

The Ceiling Moves

When the cost of building and shipping a feature trends toward zero, “can we build it” stops being the interesting question. I can now point a handful of agents at a backlog and have each of them deliver a feature by the end of the day. The bottleneck isn’t the typing anymore (and increasingly, reviewing the code is not either).

So what becomes the new constraint? I’d argue it’s the one on the other side of the release: how much change your users can actually absorb.

Call it change capacity — the amount of product change a person can take in, understand, and get comfortable with before it stops feeling like improvement and starts feeling like a treadmill. It’s a finite budget, and it belongs to the customer. Every incidental change spends a little of this budget: shipping faster than a user can metabolize ceases to register as more value. It registers as noise, and eventually as cognitive exhaustion.

Engineering capacity was our constraint. Change capacity is the user’s. Agents are the thing that swaps which one binds.

I don’t have to reach far for an example. While I was reviewing the draft of this very post, GitHub rolled out a redesigned comment interface — the posted-and-pending comment flow, quietly rearranged under me mid-review. Nothing about it was broken, and I’m sure it’s an improvement by some metric someone is proud of. But I hadn’t asked for it, I wasn’t expecting it, and for a few seconds I was relearning something I already knew how to do instead of doing the thing I’d opened the tab to do. That small jolt — the involuntary relearning, the momentary “wait, where did that go” — is what spending someone’s change capacity actually feels like from the receiving end. It’s easy to wave off a single instance as trivial. The problem is that it’s never a single instance; it’s every product I touch, all doing it at once.

Isn’t This Just Change Management?

This is the first objection I’d raise if someone said it to me, so let me take it seriously. Change management already exists as a discipline. Haven’t we been here before?

Partly. But the shape is genuinely different. Classic change management was built for the infrequent rollout of substantial changes — the big, discrete shift that you plan, stage, communicate, and gate deliberately. An ERP migration. A platform cutover. A reorg. The process was heavyweight precisely because the changes were rare and large. More often than not, this process was instituted on a captive audience. It was an organization instituting change for their employees. This is a substantially different effort, with substantially different requirements, than managing change for end customers (or users) with varying friction to just leaving.

Product updates never carried that weight. A feature here, a redesign there, a new setting — each one was assumed small and continuous enough that it didn’t need a formal process. And for a long time that assumption held, largely because engineering capacity kept the rate of change naturally bounded. You couldn’t ship faster than you could build, and you couldn’t build all that fast.

What’s changed is that the rate is no longer bounded by the thing that used to bound it. Engineering’s capacity to make functional changes now drastically exceeds the user’s capacity to absorb them. So this isn’t change management rebranded. It’s the discovery that continuous, lightweight product change has quietly crossed the threshold where it needs the kind of governance that only the big, rare changes ever got — and nobody built that process, because until recently nobody needed it.

Somebody Still Has To Gate

Here’s the part I find genuinely interesting. If engineering capacity is no longer the gate, something else has to be, because “let every engineer ship whatever they can generate” is not actually a strategy. It’s a fairly reliable way to lose your users.

I think that gate lands on product. Not on grounds of feasibility — feasibility is increasingly free — but on grounds of coherence and absorbability. The question a PM is now uniquely positioned to ask isn’t “can we build this,” it’s “should this reach the user this week, given everything else we’re already asking them to absorb?” That’s a product-marketing question as much as a product one: what’s the through-line, what’s the story of the product this quarter, does this change fit it or just add to the pile.

If you let engineers — or worse, a swarm of agents — push features out with no continuity or cohesion, you can absolutely build your way into churn. Not because any individual feature was bad, but because the aggregate rate of change made the product feel like an exhausting thing to keep up with. Using it starts to feel like a commitment rather than a tool. That tends to be a bad psychological experience, and people leave experiences that exhaust them.

Velocity used to be the scarce resource. Now it’s the user’s attention and tolerance for change. Product’s job is to spend it deliberately.

But My Users Want Fast

The obvious counter is that some users genuinely want rapid iteration. Power users, developer tools, early-adopter and B2B segments — they’ll take every new feature the day it lands and ask for more. Telling those people to slow down would be its own mistake.

I don’t think change capacity means “ship slower for everyone.” It means change capacity isn’t uniform, and different segments carry different budgets. Which happens to be a problem we already have a mechanism for: feature flags.

It’s worth being precise about the two distinct jobs a flag can do here, because they often get conflated:

• Rollout pacing — controlling how fast a given change reaches a given user. This is where “rollout speed” becomes an actual product lever. You can offer a fast ring for the people who want the bleeding edge and a slower, calmer default for everyone else, and let users self-select.
• Availability / entitlement — controlling which features a user can see at all. Strictly this is closer to an entitlement system, and entitlements usually tie back to billing — what you’ve paid for — rather than to how much churn you’ve opted into.

Same primitive, two different questions. Keeping them separate matters, because “you get this feature because you’re on the pro tier” and “you get this feature early because you opted into the fast ring” are different promises to the user.

And whether to build tiered rollout speed at all isn’t a universal answer. It’s a product and business decision that depends entirely on what your customer base actually looks like. A prosumer tool full of tinkerers can offer a fast ring and watch people opt in. A mass-market or enterprise product, where change itself is a cost the customer pays in retraining and support tickets, might want the opposite: one slow, coherent, heavily-governed lane for everyone. The framework only names the lever. Your segment decides how hard to pull it.

Where This Leaves Us

I’m not fully certain where the line sits, and I suspect it’s different for every product and market. But the direction feels clear enough to plan around. As agents keep eating engineering capacity as the binding constraint, the teams that come out ahead probably won’t be the ones who ship the most. They’ll be the ones who are deliberate about how much change they ask their users to carry, and who treat that budget as the scarce resource it’s quietly become.

The uncomfortable version, if you’re an engineer: shipping more is no longer the flex. Restraint with intent is.

Hopefully this works out for you, or was at least helpful. If you have any questions, don’t hesitate to shoot me an email, or follow me on twitter @nrmitchi.