Your organization is more complex than it needs to be, and the person who made it that way is you. Technical founders model complex systems for a living. They see nuance, interdependencies, edge cases. Then they build organizations that reflect that same cognitive architecture — matrix structures, distributed decision rights, intricate reporting lines, committees for everything. The org chart looks like a systems diagram because the founder designed it like one. But an organization isn’t a system to be modeled. It’s a machine to be operated. And the difference between load-bearing complexity — the complexity your business actually requires — and accidental complexity — the complexity your brain generated because it could — is the difference between a functional company and one that’s drowning in its own structure.
What it looks like
Every individual contributor has two or three reporting lines. Decisions require sign-off from multiple functions, and nobody is sure who has final authority. There are working groups, steering committees, and cross-functional pods layered on top of a matrix structure that was already layered on top of a functional hierarchy. A straightforward product decision touches five stakeholders and requires two meetings before anyone can act. New hires take months to figure out how anything actually gets done. The company has more process than a company its size should need, and every process was created to solve a real problem — which makes each one feel individually justified. But taken together, they create a coordination overhead that consumes more energy than the actual work. People spend their days in meetings about meetings. The organizational design is elegant in theory and exhausting in practice.
The mechanism
The founder who can model atmospheric convection systems or satellite data pipelines brings the same cognitive tools to organizational design. They see the interactions between teams, the edge cases in decision-making, the failure modes in communication. So they design for all of them. Every potential conflict gets a coordination mechanism. Every dependency gets a review process. Every edge case gets a committee. The result is an organization designed for a level of complexity that the business doesn’t actually generate. A twenty-person company doesn’t need a matrix structure. It needs clear ownership. A forty-person company doesn’t need distributed decision rights across seven roles. It needs three people who can say yes. But the founder’s instinct is to design for the system’s theoretical complexity, not its operational reality. They build the org like they’d build a model — capturing every interaction, every feedback loop. The problem is that organizations aren’t models. Models benefit from completeness. Organizations benefit from simplicity. Every interaction you capture in your org design becomes a coordination cost that real humans have to pay with their time and energy every single day. The model doesn’t get tired. Your team does.
Why it persists
Accidental complexity is invisible from inside because every piece of it was a reasonable response to a real situation. The matrix structure exists because someone needed to report to both product and engineering. The committee exists because a cross-functional decision went wrong once. The process exists because something fell through the cracks. Each piece has a story that justifies it. Removing any single piece feels risky because it was built to solve a problem that’s still real. What nobody can see is the cumulative weight — the interaction effects of all these mechanisms layered on top of each other. And the founder can’t see it because the complexity matches their own cognitive model of how things should work. They navigate it fine because they built it. They mistake their own ability to operate within the complexity for evidence that the complexity is appropriate. Meanwhile, everyone else is spending forty percent of their time navigating structure instead of doing work. The organization’s velocity is a fraction of what it should be, and the founder attributes this to hiring quality or team motivation, never to the machine they designed.
What changes
The distinction that matters is between load-bearing complexity and accidental complexity. Load-bearing complexity is the minimum structure required to manage the actual coordination demands of the business. If you’re building hardware and software with a government customer, yes — you need some cross-functional coordination. Accidental complexity is everything else: the structures that exist because the founder’s brain generated them, not because operations demanded them. Stripping accidental complexity means asking one question of every structure, process, and reporting line: does this exist because the work requires it, or because someone designed it before the work proved it was necessary? The goal isn’t simplicity for its own sake. It’s operational clarity — an organization where people spend their energy on the work, not on navigating the structure that’s supposed to support the work.
What I see
My PhD is in atmospheric physics — I built complex models for a living. So I recognise the instinct immediately when I see a technical founder’s org chart that looks like a systems diagram. The depth of modelling that makes a good scientist makes a dangerous organisational designer. I’ve worked with climate tech companies where the coordination overhead consumed more energy than the actual work, and in every case the founder could explain the logic behind each piece of the structure. Each piece was individually defensible. The cumulative weight was crushing the team. The founders who break this pattern are the ones who internalise a different design principle: organisations aren’t models to be complete. They’re machines to be operated.
Where this shows up
Accidental complexity is endemic in climate tech because the sectors themselves carry genuine structural complexity — and founders overdesign in response. Earth observation companies build matrix structures to manage the hardware-software seam and end up with three reporting lines for every IC. Energy markets companies layer regulatory, commercial, and technical coordination into structures that nobody can navigate. Defense & dual-use companies add compliance and security structures on top of an already complex commercial org. The diagnostic question isn’t whether the business is complex — it is — but whether the organizational complexity is proportional to the operational demand. For investors, accidental complexity is a structural risk that standard due diligence misses entirely, because it looks like thoroughness from the outside. Understanding climate tech operating models is the starting point for distinguishing load-bearing from accidental.
Organisations aren’t models to be complete. They’re machines to be operated.