There’s a pattern I see repeatedly in climate tech companies led by technical founders. The founder is brilliant at modeling complex systems. PhD-level thinking. Comfortable with nonlinear dynamics, feedback loops, emergent behavior.
Then they design an organization, and they build something nobody can navigate — including themselves.
The skill becomes the liability
Technical founders are trained to see complexity. They’re good at holding multiple variables in their heads. They can reason about systems with dozens of interacting components. This is a genuine advantage when you’re building products that model physical systems.
It becomes a liability when you’re designing an organization. Because the correct number of interacting components in an org chart is as few as possible. Not because simplicity is aesthetically nice — because humans aren’t compute nodes. They need clarity to act.
What I see in practice
The org has a matrix structure that made sense on a whiteboard but creates three reporting lines for every IC. Decision rights are distributed across so many roles that nobody knows who can actually say yes. The strategy has seventeen priorities because the founder can hold seventeen priorities in their head simultaneously.
The team can’t. The team needs three priorities, clear ownership, and a decision-making framework that doesn’t require a PhD in systems thinking to operate.
The founder designed the organization like a complex system to be modeled. They should have designed it like a machine to be operated.
The structural diagnosis
This isn’t a communication problem. You can’t solve it with better all-hands meetings or a new project management tool. The structure itself is generating confusion. The org chart is the bug.
When I work with founders on this, the first reaction is usually resistance. The complexity feels earned. It feels like it reflects the real complexity of the problem space. And it does — but the org’s job isn’t to mirror the problem space. It’s to be simple enough that people can execute against it.
What changes
The intervention isn’t simplification for its own sake. It’s identifying which complexity is load-bearing and which is accidental. Most of it is accidental. The founder added it because they could hold it, not because the org needed it.
Strip the accidental complexity. Make the load-bearing complexity explicit. Give people clear ownership and fewer dependencies. The organization doesn’t need to be as smart as the founder. It needs to be clear enough that everyone else can do their best work.