Transforming your tech organization to make it AI-driven

What changes when building costs less than deciding

Building an AI-native team of four is easy. The problem is when you already have eighty or more people in your teams: how do you rethink your organization in the age of AI?

As long as building took weeks, a few days of specs, alignment and handoffs blended into the cycle. When building drops to a few days, those same delays become the cycle. AI challenges current organizations, built around long delivery times. With that problem partly solved, how do you adapt and build effective organizations?

What changes inside teams

At ten people, even in a single squad, many interfaces need to be formalized. "Who takes this?" becomes a Jira ticket. "We need to align stakeholders" becomes a meeting. At three or four, those same interactions often stop needing a process. "You take this?" is a sentence. "Wait, come look" replaces the alignment meeting. You don't eliminate coordination. You reduce its transaction cost.

Gradually, a different format is emerging: the one-pizza team. One person whose role is to understand and communicate customer needs, to verify the impact of what's being built, and who can prototype. Not necessarily a PM. Two or three others to help with the prototype or to industrialize and evolve the product. Not necessarily the same roles, but always a small team. And in my view, never a single person with agents: multiplying agents doesn't create the diversity of judgment that comes from several humans accountable for the result. Collective intelligence remains necessary.

Each step of the product cycle then raises a simple question: does it add judgment, or does it transport information? Customer, PM, spec, ticket, dev, review, QA. When you remove the pure transport steps, a smaller team becomes viable. It's the removal that enables the reduction, not the other way around.

In many organizations, especially those where product culture is weak, developers live behind the PM. Specs in, code out, never a customer. When transport steps compress, developers find themselves exposed to the real need: why a feature is requested, in what context, with what urgency. The transformation is simpler when silos are weak, when devs know their customers and their needs, are already able to absorb part of QA. But that doesn't make it easy.

Why it's hard

As soon as a team of three can absorb part of the work that used to require eight, the arithmetic question comes up. And there's no simple answer. A capacity increase can go toward less headcount, more product built, more quality, or a shift in skills. That's the CEO's call. But starting with headcount carries a risk: freezing the new organization before understanding where human value has shifted. Cutting today the people you'll discover six months later were excellent at understanding customers, making trade-offs, or maintaining context (hello Klarna, Ford, and the rest).

And headcount isn't even the most complex part of AI transitions.

In an organization, status often follows scarcity. The person who can do what others can't becomes indispensable, then senior, then lead or manager. AI doesn't eliminate this expertise, but it changes what is scarce. When certain technical capabilities become accessible to many more people through agents, it's not the skill that disappears, it's its organizational monopoly. The back-end engineer is no longer necessarily the only one able to touch the back-end. The senior is no longer the only one able to quickly produce a complex prototype. The PM is no longer the only one able to turn a customer conversation into a first materialization of the need. Expertise is still just as useful, but since the expert's impact is also multiplied, the expert-to-generalist ratio can shrink.

The manager's role shifts too. In a cell of three or four, there's less daily work of distribution and synchronization. The manager doesn't disappear: the scope changes. It moves from optimizing the team to optimizing the system between teams. Creating the context a cell can't produce alone, managing dependencies, moving people and skills where they have the most value, supporting roles that change faster than job descriptions. It's a change of profession, not an increase in the number of people to manage.

This shift is easy to write in a blog post, but less so when you're facing reality. A senior developer may have spent fifteen years becoming excellent at a skill that agents suddenly make accessible to others. Telling them "now talk to customers, orchestrate agents, and be versatile" is easy to say, but far more complex to live through. It's a challenge to the very source of their professional confidence.

Part of what we'll call "resistance to change" won't be technological conservatism. It will be the rational reaction of people whose place in the organization rested on a scarcity that's disappearing. Which is why this change needs to be planned and structured.

How to get there

You don't do an AI transition just by redrawing an org chart. You take a real product flow, you reduce the interfaces that transport information without adding judgment, you tool up with agents, and you observe what breaks. You start with one team: before impacting everything, you learn, then you deploy.

Blockers appear fast: a PM who can't let go of writing specs, a developer who doesn't know what to ask a customer, a manager who keeps coordinating a cell that no longer needs them to coordinate. Sometimes it's the technical skill that's missing, sometimes it's the business understanding.

That's when you train, not before, and on the actual friction point rather than on generic skills. Training everyone on prompt engineering before changing the workflow is reproducing the old model with faster tools. The transformation starts when you change the flow itself. Then you start again on another flow.

I don't know yet what the steady state looks like. None of the organizations I observe have reached it, including the ones moving fast. What I see is that those making progress aren't looking for the right org chart. They're shortening the path between a customer problem and the moment the team learns whether they've solved it. They share the lessons and support the changes. Tool capabilities move faster than job descriptions. On this path, every interface must justify the judgment it adds.