The two most common types of organizations you’ll see have either organized themselves along product lines or functions.
Product line organizational models tend to be as cross functional as possible, allowing for multiple disciplines to “own” a system. You’ll have frontend and backend folks working together, often with design, qa, and “devops” thrown in for good measure. You’ll also have a PM whose job it is to coordinate with the rest of the “product org” at your company to try and move your product toward some kind of vision.
Functional lines end up with larger teams and is, often, an older way of working. The idea is that you end up having a “backend” team and a “frontend” team. You have a team of “QA” and “designers”. You don’t really have product managers in this mechanism, regardless of what they are called. You actually have project managers. And their job is to take a feature or functionality from beginning to end, shepherding it across functional lines.
In both these models, the PM is often treated as the person with the full context on the project. That is true in some organizations, but it is not quite the right framing. In strong product organizations the PM usually has the customer and business context. Designers may have the strongest user and workflow context. Engineers may have the strongest system, operational, and technical constraint context.
The people getting the most out of AI are not simply the people with the “PM” title. They are the people who can express intent clearly across all of those boundaries. They can describe the customer problem, the product bet, the system constraints, the operational risks, and the shape of a good solution with enough precision that an AI agent can do useful work.
That changes the job of the builder. In an AI Native organization, the builder cannot only be a ticket-taker sitting downstream from product context. The builder needs enough product, technical, and operational context to direct the agents doing the work. Sometimes that person will come from product. Sometimes they will come from engineering. But the important shift is that the person closest to the implementation also needs to be able to express the intent behind the implementation.
When I say “AI Native” I do not mean “everyone has ChatGPT open in another tab”. I mean an organization where AI agents are part of the delivery system. Work is decomposed with agents in mind. Context is written down so agents can use it. Reviews, tests, evals, observability, and production gates assume that some meaningful portion of the work was done by agents. AI is not a personal productivity tool layered on top of the old org chart. It is part of how the org ships.
What I propose next is what I envision as the direction to move for “AI Native” organizations.
Feature Teams: Small By Design
Your new project should have a small number of folks on it. Maybe that is two people. Maybe it is a few more. The exact number is less important than the shape of the team. These teams stay small because parallelization is handled at the agent workflow layer, not by adding more people to every discipline. Aided by “AI” the whole way, the goal for these folks is to take something from idea to completion.
Right now when we talk about ‘feature teams’ we envision cross functional folks that are coordinating with each other. Frontend, backend, QA, design, infra, analytics, documentation. The important bit is that those are already the places we break work apart for parallelism. Those boundaries do not disappear in an AI Native organization. They move inside the workflow of the feature team.
A small feature team is not doing less work than a traditional squad. They are directing a set of focused agents against the same problem space. One agent can explore frontend changes, another can generate test cases, another can trace through a backend flow, another can draft documentation. The human team is still responsible for whether the whole thing is coherent, shippable, secure, and aligned with the product bet. But the parallelism is coming from agent orchestration instead of headcount.
As you transition from traditional organizations to “AI Native” these teams will naturally be the folks that have embraced AI workflows the most. They probably have their own systems and flows in place that allow them to move quickly. If you don’t have any of these folks, you’re behind. You need to either hire them ASAP or pick some folks and get them there. But that’s another post I think.
Failure Modes
The failure mode here is the demo factory. A small team with a strong agent workflow can produce an enormous amount of convincing work very quickly. That does not mean the work is correct, maintainable, secure, or worth shipping. Without strong ownership and production discipline, the feature team becomes a prototype generator that leaves the rest of the company to clean up the mess.
The other failure mode is confusing agent orchestration with management. If the humans on the feature team cannot evaluate the output, they are not leading the work. They are just accepting whatever the agents produce. These teams need to be small, but they cannot be shallow. They need enough judgment to know when an agent is wrong, when a specialist needs to be pulled in, and when the product idea itself is not strong enough yet.
Enablement Teams
If you’re not on a feature team, the truth is that you’ve likely specialized. In that you are not a “generalist” developer, but rather have honed in on a particular area or skillset. This wasn’t a bad thing before, and it isn’t a bad thing now. The difference is that now you’re doing less “single feature” work, and instead working across a series of projects operating more as a consultant. Your job is to parachute into a project, quickly understand the bottlenecks in your area of expertise and offer solutions.
These are not only engineering specialists. In regulated or domain-heavy industries, this is where the enterprise knowledge lives. Your security experts, compliance experts, data governance folks, FHIR experts, payments experts, or whatever domain-specific people matter to your business need to be available to feature teams as context providers. Their job is not to take ownership away from the feature team. Their job is to inject the right constraints early enough that the feature team and their agents can build the right thing.
Historically we’ve had these segmented as “platform teams”. Their job was to create a solid base so that the rest of the org can move quickly. This is still vital, the difference is the level of involvement. Before platform teams often worked on longer term roadmap items to enable other teams to work faster. Now the horizon for that is shrinking and your users (feature teams) are able to get a lot of work done and waiting for all the larger scale things to be resolved will slow things down.
This is not a handoff model. Once a feature team builds something, they own the lifecycle of that feature from beginning to end. That means they own the implementation, the deployment, the production behaviour, and the on-call escalations once the first level of AI agent integrations cannot resolve an issue.
The job of enablement teams is not to inherit risk from feature teams. Their job is to create paved roads, provide embedded consultation, run reviews, and define the production gates that make it safe for feature teams to move quickly. They’re not “fixing bugs” - they’re doing things like optimizing LLM chains, ensuring proper observability between application and AI, and making sure that every new system has a clear path to production.
This is a new team. Traditionally “platform teams” would spend quarters working on this stuff, and then throw it over the wall at feature teams to implement. Now enablement teams are closer to the work and more involved in the decisions that determine whether something is production ready. Without these teams working, things are NOT going to production. This is really where your staff/principal engineers would sit.
They might get pulled into planning meetings with feature teams quite frequently because they will have a lot of context across the org.
Failure Modes
The failure mode here is recreating the handoff model under a better name. If enablement teams become the place where feature teams throw work before production, then you have not built an AI Native organization. You have built a faster waterfall. Feature teams will optimize for impressive demos and enablement teams will inherit all of the risk.
The other failure mode is becoming a committee. Enablement teams should provide constraints, paved roads, reviews, and deep context. They should not become a central approval board that every feature team has to satisfy before anything interesting can happen. If they are involved too late, they become blockers. If they are involved early, they become leverage.
Platform Teams
These teams were traditionally just SRE teams - but these will be expanded. Yes, they will contain the traditional larger platform enablements, but they’ll also include higher level product folks. People who are thinking 1 to 2 years in the future and trying to understand where the business as a whole is working toward.
In an AI Native organization, the platform team is building the operating system for the rest of the company. They own the golden paths that let feature teams move quickly without inventing a new production model every time. That includes deployment pipelines, environment management, observability defaults, security policies, access controls, incident response patterns, documentation systems, and the shared context that agents need to be useful.
They also own the AI-specific parts of the platform. Agent workflows, prompt and context management, eval infrastructure, model routing, audit logs, data access rules, and the standard ways teams are allowed to put AI-backed features into production. If feature teams are going to move quickly, platform teams need to make the safe path the easy path.
Traditionally these folks were rather isolated from the “higher ups” but the truth is that they need to be even closer to strategy vision and direction because the work they are doing directly impacts how quickly the rest of the teams will be able to move.
Failure Modes
The failure mode here is centralizing too much. Platform teams can easily become the only group allowed to make important technical decisions. That will slow the organization down and push feature teams back into dependency chains. The platform team’s job is to make the safe path easy, not to make every path go through them.
The other failure mode is building a beautiful internal platform that does not match how teams actually work. If the platform team is too far from feature team workflows, they will create tools, policies, and agent systems that look good in strategy decks but get bypassed in practice. The platform only matters if it becomes the default way teams ship.
The Shape Of The Org
The old squad model assumed that if you wanted parallel work, you needed parallel people. You needed a frontend person, a backend person, a QA person, a designer, a PM, an infra person, and enough rituals to keep all of those people pointed in roughly the same direction.
AI changes that assumption. It does not remove the need for judgment, domain expertise, or production ownership. If anything, it makes those things more important. But it does change where parallelism happens. The work that used to be spread across a cross-functional team can now be decomposed into agent workflows by a much smaller group of high-context builders.
That only works if the rest of the organization changes around them. Feature teams own the outcome. Enablement teams bring deep expertise and production constraints into the work early. Platform teams make the safe path the default path. If any of those pieces are missing, you do not get an AI Native organization. You get faster prototypes, overloaded specialists, and a platform everyone works around.
The goal is not to replace teams with agents. The goal is to design teams around the fact that agents are now part of how work gets done.