DEV Community: Stoic Lead

What Stoic Philosophers Teach Us About Building a Startup (That Business School Doesn't)

Stoic Lead — Thu, 28 May 2026 15:01:46 +0000

The Meeting-Free Week Playbook: How Scaling Founders Actually Get Work Done

Stoic Lead — Wed, 27 May 2026 17:25:41 +0000

You spend 40 hours in meetings and 8 hours doing actual work. This is not a time management problem. It's a system design problem.

Most scaling founders accept this as inevitable. "You can't run a 50-person company without a ton of meetings." This sounds wise. It's actually an abdication. You're not running a company — you're drowning in an operational system that wasn't designed with your attention in mind.

The meeting-free week is not a hack. It's a structural reset that forces you to redesign your entire communication system. And when you do it right, you don't go back.

The Problem Isn't Meetings. It's Your Operating System.

Here's the pattern I see in every growing company: as you add people, meetings multiply to fill the gaps in clarity. Why? Because the alternative — actually building systems that communicate asynchronously — requires discipline upfront.

It's easier to add a standup. Easier to add a "quick sync" than to write documentation. Easier to throw a problem into a meeting room than to articulate it clearly enough for someone to solve it on their own.

Meetings are what happens when you haven't done the harder work of designing communication. They're the debt you pay for not building clear processes.

But here's the thing: you can't eliminate meetings entirely. You don't want to. Some conversations need real-time interaction. What you need to eliminate is the false assumption that real-time is the default.

In a well-designed company, real-time is the exception. You use it for decisions that actually require it — complex conversations, urgent problems, team culture moments. Everything else? Asynchronous. Written. Clarified.

What The Meeting-Free Week Actually Teaches You

The meeting-free week works like this: You declare one week where no meetings are allowed. None. Not standup, not syncs, not 1-1s. Complete radio silence on the calendar.

The panic starts immediately. "How will we communicate? What if someone needs to talk to me? How do we make decisions?"

This panic is useful. It reveals the dependency. And here's what you learn:

1. Most of your meetings aren't actually about decisions.

They're about status updates. "Here's what I'm working on." "Here's what my team shipped." "Here's the quarterly plan." None of this requires the people in the room simultaneously awake at the same time. You could email it, post it, Slack it, write it up. The fact that you're doing it in a meeting is just inertia.

2. Without meetings, people over-communicate in writing.

When you remove real-time as the default, people start writing things down. Clear briefs. Context. The work actually becomes legible. You can skim it. You can come back to it. You have a record. This alone is worth the experiment.

3. The decisions that actually need discussion become obvious.

After a week of no meetings, you'll have three real decisions that require conversation. Maybe four. Everything else sorted itself. People solved their own problems. Decisions got made in writing. One hour of thoughtful discussion replaces five hours of "alignment meetings" that weren't actually about alignment.

4. You'll protect the deep work hours you forgot you needed.

A founder without meetings is a founder who can actually think. You can hold a complex problem in your head. You can review code. You can write strategy. You can close deals. You can do the actual work your company hired you to do. This alone makes your company better.

Running a Meeting-Free Week (The Rules That Matter)

If you're going to try this, do it right. Half measures won't work.

Rule 1: Set clear expectations beforehand. Tell your team in advance: "Next week is meeting-free. No meetings. We're going to communicate entirely asynchronously. If something is genuinely urgent and requires a decision, send me a brief (3 paragraphs max) and I'll respond within 2 hours."

This prevents panic. People know the deal. They plan accordingly.

Rule 2: No exceptions for "quick syncs." This is where people cheat. "It's just a 15-minute standup." Nope. If you allow one exception, you've broken the experiment. The whole point is to feel the absence of the system and understand what it's actually doing for you.

Rule 3: Switch to written updates. Before the week starts, create a simple format for async updates. Here's what works:

Daily status update (3 bullets): What you shipped, what's blocking, what you're working on next
Weekly summary (2 paragraphs): Key decisions, major blocks, progress toward quarterly goals
Urgent decisions (briefs only): If something genuinely needs a decision, write a 2-3 paragraph brief with the problem, options, and recommendation

Rule 4: Set response time expectations. No all-hands decision-making. You respond to briefs within 2 hours during working hours. Async decisions get documented in one place. Everyone can read context and see what you're thinking.

Rule 5: Plan to feel weird for 2-3 days. The first few days of a meeting-free week feel strange. You'll be tempted to "just do a quick sync." Don't. You're detoxing from a meeting addiction. Sit with the discomfort. By day 4, you'll realize you got more done than you do in a normal week.

What Happens After: The Real Playbook

The meeting-free week is not permanent. It's a forcing function that teaches you something about how your company actually operates. The lesson is the thing.

After the week, you do three things:

1. Kill the meetings that weren't real

Status update meetings gone. Standups converted to daily async updates. Optional weekly all-hands replaced with a written summary. You've just reclaimed 10-15 hours a week.

2. Design the meetings that stay

The meetings that survive the week are real. They do something only real-time can do. A product strategy discussion with your leadership team. A difficult conversation with someone about performance. A brainstorm that actually needs spontaneous thinking. These are worth the time. Schedule them. Make them count.

3. Build the async systems

This is the real work. You need:

A decision log: Major decisions, who made them, reasoning, when they were made. Searchable. Anyone can look back.
A weekly cadence: Exec team briefs, OKRs, metrics, known blocks — all written, all posted on Monday or Tuesday
Clear escalation rules: What decisions can an IC make? What needs a manager? What needs the founder? Written down. Known.
Documentation standards: Big decisions, architectural choices, process changes — all documented. Not "will document later." At decision time.

Why Most Companies Don't Do This (And Why You Should Anyway)

The reason most companies don't implement async-first operations is that it requires discipline at the top. The founder has to stick to it. The leadership team has to write things down instead of having a quick chat. You have to tolerate slightly slower decisions in exchange for massively clearer thinking.

This is exactly where most companies fail. They try the meeting-free week, see positive results, then slowly backslide into "let's just have a quick sync" and within two months they're back to 40-hour-a-week meeting schedules.

The companies that break this pattern and stay async-first are the ones where leadership genuinely changes their behavior. The CEO blocks 25 hours a week as deep work, inviolable. The ops person maintains a strict decision log. The leadership team writes weekly briefs, not chats about them.

And they get founders back. Founders who actually build. Who think. Who make good decisions. Who have the mental space to notice when something isn't working and fix it before it becomes catastrophic.

Your Stoic Connection

This is where Stoicism connects to operational efficiency. The Stoic principle is: distinguish what you control from what you don't, and focus relentlessly on the first category.

Most founders act like their calendar is not in their control. "Too many people want my time." False. Your calendar is completely in your control. Other people's expectations about your availability are not. But your calendar is yours.

A meeting-free week forces you to reclaim that. And once you do, you realize you were delegating your own decision-making power to the calendar. You were letting the system run you instead of running the system.

Design your operating system first. Then fill it with people. Not the other way around.

Try It This Week

Pick a week in the next month. Schedule zero meetings. Tell your team why. See what actually needs a meeting and what doesn't. When you come back, you'll have rebuilt your calendar the way you actually want it.

Most founders run their companies like they're passengers. They think their schedule is something that happens to them. This is the one week you remember that you designed it. And that you can redesign it.

Originally published on StoicLead. Want to work async-first? Take the StoicLead Assessment — 3-minute diagnostic for founders ready to reclaim their time.

The First-Time Founder's Guide to Delegation (Without Losing Control)

Stoic Lead — Wed, 20 May 2026 04:40:38 +0000

There is a specific kind of pain that hits founders somewhere between five and fifteen people. You hired well. Your team is capable. And yet you can't stop checking their work, re-writing their emails, redoing their code, or quietly redoing the decisions you delegated out last week.

You know delegation is supposed to happen. You've read the articles. You even gave someone ownership of a project. But "ownership" in practice means you gave them the task and kept the anxiety — which is not delegation. It's outsourced execution with retained suffering.

The problem is almost never the team. The problem is that nobody taught founders how to actually let go.

This article is that guide. It covers what's really happening when founders can't delegate, the framework for doing it without losing quality or culture, and the Stoic principle that makes it actually stick.

Why Founders Can't Let Go (And It's Not What You Think)

The standard explanation is ego: founders are control freaks who think no one can do it as well as they can. That's sometimes true. But it's a lazy diagnosis that skips the real mechanism.

The actual reason is that the work that built the company was the founder's domain of mastery. You were the best salesperson, or the best engineer, or the best at writing copy that converts. That mastery was the foundation of the business. Delegating it doesn't just mean giving someone a task — it means stepping back from the thing you're most confident in, and trusting someone who is by definition less experienced in your specific context.

That's genuinely hard. It's not vanity. It's rational concern about a real risk.

The second reason is less obvious: most founders haven't made the identity transition from maker to leader. The maker produces output. The leader produces conditions for others to produce output. These are completely different value creation modes, and the transition requires deliberately devaluing what made you successful — your ability to do the thing well — in favor of a new skill: your ability to enable others to do the thing well.

Until a founder makes that identity transition explicitly, delegation fails not because of execution problems but because of a values conflict at the level of identity. Every time you take the task back, you're not failing at delegation — you're expressing who you still believe yourself to be.

"The impediment to action advances action. What stands in the way becomes the way." — Marcus Aurelius

The Maker-to-Leader Transition: What It Actually Requires

This transition is not a one-time decision. It's a slow, uncomfortable reorientation of what "good work" means for you personally.

In the maker phase, good work means: I built a thing, the thing is excellent, I can point to it. The feedback loop is tight and personal. Your fingerprints are on the output.

