The S.E.E. Manifesto
Software Engineering Economics: A Commercial Doctrine
We do not worship code. We respect capital.
The function of an Engineering department is not to build "cool tech" but to generate Free Cash Flow and protect Asset Value. Too many Boards are blind to the reality of their technical investment; they pour money into a black box and hope features come out.
Our mission is to help CEOs and Boards SEE tech clearly. We adhere to these six absolute truths…
I. Profit over Purity
Technology is an asset class not an art form. We reject architectural perfectionism unless it serves a direct commercial outcome. If a messy monolith makes money and a pristine microservice architecture burns cash, we choose the monolith (until the maintenance cost outweighs the rewrite cost).
The Rule: If we cannot explain and measure the P&L impact of a refactor, we don't seek the budget.
II. Code is a Liability, Not an Asset
Every line of code we ship is a promise of future maintenance. It is a debt instrument.
- Unshipped Code → Inventory (Cash tied up in Work-In-Progress).
- Shipped Code → Long-term Liability (Requires patching, hosting, securing).
The Rule: The most profitable code is the code we didn't have to write. We minimise inventory to maximise liquidity.
III. Boring is Valuable
Exit events rely on certainty, not novelty. "Bleeding Edge" infrastructure where boring standards exist is a liability that hurts reliability and depresses valuations. We restrict innovation to the "Secret Sauce" – the logic that generates revenue and builds moats.
The Rule: Innovation belongs in the product, not the plumbing. Stability expands the EBITDA multiple.
IV. Complexity is a Tax
Headcount does not scale linearly with output; cost scales quadratically with complexity. Adding more engineers to a chaotic codebase slows velocity (and destroys margins). It is the "Diminishing Returns" curve of software.
The Rule: We do not hire our way out of problems. We simplify our way out. We earn the right to hire by proving efficiency per head.
V. Outcomes over Outputs
They measure success by velocity (how fast they ship). We measure success by R.O.I. (how much value we capture). Shipping a feature that nobody uses is not "progress." It is waste.
The Rule: We measure impact in £, $, or %, never story points or “features shipped”.
VI. English is the Primary Language
We reject technobabble used to obscure lack of progress. If we cannot explain a delay without using words like "Kubernetes," "Refactor," or "Technical Debt," we do not understand the commercial problem.
The Rule: Radical transparency. The Boardroom is an English-speaking zone.