Stephan Schmidt - January 24, 2026
The Ontology of Leadership: Why Good Managers Build Worlds
TL;DR: Management isn't administrative - it's ontological. Like ancient storytellers who turned terrifying thunder into an angry goddess people could understand, modern managers weave chaos into meaning. The managers job isn't to move tickets. It's to create categories that filter reality (sprints, technical debt), choose frames that shape how facts are understood, and articulate a story that becomes their team's shared world. Stop managing resources. Start managing meaning.
People for thousands of years have observed the world and it’s phenomena. The chaos of information and events surrounding them. Moon rising, Sun setting, Thunder roaring - phenomenas that are chaotic and confusing. And some of the things people see are even frightening.
Then someone stood up and created a story. How the sun goddess wanders around the earth and the moon god is frightened of the bright light and moves away. The moon sets and the sun rises. How the thunder goddess thunders because she is angry at the sun goddess because the sun fled her place and it got dark. The storyteller continues explaining that this is how the world works and there is nothing to be afraid of. And people said “Ah that makes sense.” and went on with their lives.
Recently in the great AI migration I’m watching engineering managers focusing on the how to migrate to AI. Many engineering managers feel CEOs and founders breathing down their neck to deliver more AI results. This makes them scramble for the best way, the best process, and pushing developers to plainly use more AI. But developers just won’t do what they are told it seems.
I have seen this pattern in the past - managers being ignored by employees. Engineering managers buying nice toys like expensive laptops or the latest IDE licenses. Engineering managers do everything they can - they think - and still the train is not moving.
Conventional wisdom through the mouth of their superiors tells them to “set a deadline” or “push harder”. I’ve watched this playbook fail dozens of times. The deadline passes, nothing changes, and somehow it’s always the developers’ fault. But this doesn’t work. There is a fundamental misunderstanding at the heart of our industry. We treat management as a mechanical discipline. We track velocity, we optimize Jira workflows, and we obsess over “resources.” We act as if the organization is a machine that simply needs oiling.
The story teller made sense of the world. The modern manager is that story teller. It’s the managers job to make sense of the world. Contrary to conventional wisdom, I argue that the role of the manager is not administrative. It is ontological - it deals with the very nature of reality and being. The manager’s true job is not to move tickets. It is to create the reality in which the team exists. We create this reality through storytelling. The modern manager weaves a story that makes sense of all those phenomena, they weave noise into signal. Employees hear marketing say something, the CEO doing something, the customers complaining, a new strategy, the CTO wants to move to AI. All these phenomena feel random and confusing. And they don’t make sense. People wonder how they fit into all of this.
The ancient storyteller explaining thunder did more than make sense of the world. Philosophers1 have a name for what she was doing. Just as the story teller turned terrifying thunder into a goddess, the manager performs what Edmund Husserl, the father of phenomenology, called Constitution (Konstitution).2 Husserl argued that the world doesn’t just “happen” to us. We actively constitute the meaning of the world through our consciousness.
In a startup, the world is the chaos of the market. It is the erratic competitors, the demands of customers, the technical debt, the entropy. Employees are overwhelmed by the noise of what is going on around them. They build their own simple explanations to make sense of the world - and those are often wrong.
The manager must perform the act of Constitution. They must stand in the void and constitute the reality of the team. The manager defines the shared world (the Lebenswelt): “This is who we are. This is what we build.” Without this act of meaning-making, there is no team, there is no department, there is no company. There is only a collection of freelancers sharing a Slack workspace.
Let’s not stop here but crash deeper into the rabbit hole. Immanuel Kant argued that we can never know the Ding an sich (the Thing-in-Itself).3 We cannot access raw reality. If we did, it would be a “blooming, buzzing confusion”4 of sensory data. To survive, our minds impose Categories on the world - concepts like Time, Space, and Causality.
Categories is what a modern manager creates.
The market, the company and the environment are the Ding an sich. They are infinite, chaotic, and terrifying. If you expose your developers directly to the raw, unadulterated chaos of the market and environment (or the CEO’s brain :-), they will struggle with reality. A manager’s job is to supply the Categories of Understanding in in this model:
- “The Sprint” is not real. It is a category you invent to slice time into manageable chunks.
- “Technical Debt” is not real. It is a conceptual container for bad code so we can talk about it without crying.
- “Scope” is not real. It is an imaginary boundary we draw around work so we can say what’s in and what’s out.
- “Done” is not real. It is a social agreement, not an objective state of the code.
A bad manager thinks these things are real. A good manager knows they are filters that save the team from chaos. Those categories are the building blocks of the story to weave. We need to weave a story out of these categories and translate those categories to make them understandable.
Selecting and forming these categories is what we call Framing. Here Lakoff comes into play. Cognitive linguist George Lakoff said: “Don’t think of an elephant.”5 (You just thought of an elephant, ha!) and named a book after it where he introduces ‘frames’ to a wider audience.
A frame is the context you put around facts. It’s the story that tells people how to interpret what they see. It’s a filter of perception on how to interpret phenomena. Storytelling is framing by selecting categories and translating phenomena. Lakoff argues that frames are not just words. They are mental structures that shape how we reason.
When a project is late, you have a choice of frames:
- The “Failure” Frame: “We are behind. We need to work harder. We are incompetent.”
- The “Scope Discovery” Frame: “We learned that the problem is harder than we thought. We are adjusting the plan to match reality.”
The facts are identical. The timeline has slipped. In Frame 1, the team hides problems to avoid punishment. In Frame 2, the team shares information to solve the puzzle.
I see this constantly with “Refactoring.” If you frame it as “Cleaning up,” the business hears “Janitorial work” (cost). If you frame it as “Reducing volatility,” the business hears “Risk management” (investment).
Facts do not matter if they do not fit the frame. If the facts contradict the frame, the frame stays, and the facts are ignored. You are not just reporting news. You are choosing the lens through which the news is understood and filtered. You create categories and frames.
Framinging is the main tool to impose your reality on the world - not only to employees but also to the CEO and customers. If you choose the wrong frame, you lose the argument before you open your mouth. If the other person sets the frame you never make the point. You weave your story through categories and frames from noise into signals, from void into reality. The most impactful framing for engineering managers is “Throughput” vs. “Impact”. You choose if your story is about throughput or impact. If the CEO frames software development as throughput, everything is seen through that lens. The team ends up in a feature factory of “faster, faster!” with deadlines, velocity and “why is this project late again?”. While if the CTO frames software development as impact, the company is on the lookout for features that have impact. The team is building features that have impact on the future of the company.
There’s a question that haunted Karl Weick: “How can I know what I think until I see what I say?”6
It sounds like wordplay, but it’s the deepest insight into what managers actually do. We don’t first understand reality and then communicate it. We understand reality by articulating it. The story isn’t a report of what’s happening - the story is how we discover what’s happening.
Weick called this sensemaking. Talking about things and connecting them into a story is sensemaking. For managers, there’s a second layer: sensegiving. You’re not just making sense for yourself. You’re shaping how everyone else makes sense of the chaos. When you stand up in a meeting and say “here’s what’s going on” - you’re not describing. You’re creating. The team didn’t have a shared reality before you spoke. Now they do. Your words became their world. This is why the manager’s job is ontological. Not because it sounds impressive. But because speaking is creating.
This also explains why even a flawed strategy beats no strategy. Weick tells the famous story of a Hungarian military unit lost in the Alps during a snowstorm.6 They were resigned to death. Then, one soldier found a map in his pocket. Reassured, they plotted a course and marched out.
Only later did they discover it was a map of the Pyrenees.
The map was empirically false. But it was pragmatically true. It provided a pretext for action. It transformed the paralyzing chaos into a solvable puzzle. By moving, the soldiers enacted their own survival.
A manager who avoids creating a strategy because “the future is uncertain” leaves their team adrift. The manager provides the map of the Pyrenees. They give the team a plausible structure - a “vision” or a “strategy” - even if the future is uncertain. The map reduces anxiety. It creates movement. And once the team is moving, they will generate the feedback loops necessary to find the real path. We are drowning in complexity. The modern tech stack is too deep for any one person to understand. The market is too volatile to predict. In this environment, the manager who acts as a mere administrator is obsolete.
So what about those engineering managers scrambling to migrate to AI? Stop pushing tools. Start with the why7 and tell the story instead. “Here’s why AI changes how we work. Here’s what stays the same. Here’s who we become. Everything will be fine.” Choose the right categories and frames and tell the story. Developers don’t respond to push. They follow meaning.
Stop managing resources. Start managing meaning.
I was the first graduate of a program called “Philosophical Computer Science” at university. At the time, combining Platonic philosophy with algorithms seemed crazy. Decades later, I find Husserl and Kant useful to explain software engineering management. ↩︎
Edmund Husserl, Ideas I (1913). Husserl argued that objects don’t just exist; they are “constituted” by consciousness. We turn raw sensory data into meaningful objects through our attention and intention. ↩︎
Immanuel Kant, Critique of Pure Reason (1781). The Ding an sich remains one of philosophy’s most debated concepts. For our purposes: raw reality is inaccessible; we only ever work with our mental models of it. pau ↩︎
William James, The Principles of Psychology (1890). The full quote: “The baby, assailed by eyes, ears, nose, skin, and entrails at once, feels it all as one great blooming, buzzing confusion.” ↩︎
George Lakoff, Don’t Think of an Elephant! (2004). A short book on political framing that applies far beyond politics. His earlier academic work with Mark Johnson, Metaphors We Live By (1980), goes deeper into how frames shape thought. ↩︎
Karl Weick, Sensemaking in Organizations (1995). The map story originally comes from the Hungarian poet Miroslav Holub. Weick uses it to illustrate how action precedes understanding - we make sense of situations by acting, not by analyzing. ↩︎ ↩︎
Simon Sinek, Start with Why (2009). Sinek argues that inspiring leaders communicate from the inside out - starting with why, then how, then what. ↩︎
About me: Hey, I'm Stephan, I help CTOs with Coaching, with 40+ years of software development and 25+ years of engineering management experience. I've coached and mentored 80+ CTOs and founders. I've founded 3 startups. 1 nice exit. I help CTOs and engineering leaders grow, scale their teams, gain clarity, lead with confidence and navigate the challenges of fast-growing companies.