There are as many ways to run a startup as the number of founders. When size is small and everyone knows everyone, coordination is easy. When size grows, existing communication patterns may become inefficient and coordination is lost. You spent too much time doing very little. This workflow is an attempt to keep the coordination cost low by minimizing the communication.
Insects lives in an environment quite similar to startups: volatile, competitive, unforgiving! In studying eusocial insects, E. O. Wilson observed that as group size increased, centralized behavioral control was replaced by coherence signals, local rules, and clear boundaries. Eusocial biology provides a stable control architecture which is already stress-tested, failure-pruned and optimized for uncertainty. Can we use this architecture for a startup?
The analogy between insect colonies and startup is already well discussed.
| Control style (Wilson) | Eusocial insect pattern | What actually happens in nature | Startup analogue | Typical startup size where it works | Failure mode when pushed too far |
|---|---|---|---|---|---|
| Direct control / dominance | Primitive wasps with aggressive queens | Constant policing, frequent conflict, high energy cost | Founder micromanagement, centralized approvals | 2–8 people | Founder bottleneck, burnout, execution stalls |
| Centralized coherence | Honey bee queen pheromones | Queen stabilizes state, workers self-organize tasks | Clear vision, priorities, incentives, values | 8–30 people | Decision latency, leader context overload |
| Local rule-based autonomy | Ant task allocation via local encounters | Individuals respond to local signals, rapid rebalancing | Team-level ownership, clear interfaces, local metrics | 30–150 people | Coordination drift if coherence weakens |
| Fully decentralized self-organization | Large ant supercolonies | No central controller, behavior emerges from constraints | Autonomous teams with shared goals and metrics | 150+ people | Fragmentation, duplicated work if signals decay |
Our motivations are definitively much more complex than insects and our behavior can be extremely irrational, e.g. A Group is Its Own Worst Enemy by Clay Shirky. But communication and coordination is a fundamental problem in any social group. So its worth looking at the table above as a good starting point. You can also use it to compare and contrast what you currently have.
This workflow is meant for a few (3-10) teams building complex products that mix software, data, and real-world systems. This workflow prefers the Local rule-based autonomy in the table above. That means focusing on “Team-level ownership, clear interfaces, local metrics”.
Remove multiple ownership which explode communication while decaying coherence
<aside> 💡
Do not breed a culture of ‣ . In practice, it means “giving tasks away” rather than relinquishing decision rights.
</aside>
If you don’t have a successful product in the market, shift focus from “what to build” to “risk that we need to remove”
I split the workflow into three layers — direction (vision and north star goals), risks (epics), execution (sprint that burn risks/uncertainty).
This is not the focus of this workflow. It is for the leadership, the founders. Every quarter (or every 6–8 weeks), define an Objective e.g. “Improve the reliability of our product in real-world use.” and three to four Key Results
These are outcomes, not features.
<aside> 💡
If you are not an expert in a domain, try to keep away from the execution in that domain! Also, If you are into micro-management, you may have to give up some control else you’ll end up creating a lot of communication overhead and drain energy. Micro-management works in great in some situations especially at short timescale but it is typically not really a great strategy for long term games.
</aside>
Epics are the most important layer. These are the unit of ownership given to team-leads or senior ICs. Each Epic should answer: