One thing I have noticed AI changing in software engineering is the relative cost of different parts of the work. Writing an implementation is getting cheaper, although that does not mean engineering has suddenly become easy or that every developer is now several times more productive. The evidence for those broader claims is still fairly mixed, but what has changed more clearly is the speed with which you can move from a reasonably well-defined problem to some working code.

The work before and after implementation has not moved nearly as much. You still need to establish whether the problem is worth solving, understand how it fits into an existing system, make sensible architectural choices and decide whether what you have built is actually correct. As implementation becomes easier, I think those other constraints become proportionally more important, and that has implications for how software teams should be structured.

The demand problem#

Large organisations do not have a shortage of things for engineers to do. There are product requests, operational problems, migrations, controls, support issues and whatever the current strategic programme happens to require, and a backlog tends to make all of these look like units of work waiting to be prioritised even though quite a few of them probably should not have reached the backlog yet.

I have seen Product Ownership become a formatting layer around demand, where someone asks for something, it becomes a user story, acceptance criteria are added and the request moves towards engineering without the original problem ever being seriously challenged. Sometimes that is simply poor Product Ownership, but I think there is also a more structural problem in expecting one person to cover everything that the role can accumulate in a large enterprise.

A good Product Owner may already be responsible for understanding the business domain, maintaining stakeholder relationships, setting priorities, developing product direction, handling governance and keeping enough detail around the work for a team to operate effectively. Expecting that same person to also understand the technical landscape well enough to challenge solution-shaped requirements, recognise duplicated capabilities, uncover architectural complexity and judge whether a request is sufficiently understood to enter engineering can become an unreasonable amount of context for one role.

There will be teams where a strong Product Owner can do all of this, particularly where the domain or technology is relatively contained, and I would not add another role for the sake of having one. The case becomes more interesting when both the business domain and the technical environment are complicated enough that the gap between product ownership and technical leadership starts consuming a significant amount of somebody's time.

In practice that work often falls to the Technology Lead, who ends up qualifying demand, negotiating with stakeholders and working out what people actually need alongside their existing responsibility for architecture and engineering quality. That can work, but it is not necessarily the best use of the person who is supposed to provide technical leadership to the team.

This becomes more significant as implementation gets easier, because a team that can get through more work is more exposed to the quality of what enters the team. Increasing delivery capacity is only useful if the organisation is also reasonably good at deciding what should consume it.

That gap is where I think a Technology Product Lead can make sense.

The Technology Product Lead#

The title matters less to me than the responsibility it describes. I do not mean a second Product Owner, and I do not think the role should simply translate business requirements into something engineers can consume. The useful distinction is that this person is responsible for qualifying technical demand before the team commits to it.

That means asking questions which are fairly basic but often skipped: what problem are we actually trying to solve, how much does it matter, what capability already exists, whether the proposed solution is necessary and what complexity might be hidden behind what initially looks like a simple request. Answering those questions properly requires enough technical knowledge to understand the consequences.

A request that sounds trivial from the business side can turn out to involve several systems and a surprising amount of operational or architectural complexity, while something presented as a major new capability may already be mostly solved by something the organisation has. Someone who understands both the business problem and the technical environment is much more likely to identify either situation before it becomes committed engineering work.

I would expect a good Technology Product Lead to be comfortable reading code, investigating defects, understanding the architecture and prototyping where that helps to understand a problem. They may write production code occasionally as well, but I would not include that when planning the team's delivery capacity because it is secondary to their main responsibility of shaping and qualifying the work that reaches engineering.

The arrangement I have in mind has three fairly clear areas of responsibility: the Business or Product Lead owns the business outcome and priority, the Technology Product Lead owns the quality and readiness of demand, and the Technology Lead owns architecture, engineering quality and technical risk, while the engineers retain responsibility for how the work is implemented.

This split is not necessary everywhere. If a Product Owner can comfortably span the product and demand responsibilities without becoming overloaded, combining them is simpler and probably preferable. I am interested in the point at which that stops being realistic, particularly in enterprise environments where both the business and technology sides are complicated enough to justify deeper specialisation.

