Prologue: Why now?
This essay and the pod structure it contains is a response to a specific technological moment highlighted by Jack Dorsey and Roelof Botha in their essay hierarchy to intelligence.
For most of the last fifty years, building software at scale required scaling people. Two main reasons. Firstly, seniors needed to delegate the growing work to juniors. Especially the trivial and time consuming. Secondly, many people were needed to keep the doers informed, aligned and rowing in the direction of the company strategy.
That equation has broken. AI can glean, synthesise and route information more effectively than human management can. Further, AI has compressed the work. A small group of exceptional operators commanding modern AI tooling can now produce the output that previously required a hundred. The constraint is no longer headcount. It is access to information, judgment, taste, customer empathy, product empathy, speed of decision making, autonomy to ship, autonomy to experiment, accountability and of course AI adoption. These qualities live in individuals and small groups, not in large org charts.
CoTreat’s pod structure is built around three convictions. Small teams perform better. Autonomy is empowerment. AI is the new communication and coordination layer.
A pod is a group of three to six people, formed around a single measurable mission, with a defined timeframe. Three is the smallest feasible shape. Six is the largest a pod can grow to without losing the qualities that make it a pod. A pod is not a department, a function, or a permanent home. It is a configuration. People form a pod, deliver against a mission, and dissolve. Some pods last weeks. Some last months. None, except perhaps the CEO’s central pod, lasts longer than that.
The chapters that follow describe the shape and characteristics that make a pod actually work: how it stays autonomous, why it must end, how it knows what it is doing, how its people are organised, what kinds of expertise it must contain, when it is allowed to grow, and the connective tissue that holds the whole formation together.
I. Autonomous
A pod is autonomous when it can ship.
That is the definition. End to end. From the first conversation about the problem to the measurable result, a pod must traverse the entire path under its own power, without queuing for another team, without waiting for a handoff that may or may not come.
This is the load-bearing claim of the whole structure. If a pod cannot deploy autonomously, it is not a pod. It is a working group with a fashionable name.
In practice, autonomy means a pod has all three angles resident inside it. Technical, so it can deploy. Domain, so it stays connected to the customer. And a third to bridge, synthesise, and amplify the technical and/or customer perspectives. More on that in chapter V.
II. Impermanent
Pods are temporary by design.
This is the part that people from traditional org structures find hardest to accept. A pod is not a permanent home. It is not a unit on the org chart with a manager and a budget. It is a configuration of people, formed for a mission, with an explicit timeframe, and dissolved or reformed when the mission ends.
The default lifespan is typically short. Long enough to deliver something real. Short enough that nobody settles in, that the pod cannot become a fiefdom or a sinecure, that everyone knows the work has to actually get done.
Impermanence prevents the slow ossification that kills most organisations. Permanent teams accumulate ritual. They develop their own rhythms, their own internal politics, and over time the team itself becomes the point. Pods cannot do this. The pod is the work, not the people, and when the work is done the pod is done.
III. Mission and metrics
A pod begins with a mission. Not a remit, not a charter, not a roadmap. A mission. One sentence that names what the pod will deliver and what success looks like when it has delivered. In bygone times, this might have been "capture this watchtower" or "guard this flock of sheep."
A good mission is narrow enough that the pod can hold it in their heads, ambitious enough that succeeding matters, and concrete enough that everyone, including people outside the pod, can tell how it’s tracking.
The mission has clear upstream metrics and time frame attached, defined at pod formation. Success and failure are unambiguous. As time passes, the progress of the metrics is the trigger for honest conversation about whether the pod should continue, regroup, or dissolve.
IV. Hats
Inside every pod there are three structural hats. They are not job titles. They are roles in the operation of the pod, and one person can wear different hats in different pods on the same day.
DRI, the Directly Responsible Individual. One person, named, accountable. The DRI owns the outcome. If the pod ships, the DRI is why. If the pod fails, the DRI carries it. There is no committee, no shared accountability, no "we." When the pod cannot reach agreement, the DRI decides. This is not authoritarianism. It is the recognition that decisions made by groups are usually slower and worse than decisions made by individuals who carry the consequences.
IC, the Individual Contributor. The engineer writing code, the designer shipping the surface, the operator running the experiment. They influence and collaborate intensely with their DRI. They are the people from whom the work physically issues. In a three-person pod, the DRI is also doing IC work most of the time.
PC, the Player-Coach. Player-coaches don't sit in a pod. They are assigned, and drift in and out of pods. They teach by doing, transfer judgment through the work itself, and hold the line when the pod is tempted to take the shortcut that will hurt later. Player-coaches are the institutional memory of how good looks. They are how a less experienced IC learns in two weeks what would otherwise take two years.
What is not allowed is hat ambiguity. On any given pod, every person knows which hat they are wearing. The DRI is named. The ICs are named. The player-coach, if there is one, is named. Confusion about who is wearing which hat is the second-most-common failure mode of pods. The first is missing upstream metrics that demonstrate the path to the mission.
I’m increasingly of the opinion that most people should only ever be in one pod at a time.
V. Diversity of Expertise
Hats are about roles. Expertise is about angle of attack.
Every pod must contain three different angles of expertise. Not three identical engineers. Not three identical researchers. Three genuinely different ways of looking at the same problem.
Deep customer. Someone directly connected to the ground, whose first instinct is to think about the customer. This is the antidote to building beautiful machines that nobody uses. Like the legendary giant Anteaus, they need to be connected directly to the ground to be strong.
Deep technical. Someone who can ship, whose first instinct is to think about the system. What it can do, what it cannot, where the leverage is, what the failure modes are. Most often the Engineering operator, though not exclusively. The antidote to confident plans and customer knowledge that collapse on contact with reality.
Amplifier-Synthesiser. The amplifier takes the customer and technical perspectives and makes them legible to each other, then to the rest of the world. They synthesise. They package. They turn the pod's work into something the company and the market can understand. Most often the Product operator, but it can come from anywhere.
This is the diversity principle in its purest sense.
VI. Redundancy
Pods begin critically lean. They grow only when they have earned the right.
A new pod has three people. One operator per angle, three hats distributed across them. At three people, the pod is fast, cheap, and entirely dependent on each individual showing up. There is no redundancy. If anyone falls over, the pod more or less stops.
This is acceptable. Most pods will not justify a redundant person, ever. They will run their course in weeks, deliver or fail, and dissolve. Adding redundancy to a pod that does not yet know if it deserves to exist is wasted headcount. It also signals low confidence in the pod members itself, and that signal travels.
Redundancy gets baked in only when two conditions are met. First, the pod is delivering. The mission is real, the metrics are moving, the work is producing value. Second, the leadership has decided to give the pod a more ambitious, critical mission that cannot have single points of failure.
When both conditions hold, each operator gains a second in command. Not necessarily a junior, though often. Someone who can carry the work if the principal is unavailable. Someone who absorbs context now so they are useful later. The pod grows from three to up to six. The structure does not change. The hats do not change. The angles do not change. There are simply up to two people on each angle instead of one, and the pod can survive losing any individual without collapse.
The second in commands also make excellent seeds for future pods through the intense learning and organic mentorship.
VII. CGAI
The pod structure would not have worked a year ago.
Pods dissolve and reform. People wear different hats in different pods on the same day. Nobody sits permanently anywhere. How does the company not descend into chaos? How does the new pod, formed on a Tuesday, learn what the old pod that ended last month actually do?
The answer is CGAI. Company General AI. The connective tissue that lets the rest of the structure work.
CGAI is, at its core, a continuously, automatically updated understanding of two things. The first is internal to the company itself: what every pod is doing, what is shipped, what is blocked, what every operator has decided and why. This is institutional memory, continuously maintained and continuously queryable. The second is the outside world: the customer, the clinics, investors, partners, competitors, and much more. The richer the signal, the better the model. The better the model, the more useful the work the pods produce.
The mechanics matter. CGAI cannot work as a thing people remember to update. It has to work as a thing that updates itself.
Everything public flows in automatically. Slack threads, Notion pages, Jira tickets, Hubspot records, Google Drive documents, GitHub commits, every public artefact the company produces is routed into CGAI without anyone having to think about it. If a pod is working in the open, CGAI is reading along. The activation energy for keeping the model current is zero, because the model harvests from work people are already doing.
Operators push their personal updates. Public artefacts capture most of the company's reasoning, but not all of it. The conversation with a customer that didn't get logged. The half-formed instinct about a competitor. The thing a clinician said in a call that changed someone's mind. Operators are encouraged and expected to push these into CGAI directly. A short note at the end of the day. A voice memo after a meeting.The discipline is light, but it is real, and it is the difference between a model that knows the past, and one that can forecast. Attribution will be transparent, and individuals acknowledged for regularly pushing to CGAI.
Permissions are paramount. Not everyone in the company should see everything. An outbound caller cannot have access to board docs. CGAI enforces these boundaries at the query layer: every operator sees what they are entitled to see, and nothing more. Without rigorous permissions, continuously tested - CGAI is fragile.
CGAI pushes, not just pulls. Querying CGAI is the obvious use case, but it is the smaller half. The larger half is CGAI deciding what each operator needs to know and surfacing it without being asked. A daily update, tailored to the operator's pods and responsibilities. Urgent updates the moment something breaks, a metric tips, a customer escalates, a competitor moves. The information arrives before the operator thinks to look for it. This is the function that, in a traditional company, requires a manager.
Every pod is connected directly to the Central Pod, with nothing in between. There are no regional VPs, no engineering directors, no programme managers, no chiefs of staff translating between the work and the leadership. CGAI is the layer that used to be people. The company of the future has no layers because it does not need them.
If we execute this well internally, CGAI does not stay internal. Every business we serve has the same problem we do. They have scattered, unorganised information. They have people out of the loop. They have institutional memory walking out the door when a team member leaves. What we build internally for ourselves is the prototype of what we eventually offer externally to our customers. Not as a separate product, but as the layer underneath everything CoTreat already does and provides them the simple interface of the future.
Epilogue: Shoulders of Giants
This model is not invented from nothing. Three ancestors deserve naming.
The closest is the Three Amigos practice from agile software development. The Three Amigos puts a developer, a tester, and a business or product representative together at the start of every story, so the work is shaped by all three perspectives before it is built rather than after. The pod model takes this seriously and extends it.
A more distant ancestor is the Spotify guild model, popularised in the early 2010s: squads, tribes, chapters, and guilds. The vocabulary spread widely. The actual practice, less so. Spotify themselves moved away from the model in subsequent years, and most attempts to copy it failed because the imitators copied the org chart without copying the underlying culture of trust, autonomy, and accountability that made the chart functional. The pod model takes the kernel of the squad idea, autonomous, cross-functional, mission-led, and discards the rest. There are no tribes here. No chapters. No guilds. Just pods, each formed around a mission, each ending when the mission ends, each connected by CGAI to the central pod and CEO rather than to a org chart.
The most recent and direct ancestor is of course Block. In late March 2026, Jack Dorsey and Roelof Botha published From Hierarchy to Intelligence, describing how Block is rebuilding itself around the same convictions. They argue, as we do, that there is no need for a permanent middle management layer. They identify, as we have, that the function middle management has performed for two thousand years, since the Roman contubernium of eight soldiers under a decanus, has been information routing, and that AI can now perform this function continuously in ways humans never could. Their "company world model" is what we call CGAI.
The right test of this model is not whether the structure looks elegant on paper. It is whether pods ship, whether they ship faster than they would in any other arrangement, and whether the people inside them are doing the best work of their careers.
MG Candid Learnings up to May 31st 2026
- Much of the pod's missions for May was predicated on a single, high impact assumption. Wildfire would be ready for beta on 1st May. This was always ambitious and high risk. The reality is, we’re more or less ready for open Beta only now - 1st June.
- Singular focus seems important. People that are in multiple pods seem overwhelmed, and conflicted on how to spend their time and mental energy.
- Querying, leveraging CGAI does not come intuitively to most. CGAI will have to optimise for pushing updates and nudges, rather than expecting team members to query. Our Notion MVP is very underused.
- The DRI role is very difficult. Some of the most capable, intelligent people struggle with the DRI mantle. I need to think deeper about who is an IC or DRI.
- Most inexperienced DRIs will have qualitative strategies light on metrics and stepwise targets. Very few think in daily/weekly activities and numbers required to achieve the mission on time.
- I’m unsure if part time team members have enough time, focus and skin in the game to be DRIs, despite their capability, passion and talent.