Verdict: The businesses that compound into real wealth are almost never the most complex ones — they are the most ruthlessly simplified ones. Steve Jobs cut Apple's sprawling product line to a single 2×2 grid in 1997 and the company returned to profit within a fiscal year. Jeff Bezos capped teams at "two pizzas" so communication overhead could not eat execution. Mark Zuckerberg wears the same grey shirt every day because decision budget is finite and he'd rather spend his on the company. The pattern is so consistent among people who get rich that it deserves a name and a doctrine, not a feel-good listicle — and in 2026, when AI makes it trivially easy to bolt ten half-finished features onto every side project, the discipline is more load-bearing than ever.
TL;DR — The Simplicity Doctrine (7 rules)
- Cut to four. Jobs drew a 2×2 grid. Do the same for your offerings.
- Cap teams at two pizzas. Six-to-ten people per goal, or communication eats speed.
- One person, one task. Splitting even a star's focus cuts their quality.
- Build on abstractions, not from scratch. Don't reinvent what a platform already does.
- Do things that don't scale — manually, first. Build the tool after you've done the job by hand.
- Stop adding features once you find PMF. Sell and market what already works.
- Keep systems easy to understand, maintain, and fix. Simplicity is a moat you build on purpose.
Why does simplifying a business make you richer, not poorer?
It works because complexity is the only cost that compounds silently. Every extra product, team member, feature, and tool multiplies the number of communication paths, dependencies, and failure modes — and none of those show up cleanly on a P&L until they've already slowed you down. The math is brutal: a 10-person team has 45 possible communication pairs, a 50-person team has 1,225, and a 100-person team has 4,950. The work does not scale linearly with headcount; the coordination cost does. That is why founders who keep the system small and focused can run laps around better-funded competitors — they spend a far higher share of their energy on the thing that makes money, not on keeping the machine turning over.
The wealthiest operators I have studied turn this into a personal principle, not just a business one. The reason Zuckerberg, Jobs, and Barack Obama each wear a near-identical outfit every day is not branding — it is decision-budget conservation. Every low-stakes choice you automate is one you do not need to spend before the work that actually matters. The same logic applies at the company level: the fewer products, teams, and tools you juggle, the more thinking you have left for the decisions that move revenue.
Where does complexity actually creep in? (Hint: it is people and features)
It rarely enters through a dramatic decision. It accumulates through hiring and well-meant "improvements."
Adding people is the most common stealth complexity tax. One experienced operator describes a pattern that almost every growing team eventually lives through: every time a new person joins a team, the work that one person used to do gets split. Timelines do not shrink — they often grow, because now everyone is waiting on someone else to send the next file. More cooks, more hand-offs, more "I was waiting on her," same output. Small teams are faster for the same reason a single chef is faster than coordinating six cooks in one kitchen: there is nothing to coordinate.
Adding features is the engineering version of the same trap. A product team ships one feature people genuinely use, then — because engineers like to build and nobody knows what else to do with their time — they ship nine more that almost no one wants. This is not a personal failing; it is feature-creep as busywork. The discipline of the operators who avoid it is the same discipline Jobs applied at Apple: draw the grid, refuse to fill a box unless it earns its place, and put the freed-up energy into selling the thing that already works.
What is the two-pizza team rule and does it actually work?
The two-pizza team is Jeff Bezos's rule that no team should be larger than two pizzas can feed — in practice, roughly six to ten people — and that each such team should own exactly one goal. AWS's own executive-insights team still cites it in 2026 as a foundational part of how Amazon organizes for speed: smaller teams "minimize lines of communication and decrease overhead of bureaucracy and decision-making," and a single goal per team keeps accountability from dissolving into committee. The rule's power is not the pizza math; it is the constraint that communication overhead is a dysfunction, not a feature, and that you should organize against it rather than around it.
"We try to create teams that are no larger than can be fed by two pizzas... we call that the two-pizza team rule." — Amazon, as cited by AWS Executive Insights.
Two preconditions matter as much as the size. First, the team must have a clear single objective it owns end-to-end; a two-pizza team with five goals is just a shrunken version of the same dysfunction. Second, it must be able to act without dependencies on other teams for every decision — autonomy is what makes small size yield speed, not size alone. If you have ten people but they all wait on three other teams to approve every change, you have the bureaucracy of a large team with the capacity of a small one.
One team, one goal — and one person, one task
Inside a two-pizza team, the same principle descends to the individual: give one person one thing to own. It sounds expensive because it is — every new task feels like it needs a new hire. But the payoff is twofold. First is accountability: when someone owns exactly one outcome, they cannot deflect blame onto a sibling task. Second, and less obvious, is quality: people given one thing reliably do that thing better than the same person juggling two, because the bottleneck in their head actually frees up. A "magic role" that tries to do everything is the fastest route to burning out your best person — and to everyone quietly knowing it is failing.
Why did Steve Jobs cut Apple's products to four? (And what does that teach a small team?)
When Jobs returned to Apple in 1997 through Apple's acquisition of NeXT, the company was widely reported to be about 90 days from insolvency and was shipping dozens of overlapping products — Performas, Power Macs, PowerBooks, the Newton, printers, servers, even a licensing program that let clones undercut Apple's own margins. According to Walter Isaacson's biography and reporting that followed, Jobs walked into a boardroom, drew a 2×2 grid on a whiteboard — Consumer vs Pro across the top, Desktop vs Portable down the side — and told the room Apple would build exactly one great product for each box and kill everything else. Apple returned to profitability in fiscal 1998.
The lesson is not "have four products." It is that every extra offering splits your attention, your team's attention, and your customers' attention — and customer attention, in particular, is far scarcer than founders believe. Recall how people actually consume your content: they are not studiously taking notes. They are half-watching one thing while fielding a phone call and scrolling another. If they remember one percent of what you put out, that one percent had better be the thing that makes you money. Fewer products, fewer stories, sharper memory in the market.
This matters at any scale, not just at Apple's. A solo founder who is simultaneously building a SaaS, a newsletter, a course, and an agency is distributing attention across four narratives and learning none of them deeply. The same founder who picks the one with real pull and cuts the other three will move faster on the winner than the four-front competitor moves on any of theirs. The playbook for scaling a service business to a real exit is built on exactly this kind of systems-first focus — the founders who actually reach an exit are the ones who refused to juggle.
How do you apply "build on abstractions, not from scratch"?
The most expensive phrase in a small team's vocabulary is from scratch. Carl Sagan joked that "if you wish to make an apple pie from scratch, you must first invent the universe" — meaning true zero-dependency building forces you to reproduce every layer beneath your own. Almost nobody builds from scratch; they cook with premade flour, supermarket butter, and a recipe someone else refined. The same is true in software and business: Photoshop is an abstraction, a pencil is an abstraction, a hosted database is an abstraction. Every layer someone else maintains is a layer your team does not have to.
This is exactly why wrapping — building your product on top of a reliable platform — is a legitimate strategy, not a short-cut to be embarrassed about. A two-person team that builds a thin, well-designed layer over Stripe, OpenAI's API, WhatsApp, or Shopify can ship faster than a ten-person team that insistently reimplements every primitive, precisely because the wrapper's team is not spending its bandwidth holding the underlying stack together. The person building the lower layer is spending that bandwidth, and that is precisely why they usually cannot ship the higher-level product on top of it — and precisely why a focused startup can beat the incumbent who owns the layer beneath them.
The rule for small teams in 2026 is simple: buy or rent anything that is not your differentiated insight. Use Zoho or Notion for project management instead of building one. Use a hosted AI provider instead of training your own model. Spend your scarce engineering budget on the thin layer of the product that is genuinely yours — the same logic behind running Claude Code on an existing free OpenRouter setup rather than standing up your own inference stack. The guide to building a personal AI agent operating system without boiling the ocean is another concrete application: you own the orchestration layer, you do not reinvent the models beneath it.
What does "do things that don't scale" mean, and why does it precede simplification?
Paul Graham's 2013 essay, Do Things That Don't Scale, is the counterweight to premature automation. His argument: startups do not take off by themselves; founders make them take off by recruiting users one at a time, by hand, in the early days. Stripe's founders offered to set up payments for new customers right then and there. Airbnb's founders went door-to-door in New York taking professional photos of hosts' apartments. These are spectacularly unscalable activities, and that is the point: they are the fastest way to learn what people actually want before you build the wrong scalable thing.
This matters for a simplicity doctrine because you cannot simplify what you have not yet understood. Premature automation locks in a workflow you have not validated; it then becomes the complexity you cannot untangle. The proper order is:
- Do the job manually, yourself, for the first few customers.
- Notice which steps are repetitive, which are different each time, and which your customers care about.
- Automate only the repetitive steps, and only after you have done enough of them by hand that you can describe the exact rules.
- Resist the urge to automate the parts that feel like work but are actually where the insight is — the parts where talking to the customer teaches you the next product.
The same logic applies to AI tooling in 2026. Founders want to ship an "AI agent" that scales automatically; the disciplined ones first spend a week doing the underlying task by hand — editing videos by hand, answering support tickets by hand, writing the blog post by hand — so they understand the game before they automate it. Without that, you automate a hallucination of the problem and spend the next two quarters simplifying the mess. It is the same reason AI agent builders set up a productivity workflow step by step before scaling to a fleet, and why the discipline that AI can do the work but cannot do the understanding is the part a human still has to do — manually — before turning it over to automation.
A decision table: simplicity vs complexity, at a glance
| Decision | The simple move | The complexity trap it avoids |
|---|---|---|
| A new product idea fits no box in your grid | Kill it (or put it on a "maybe later" list) | Splitting your team and your customer's attention |
| Team hits ~10 people and slows down | Split into two teams with separate goals, not one of 20 | Communication-pair explosion (45 → 1,225 pairs) |
| A star employee is juggling 3 projects | Give them one, redistribute the others to new hires or to the cutting-room floor | Mediocre output across all three and eventual burnout |
| A vendor already solves a problem well | Use it; do not build your own | Holding a stack together so you never ship your real product |
| You have not yet done the job by hand | Do it manually; do not build a tool yet | Automating a workflow nobody validated |
| A feature shipped and is working | Spend the next quarter selling it, not shipping nine new features | Feature-creep as busywork; few users want the nine |
| A new platform looks cool | Wait; ask "what does this replace, and is the replacement simpler?" | A second toolchain to maintain on top of the first |
What this means for you
If you are a solo founder or small-team builder using AI in 2026, the doctrine maps cleanly onto your week:
- Run a "kill" audit monthly. List every product, sub-product, feature, tool subscription, and recurring meeting. Box each into your 2×2 — or into "kill." Anything that does not fit a box is a complexity tax you are paying every day. Most teams find 30–50% of their surface area does not earn its place.
- Cap the team you actually run, not the one on the org chart. Six-to-ten people per goal is the ceiling, not the target. If one goal has fifteen people on it, split it into two one-goal teams or accept the slowness.
- Write down each person's one thing. If you cannot name the single outcome each person owns, accountability is already diffusing. The act of writing it down is often the first time the split is visible to you.
- Pick your abstractions deliberately. Your tool stack is your abstraction stack. Every vendor you keep is a layer you do not maintain; every one you remove is a layer you now must. Audit it like a portfolio, not a closet.
- Refuse to build the tool until you've done the job by hand. This is the cheapest single discipline in the doctrine: do the thing once or twice first, then ask whether the tool you'd build solves what you just experienced — not what you imagine.
FAQ
Q: What does "simplifying your business" actually mean in practice? A: It means deliberately reducing the number of products, teams, goals, tools, and recurring decisions your business depends on, so that more of your energy goes into the few things that make money. In practice it usually looks like a monthly kill list, capped team sizes, one-task-per-person assignments, and a deliberately short tool stack — not a generic life-hack.
Q: How big is a "two-pizza team" supposed to be? A: Jeff Bezos's rule is that a team should be no larger than two pizzas can feed — commonly interpreted as six to ten people. AWS itself still cites the rule in 2026 and stresses two preconditions beyond size: each team must own a single clear objective, and each must be able to act without dependencies on other teams for everyday decisions.
Q: Did Steve Jobs really cut Apple's products from 70 to 4? A: Reporting varies on the exact number — some sources say "dozens of products," others cite "40-plus" or "up to 350 configurations" — but the verified kernel is consistent: when Jobs returned in 1997, Apple had a bloated, overlapping lineup; he drew a 2×2 grid (consumer/pro × desktop/portable), kept exactly one product per box, killed the rest (including the Newton and the clone-licensing program), and Apple returned to profitability in fiscal 1998.
Q: Why do successful founders wear the same outfit every day? A: Decision-budget conservation. The consensus from coverage of Zuckerberg's grey shirts, Obama's blue/grey suits, and Jobs's black turtlenecks is that automating low-stakes recurring choices (like clothing) leaves more mental bandwidth for the decisions that move the business. It is a personal-application of the same principle behind cutting products: anything you do not consciously choose does not tax you.
Q: What does "do things that don't scale" mean for a small business in 2026? A: It means doing the core job manually for the first few customers before you build any automation — recruiting users one by one (as Paul Graham's 2013 essay puts it), answering support by hand, editing the first videos by hand, writing the first blog posts by hand. The point is not the manual labour; it is that the manual phase is the fastest way to learn what is actually worth automating, so you do not build automation for a workflow nobody has validated.
Q: Isn't building on top of other people's platforms risky? A: It carries some platform-dependency risk, but the alternative — rebuilding every layer yourself — is almost always worse for a small team, because it traps your scarce bandwidth holding the lower stack together instead of shipping the product on top of it. The disciplined version is to use abstractions for everything that is not your differentiated insight, and invest your own engineering only in the thin layer that genuinely is.
Discussion
0 comments