There will obviously be overlap between those responsibilities, which I think is both unavoidable and useful. The distinction I care about is that something being a high business priority does not necessarily mean it is understood well enough to start implementing, just as something being technically feasible does not make it worth doing.

Don't put another wall in front of engineering#

One of the main risks with this structure is that the Technology Product Lead becomes an intermediary through which every conversation has to pass, which would separate engineers from the people and problems they are supposed to understand.

Engineers still need direct contact with users and stakeholders, enough domain knowledge to challenge assumptions themselves and involvement in discovery when their technical perspective is useful. I am not trying to control who engineers are allowed to speak to; I am trying to make the allocation of engineering capacity more deliberate.

There is a meaningful difference between a stakeholder speaking directly with an engineer about a problem and a stakeholder persuading that engineer to pick up several days of unplanned work outside the team's existing priorities. The Technology Product Lead should help manage the latter without making the former more difficult.

Where XP fits#

I have also been thinking about this in the context of Extreme Programming (My favourite methodology), partly because a surprising amount of XP maps quite naturally to software development with AI in the loop. Small changes, continuous integration, automated tests, simple design, refactoring and collective ownership are all still useful, and faster code generation makes some of them more important rather than less because the ability to integrate, test and get feedback has to keep pace with the rate at which changes can now be produced.

Pair programming is the practice I am less convinced should remain universal. I do not buy the idea that an AI coding assistant is a replacement for a human pair, because pairing does much more than increase the rate at which code gets written: it spreads knowledge, provides continuous review, creates shared context and makes it much harder for one person to become the only engineer who understands a particular part of the system.

At the same time, I do not think every change benefits enough from synchronous pairing to justify doing it by default. For a routine change in a familiar and well-tested part of a system, I am generally comfortable with one engineer working independently, whereas a risky migration, an unfamiliar subsystem, difficult debugging, a production incident or a design with unclear consequences gives me a much stronger reason to involve another person.

The principle I have been using is to pair on uncertainty, with the amount of collaboration increasing as a problem becomes harder to understand, harder to reverse or more important for other people in the team to learn. There does not need to be a fixed threshold, and in practice I would expect teams to develop a reasonable instinct for when another person materially improves the work.

This only works if the rest of the engineering discipline remains intact. If less routine pairing gradually turns into large branches, weak review and isolated ownership, then most of the useful properties of XP have been lost rather than adapted. Knowledge still needs to move around the team, changes still need to remain small and feedback still needs to arrive quickly.

I therefore see this less as removing a practice from XP and more as being flexible about when one particular practice is needed while keeping the outcomes it was intended to produce.

My proposal#

The organisational part and the XP part are related because both are concerned with how engineering attention gets spent. Before work reaches the team, someone should have done enough work to establish that the problem is understood, worth solving and sufficiently well shaped to justify consuming engineering capacity. Once it reaches the team, the development process should make it relatively cheap to discover mistakes, change direction and involve more people when the level of uncertainty makes that worthwhile.

AI makes the implementation step faster, but there is not much value in accelerating that part of the process if the organisation becomes increasingly constrained by poor demand, weak decisions or slow feedback elsewhere.

I also would not judge whether this model works by story points, lines of code or another measure of raw output. I would be more interested in whether less work reaches engineering only to be abandoned or substantially reworked, whether engineers spend less time responding to unplanned requests, whether changes remain small and whether technical and domain knowledge continue to be shared across the team.

There are fairly straightforward ways for the model to fail, unfortunately. The Technology Product Lead could become a backlog administrator, become the only person with meaningful contact with the business or inadvertently reduce the amount of domain knowledge held by engineers. Selective pairing could similarly drift into almost no pairing at all, with collective ownership gradually deteriorating as a result. Those would be signs that the implementation of the model is working against its purpose.

The interesting consequence of AI for me is not simply that we can write more software, because large organisations have rarely been short of things they could build. What is changing is that implementation is becoming cheap enough, relative to the rest of software delivery, that the constraints around it are becoming harder to ignore, and engineering attention is one of the more important ones.

I think there is value, particularly in the age of AI in being much more deliberate about what gets to consume that attention and where, within the engineering process.