Engineering Philosophy
Standards describe how we work. This describes why.
The thesis is simple. Companies compound through people. Engineers who are trusted, taught, and held to a clear standard become engineers who can take on any problem, including ones they have never seen. Teams of those engineers ship faster, break less, and recover sooner. That is how engineering becomes a source of enterprise value instead of a cost center.
Grow the person. Grow the team. Grow the company.
1. Failures belong to the system
When something breaks, we ask what made the failure possible, not who made it. A reasonable person, acting on the information and tools they had, should not be able to take a product down. When they can, the system has a gap, and closing it is the team's work.
Blame teaches people to hide problems. Safety teaches them to surface problems early, when they are cheap. Every incident ends with a blameless review, a fix to the system, and a lesson shared across the team.
Blameless is not consequence-free. Accountability means owning the fix, the follow-through, and the lesson. We hold high standards and give high support, and neither works without the other.
What this protects: speed of detection, honesty of reporting, and the willingness of engineers to take on hard work.
2. We build engineers who can solve what they have never seen
Anyone can follow instructions for a familiar problem. The engineers who move a company forward reason from first principles when there are no instructions. We develop that deliberately: real ownership, stretch work with support behind it, design reviews that teach rather than judge, and mentoring as part of every senior role.
We measure leaders by the growth of the people around them.
What this protects: a team that scales with the company, and leadership depth that does not depend on any one person.
3. Clarity is a leadership duty
Every engineer should be able to answer three questions: what matters most right now, why, and who decides. Unclear priorities waste more engineering capacity than any technical problem. Leaders owe the team clear goals, clear roles, and decisions made at the right level, written down where everyone can find them.
What this protects: focus. Teams that know the priority stop paying for context switches, rework, and shifting direction.
4. Evidence over opinion
Decisions rest on data from the system, the users, and the business, not on rank or volume. Tradeoffs are written down with the evidence behind them, so the reasoning outlives the meeting. When the evidence changes, the decision changes.
What this protects: capital. Every major technical decision is an investment, and opinions are an expensive way to allocate it.
5. Standards are enforced by systems, not memory
A rule that lives only in a document gets followed once and forgotten. Our standards are checked automatically on every change: security, accessibility, tests, build, and dependencies. People are free to focus on judgment, because the baseline is guaranteed.
Quality is not the opposite of speed. Rework, outages, and lost trust are what slow companies down.
What this protects: delivery speed that holds as the team and the codebase grow.
6. Tell the truth, in writing
Documentation describes what the product does today. Metrics come from real measurement. Risks are stated plainly, to the team, to leadership, to clients, and to the board. A reader who finds one overstated claim stops trusting every accurate one.
What this protects: credibility in due diligence, with customers, and with investors. Trust takes years to build and one discovered exaggeration to lose.
7. Build ownership, not dependency
The measure of good technical leadership is how well the team runs without it. We document decisions, automate standards, and teach the reasoning behind them, so knowledge belongs to the organization rather than to individuals.
What this protects: continuity through growth, turnover, acquisition, and leadership change.
8. AI is accountable like any other system
AI amplifies whatever system it lands in. On strong foundations it accelerates delivery; on weak ones it multiplies the problems. So the foundations come first: small changes, automated quality gates, and a clear, written stance on which AI tools are used and how.
Every AI feature has an owner, measured quality, rules it cannot break enforced in code, known costs, and a human path for high-stakes decisions. AI-written code meets the same review and the same standards as any other code.
What this protects: the upside of AI without unmeasured risk to customers, data, or reputation.
How we know it is working
Principles that cannot be measured are slogans. We track:
| Area | Measures |
|---|---|
| Delivery | Deployment frequency, lead time from commit to production, change failure rate, recovery time from failed deployments, and rework rate (the DORA metrics) |
| Quality | Escaped defects, incident count and severity, accessibility and security findings open |
| People | Retention, internal promotions, time for a new engineer to ship to production, developer experience, and signs of burnout |
| Business | Engineering cost relative to revenue, roadmap commitments met, cost per unit of product usage |
These are reviewed with leadership quarterly and reported to the board in plain language: what improved, what did not, and what we are doing about it.
Metrics measure the system, never the individual. Delivery metrics are never used to rate or rank engineers. A measure used to judge people stops measuring anything, because people optimize the number instead of the outcome, and it destroys the safety the first principle depends on.
Research foundation
These principles follow the evidence.
- Psychological safety comes first. Google's Project Aristotle studied 180 teams over two years and found psychological safety to be the most important of five dynamics that set its most effective teams apart, ahead of individual talent, seniority, and team size. The other four were dependability, structure and clarity, meaning, and impact. Principles 1, 2, and 3 put these into practice.
- Culture predicts performance. DORA's multi-year research on software delivery has consistently found that high-trust, learning-oriented cultures predict both software delivery performance and organizational performance.
- AI amplifies foundations. DORA's 2025 research found AI acts as an amplifier: it accelerates teams with strong practices and magnifies the problems of teams without them. It also found AI tends to increase change size, which DORA has long linked to risk, and that a clear organizational stance on AI matters. Principle 8 reflects this.
- Small batches and fast feedback. DORA's research links small, frequent changes, automated testing, and continuous integration to both speed and stability. Principle 5 reflects this.