In Don’t Automate the SDLC, I argued for recovering the needs behind software development’s familiar artefacts. In What Replaces the SDLC?, I described agents working continuously around outcomes, gathering evidence and earning authority. Changing the work that substantially would also change how I’d organise the people doing it.
I’d keep stable teams with end-to-end responsibility for a durable customer or business area, and let smaller working groups form within them around the problems needing human attention. People would work across more of Engineering, Product and Design, while retaining first-line managers who understand their discipline. Above that, I’d want one R&D leader below the CEO, responsible for product coherence, investment, technical sustainability and how the product is built and operated.
I think a smaller organisation could take responsibility for substantially more than it used to. AI can increase individual output, but the larger gain depends on removing handoffs, repeated negotiation and work heading in conflicting directions. Today, code generation is moving faster while people still coordinate delivery through the old stages. I’d have agents check changes against the team’s goals and customer promises, run the required evaluations and act within permissions people had set. That would take routine delivery coordination out of people’s jobs.
Anthropic describes seven people building the Scion source-control system, the Antique code-review tool and related systems, and migrating its monorepo in five months. Its unusual workload and early access to models matter when considering what other small teams could take on.
Stable teams with enough room for the work to change
People need a group they can trust, colleagues who know them and a manager with time to notice how they’re doing. I’ve argued for keeping that management work, including the room in people’s weeks to help each other. Constantly assembling people who happen to have the right skills for today’s task would give us a fairly miserable organisation, however good the allocation spreadsheet looked. The team also needs enough cover for holidays, sickness and parental leave. (Yes the humane AI companies do do vacation!)
The stable team would retain its relationships, customer understanding, decision history and responsibility for the health of its capabilities. Its mission could evolve, but it should also be broad enough for the work to flex without rewriting the mission every time. A team responsible for how customers use agents could explore onboarding, reliability, permissions or cost as the evidence warranted.
Smaller working groups could form around an uncertainty, opportunity or consequential decision needing sustained human attention. Agents could continue making changes within their permissions without people assembling for every intervention.
The team would also improve how it builds and operates its part of the product. That includes keeping customer evidence and decisions current, improving evaluations and deciding what agents can do without approval. This needs time alongside the immediate customer problem. It can’t depend on somebody having a quiet Friday.
Reporting lines and leadership at different horizons
I’d retain discipline-specific first-line management. Too much of development, assessment and managerial credibility depends on understanding the work. Engineers need technically credible managers, and Product or Design people reporting to somebody who understands only engineering could face the same problem. Cross-discipline first-line management might become more practical as careers broaden, but I wouldn’t build any proposal around that happening now.
At Director and VP level, I expect considerably more breadth. An engineering leader should have informed product opinions and understand the difficulty of creating a coherent vision. A product leader should understand the technical and operational consequences of that vision. Good companies have encouraged this for years, and I’d expect leaders to develop that breadth.
I’d put R&D under one leader below the CEO. A CPTO or VP with a combined remit could oversee separate Engineering, Product or Design directors or VPs where the scope justified them. Combined leadership needs to respect the judgement of all those disciplines.
Anna Shipman’s notes from a CPTO panel describe both the appeal of that combined responsibility and something it can remove. Working through a decision with a Product or Technology counterpart provides challenge, helps rehearse the questions teams will ask and gives people time to catch up. I’d build those opportunities into a combined remit: seek challenge from people with the confidence to disagree, and discuss consequential decisions while there is still room to change them. One accountable leader shouldn’t mean one person’s thinking goes untested.
For example, an Agents director could oversee a few stable teams within that area. Each team would have engineers and continuing Product and Design membership. Engineers would report to an engineering manager; product managers and designers would report to leads in their own disciplines, who could support people across those teams. The engineering managers and discipline leads would report to the Agents director, who in turn would report to the common R&D leader.
The director would decide where to invest within an agreed budget and company strategy. Managers would make sure people joining a working group had the focus and support to contribute. The team and agents could make routine decisions themselves. A larger commitment would need the budget holder; a change to a customer promise or security boundary would need the person accountable for it. The R&D leader would resolve trade-offs across areas.
Good Engineering and Product directors already align their teams. I still think separate functional commitments create overhead even in good, fast-moving organisations. Broader contribution within teams and common leadership could reduce that negotiation. Leaders would still need to resolve disagreements about investment, experience quality and technical consequences.
The horizons remain familiar: managers stay close to people and current work, directors connect related areas and wider stakeholders, and VPs hold longer-term direction and company commitments. AI can help them examine more information and prepare decisions, which may let each person cover more ground. It doesn’t establish that a manager can know twice as many people well. Anthropic’s October study of its own employment and working patterns reports increased technical IC meeting time.
Nor do I think AI is good enough at sharing strategic context yet. A summary saying “make agents first-class” leaves out why that matters now, which customer promises must survive and which trade-offs people can make. Leaders need to discover different interpretations, explain the reasoning and revise the direction when teams find evidence against it. Agents can preserve decisions and explain technical state, as I argued in the SDLC posts.
Engineering, Product and Design need a broader remit
I argued in 2025 that engineering needed to work across frontend, backend and infrastructure boundaries. I expect that to continue, and to extend further into product judgement and design. Twenty years ago, engineers generally had a wider remit than many of the specialisations we’ve since created. AI gives more people the ability to investigate a problem, produce working options and evaluate what happens.
That expectation should extend across Product and Design too. A designer can build and test a working experience, and a product person can investigate data or explore a possible intervention directly. People still need to recognise when their understanding is enough for a decision and when they need somebody with more depth. Being able to generate an interface or some code doesn’t tell you whether it’s any good.
Anthropic’s study of how AI was changing its own engineers’ work found people working across unfamiliar areas and broadening their skills. It also recorded concerns about losing the deeper competence needed to critique generated work, and fewer opportunities for mentorship as questions moved from colleagues to Claude. The study combined interviews, usage data and self-reports from Anthropic employees.
Keeping skills fresh has always been part of working in technology. The pace has increased, and the range of things we need to understand is growing. I’m comfortable expecting people in well-paid technology roles to keep learning. At more senior levels, some self-directed learning in your own time is necessary; that’s been my experience. Companies should support development within the job, and people need to take responsibility for keeping their own skills current.
Shared teams can improve the system for everyone
Shared teams could maintain identity, deployment and security capabilities for other teams to use directly. I’d expect more agent execution to let a smaller human group support more teams, provided it wasn’t manually fulfilling every request.
Some of those capabilities would serve customers too. An IAM team could own identity and authority for internal agents and the customer-facing platform. It would need to understand both sets of users and the promises attached to each. I wouldn’t force it into an exclusively internal platform category or split the work just because one part is visible to customers.
A security team could own reusable controls, evaluations, agent capabilities and help with unfamiliar risks. Humans would establish and improve the guardrails and rules of engagement for getting changes into production safely. Agents could then act within that authority without a human approving each intervention. Research agents could help teams gather and analyse evidence, with people responsible for the quality of the methods and recognising where they aren’t sufficient.
Some of this brings us back to Team Topologies, with teams providing shared services and helping others develop capability. Apparently we can rethink the SDLC and still find familiar organisational ideas useful.
In OpenAI’s harness engineering experiment, engineers made repository information accessible to agents, enforced architectural boundaries through automated checks and built feedback mechanisms so agents could do more of the execution. It was a deliberately designed greenfield setting, and the scope for autonomy depended on that investment.
How a team could explore a product direction
Take one stable team in that Agents area, responsible for how customers create and manage agents. We want to replace the existing experience so agents become first-class citizens, with the thesis that this will improve onboarding and long-term adoption. Perhaps agents become reusable objects with their own configuration, permissions and operational visibility. That is one possible product form, and there may be better ones. Existing agent functionality must continue to work, and the platform has both SaaS and self-hosted customers.
The idea could originate anywhere in the team or with a customer. The Agents director would choose the direction, with identity, security and compatibility requirements agreed with the teams responsible for them. I don’t think consensus is a useful requirement for that decision. People should contribute evidence and judgement, and somebody needs the authority to choose.
A product manager, a designer and an engineer might gather around the question of whether customers understand and can use the proposed concept. They could use agents to produce working alternatives and gather evidence, then interpret real customer feedback together. The designer could change the interaction directly and the engineer could challenge whether the product concept made sense. Their people managers would remain the same while they worked together, and the broader team would retain its other responsibilities.
Compatibility would be a hard constraint for production: existing supported configurations, workflows and interfaces must retain their supported behaviour and permissions. Customers shouldn’t have to rebuild existing usage to keep it functioning. A demo can show us something valuable while being entirely unsuitable for production, leaving the team and agents room to explore how compatibility could be achieved.
Suppose a promising interpretation needs agents to delegate authority, and the current identity system doesn’t support it. An engineer from the working group and somebody from IAM could investigate together, involving security where the authority model needed its judgement. They would extend the working group for that question, and any reusable identity capability would remain owned by IAM. I want people who ask “how can we?” and can distinguish a limitation of the current implementation from a rule we genuinely must preserve. Agents can be creative, but they can also get stuck on a small refusal or take a constraint too literally. I expect the humans involved to develop that creative problem-solving ability and take responsibility for finding a way forward when the agents get stuck.
How the team would decide what to productise
For this substantial new capability, the Agents director would decide whether a candidate deserved further exploration, productisation or culling, informed by the working group’s evidence and judgement. Expected adoption and retention would matter, along with the larger strategy and whether the remaining uncertainty was worth a bet. Routine interventions within existing authority could continue without returning to the director for approval.
Implementation readiness shouldn’t be a prerequisite for that investment decision. Productisation does the work to make a promising candidate suitable for production: compatibility, migrations, operational behaviour, release guidance and configuration of the relevant agents. The same team and agents can continue evolving the work. Deciding to invest gives them a remit to solve those problems; production exposure remains subject to the agreed guardrails.
Total cost of ownership and opportunity cost belong in the judgement. If something is cheap to build, run and reverse, we can afford to proceed with less analysis. If it requires substantial implementation effort or creates an expensive operating and support commitment, we need a stronger belief that it will move an outcome worth the investment, whether that’s adoption, retention, ARR or cost. We should consider what else the people, agents and budget could achieve. The time already spent on a prototype doesn’t make further investment more valuable, and discovering a much higher forward cost is a reason to reconsider.
As the product concept became better understood, the working group could change again. A designer might reduce their involvement while another engineer focused on compatibility and operational behaviour. Agents could continue refining the implementation and running evaluations against the maintained intent. The people would keep their stable team relationships, and responsibility for the capability would remain in that team throughout.
Production and customer adoption still need enduring ownership
For a routine change within the agreed authority, an agent could check existing workflow contracts, run permission and security evaluations, and prepare the supported release artefacts. Failed checks could feed another attempt without somebody assigning the correction to a new owner. The product manager wouldn’t need to translate every correction into a ticket, and the engineer wouldn’t need to negotiate a routine security review. Novel risks, changed promises or an inadequate evaluation would bring people back into the decision. The shared teams would improve the controls when a recurring issue showed the system needed to change.
The same team would remain responsible for making the capability work across both delivery models. In SaaS, agents could progressively expose behaviour, observe the result and stop or reverse exposure within their authority. In self-hosted installations, the vendor supplies a supported release with compatibility evidence, upgrade checks, migration guidance and recovery provisions. The customer retains control of installation and enablement. Customers could authorise a deployment agent to check compatibility, apply an upgrade within their change policy and verify the result. Recovery plans would need to cover data changes as well as application code.
Marketing and Sales need to work with that fluidity too. Marketing can help customers understand the new agent concept and communicate a meaningful benefit without turning every refinement into a launch. Sales needs a dependable view of supported behaviour, experiments, eligible self-hosted versions and explicit commitments. Commercial decisions about positioning, packaging or promises need human involvement early enough to shape the product. Those conversations remain necessary across R&D and GTM even as routine delivery coordination inside R&D disappears from the model.
The team would track customer success, the health of existing functionality and the capability’s ongoing cost. Adoption evidence needs separate interpretation for SaaS and self-hosted customers: somebody who hasn’t upgraded can’t yet use the new capability. That evidence could prompt a different intervention, better agent controls, another human working group or a decision to stop investing.
I believe a smaller organisation can take on more when people have a stable team and the authority to work across a wider remit. I’d expect R&D leaders to examine the handoffs and approval decisions their reporting boundaries create, and remove the ones the system can now handle. I’d make reducing that coordination work an explicit responsibility, alongside product direction, investment and developing their people.