In the leader phase, good work means: my team built a thing, the thing is excellent, and I can't personally identify where I contributed — and that's the success. The feedback loop is long and indirect. Your fingerprints are on the conditions, not the output.

Most first-time founders find this deeply unsatisfying for at least six to twelve months. They're used to the maker's direct feedback loop, and leadership feels like operating in fog. This is normal. It doesn't mean you're bad at leading — it means you're in the transition.

Three things accelerate the transition:

Naming it explicitly. Tell yourself and your team: "I'm moving from maker to leader. I'll make mistakes. I may take tasks back when I shouldn't. Hold me accountable." Making the transition visible reduces the pull of the old identity.

Defining your new success metrics. What does good leadership look like for you, measured weekly? Not output metrics — input metrics. Did I have the hard conversation I avoided last week? Did I delegate something uncomfortable? Did I create a decision-making system instead of making the decision myself?

Building a practice, not a goal. "Become a better delegator" is not a practice. "Every Monday morning, identify one decision I can delegate entirely this week — and then don't look at it until Friday" is a practice.

The Startup Delegation Framework: Four Levels

Not all tasks should be delegated the same way. One of the biggest mistakes founders make is treating delegation as binary — either you do it, or someone else does it. The reality is that delegation exists on a spectrum based on the stakes and the delegate's track record.

Here's a simple framework with four levels:

Level 1: Do it and tell me (high stakes, new delegate)

The person does the work and reports back after. You're in the loop but not in the way. Use this for new hires or new responsibilities where the stakes of failure are meaningful. The goal is to build your confidence in their judgment through a track record — not to audit every decision.

Level 2: Do it and tell me if there's a problem (medium stakes, established trust)

The person has full ownership. They surface only exceptions. This is the first true delegation level — the person makes the call without checking in. Most routine operational decisions belong here once trust is established.

Level 3: Do it — I don't need to know (low stakes, high trust)

Full autonomy. The founder finds out in a quarterly review or not at all. Marketing copy, vendor negotiations under a threshold, team scheduling, process improvements — these should live here for any experienced hire.

Level 4: Your domain, not mine (strategic ownership)

The person owns not just execution but strategy in a domain. You hired a Head of Engineering — engineering strategy is now theirs. You hired a VP of Sales — pipeline architecture is now theirs. You give input as a peer, not approval as a manager. Most founders never get here with their first leadership hires because they can't give up the strategic layer. This is where the identity transition matters most.

The key discipline: when you delegate, specify the level explicitly. "I want Level 2 delegation on this — handle it, but flag me if revenue impact exceeds $10K" is a delegation. "Let me know how it goes" is not.

The Stoic Principle That Makes Delegation Work

The Stoics had a concept they called the dichotomy of control — the distinction between what is within your power and what is not. Epictetus taught that most human suffering comes from trying to control things that aren't actually controllable, while neglecting the things that are.

For founders trying to delegate, this distinction is the practical key.

What is within your control as a delegating founder:

The clarity of the brief and outcome you hand off
The level of trust and autonomy you specify
The check-in cadence you agree on
The feedback you give after the work is done
Whether you take the task back or let the delegate own the consequences

