The Stoic Programmer: Marcus Aurelius on Technical Leadership

What does Marcus Aurelius teach about technical leadership?

Marcus teaches three principles that map directly to engineering leadership: focus only on what you control, judge your actions rather than their outcomes, and define your role as service to the people you lead.

I kept a copy of the Meditations on my desk for 3 years. I opened it most often after production incidents. Not for comfort, but for calibration. After a 4-hour outage that affected 12,000 users, I was furious at the team member who had merged the bad deployment. Marcus wrote: “How much more harmful are the consequences of anger than the circumstances that aroused it.” I closed the book and opened Slack with a different message than the one I had drafted.

This is not sentimentality. It is engineering discipline applied to the self. The Stoic programmer does not suppress emotion. They refuse to let emotion make architectural decisions.

What does “focus on what you control” mean in engineering practice?

It means distinguishing between your code, your communication, and your preparation (which you control) and the production environment, stakeholder reactions, and market conditions (which you do not). The distinction is not passive acceptance. It is strategic clarity.

Marcus called this the “dichotomy of control,” and Epictetus formalized it before him. In engineering, the dichotomy is concrete. I control the quality of my code review. I do not control whether the reviewer accepts my feedback. I control the clarity of my architecture decision record. I do not control whether the organization follows it. I control my preparation for the incident. I do not control when the incident arrives.

I watched a senior engineer spend 3 weeks frustrated that stakeholders were not reading their technical documentation. Marcus would have asked: “Is the stakeholders’ reading within your control?” No. “Is the quality and accessibility of your documentation within your control?” Yes. The engineer restructured their documentation, added visual summaries, and reduced it from 40 pages to 8. The stakeholders started reading it. The Stoic approach worked not because the engineer controlled the outcome, but because they stopped trying to control the outcome and focused on controlling the input.

This connects directly to the dichotomy of control in production systems. The principle is the same whether applied to the soul or the server.

How does Stoic judgment apply to incident response?

Marcus taught that events are neutral. Our judgments about events create suffering. In incident response, the Stoic approach separates the technical fact (the system is down) from the narrative (someone failed, this is a disaster, we are incompetent). The first requires engineering. The second requires nothing and helps no one.

I established a rule in my teams: during an incident, no one assigns blame. After the incident, the retrospective examines the system, not the person. This is not kindness. It is effectiveness. Marcus wrote: “Waste no more time arguing what a good person should be. Be one.” Translated to engineering: waste no more time in incident calls arguing who caused the failure. Fix the system that allowed it.

The blameless postmortem, now standard practice at companies like Google and Etsy, is Stoic philosophy in operational form. It embodies Marcus’s principle that people act from their best understanding at the time, and that the system’s design, not the individual’s moral character, determines outcomes. When a deployment fails, the question is not “who approved this?” but “why did our process allow an unsafe deployment to reach production?” This is what premeditatio malorum looks like in engineering: anticipating failure at the system level rather than blaming it at the individual level.

What does “serve the people you lead” mean in a technical context?

Marcus governed 70 million people. He wrote: “What does not benefit the hive does not benefit the bee.” Technical leadership is not about shipping features. It is about creating conditions where your team can do their finest work.

The best engineering managers I have worked with embody this principle without knowing its Stoic origin. They clear obstacles rather than assign tasks. They absorb organizational chaos rather than transmit it. They measure their success by their team’s growth rather than their own visibility. Marcus would recognize them immediately.

I adopted a practice from the Meditations: every morning, I ask myself what I can do today that makes someone else’s work easier. Not what I can ship. Not what I can present. What I can remove, clarify, or absorb so that someone with less organizational power than me can focus on the work that matters. This is what platform engineering as service looks like at the human level.

“The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” — Marcus Aurelius, Meditations

Marcus Aurelius did not have access to cloud infrastructure, distributed systems, or language models. He had something more useful: a framework for maintaining clarity, purpose, and moral seriousness in conditions of extreme uncertainty. The Meditations is not a self-help book. It is a field manual for leading when the world will not cooperate. Every engineering leader works on that frontier. The Stoic programmer does not pretend the frontier is tame. They show up anyway, clear-eyed, focused on what they control, and committed to the people they serve.