It’s here. Whether it lasts, pops the bubble or leaves a lasting impact is a debate that will last for another decade. AI has made building exponentially less effort intensive. Roadmaps that used to take months in engineering effort are now normalizing to days.
I was working with a leader on a strange divergence. With stronger AI adoption in the team, their throughput had climbed sharply. However, what was shipped to the customer had not moved proportionately. We were quite struck with what we observed and went looking for where the throughput had gone. It had not gone anywhere, it was just queued.
In a parallel era, Eliyahu Goldratt spent his career telling an uncomfortable truth to factory managers in 1980s.
Every complex system has at least one bottleneck or constraint that limits its ability to reach its highest potential (Theory of Constraints, Eliyahu Goldratt)
If you don’t have a handle on that constraint, your inventory gets piled up there. When you finally unlock the constraint, it does not disappear, but moves somewhere else - the next problem to solve.
For Engineering, that constraint sat at building (code). With AI, that constraint is being removed. Sizing effort based on lines of code per engineer is becoming irrelevant fast. But, the limitation has not dissolved, it has now moved to the pull request/integration points.
Five New Realities for AI Native Organizations
Organizations are at different stages of adoption, but these ground truths hold wherever you are in the journey.
Reality 1: Code Throughput is not the thing anymore
The time taken for producing code is dropping significantly. Your estimation models, your capacity plans, the sizing and composition of team still assume that code is expensive. They are measuring for something that is not the constraint anymore.
Reality 2: Engineering value is shifting from code quality to product quality
Productivity and value is moving from producing code to the ability to orchestrate, integrate and deliver customer outcomes. Expertise over an area, component, feature or customer segment (the nuanced “context”) will drive more value than expertise on a stack.
Reality 3: Reviews are where the Queue forms
Human review is a valued currency now. Generated code still needs to clear the human bar for security and privacy. And this is to stay. It is now often faster to rewrite entire feature/stacks with generated code than integrating generated code into the existing system. If you break the engineering cycle into design, build, test, deploy and iterate, then friction has collected entirely at one point.
Reality 4: Specialist roles are blurring
The lines between functional specialists (quality, program management, science, data) and core engineering are blurring with their focus areas merging into the primary engineering cycle. The interesting angle is what these specialists are doing about it. The key specialists players are building the tools and systems to democratise their expertise, so that everyone can integrate their expertise unaided.
Reality 5: Teams can now own whole parts
The mental model of hyper slicing ownership and binding teams to own parts of the system is losing steam. AI Native teams can exponentially extend their ownership beyond sum parts to whole. Smaller teams organized around singular missions can deliver across domains, platforms and large sphere of influence.
Practical To-dos
Take a large impact goal your teams delivered the last quarter and map out how they spent time between design, build, test, review and deploy. Specifically, the waiting. You are looking at the stage where work lingered. That’s your action area.
The Trust Tax
I have written about three different taxes you need to manage and design around for organizations to really work. With the new realities, we have a fourth, and AI has made it the expensive one.
Trust tax is the effort required to establish that work is safe to ship. Reviews, security, privacy, testing and all other gates that ensure your organization ships great products make up this effort. It used to be small relative to the cost of building, so we did not structure/design organizations around this flow. That ratio has now inverted.
When the trust tax is low, you could work it with the goodwill of your staff. When it is high, it is your operating model. Every dollar spent on accelerating the build phase pushes the tax number up and it increases with the investment actually funding the bottleneck.
Practical To-dos
Take the value map of your team and attach a shirt-size to the effort to build and effort to prove that it’s safe to ship. The highest points of tax are your action areas.
Design Principles for AI Native Organizations
Here are the organizational design principles that will influence how you would organize talent for the the new realities. They will evolve as we experience more ground truths.
Principle 1: Organize around Missions
Fixed ownership of services and components starts being a constraint. Bind teams to a durable mission and let its ownership follow the mission. These teams will extend from owning individual parts to delivering whole outcomes. Enable the team with everything they need to deliver the mission - talent, resources, data, authority. Whenever you reorganize, move missions, not component parts.
Principle 2: Specialists become force-multipliers
Build systems to incentivise your specialist to become multipliers. Their roles are not confined to a specialist function, it is to enable others to do their work upstream. Reframe their goals to one question - how are they democratizing their roles? Every specialist who answers removes one layer from the constraints we identified.
Principle 3: Value Orchestration and Domain Depth
Teams have shifted their value to deliver whole missions, specialist have shifted their value to democratizing. Now, reward systems need to change - hiring assessments, promotion criteria, recognition all have to change. Shift these systems towards the ability to orchestrate outcomes.
Principle 4: Plan against your Trust Tax
With developer-week estimation becoming obsolete, you need to anchor planning around outcomes and the trust tax your teams have to navigate. Review and integration capacity is the new planning unit. The question is not how much you can ship, but how you can responsibly ship.
Principle 5: Optimise the Trust Infrastructure
Automated review, security/privacy gates, testing and iteration loops deserve first class investment and staffing. This is the highest needle mover but the one that receives low attention in any budget today. Organizations that nurture their trust infrastructure convert throughput into shipped products.
Practical To-dos
Pick one principle and test it on your organizational structure. Reflect on how you are improving your structure.
What effect does this have on the Organizational Pyramid?
Here’s where change is a super cycle. And, the thing that’s bothering many of us is:
What changes for new hires and entry level employees?
The uncomfortable part is what this asks of entry-level talent. If trust friction is the constraint, then the expectation of the newest person on the team changes fundamentally. You aren’t asking them to produce code now and develop judgement over years. You are asking for orchestration and owning product quality from the start. This is a steeper first year than any of us had and it will not happen by default. It needs a deliberately structured learning curve.
Does this mean you need fewer people/lesser headcount?
Not quite. Mission teams are smaller and self contained. However, the same exponential capacity should flow to product roadmap, design and decision making. If you had to choose between three features for your product’s roadmap with constraints on the engineering cycle, you don’t have that now. You can do all three features. In parallel! As what you can promise your customers gets larger, the scale would tip and utilize your engineering bandwidth.
There is a lot of debates on how the organizational pyramid would look like at full scale AI integration. Some see it as an inverted pyramid and some see it evolving into a diamond with lean middle layer. I think the shape of the pyramid will not materially change - it would just reconstitute into smaller pyramids that would drive more customer outcomes.
Am watching this as the change happens like everyone. Goldratt had decades of data, while we have a very limited observation window. The design principles above are what I hold today and I expect to revise a few of them as the window expands.
Where has the constraint moved for your organization? Let’s talk.