On a tour of Hoover Dam, I noticed a small plaque on one of the generators that said “Proudly Maintained By Mike E.” It has been living in my head as a systems principle ever since.
This page is a Doctrine Guide. It shows how to apply one principle from the Doctrine in real systems and real constraints. Use it as a reference when you are making decisions, designing workflows, or repairing things that broke under pressure.
The plaque that explained the whole system
Hoover Dam is an easy place to feel small.
You can talk about installed capacity and concrete pours and transmission lines. You can stand on the edge, look down at the Colorado, and think big thoughts about infrastructure.
The view from the bottom. Standing in the non-public maintenance zone at Hoover Dam. From this angle, you feel the true weight of the infrastructure. It reminds you that “System Reliability” isn’t an abstract concept; it is millions of tons of concrete and steel that rely on specific individuals to keep running.
What stopped me in my tracks was not the scale. It was a plaque.
On one of the generators, there was a small, simple sign:
Proudly Maintained By Mike E.
This image illustrates infrastructure spanning a canyon, highlighting connectivity amid rugged terrain and integration with natural features.
That was it.
No long mission statement. No wall of logos. Just one human name attached to a critical piece of machinery.
In that moment, the whole system snapped into focus.
Named stewards, not faceless owners
Ownership by Type: Don’t guess who decides. Map the type of decision (e.g., “Annotate stale data”) to the owner (Operator). Clarity removes drag. Owning the Truth: Golden Datasets (among others) require explicit ownership at the right altitude. Architects own the Schema (Altitude 3). Managers own the Data Quality (Altitude 2). Operators own the Updates (Altitude 1). Named Ownership: A committee cannot own a decision. A matrix assigns specific types of decisions to specific roles (Operator, Manager, Architect). This is the administrative version of the Mike E. plaque.
You can design systems so that responsibility is:
Spread thinly across committees, or
Held concretely by someone who can point to a thing and say, “That is mine.”
The generator with the plaque was not just “Unit Whatever in the asset inventory.” It was, very clearly:
Someone’s craft.
Someone’s pride.
Someone’s career and reputation.
When that unit spun up, you could imagine Mike E hearing it and knowing, in his bones, how it should sound.
That is a very different signal than “Operations is responsible” or “The team owns it.”
Why that plaque felt dangerous in a good way
Systems people like to talk about “single points of failure.”
If you name a person on a plaque, is that not a single point of failure?
Sometimes, yes.
Sometimes that is also the point.
When you give someone visible, personal ownership, you are doing a few things at once:
You are trusting them enough to attach their name to outcomes.
You are making it easy to know who to talk to when something is off.
You are quietly raising the standard from “meets spec” to “I am proud to sign this.”
There is risk in that.
There is also risk in pretending that a committee will care in the same way.
Pride is a control measure
The Snapback Effect: Mandates (Top) create forced behavior that reverts as soon as attention shifts. Commitment (Bottom) creates sustained behavior driven by belief. Pride vs. Compliance: Compliance (Top Path) only prevents failure while you are watching. Pride/Commitment (Bottom Path) drives sustained care even when no one is looking. Mike E. lives on the bottom path.
In most formal systems, the control measures are:
Policy and procedure.
Checklists and inspections.
Compliance audits.
All useful. None of them quite equal what happens when someone’s pride is on the line.
Imagine two versions of the same generator:
It is Asset ID 12345 in a spreadsheet that ten people are technically responsible for.
It has a small plaque that says “Proudly Maintained By Mike E.”
In which scenario do you think someone is more likely to:
Hear a weird noise and come in on a weekend.
Spend a little extra time on a repair so it is not just “good enough.”
Speak up if they see a pattern that does not look right.
Pride is not a substitute for engineering practice or safety doctrine. It is a multiplier.
When you align it with good systems and checks, it becomes one of the strongest risk controls you have.
The invisible plaque problem in digital work
Role Clarity: The Leader owns the Frame (Objective). The Member owns the Content (How). Distributed decisions work when this split is respected. Defining Responsibilities: A contract fails if roles are fuzzy. This simple split, the Lead owns the Frame, the Member owns the Content, is the building block of a good agreement. Signing the Work: In digital systems, we replace the plaque with the “Human Contract.” Named owners on both sides of the interface ensure that someone is actually listening for the noise.
In digital systems, the plaques are mostly invisible.
We have:
Services, microservices and “products.”
Tickets, queues and backlogs.
Teams and guilds and chapters.
What we often do not have is a clean answer to:
“Who is proud to put their name on this?”
Instead we get:
“The team owns it.”
“Operations handles that.”
“That is a shared responsibility.”
Which usually means:
Nobody quite feels it as theirs.
Problems get bounced instead of owned.
The people who actually care burn out while everyone else hides behind structure.
The Hoover Dam plaque is a quiet rebuke to that.
It says:
“You can do complex, safety-critical work and still have someone willing to step up and say, ‘I will own this and be proud of it.’”
Linking this back to doctrine
The Leadership Target: A Leader’s job isn’t just to be “Nice” (Green) or “Bossy” (Orange). It is to maintain High Harmony while using Precise Authority (Blue) to set direction. Human contracts move teams out of “Stalemate” (Grey) and “Compliance” (Orange) into the “Healthy Project Space” (Blue), where trust and authority are balanced.
Crucially, leadership must be a net gain. If the team is just as effective without you as with you, you are not leading; you are overhead.
This hits hard because it gives the reader (or a practitioner) a diagnostic they can apply immediately: “Does my presence make the team faster or just more managed?” The Healthy Project Space: “Mike E.” represents the top-right quadrant: High Trust + Clear Authority. He has the authority to maintain the unit and the trust to do it right.
When I talk about doctrine like:
Named stewards, not committees
Guardrails over heroics
Commitment over compliance
I am not talking about vibes.
I am talking about choices like:
Do we attach named ownership to this system, or do we hide behind a team name.
Do we design roles so that people can take pride in what they own, or so that everyone has plausible deniability.
Do we create enough slack and guardrails so that people like “Mike E.” are supported, or do we rely on their pride to carry the whole system while we under-resource it.
The Hoover Dam plaque is the picture I carry around when I think about that.
How this connects to my work now
A lot of my current work is about:
Making invisible systems visible.
Identifying who actually owns what.
Designing structures where responsibility is clear and realistic.
Whether it is:
A federal portfolio that spans agencies.
A NATO or alliance context where different nations own different pieces.
A small business where one person wears six hats.
The questions are the same:
Who is the “Mike E.” for this system.
Do they know it.
Do they have the tools, guardrails and authority to do their job.
Or are we just counting on them to care while the system quietly erodes around them.
If you can look at a critical system and cannot think of a single person who would be comfortable with a plaque that says “Proudly Maintained By [Their Name],” you do not just have a culture problem.
You have a risk problem.
And it will show up first where you have the least slack to absorb it.
