M11 — 3 Delegate Case Snapshots
Three real delegation patterns. One human team that emerged from a resignation rather than an org-chart — the realistic operational shape of a 6-person operation. One AI-as-junior-team workflow you can verify in real time, because the page you are reading was produced by it. One delegation to a system rather than to a person — the third dimension most founders miss until the bottleneck is their own memory.
Case A — Bausele’s team structure (April 2026, after Jack’s resignation)
The realistic 6-person operation — specialists per workstream, not a generalist team, formed by reacting to a departure rather than designing a clean org-chart.
The state, April 2026. Bausele’s operational team as of April 2026 is six people: Christo (founder), Kelvin (digital lead), Steven (Meta), Damien (content), Emily (operations), Amanda (intern — do not brief). Christo runs the company. Kelvin is the digital lead, owning direction and Klaviyo. Steven owns Meta paid acquisition. Damien owns content production. Emily owns operations. Amanda is an intern — explicitly do-not-brief, which is part of the discipline. Five people are specialist owners of one workstream each; one (Christo) holds the founder-irreplaceable list and the cross-workstream judgement. There is no generalist on the team.
How this structure was actually built. Not by an org-chart exercise. Jack was the previous digital lead and resigned early in March 2026. The temptation in that moment is the one most founders fall into: re-hire like-for-like, find another Jack, fill the gap, move on. The decision that actually got made was different. Christo redistributed the work — Kelvin stepped up into the digital lead seat, Steven was given Meta as a defined specialist workstream rather than as one part of Jack’s broader remit, Damien was given content as its own specialist line, Emily’s operations role was firmed up. The team that emerged was structurally cleaner than the team that existed before the resignation — fewer overlapping responsibilities, clearer single-owner accountability per workstream, and the new digital lead (Kelvin) already inside the business and trusted, rather than an outside hire that needed 6 months of context-loading before producing.
Why this is the M11 case for “first human hire” thinking. The textbook first-hire conversation imagines a founder building from zero, deciding deliberately what to hire first. The real first-hire conversation, for most founder-led businesses, is the second-hire conversation triggered by someone leaving. The Bausele case shows what M11 discipline looks like when the team is reshaped under pressure rather than designed at leisure. Three things to notice. First, every named role is a specialist workstream (digital lead, Meta, content, operations, support) — none of them is “a generalist to help me out”. Second, the intern (Amanda) is explicitly outside the briefing flow — interns hired without a defined owner consume founder time rather than save it, and naming that boundary in the team’s own memory is the operational discipline that protects it. Third, the founder is still the founder — not the digital strategist, not the content director, not the ops manager. The handoffs went to the specialists who were already doing the work; the founder’s job became the irreplaceable list (capital, key relationships, brand voice, strategic decisions).
Why hiring a generalist would have been the wrong move. When Jack left, the easy move was “hire another Jack” — one person who does a bit of everything across digital, paid, content and ops. That hire is faster to recruit, cheaper to pay, and produces less than half the output of four specialists because (1) the cognitive cost of switching between workstreams is real and brutal, (2) each workstream has accumulating expertise that compounds when owned by a specialist and stays flat when owned by a generalist, and (3) the founder cannot delegate quality oversight when the same person is doing four different things — the founder ends up shadow-reviewing all four workstreams, which is exactly the bottleneck the hire was supposed to solve. The specialist redistribution avoids all three.
The lesson: The realistic first-hire plan for most founders is the third-hire plan written in advance — by the time the second person leaves, you want a structural understanding of who replaces them and how the workstreams resettle. Most founders don’t have that understanding because they never wrote the SOPs that would let a specialist step in cleanly. The handoff from Jack to Kelvin was easier than it could have been because the digital workstream was substantially documented; the team additions of Steven, Damien and Emily into clean workstream ownership were possible because the work could be described in single-workstream terms rather than as “everything Jack used to do”. M11 builds the conditions for this kind of resettlement before it has to happen under pressure.
Case B — The EXITR Toolkit module-push pattern (live, May 2026 — and yes, this page is the proof)
An AI-as-junior-team workflow shipping production output right now — verifiable by the reader of this exact page.
The pattern, mechanically. Across May 2026, EXITR’s Toolkit modules M2 through M10 were shipped to live Shopify pages using a repeatable AI-as-junior-team workflow. The mechanics: Christo briefs Sasha (the EXITR agent inside Claude Code) with the module number, the locked framework, the content angle, the cases to pull from, and the hard rules. Sasha drafts the module inline — hero, tagline, what-you’ll-do, 10-prompt pack, self-check, 6-page worksheet, 3 cases — all to the locked M2-M10 structural parity. Christo reviews. Christo says push, edit, or scrap. On push, Sasha executes 4 Shopify ops (module page + worksheet companion + cases companion + memory update). The next module starts the same evening or the next morning. Ten modules shipped in a single session through this loop.
Why this is a real AI-as-junior-team workflow and not a marketing prop. The page you are reading right now was produced by the workflow being described. The 10-prompt pack above was written by Sasha, against a brief from Christo, against a locked template established across the previous nine modules. Christo will read this draft, mark up the parts that don’t sound like him, mark the parts that overstate or under-specify, and either ship it as-is, send it back for one edit pass, or scrap it. If you are reading this on exitr.net/pages/toolkit-m11, the version live in front of you went through that loop. This is the unique strength of using an AI workflow for content: the customer can verify the system is real by inspecting the artefact the system produced.
The structural elements that made this workflow work. Five. First, a locked template — the M2-M10 structural parity is rigid enough that Sasha knows exactly what shape the output has to take without re-deciding it per module. Locked structure is the SOP. Second, a voice rubric — Christo’s voice rules are documented enough (Australian spelling, short sentences, founder-to-founder tone, no corporate fluff, no guru language, verified-fact discipline, real numbers cited with context) that Sasha can draft against them and Christo edits rather than rewrites. The voice rubric was built across M2-M10 and stabilised by M5 or M6 — the early modules required heavier editing, the later ones less so, exactly as a junior team would learn the founder’s voice across the same arc. Third, cases pulled from verified founder material — not invented stories. Every case in every module is sourced from real Bausele or EXITR project memory, which makes the founder’s editing pass focus on accuracy rather than rewriting from scratch. Fourth, a binary review — push, edit, or scrap. Three options, fast decision, no committee. Fifth, the founder ships the work after review — Sasha is the junior team, not the brand voice; Christo’s name is on the page and the founder takes responsibility for what goes live.
What this case is for a Toolkit reader. It is the answer to the most common reason founders give for not using AI to draft content: “AI can’t capture my voice / my judgement / my brand.” The honest version of that objection is usually “I haven’t written down my voice / my judgement / my brand clearly enough for anything — AI or human — to produce against it.” The M11 discipline is the writing-it-down work. Once the voice rubric and the locked template exist, AI delegation works. Before they exist, neither AI nor a human writer can produce work that meets the founder’s bar — which is why hiring a writer first usually fails. The sequence that works: write the rubric, ship the AI workflow against it, audit at 30 days, hire a human only if the AI workflow has revealed a quality ceiling the human can clear.
The lesson: “I’ll hire a content writer” is the wrong first move for most founders at the stage M11 reaches them. The right first move is to write the rubric (M6 work), build the AI workflow that drafts against the rubric (M11 prompts 5-7), audit it at 30 days, and only then decide whether the next hire is a writer (because the AI hit a ceiling) or an editor (because the AI is doing the drafting well enough that the founder just needs a second set of eyes on quality and consistency). The page you are reading is one data point in favour of the second path.
Case C — Notion CRM as the system that holds bespoke pipeline state
Delegation to a system, not to a person — the third dimension most founders miss until the bottleneck is their own memory.
The rule, exact wording. “On every bespoke activity (new contact, meeting, call, email, stage change), update Notion immediately. Don’t ask permission. Local files = backup only.” The rule is short by design — short enough to remember mid-call, mid-email, mid-Zoom. It assigns a single source of truth, gives the founder explicit permission to update the system without checking in (because checking in re-creates the founder-in-the-middle bottleneck the system is supposed to remove), and demotes everything else (local files, notebooks, scattered Slack messages) to backup status.
The bottleneck this system was built to remove. Bausele’s bespoke pipeline as of mid-2026 includes major institutional opportunities — the Army 125th Anniversary watch (400+ EOI replies, revenue potential $120-200K), the RAE 125th Anniversary watch (Royal Australian Engineers, $100-300K potential), 4 RAR, Brisbane Boys College 125-unit confirmed, DFAT discussions active, the Bausele Voyage cruise channel proposal — across a combined 2027 institutional pipeline of 320-700 units and $320-700K revenue potential. A pipeline that size, mid-conversation across multiple stakeholders, with stage changes happening across calls and emails and chance meetings, cannot live in the founder’s head without one of three failure modes triggering: (a) the founder forgets a follow-up commitment to a major contact and the deal stalls; (b) the founder has to spend 30-60 minutes reconstructing pipeline state every time the question “where are we with X” comes up; (c) the founder cannot delegate any pipeline work to the team because the state of every deal is locked inside the founder’s recall. The Notion CRM removes all three failure modes at once.
Why this is a delegation case, not a tooling case. The instinct is to call this a CRM implementation, a tool adoption, a software story. It is, structurally, a delegation — the founder is delegating the work of remembering pipeline state to a system rather than to a human assistant or an AI. Three reasons this is the right delegation choice for this specific task. First, the work is not judgement-heavy at the storage layer — it is memory-heavy. The decision of “what does this lead need next” requires founder judgement; the recall of “what stage is this lead in and what was the last thing we said to them” requires reliable storage, which a system does better and cheaper than any person. Second, the work has a state-shape — a pipeline has named stages, named contacts, named next-actions — which means a structured database fits it naturally where a human assistant would have to be told the structure every time. Third, the work has compound failure cost — a 10% recall rate failure across 50 active conversations means 5 deals quietly drift, and those failures don’t surface until weeks later when the founder realises they haven’t heard back. A system that holds state with 100% reliability removes the compound failure entirely.
What the discipline actually requires from the founder. Two non-obvious things. First, the founder has to update Notion immediately, not “later when I have time” — because “later” is the failure mode the system was built to prevent, and a CRM updated weekly is a CRM that is wrong six days out of seven. Second, the founder has to grant themselves explicit permission to update without checking — the “don’t ask permission” line in the rule is the structural permission slip that prevents the founder from inserting themselves back into the middle. Most founders who adopt a CRM and then quietly stop using it within 60 days fail on one of these two — they batch updates instead of updating immediately, or they keep emailing the team to “remind me to add this to Notion” instead of just adding it themselves. The Bausele rule explicitly closes both failure modes.
The lesson: Not every bottleneck on the founder’s calendar is solved by hiring a person or shipping an AI workflow. Some bottlenecks are pure state-management problems disguised as “I need an assistant” — the founder thinks they need someone to track deals, when what they actually need is a database that holds deals reliably so the founder can stop tracking them in their head. The M11 discipline of categorising the queue (prompt 2) into AI / human / system / outsource is precisely the work of catching these. The cost of a Notion CRM is essentially zero; the cost of mis-diagnosing this as “I need to hire a CRM admin” is months of founder time and a hire who doesn’t solve the actual problem. The right first question for any task on the queue is not “who does this” — it is “does this need a person at all, or does it need a system that holds the state”.