Designing AI Native Organizations
Trust Tax – The fourth cost of getting work done
AI made building fast and less effort intensive. It did not make shipping less effort intensive. Here’s how to design organisations for where the constraint actually sits now.
I was recently sitting through a rather complex organisational challenge, working with a leader on a frame that would line up several interlaced decisions. Somewhere in the middle of it we found a strange divergence. The team's throughput had climbed sharply. What had actually shipped had not moved proportionately. We were quite puzzled, and then we went looking for where the work had gone.
It had not gone anywhere. It was queued.
In a parallel era, Eliyahu Goldratt spent his career telling factory owners something they did not want to hear. Every system has exactly one constraint. If you invest in any station that is not the constraint, you produce nothing except inventory piling up in front of the station that is. And when you do finally relieve the real constraint, it does not disappear. It moves.
That is the most useful thing anyone has said about engineering organisations in the last three years, and it was said about a factory floor in 1984.
AI relieved the authoring station. Coding assistants draft, refactor and test in minutes. Where teams build from the ground up without legacy nuances, work that took months now takes days. The usual tools of shirt sizing based on lines of code per developer are becoming irrelevant fast.
The constraint moved. It now sits at the pull request/integration points.
What has actually changed
Organisations are at very different stages of adoption. But a few ground truths hold consistently, wherever you are in the journey.
Code throughput is no longer the scarce thing. The time taken to produce working code has dropped drastically. Your estimation models, your capacity plans and your team sizing all still assume it is expensive. They are measuring a station that is no longer the constraint.
A developer’s value is shifting from code quality to product quality. Productivity is moving from the ability to produce code to the ability to orchestrate, integrate and deliver customer outcomes. Expertise over an area, a component, a feature or a customer will drive more value than expertise in a language or a stack.
Review is where the queue forms. Generated code still needs human review. It still has to clear the bar on security and privacy. It is now often cheaper and faster to rewrite an entire feature with generated code than to integrate it with the legacy system next to it. Break engineering into design, build, test, deploy and iterate, and the friction has collected almost entirely at one point.
The specialist roles are blurring. The lines between quality, programme management and engineering are dissolving, with their focus areas merging deeper into the primary engineering cycle. The interesting shift is what the specialists are doing about it. The good ones are building the tools and systems that democratise their expertise, so that everyone can perform in those areas unaided.
Teams can now own whole parts. Teams bound to their ownership of sum parts of a system can extend to the whole. A small team organised around a single mission can deliver across domains, platforms and a large sphere of influence, once the support systems exist.
Practical to-dos
Before you borrow my five, write your own. Take one delivery from the last quarter and log the calendar time it spent in each stage: design, build, test, review, deploy. Not the effort. The waiting. You are looking for the stage where work lingered. That is your constraint, and it may not be the one I have described.
The Trust Tax
I’ve written before about three costs that good structural design exists to minimise. Coordination tax, the effort of getting teams to move together. Decision tax, the hoops an idea jumps through before someone can say go. Information tax, the distance between a team and the insight it needs.
There is a fourth, and AI has made it the expensive one.
Trust tax is the effort required to establish that finished work is safe to ship. Review, security and privacy gates, testing, provenance. It was always there. It used to be small relative to the cost of building, so nobody structured an organisation around it. That ratio has now inverted.
When that number was 0.2, you could staff it out of goodwill and senior engineers’ evenings. At 2, it is your operating model. And the trap is that every rupee you spend accelerating the build side pushes the number higher, which means your throughput investment is now actively funding your bottleneck.
Your shippable output is the smaller of what you can build and what you can trust. Not the average of the two. The smaller.
Practical to-dos
Take the value map of your team and attach a shirt-size (XS, S, M, L, XL) to the trust tax on each handoff, the same way you would size coordination or decision tax. Then find the ratio. If proving a change is safe costs more than making it, you have your answer on where to invest next, and it is not another coding licence.
Designing for where the constraint sits
These are design tenets, not laws. They will change as we experience more ground truths. Hold them until you know better.
Organise around missions. When small teams can extend from sum parts to whole parts, fixed ownership of services and components stops being clarity and starts being a constraint. Bind a team to a durable customer mission and let its span of ownership follow the mission. Fewer, broader teams will out-deliver many narrow ones. The team has to be self-contained enough that it never stalls waiting for someone else’s function to test it or give it data. And when you move talent, move an entire mission. Not fractional roles.
Turn your specialists into force-multipliers. As the lines blur, the highest-leverage move for a specialist is to stop being the person who does the work and start being the person who makes the work doable by anyone. Reframe the role around one question: what expertise can I democratise? Every specialist who answers that well removes a queue.
Reward orchestration and domain depth. If value has shifted to product quality and customer outcomes, then hiring bars, promotion criteria and recognition have to follow, or you will spend two years rewarding the thing you no longer need. Reward depth in a customer domain over fluency in a stack. Reward the ability to marshal AI, systems and people towards an outcome over the ability to author code alone.
Plan against your trust capacity. With developer-week estimation obsolete, planning has to anchor on the outcome and the judgement required to deliver it safely. Review and integration capacity is now your real planning unit. The question is no longer how much you can build. It is what you can responsibly ship and own.
Treat trust as infrastructure. Automated review, security and privacy gates, testing and provenance deserve first-class investment and dedicated staffing. This is the least glamorous line in any budget and currently the highest returning. Teams that build a strong trust system convert throughput into shipped product. Teams that don’t simply relocate their bottleneck and call it progress.
Practical to-dos
Pick one tenet and test it against a live decision you are about to make on structure. If the tenet doesn’t change the decision, either the decision was already right or the tenet is not yet real in your organisation. Both are worth knowing.
What this does to the pyramid
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 a mission team changes fundamentally. You are no longer asking them to produce code and grow their judgement over five years. You are asking for orchestration and full product quality, from the start. That is a steeper first year than any of us had, and it will not happen by default. It needs a deliberately engineered learning curve.
Does this mean you need fewer people? Not quite. Mission teams that are small and self-contained also mean you can run more missions at once. You expand what you can deliver this year against what you had planned for next year. Headcount may fall in places. But, as the set of things you can credibly promise your customers gets larger, the scale would tip. People talk of inverted triangles, but I think we will just have multiple smaller triangles, exponentially building more possibilities for the customer.
Sequencing
Most of this fails on the order, not the idea.
Trust before speed. Invest in the paved paths first. Automated review, security and privacy gates, testing, provenance. Pick one team to build and prove them. Nothing else is safe to scale until throughput can be trusted.
Capability before ownership. Convert a single willing team to the self-contained, mission-bound model and let it consume what phase one built. Embed the specialists to transfer expertise, then let them step back into the multiplier role. Measure delivery, not headcount.
Outcomes before structure. Re-point ownership one boundary at a time, as missions prove out. Component ownership dissolves only after a mission team can safely own the whole. Planning, hiring bars and promotion criteria change next. The org chart changes last.
Attempting the reorganisation before the trust system exists simply relocates the bottleneck and adds a reorganisation to the cost.
Taken together, these tenets do one thing. They concentrate scarce human attention exactly where machines cannot go, which is deciding what is worth building and standing behind whether it is safe to ship.
I should say that I am watching this change as it happens, like everyone else. Goldratt had decades of factory data. We have about three years and a lot of conviction. The tenets above are what I would hold today, and I fully expect to revise at least two of them.
Where has the constraint moved in your organisation? And what is it costing you to find out? Let me know!