June 3, 2026
Things are changing in how the some forward-thinking technology leaders are thinking about organisational design in the age of AI. It's not at the tooling layer as that conversation is largely settled. Rather it's at the structural layer. How organisations are designed.
Jack Dorsey's restructuring of Block, and Brian Armstrong's parallel moves at Coinbase, are the clearest visible signals. And what we are observing more broadly, across the engineering organisations we work with, is a growing divergence between leaders who are treating AI as a productivity layer and those who are beginning to treat it as an organisational and architectural principle.
This piece is speculative. We are not describing a proven model. Indeed, the evidence on results is still very much out. Rather, we are describing a directional shift that appears to be underway. We draw on what Dorsey and Armstrong are doing in practice and applying our own analytical lens to what it might mean for engineering and technology leaders specifically.
The evolution of organisational design can be read as three distinct eras, each defined not by culture or leadership style, but by where the binding constraint on performance actually sits.
Manager Mode was the dominant model of the 20th century. Hierarchies were deep, roles were narrow, and information moved vertically through layers of management. The pyramid was not an accident of power. It was imply the most efficient available organisational architecture for aggregating human judgment and routing decisions. Jack Welch at General Electric is the archetype: command, control, and clarity of reporting as competitive advantage.
Founder Mode, which was popularised by Steve Jobs and articulated more recently by Paul Graham, shifted the constraint. The problem was no longer coordination but instead creative and other bottlenecks at the top. The response was a flatter, faster organisational structure where leaders stayed close to the work and the best ideas could surface from anywhere in the organisation. It was still, however, fundamentally human-centric.
Dorsey Mode, as it has been called, changes the things entirely. The binding constraint is no longer seen as human coordination or creative access. Rather it is the quality of organisational data and the degree to which internal systems are legible to AI agents. Dorsey's restructuring of Block is the clearest live example: a deliberate move to place AI at the centre of the organisation as a unified intelligence layer, reducing the human hierarchy to the functions that agents genuinely cannot perform.
Each transition has followed a similar same logic: identify where the constraint on organisational performance sits, and redesign the architecture around it. The organisations that recognised the shift from coordination to creativity early built durable advantages. The same dynamic is now playing out again, at greater speed and with higher structural stakes.
The traditional organisational pyramid was not about power for power sake. It was about information architecture. Hierarchies exist because they were the most reliable way to aggregate, filter, and route decisions through a system of "human nodes". Remove the information problem, and the pyramid loses its justification.
In Dorsey Mode, AI sits at the centre of the organisation as a unified intelligence layer. It is envisioned as a central brain rather than a central bureaucracy. In this model, rather than information crawling up and down a chain of human managers, it flows continuously into a system that can process it, surface patterns, and execute workflows autonomously.
This is not a minor operational upgrade. It is a very radical re-imagining of how organisations process reality.
The prerequisite for this model is organisational legibility: the degree to which your internal systems, data, and processes can be read and acted upon by AI agents rather than just by humans.
In practical terms, this means:
Frankly, most enterprise engineering organisations are a long way from this. The friction is not just at the AI layer. It is that systems, data and processes are embedded in decades of tooling decisions, data architectures, and process designs that were built for human navigation in that organisation. Not for agents.
Moving forward, the question becomes about increasing the percentage of your organisation's decisions made, or materially informed, by AI. It's a radical transformation.
The Dorsey approach is not a single design decision. It is a set of interlocking principles that, taken together, produce a fundamentally different kind of organisation. And each one challenges a deeply held assumption about how technology companies should be built and run.
The conventional wisdom in technology strategy has long been that focus is the primary discipline. This is the idea that an organisation can only sustain a small number of genuine priorities before fragmenting. This reflects a real constraint, but one that was shaped by the economics of human execution.
In an AI-native organisation, the cost of experimentation collapses. When an AI-native team can build, test, and kill a product in a matter of weeks, the calculus changes. The cost of choices is reduced. So, the organisations that will win are not the ones that focus hardest, but the ones that can run the most intelligent experiments simultaneously. Prolific, in this context, becomes a structural property not a cultural one.
The talent profile for a Dorsey-like organisation may look genuinely different from the traditional engineering hire. Three qualities are emerging as the relevant differentiators:
Traditional experience, in this framing, carries a specific risk. Years of experience in a pre-AI engineering organisation can mean years of caution and internalised assumptions that no longer hold. The claim is that the "20x engineer" is no longer the one who writes the most code. It is the one who can orchestrate to do the work of an entire function while maintaining the judgment to know when the output is trustworthy.
In the previous era, team size was a reasonable proxy for organisational capability. More people meant more capacity. That logic made sense when humans were the primary unit of execution.
In these new organisations, large human hierarchies may be a signal of something else: insufficient AI integration. Every layer of management that exists primarily to move information between other humans is a layer that, in principle, an AI agent could replace or dramatically compress.
This does not mean engineering organisations should immediately reduce headcount. It means they should be able to articulate precisely why each human layer exists and what it provides that an agent could not. That question alone may be a useful diagnostic.
The structural advantage in Dorsey Mode belongs to organisations building from scratch. A startup founded today can design its data architecture, tooling, and processes around AI-native principles from day one. It does not have to unlearn a decade of accumulated hierarchy.
For established engineering organisations, the path is harder. Legacy systems were not built to be legible to agents. Processes were designed for human navigation. Compensation structures and job descriptions reflect a world where the unit of productivity was an individual contributor, not a human-agent pairing.
It's going to be challenging. It requires bold moves, but also being precise about sequencing. The organisations that will navigate this successfully will be those that treat AI integration as an architectural question, not a tooling question, and that build the measurement infrastructure to understand where their current structure is creating friction.
While this Dorsey framework biases towards startups, the structural logic might apply with equal force to the engineering organisations inside medium-to-large enterprises.
A startup that fails to become AI-native simply loses to one that did. An established engineering organisation that fails to make this transition becomes progressively less competitive while continuing to carry the overhead of a structure built for a different era.
The specific pressure points that may apply to engineering leaders in this transition are worth naming:
Obviously, this is speculative. None of this requires an immediate organisational revolution. But it may require an honest assessment of where your current structure sits on the AI spectrum (AI-washed to AI-native), and a clear view of which architectural decisions need to be made.
Before we throw the baby out with the bathwater, it is worth being precise about what the Dorsey approach does not claim. It is not a prediction that human engineering leaders become redundant. The human remains the final arbiter. The leader role shifts from conductor to editor, from coordinator to curator of context and taste.
That shift is not a demotion. In many respects it is a more demanding role. Editing AI output well requires deeper domain knowledge than generating average output manually. Providing useful context to an agent requires a clearer understanding of organisational goals than most management processes currently demand. And maintaining the judgment to know when AI-generated work is subtly wrong is a skill that takes time to develop.
The organisations that navigate this will transition well will not be the ones that automate the most. They will be the ones that develop the clearest view of what humans are uniquely positioned to contribute, and build their architecture around that distinction.
Dorsey's restructuring of Block and Armstrong's moves at Coinbase are early, very imperfect data points. The approach is not proven at scale across diverse organisational contexts. But the directional logic of AI-native architecture as a structural advantage rather than a productivity tool, does have a resonance.
The question for engineering leaders is not whether this transition is coming. It is whether their current structure is oriented toward it, or away from it.
Implement Partners works with technology leaders to build the measurement infrastructure, delivery frameworks, and organisational clarity needed to make this kind of transition legible and actionable. If your organisation is working through what AI-native actually means in practice we would be glad to think through it with you.
A 30-minute call is usually enough to know whether a Delivery 360 would be useful — and what it would look at in your situation.
