Cases from the MBA and the Vanguard · MBA module — when a small practice's quality still runs through the founder's desk
Subtitle: How can a small design practice grow when its quality still depends on the founder's personal judgment?
I have run my architecture practice for thirteen years. It is a small office, and that has always been part of its strength. Clients know who is responsible. Decisions can be made quickly. I know the history behind every important drawing, every conversation with a consultant, and every promise made to an investor.
It is also becoming a constraint.
One of our major assignments is an educational building of approximately 7,500 square metres. The project requires architectural design, detailed documentation, and coordination with structural engineers, building-services designers, fire-safety specialists and other consultants. A decision made in one discipline can affect several others. An opening moved on one drawing may require changes to a structural plan, an installation route, a section, a schedule and a cost estimate.
My colleague is an excellent designer: precise, reliable and committed to the quality of the work. We also work with students and external collaborators when the workload requires it. Yet many questions still come back to me. I coordinate the disciplines, communicate with the investor, resolve conflicting information and make the final judgment when drawings do not agree. I review documents because I am responsible for what leaves the office, and because experience tells me where an apparently small inconsistency can become a serious problem on site.
This arrangement works while I can keep the whole project in my head. On a large project, that is increasingly difficult. Every interruption takes me away from another decision. Checking routine coordination work consumes time I could spend on design, clients and the future of the practice. At the same time, skipping a check simply because I am tired or busy would be a poor way to increase capacity.
The next question is what kind of office I should build after this project. I would like colleagues to take greater ownership of production and coordination while I focus more on direction, review and relationships with clients and consultants. But hiring increases fixed costs before it increases dependable revenue. Training someone takes time, and giving a person responsibility on paper does not immediately give them the context needed to exercise it well. I cannot assume that a large project will always be followed by another one of the same scale.
I can see three possible paths. I could keep the office small and remain highly involved in almost every important decision. That protects the working method I know, but keeps capacity tied to my own time and energy. I could employ more people and define clearer decision rights, accepting the financial and management risk in exchange for a practice that can handle more work without routing everything through me. Or I could keep a small core team, use external specialists where needed, and improve our processes and tools before committing to permanent growth.
None of these options removes the central problem: which decisions must remain mine, and which decisions am I holding onto because I have never built a reliable way to share them?
There is a human side to this question. A colleague cannot become more independent if I take every difficult decision back. Yet it would be unfair to hand over responsibility without clear authority, enough information and a way to ask for help. Consultants also have different ways of working and different levels of availability. Coordination depends on relationships as much as on a task list. I need a system that makes expectations clear while leaving room for professional judgment and respectful communication.
I do not want to measure success only by the number of employees or the size of the next contract. I want an office that can produce dependable work, earn enough to sustain its people, and function without every uncertainty waiting on my desk. I have not yet decided what combination of people, authority and processes will achieve that.
I would begin by asking the table to separate professional accountability from personally making every decision. I would first invite someone who has grown a professional-services firm to explain which decisions they delegated earliest. Then I would ask someone who chose to remain small what risks that choice avoided and what it cost. Evidence that would change the discussion includes the reliability of future work, the office’s financial margin, and whether colleagues can resolve defined categories of problems without repeated intervention from the founder.
AI could help compare drawing revisions, flag inconsistent dimensions or quantities, organize comments from consultants, and trace which documents may be affected by a change. Used well, it could give the team more time for decisions that require architectural and human judgment. But a clean automated report would not prove that a design is correct: the same mistaken assumption can appear consistently across several documents.
If an AI system becomes part of the workflow, I would need to define what it may check, what evidence it must show, and when it must stop and alert a person. Someone must still own the decision, particularly where safety, regulations, cost or a promise to the client is involved. The leadership question then becomes broader: how do I give both people and AI useful authority without allowing responsibility to become unclear?
A practice can share decisions only when its people know what they may decide, what they must verify, and when they must ask for help.
A live case: every round can be improved, and the author's feedback is the next one.
The same two questions, answered twice: first without the mentor's corpus, then from it — his decision doctrine, the Command Layer, the four kinds of leverage, the orchestration test, VIS and the agent charter.
Without the mentor's corpus
1. The founder should keep the decisions only he can answer for, and hand over the ones the office has already solved once, with the rules written down. Construction learned this long ago. In The Checklist Manifesto (2009), Atul Gawande calls one chapter "The End of the Master Builder". Buildings became too complex for one person to master, so the industry replaced him with specialists held together by two lists: a schedule of the work, and a submittal schedule that says who must talk to whom, about what and by when. David Maister gives professional firms the sorting rule: "brains" work is new or extremely complex and needs the most senior person; "grey hair" work has been seen before; "procedure" work can be systematised. In this office:
The colleague needs the intent on one page, the limits that send a change back, and direct access to the consultants. In return, the founder overrules openly, with a reason, and never quietly takes a decision back. Ask yourself: how many of the questions on my desk this month had I already answered once?
2. Develop the team's decision authority first, use the network for peaks, and hire last. The order follows reversibility. In his 2015 letter to shareholders, Jeff Bezos separated one-way doors, nearly irreversible decisions that deserve slow deliberation, from two-way doors, reversible decisions that "can and should be made quickly by high judgment individuals or small groups". Widening a colleague's authority or bringing in a specialist for one project is a two-way door; a permanent hire is close to a one-way door. Uncertainty argues for delegation, not against it. Philippe Aghion, Nicholas Bloom and colleagues found that firms which had given local managers more power before the Great Recession outperformed centralised rivals in the sectors hit hardest, because local knowledge is worth more in turbulent times. The market gives no reason to hurry either: in the Architects' Council of Europe's 2024 sector study of 28,000 architects, 37% expected less work in the coming year and 19% more. Three signals would change the choice:
Ask yourself: if someone new joined on Monday, whose desk would their questions land on?
Sources: A. Gawande, The Checklist Manifesto, 2009, chapter "The End of the Master Builder"; D. Maister, Managing the Professional Service Firm, 1993 (brains, grey hair and procedure work); J. Bezos, 2015 Letter to Shareholders, Amazon (one-way and two-way doors); P. Aghion, N. Bloom, B. Lucking, R. Sadun and J. Van Reenen, "Turbulence, Firm Decentralization, and Growth in Bad Times", American Economic Journal: Applied Economics 13(1), 2021; Architects' Council of Europe, The Architectural Profession in Europe, 2024 Sector Study.
From the mentor's corpus
1. Keep the intent, the limits and a short written list of decisions that always come back; everything inside the limits belongs to the colleague. The mentor's decision doctrine starts from an axiom: a system that depends on one permanently trustworthy guardian is badly designed. This office's quality rests on one guardian, and the project has outgrown what one head can hold. The doctrine's sixth rule gives the sorting line. Decision confidence and engineering safety are different: roughly 80% confidence can be enough for a reversible decision, while critical infrastructure advances through tests and progressively wider deployment for as long as the evidence requires. So:
The mentor's Command Layer chapter says who answers for what. The subordinate answers for the action; the commander answers for the intent, the boundary conditions and the authorisation, and both are on the record. The VIS framework writes the rest down for every role: what it may decide without escalation, and the triggers that send a decision back. Ask yourself: which decisions come back to me only because I never wrote down the ones that must?
2. Not one of the three paths but an order: authority first, the network next, a hire last. The mentor's decision doctrine calls this frame before choice: do not accept an A/B/C menu until it is tested, and if every option is bad, change the sequence. The author has already tested this menu: none of the three removes the central problem. A passage written for his second volume gives the sequence. Four kinds of leverage exist in every era, and their order matters: information, systems, people, and capital last. A leader short of resources, it says, is not short of money but of the three prior kinds of leverage that would make money rational to invest. Here:
The Command Layer adds the human side: trust cannot be declared; it is built through shared context, after-action review and consistent backing of people who acted within intent and took losses doing so. The evidence for the last step is the test in the mentor's first volume: count honestly how many people can make good decisions on your intent without needing approval. Ask yourself: how many people could take a good decision on this building tomorrow without calling me?
On the NEO Turn. The mentor's decision doctrine gives people and machines the same limits: scope, time, evidence, independent review and revocation, with several imperfect checks preferred to one perfect guardian. His task-to-agent protocol puts it on one page: a charter that works like a commander's intent, with a mission, constraints, a human checkpoint and a kill indicator. The case already names the checkpoint: anything touching safety, regulations, cost or a promise to the client stops at a named person. Under the VIS provenance rule, every flag points to its sheet, revision and conflicting values. The protocol also names the author's worry, automation bias: accepting machine output uncritically when oversight is absent. So the design assumptions, from occupancy to the fire strategy, are tested by a person against their source, not against other drawings. The tool can show that the documents agree; only a named person can answer for whether they are right.
Sources: the mentor's decision doctrine of 22 August 2026 (the single guardian; AI is not a trusted root; frame before choice; decision confidence and engineering safety); Vanguard Leadership, vol. 2, the Command Layer (accountability under delegation; trust) and the passage on the four kinds of leverage written for its fortitude chapter; Vanguard Leadership, vol. 1, §2.4 (the orchestration test); the VIS framework (edge decision rights and escalation triggers; the provenance rule); the Vanguard Task-to-Agent Mapping Protocol (automation bias; the Agent Charter).
The case's central question asks which decisions must remain the founder's, and which he holds only because he never built a way to share them. It is the paradox the mentor puts near the start of his first volume. The capabilities that make a successful founder often prevent a successful operator. A company of ten can succeed through the founder's personal capability; beyond that, the founder's capability becomes the bottleneck, not the advantage. Intuition does not systematise; you cannot teach "just know". And a firm rescued again and again by the founder's personal heroics becomes dependent on them.
Founder mode, read correctly. The mentor does not answer this by telling the founder to let go. His essay on founder mode, written after Brian Chesky's talk at a Y Combinator event in 2024, reads it as a hybrid of founder and manager, not a choice between them. Paul Graham's essay, which gave the idea its name, records what went wrong first. As Airbnb grew, Chesky was advised to "hire good people and give them room to do their jobs"; he followed the advice, and the results were disastrous. What worked was staying in the details that matter. Graham's model of the right attention is Steve Jobs's annual retreat for what Jobs considered the 100 most important people at Apple, and these were not the 100 highest on the org chart.
For a practice of this size, that means three things.
The test after this project. The mentor's first volume states the goal: a founder who can operate, and an operator who can found. The measure is whether the next large project can start without every coordination question landing on the founder's desk. If defined categories of questions keep coming back after a quarter, the trap list is incomplete, not the colleague. Ask yourself: which of my interventions this month were founder mode, and which were only habit?
Sources: Vanguard Leadership, vol. 1, §1.3 "The Founder/Operator Gap"; the mentor's essay "Founder Mode: Navigating VUCA-on-Steroids in the AI Era"; P. Graham, "Founder Mode", September 2024.
Stay small: keep a small core team with external collaborators, and automate the work with AI as far as possible, as in the case of 4uha, where we introduced an AI office with EDIH funding.
Which decisions stay with the founder? As many as possible.
What first? AI automation and a network of collaborators. That avoids permanent fixed costs, because the practice hires per project, when there is money. It is better to pay more occasionally than to carry a fixed cost permanently.
A question for the table, a disagreement, what you would have done. The case lead reads every comment; the ones the table takes up enter the chapter as questions from the room, with your name.