Engineering Doctrine
This document captures the professional principles that have emerged from thirty years of building systems, organizations, and people. It is intended to evolve continuously.
Why This Exists
Throughout my career, technologies have changed repeatedly:
- Enterprise UNIX
- Linux
- The Web
- Enterprise Data Warehousing
- Engineering Education
- Platform Engineering
- AI
What has remained constant is not the technology.
It is the core principles for how engineering connects and helps people solve problems, from societal to personal.
This document attempts to capture those enduring principles.
Core Belief
Technology by itself rarely transforms organizations.
Organizations transform when technology, process, economics, governance, and most importantly, people evolve together.
My work has always been about enabling that transition. Over the span of my career, the span of these transitions has certainly increased, but the clarity these principles give me has not.
Principle 1 — Build Systems, Not Components
Components solve today's problem.
Systems solve tomorrow's problems.
Whenever possible:
- create reusable capability
- reduce duplication
- improve leverage
- enable future work
Principle 2 — Reduce Friction Before Increasing Effort
Most organizations do not fail because engineers lack effort.
They fail because the system creates unnecessary friction.
Reduce friction first.
Examples include:
- better tooling
- common platforms
- improved traceability
- automation
- clearer ownership
- faster feedback
Principle 3 — Platform Is an Economic Strategy
Platforms are not technical artifacts.
They are financial assets.
The purpose of a platform is to reduce total cost while improving consistency, quality, security, and velocity across a portfolio.
Principle 4 — Governance Should Accelerate Engineering
Governance is often viewed as overhead.
I reject that view.
Good governance should:
- reduce uncertainty
- improve confidence
- shorten review cycles
- produce evidence continuously
The objective is deterministic engineering.
In my experience, this forms a type of litmus test. Engineering performance is often a reflection of the broader organizational governance.
Principle 5 — AI Amplifies Judgment, It Does Not Replace It
AI should increase:
- exploration
- learning
- documentation
- verification
- traceability
- consistency
Engineering judgment remains a human responsibility.
The highest value of AI is helping organizations learn faster while maintaining trust.
→ See also: AI Transformation in Regulated Development · Interpretable ML and Composite Kernels · AI — Artificial Intelligence
Principle 6 — Teach Through Mental Models
Facts expire.
Frameworks endure.
The goal is not to provide answers.
The goal is to help people reason better.
If someone leaves a conversation thinking differently, the conversation succeeded.
Principle 7 — Leadership Is Multiplication
My career began by building systems.
Its next chapter is about building organizations capable of building systems.
The measure of success becomes:
How many people became more capable because they worked together?
Principle 8 — Truth Matters
Accuracy matters.
Evidence matters.
Opinions should yield to better evidence.
Engineering depends upon intellectual honesty.
Correctness should never become an excuse for disrespect.
Principle 9 — Preserve History, Don't Live In It
Past accomplishments are evidence.
They are not identity.
Historical work should be preserved because it informs future thinking—not because it deserves admiration.
Principle 10 — Leave Doctrine Behind
Software will be replaced.
Architectures will evolve.
Organizations will reorganize.
The most durable contribution is a way of thinking that enables others to continue improving after I am gone.
Principle 11 — Beyond the Prototype
Building creates progress, certainty, and control.
Leadership often creates ambiguity.
At senior levels, the harder work is rarely the next artifact. It is:
- communicating doctrine
- creating alignment
- developing leaders
- establishing ownership
- changing organizations
The builder's instinct remains valuable.
The leader's responsibility is to aim it at capability others can sustain.
Related: Pattern 6 — Builders Avoid Ambiguity by Building
Principle 12 — Process Should Enable Judgment, Not Replace It
Process can be a powerful enabler.
Unfortunately, it can also be a crutch — allowing teams to retreat from hard decisions while appearing disciplined.
Highly functional organizations use process to:
- clarify goals for safety, reliability, and quality
- reduce interpersonal drama by making expectations explicit
- ground decisions in data, metrics, and feedback
- improve continuously as conditions change
The engineer's responsibility is to use process to produce evidence and reduce friction — not to hide behind it.
The manager's responsibility is to ensure process does not become a reason for paralysis.
The leader's responsibility is to change process when the landscape demands it — and to ensure delivery does not wait for perfect certainty.
→ See also: Platform Strategy in Regulated Environments · Principle 4 — Governance Should Accelerate Engineering · Principle 11 — Beyond the Prototype
A Working Definition of Success
Success is leaving an organization more capable than it was when I arrived.
Not because of the software I wrote.
But because the people, systems, and ideas continue improving after I leave.
This doctrine is intentionally unfinished.
Like engineering itself, it should continue to evolve.