Main idea

A developer who uses a code agent and ships three times faster doesn't change role for all that. If they have access neither to customers, nor to usage data, nor to business context, nor to prioritization trade-offs, what they gain is a load: more features carried, more pressure on deadlines, more local decisions to make in the dark — without the product power that would let them settle things other than by default.

That is the difference between carrying part of the product judgment as close to construction as possible and operating a production machine. The first presupposes access; the second presupposes only a tool.

An organization that announces it is redistributing product ownership to those who build, without opening up access to the customer, the data and the trade-offs at the same time, is therefore redistributing responsibility and keeping the power. The step up in role is nominal.

Why it matters

This gives a test to apply to any announced redistribution: what has the person been granted the right to see and to settle, on top of what they have been granted the right to ship?

And it names a risk of silent degradation: the team is more productive, the delivery indicators improve, and the work becomes less sustainable for those doing it.

Nuances and limits

Access isn't enough either. Meeting customers without the time to digest what you hear there, or attending trade-off discussions without carrying weight in them, reproduces the same effect with an appearance of openness.

And not every developer wants this shift: some want to build, not arbitrate, and imposing product ownership on them degrades the work instead of enriching it.

Open questions

• What level of access to customers and trade-offs is enough to make ownership real, without turning the development team into a discovery team?