With AI, a product manager can build a working prototype and test it with users. A designer can go as far as implementing an interaction in the product. A developer can explore several responses to a need and make them testable before a solution is chosen. The boundaries between design and implementation are becoming more permeable: one person can take an idea further, bringing in other expertise when it becomes necessary.
For product and engineering leaders, this opens up work that goes beyond choosing tools. What happens to the organisation when people can take on a larger share of a piece of work? Which decisions need to be brought closer to that work? Which expertise must remain accessible?
We can begin to answer by following a real request, from its origin through to use.
Look at where work waits
Development time is only part of the wait a user experiences. Before and after development, the work may be waiting for clarification, a decision, an available environment or approval.
If implementation speeds up while these waits stay the same, the queue moves elsewhere. A team can produce more changes while waiting longer for them to be reviewed. The people responsible for approval then become the point through which decisions pass, without enough time to examine them.
For a recently delivered piece of work, it helps to reconstruct this journey with the people involved. When did the work move forward? Where did it stop? Why did a decision need to be revisited? This exercise helps identify a specific change, such as bringing the necessary expertise together earlier or making certain approval criteria available to the team.
DORA’s work on user-centric focus highlights the risk of using AI to amplify work that is poorly directed. These organisational research findings provide useful reference points; they do not, on their own, determine which changes a business should make.
Bring activities closer without losing expertise
Being able to produce a prototype changes the conversation between product, design and engineering. People can discuss a visible user flow, spot difficulties earlier and compare options. The person responsible for the question can take on some of the exploration.
This capability does not mean that all skills have become interchangeable. The quality of an interaction, the consequences of an architectural choice or the relevance of a metric still require experience. The question becomes how to bring that expertise into the work: when, on which question and with what responsibility?
A team can gain autonomy while still seeking specialist advice on a consequential decision. That requires recognising the decision for what it is. Without that ability, autonomy risks producing decisions made too early, which experts only discover once implementation is well under way.
Make decisions explicit
When several people can move a piece of work forward, the old boundaries no longer suffice to show who decides. Has the person producing a mockup also chosen the scope? Can the person having a feature developed change the access policy? Who accepts a trade-off on quality?
It helps to define these responsibilities through the work itself. The team needs to know its objective, the constraints it must work within and the decisions it can make. Disagreements need someone who can resolve them.
This framework also prevents autonomy from depending on one particularly experienced person who carries everything implicitly. Others need to understand the reasons behind a decision, build on them and discuss them when the situation changes.
Assign responsibility for how agents operate
Agents add another dimension to this organisation. Someone needs to maintain their context, monitor checks, examine errors and decide which tools they can access.
This is what we address when setting up an agentic software factory. It connects the technical means with the team’s responsibilities: who approves a change, who can authorise a sensitive action and who steps in when a check stops working?
These questions deserve dedicated time. If maintaining this system depends entirely on one developer’s goodwill, the team risks relying on something it uses without really being able to take it over. Documentation helps; shared practice and opportunities to learn matter just as much.
Try changes within a scope that supports a decision
A transformation can start with one product, one team and an observable objective. For example: shorten the time between a clearly defined need and its delivery, while maintaining the expected quality.
We then observe the total time, rework and incidents, as well as the time spent on checks. We gather what the team understands better and what it finds difficult. A reduction in development time accompanied by a sharp increase in review effort calls for an adjustment.
Measurement needs to stay in context. In its February 2026 update, METR explains why selection biases and working with multiple agents make gains harder to estimate. This encourages us to examine our own results rather than adopt a productivity multiplier from elsewhere.
The experiment also helps decide what is worth extending. Some practices may be shared widely; others will depend on the product, its exposure to risk or the team’s experience.
At The Spark, we connect this evolution in organisation with the practice of building. Our Rethink your organisation service supports this work with leaders and teams, from examining the product lifecycle to trying out new practices.