The Geometry of Organizations

There are endless frameworks out there for expressing the essentials of an organization: what it is for, and how it proposes to do business. Such frameworks use terms like purpose, and principles, and values, typically without really defining what those words mean or how they are intended to operate.

The point of using such terms—whatever they mean—is to help an organization make good decisions, and refrain from making bad ones. Together they constitute a loose, somewhat hand-wavy instance of what in mathematics would be called a formal system.

One very broadly-known formal system is Euclidean Geometry. Consider this simple Euclidean proof. It has 3 parts:

  • The proposition is the statement one wishes to prove. In business, this is analogous to a decision one proposes to make, or a policy one proposes to enforce. For example: The team is small and the client is in a hurry, so the client wishes to proceed directly to production without formal testing.
  • Axioms are fundamental assumptions: they are held to be true without proof. In business, these are principles. They are the starting point for every decision. For example: Good design validates itself.
  • Rules of inference are the paths one is allowed to take between steps in a proof, or a thought process. An example from geometry: If P implies Q, and P is true, then Q is true. In business, rules of inference are encapsulated in values. If a step expresses some core value, it is allowed. If the opposite, then not. Examples: economy, agility (each of which should be well-defined).

In the example above, the client desires velocity at the expense of quality, a trade-off that may not be acceptable to both sides (or even achievable in practice). The challenge is to use this framework to come up with a path that both sides can accept.

The solution in the real world was this: a design may express tests that have not yet found their way into the current implementation. We therefore proposed to evolve a design that expressed appropriate test points, but to prioritize only the most essential tests for immediate implementation and to leave the rest explicitly as tech debt. This got the client into production as rapidly as possible while ensuring acceptable quality from the outset and providing a clear path to higher quality in the future. Values expressed: economy, agility.

What about purpose? This is quite literally a description of what the organization is for. We used values above to determine whether a proposed step was an allowable expression of first principles. We use purpose to determine whether we should even be having the conversation.

A high degree of formalism in such things is a value unto itself: many organizations will have neither the skill set nor the stomach to implement it. But for those that can, this formalism produces a framework that can slash ambiguity and clarify the context around even the most difficult decisions. 

Tell me why I'm full of shit!