The moment of recognition
A few weeks ago I was in a retrospective with my team. One of my developers hadn’t delivered a feature on time—not through incompetence, but through misjudging scope. The first thought that came into my head wasn’t ‘why didn’t you tell me sooner’ or ‘next time plan better’, but: this is his moment to learn from this. My role is to give feedback, not steer him like a puppet.
Later that evening, barely sleeping, I thought: why does this feel like the only thing I can do, and also the hardest? Then I saw the pattern. I wasn’t being passive. I had just done the reverse of what most managers do: I let go of what I couldn’t control (his learning process, his motivation) and focused on what I could determine (my feedback, my tone, my patience). That’s stoic management. And I was already doing it without calling it that.
What stoicism actually is
Stoicism gets regularly blamed for passivity, as if it means ‘what happens, happens’. That’s a misreading. Nonsense. Marcus Aurelius and Seneca led masses of people—the empire, billions in money, political power—and their notebooks are about the same friction I encounter now: incompetent people, delays, grief. They weren’t passive. They were clear-eyed.
The real idea is this: you separate what you control from what you don’t. What you control are your reactions, your aims, your values, your daily work. What you don’t control are the outcomes, what others feel, whether the market cooperates. The difference seems subtle, but it changes everything.
If I try to control that my developers make no mistakes, or that they’re enthusiastic, or that their career path follows mine—then I’m in constant conflict with reality. I become emotional, defensive, controlling. They feel that and grow less. That’s what I see happen with managers who lead from fear.
If instead I direct my energy toward what I do determine—clarity about what we’re building, honest feedback, a culture where mistakes are part of growth—then something else happens. The tension falls away. They start to feel ownership.
Three things a stoic lead does differently
One: you correct your story about the problem
A junior developer brings bad news: the integration will take two more days. Most managers feel a surge of rage energy: ‘how could you miss this, this ruins our sprint plan’. That story, that moment of interpretation, determines everything after. Your tone, your decisions, how the team reacts.
Stoicism says: the fact is neutral. The integration takes longer. Period. The story I tell about it—that this is a disaster, that someone failed, that my week is now wrecked—that story I make myself. And I can make it differently.
What I do instead: I pause, I tell myself ’this is information, not drama’, and then I ask: what do I determine about this? I determine how I approach it. I determine the next step. I determine how I communicate it upward, to the team. That focus creates space. And suddenly it’s just a problem that needs solving, not a moral failure.
Two: you give direction, not instructions
I don’t tell my developers how to write code. I do tell them what the goal is, what constraints exist (performance, security, data quality), and I’m not afraid of disagreement about the path. That’s hard for everyone, because it feels slower. But it means they use their brains, not their obedience.
This only works if I truly let go. Not just say ‘I trust you’, but also show it in behavior. I don’t control in the background. I don’t constantly ask ‘how’s it going’. I extend trust—and also accept that some will break it. That’s their failure, and they learn from it. My job isn’t to secure their life; my job is to be clear and fair.
Three: you accept that their path doesn’t have to be yours
I have strong opinions about architecture, about how you write elegant code, how you build a career. For many of my developers—especially the juniors—that’s fascinating, and they pick it up. Good. But there are also those who think differently, who want to grow differently, work differently. I noticed that used to make me impatient. Too much investment in their following, not enough originality.
Now I see it differently. That’s not my problem to solve. My job is to help them see where they’re good, give them feedback, let them try it differently. If a developer makes an architecture choice I wouldn’t make, but it works, and it’s defensible—then that’s their growth. Not mine.
That feels counter-intuitive. You want to shape your team in your image. But stoicism says: you determine your own goals and principles. Their path is their path.
Where stoicism stops
This all sounds neat. But there are gaps.
First: not everyone on your team is stoic. Many of my developers aren’t interested in philosophy. They want certainty, clear rules, a plan that works. I can’t expect them to share my clarity. So then I need other tools—better documentation, clearer deadlines, more foreseeing what will happen. Stoicism helps me, not them.
Second: there’s a line between ‘letting them grow’ and ‘not taking my responsibility as a lead’. If someone is really struggling, and I say ’that’s their learning moment’, I might just be absent as a leader. Somewhere I have to step in, ask questions, maybe help. The difference is in intention: am I doing it because I’m afraid and want to control him, or because it’s my job to give him honest feedback?
Third: stoicism doesn’t solve what you don’t control. The market can collapse. Sprints can become chaos from things outside our reach. My developers can all leave. Stoicism helps you stay emotionally healthy in that chaos, but it doesn’t stop it. You still have to do good work, communicate well, be flexible.
Active versus passive
Here sits the real question for me: is this discovery or intention?
I’ve already been managing this way without thinking about it consciously. But now that I see it, I’m also accountable for it. I can’t say anymore ‘it’s just who I am’. I have to choose to keep doing it, and on some points become more conscious of where I slip back into control behavior.
Last night I had a conversation with one of my seniors. He told me he’s looking at other companies. My first reflex was shame and panic: did I not manage him well? Did I fall short? That’s the control mechanism returning. He’s not leaving because I failed; he’s leaving because he made a choice. That’s his ownership. And my job isn’t to keep him, but to tell him honestly what I think of him and what I’ll miss if he goes.
That shift—from ‘how do I keep him’ to ‘how do I be honest’—feels like the real application of stoicism.
Can this scale?
I lead nine developers now. If the team grows to fifteen, twenty—does this still work? I think so, but differently. With nine I can give individual feedback, bring nuance. With twenty it has to become more system: clearer culture signals, more formal structure, less personality.
But the principle doesn’t change. What do I determine? My goals as a leader (growth, quality, safety), my systems, my values. What do I not determine? Whether someone understood after one explanation. Whether they want to work tomorrow. Whether they feel they matter.
That separation stays clean. It’s only the detail that changes.