What is not within your control:

Exactly how the delegate will approach the problem
Whether they'll do it the way you would have done it
Whether the output will be exactly as good as yours would have been
Whether something goes wrong despite a good brief

The founder who can't let go is trying to control the second list while ignoring the first. They're spending energy on the delegate's approach — which isn't theirs to control — and skimping on the brief and the feedback loop — which are.

"Never let the future disturb you. You will meet it, if you have to, with the same weapons of reason which today arm you against the present." — Marcus Aurelius

This reframe is practical, not philosophical. If you write a clear brief, set the right delegation level, and agree on check-ins — you've done your job. The outcome is no longer yours to carry. If something goes wrong, you fix it in the feedback loop. But you don't preemptively fix it by checking in every day, taking the task back, or redoing the work at midnight.

The Delegation Brief: What Every Handoff Needs

Most failed delegations fail in the first five minutes — not because the delegate wasn't capable, but because the brief was incomplete. The founder assumed context that didn't exist. Or they described the task without describing the outcome. Or they gave the delegate a to-do without a definition of done.

A complete delegation brief has five components:

The outcome, not the task. "Write a proposal for the Acme renewal" is a task. "Land the Acme renewal at our current rate or above" is an outcome. Outcome briefs give the delegate latitude to figure out the best approach — which is how you develop judgment in your team.

The constraints that are real. Not everything is a constraint — don't list every preference as a rule. But actual constraints matter: budget, legal boundaries, non-negotiable stakeholders, deadlines that are hard. Be explicit about these.

The delegation level. As described above. Say it explicitly: "I want to know about this only if X happens" or "handle it completely, I'll see the result in the weekly review."

The success signal. How will you know this worked? Not a vague "go well" — a specific signal: renewal signed, NPS above 7, launched by Friday. This is the only thing you check. Not the process.

Your availability for questions — and your expectation that they'll try first. "I'm available if you get truly stuck, but I expect you to attempt a solution before you bring it to me." This is the sentence most founders skip. It signals that you trust the delegate's judgment and that asking every question is not the expected pattern.

The "Good Enough" Problem — and the Stoic Answer

Every founder who delegates seriously will eventually face this: the delegate does the work, it's good, but it's not how you would have done it. Not wrong — just different. Maybe a little less polished. Maybe a different approach that works but isn't yours.

The Stoic question to ask yourself in that moment: Is the difference between their version and my version within my control to fix, and is fixing it worth the cost?

If yes — give specific, actionable feedback and let them redo it. That's coaching, not micromanaging.

If no — accept it. Your version and their version both produce the outcome. The world doesn't run on your aesthetic preferences. The cost of always improving "good enough" to "exactly how I would have done it" is a team that stops bringing you their real work because they know you'll redo it anyway. That's how you become the bottleneck that kills your own company's growth.

The Stoics called this amor fati — love of what is, not love of what you wish were different. Applied to delegation: learn to appreciate a different approach that works, not just the approach that matches your mental model.

How to Rebuild Trust After You've Taken Tasks Back

If you've been micromanaging — and most first-time founders have, to some degree — your team has already adjusted. They've learned that delegation is temporary, that you'll eventually take it back, and that bringing you problems is safer than solving them independently.

Rebuilding that trust takes explicit action, not just good intentions. Here's what actually works:

Name it directly. In a team meeting or 1:1, say: "I've been taking work back when I said I'd delegate it. That's on me. I'm changing it. Here's what that looks like in practice." You don't need to grovel. One clear, direct acknowledgment resets the signal more effectively than months of trying to change quietly.

Delegate something real, not something safe. If you delegate the low-stakes stuff and hold the high-stakes stuff, your team knows it. They're not fooled by "you own the blog calendar." Delegate something that matters: the customer success process, the next sales proposal, the engineering architecture decision. Make the trust visible by making the stakes real.

Don't look, even when it's hard. If you said "you own this through Friday," don't check in Thursday night. The hardest part of rebuilding delegation trust is not the words — it's not checking. Your team doesn't need you to say you trust them. They need to see you not look over their shoulder.

Debrief, don't audit. After the delegation period, the conversation is about learning — not grading. "What would you do differently?" before "here's what I noticed." This is the difference between developing a leader and auditing an employee.

The Benchmark: What Good Delegation Looks Like at 30 People

When you scale from 5 to 30 people and delegation is working, here's what it actually feels like:

You're surprised by good decisions your team made without you. You find out in retrospect and realize they handled it better than you would have.
Your calendar has space for thinking. Not because you're working less — because the execution layer runs without you in every meeting.
Your team brings you problems framed as options, not as requests for you to make the call. They've internalized your thinking enough to propose solutions.
You feel slightly irrelevant to the day-to-day, and that feels like success instead of anxiety. This is the hardest one. It means the maker identity is actually gone.

If you're not there yet — that's not a failure. It's a process. The founders who delegate well at 30 people usually tried and failed at 10, rebuilt the trust at 15, and made a real identity shift somewhere between 18 and 25. It's not a moment — it's a practice.

Start Here

This week, identify one decision you've been making that a member of your team could own. Write a delegation brief using the five components above. Specify the delegation level. Set the success signal. Then don't look until the agreed-upon date.

That's it. One delegation. Done well. That's the whole practice in compressed form.

The rest — the identity shift, the trust rebuilding, the "good enough" calibration — happens by repeating that one delegation, with increasingly high stakes, until the new identity settles in. The Stoics would call this askesis: deliberate practice toward a better character.

The founder who can delegate is a different kind of leader than the one who can't. The company they build is a different kind of company. The ceiling is higher, the culture is stronger, and — critically — the founder isn't the bottleneck to their own growth.

That's the whole thing.

Ready to make the maker-to-leader transition? Take the free 13-question leadership assessment and get a personalized Stoic coaching session — built for founders scaling their first team.

5 Decision Frameworks Every Founder Gets Wrong

Stoic Lead — Mon, 11 May 2026 12:33:24 +0000

Founders make more high-stakes decisions per week than most executives make in a year. And they make them with incomplete information, sleep deprivation, and real money on the line.

Most founders wing it. They trust their gut, lean into conviction, and move fast. Sometimes this works. More often it produces decisions that look obvious in retrospect but felt unavoidable at the time — a hiring bet that didn't pay off, a pivot that was actually just panic, a pricing strategy that chased the wrong customers.

The founders who compound their judgment over time aren't smarter. They have better systems. Frameworks that filter out the noise, force explicit thinking about trade-offs, and catch obvious mistakes before they compound.

These five are the most useful I've encountered. They're drawn from ancient Stoic philosophy, military doctrine, and modern cognitive science. Together they cover most of the decisions a founder actually faces.

1. The Stoic Dichotomy of Control — The Filter Before Everything Else

Epictetus, who spent his life as an enslaved person in Rome before becoming one of the most influential philosophers of antiquity, built his entire system around one question: Is this within my control?

"Make the best use of what is in your power, and take the rest as it happens." — Epictetus

For founders, this is not abstract. The market, your competitors, the economy, whether a deal closes — none of these are in your control. Your strategy, your execution, the culture you build, how you spend your time — these are.

The Dichotomy of Control is a pre-decision filter. Before any significant decision, ask: is the outcome I'm hoping for actually something I can influence? If not, design the decision around inputs you can control — not outcomes you can't.

Practical use: before hiring someone, the question isn't just "will they be great?" It's "did I set the right expectations, build the right environment, and give clear enough direction to give them a fair shot?" The hire's performance is not fully within your control. Your management is.

This sounds simple. It's not. Most founders spend enormous energy on outcomes they cannot influence while neglecting the inputs they can. The Dichotomy of Control is a daily discipline, not a one-time insight.

2. Pre-Mortem — The Reality Check Before Every Big Bet

Gary Klein, a cognitive scientist who studied how experts make decisions, found that elite teams use a technique he called the pre-mortem: before a major decision, you imagine it has failed catastrophically. Then you work backward to figure out why.

The value is that it counteracts optimism bias — the systematic tendency to overweight positive scenarios and discount negative ones. Founders are paid to be optimistic, which is a feature. It's also a bug when it prevents realistic assessment of risks.

How to run one: before committing to a major decision — a new product line, a major hire, a pricing change — spend 10 minutes writing down exactly why it failed. Not "could fail" but "has failed." Be specific. The goal is to generate the failure modes before they have a chance to surprise you.

Research has found that this technique activates different cognitive circuits than standard planning. Standard planning asks "how do we succeed?" Pre-mortem asks "why did we fail?" The second question surfaces the objections that the optimistic brain tries to suppress.

Use it before you sign any major contract, launch any new product, or make any structural change to the business. The 10 minutes will save you months of recovery from obvious mistakes.

3. The Reversal Test — Protecting Against Your Own Conviction

Philosopher Derek Parfit described a technique he called the Reversal Test: when you're confident about something, ask the opposite. If you still believe the original after considering the counterargument, your confidence is warranted. If you can't articulate why the reversal is wrong, that's a warning signal.

Ray Dalio uses this explicitly. Before committing to any major decision, Bridgewater requires that the decision-maker articulate the strongest argument against their position. Not to be contrarian — but to test whether the conviction is well-grounded or just familiarity dressed up as expertise.

Founders who can't reverse their own positions have built their strategy on assumptions they've never stress-tested. The Reversal Test is uncomfortable because it feels like arguing against yourself. That's the point. The discomfort is the signal.

Concrete use: if you're convinced your startup should pivot to enterprise sales, write the strongest argument you can for staying with SMB. If after doing that you still believe in the pivot, you understand the tradeoff better than before. If you struggle to write the counterargument, your conviction is probably under-examined.

4. Second-Order Thinking — Where Most Decisions Actually Live

Howard Marks of Oaktree Capital Management has a concept he calls second-order thinking: most decisions have obvious first-order effects. Winners think about what happens after the first thing happens.

First-order: "If I cut prices, I'll get more customers." Second-order: "If I cut prices, I change the customer segment I'm attracting, I train the market to expect lower prices, and I compress my margins at the exact moment I need them most." And then: "And then my gross margin will be too thin to invest in the product improvements that would actually differentiate us."

"The smart decision is the one that takes into account what happens after the immediate consequence." — Howard Marks

The trap is optimizing for immediate feedback loops while ignoring the delayed feedback loops that tend to be more consequential. Founders often make decisions based on outcomes they'll see in weeks while the most important outcomes take quarters or years to materialize.

Second-order thinking is a discipline of asking "and then what?" until you reach the bottom of the chain. It's not about predicting the future — it's about making the implications of your current decision explicit before you're locked in.

5. The OODA Loop — Decision Velocity in Competitive Markets

Colonel John Boyd developed the OODA loop — Observe, Orient, Decide, Act — as a military decision-making framework. Its core insight: in competitive situations, speed of decision-making compounds. The faster you can observe, process, decide, and act, the more you exploit information advantages and force competitors to react to you rather than the other way around.

This is especially relevant in markets where you're competing against well-resourced incumbents. Their advantage is depth of analysis; your advantage is speed.

The practical version: build triggers for when to re-evaluate decisions. Not constant re-thinking, but clear conditions under which the current decision logic no longer applies. In product, this might mean: "we decided to go upmarket. If we haven't landed three enterprise deals in 90 days, we revisit this." Without triggers, you either over-index on the original decision or you oscillate chaotically between pivots.

OODA loops work best when combined with the other four frameworks. You use the Dichotomy of Control to know which decisions matter. You use Pre-Mortem to check for obvious failure modes. You use the Reversal Test to stress-test your conviction. You use Second-Order thinking to see around corners. Then you use OODA to move fast on the decisions that remain.

The Pattern Behind All Five

These frameworks share a common structure: they externalize a cognitive process that most founders run entirely in their heads. They force explicit reasoning where default behavior is implicit.

None of this replaces judgment. But it protects your judgment from the specific failure modes that founders are most vulnerable to: optimism bias, recency bias, sunk cost, and the comfort of a confident narrative over a realistic one.

Start With One

You don't need to run all five before every decision — that's analysis paralysis by another name. Pick the one that most closely matches your current blind spot.

The goal is not perfect decisions. It's better compounding of judgment over time — so that the decisions you make in year three are better than the ones you made in year one, not because you got smarter, but because you built better systems for thinking them through.

That's the actual long-term advantage in building a company. Not the idea, not the market timing, not the team. The quality of the decisions made under pressure.

Want to know which of these frameworks matches your natural decision-making style? Take the free StoicLead assessment — 13 questions, personalized results.