Engineering an Organization
Primitives are as fundamental to building a great company as they are to designing a great engineering system. In some ways, they matter even more than moral values.
Every company can claim to believe in honesty, integrity, fairness, and responsibility. What distinguishes companies is not what they claim to believe, but how they actually behave.
Human nature is imperfect. We are inconsistent, driven by self-interest, constrained by fear, and often drawn toward the path of least resistance. Even the best people cannot be expected to make the right decision every time.
A great company should not require great people to do the right thing. It should make doing the right thing the natural choice.
Values define what a company aspires to be. Primitives determine what it actually becomes.
Primitives are the fundamental building blocks of how a company operates.
Like primitives in engineering, they are opinionated, explicit, reusable, and composable. They can define resources, operations, contracts, or workflows. A primitive should be concrete enough that anyone can understand how to use it without reinventing the process.
For example, a project management primitive should define not just that every task needs an owner, but when to create a project versus an issue, how ownership is assigned, and how progress and blockers are communicated.
We want primitives to work like a well-designed SDK. Anyone joining the company should be able to discover how things work and start contributing, without spending months learning unwritten conventions.
Good primitives make the right way to work obvious, the wrong way difficult, and the possibilities for creation open-ended.
Our ambition is to build a company that operates with the precision of a well-engineered system: financially sustainable, operationally reliable, and consistently delivering value. At the same time, talented people should have the autonomy to explore, challenge assumptions, and create things no one could have planned in advance.
These ambitions are not contradictory. Well-defined interfaces allow independent components to evolve without breaking the larger system. Organizational primitives should do the same for people and teams.
The purpose of primitives is not to make people predictable. It is to make the organization predictable without making its people predictable.
We believe a company should be engineered with the same rigor as a great software system.
We don't engineer people. We engineer the system in which people work.
Just as poorly designed abstractions create complexity in software, poorly designed primitives create bureaucracy in organizations. We therefore establish a set of engineering principles for designing primitives themselves.
1. Opinionated by Default
Make deliberate choices about how we work. Strong defaults and explicit workflows eliminate unnecessary decisions.
2. Explicit and Actionable
Primitives should be immediately understandable and usable, with clear operations, responsibilities, and expected outcomes.
3. Minimal and Composable
Prefer a small set of reusable building blocks over complicated rules for every possible scenario.
4. Autonomy by Design
Standardize coordination, not creativity. Clear contracts and boundaries should enable independent judgment rather than require constant approval.
5. Observable and Resilient
Make failures visible and recovery systematic. Reliability should not depend on individual heroics.
6. Detailed in Specification, Lightweight in Execution
Precision should reduce operational overhead, not introduce bureaucracy.
7. Designed to Evolve
No primitive is permanent. Every primitive should be open to challenge, improvement, and replacement.
We manage our primitives in Git, just as we manage software.
Git gives our organizational operating system a single source of truth, explicit changes, review, version history, and traceability. We want to understand not only how the company operates today, but how and why it evolved to operate this way.
Every new primitive, modification, or deprecation goes through a Pull Request. The diff defines exactly what changes, the review catches conflicts and unintended consequences, and the commit preserves the decision in the company's history.
Merging a change updates the source of truth; putting it into practice may still require a rollout. The distinction matters: a primitive is only effective when it changes how people actually work.
Changing how the company operates should be as deliberate and traceable as changing its code.
An organization should not depend on its founders' memory to understand why things work the way they do. Its operating system should carry that knowledge forward.
We version our code so our systems can evolve. We version our primitives so our organization can, too.