SolveFor42
The 42 PrinciplesInstitutional Practice

The 42 Principles

A practical book about how we think, solve problems, lead people, build trust, learn, teach, recover from failure, understand systems, and leave people and institutions better than we found them.

Version
1.0
Status
published

Version 1.0

Principle I — Stay Curious

Foundational Truth

The world should never be accepted merely because it is.

Everything worthy of improvement begins by asking why.

Why It Matters

Curiosity is the beginning of every meaningful advancement humanity has ever made.

Every scientific discovery.

Every engineering breakthrough.

Every medical innovation.

Every great work of philosophy.

Every civilization that chose progress over stagnation.

Each began because someone looked at the world and refused to believe that the current state was the only possible state.

The easiest thing in life is acceptance.

“This is how we’ve always done it.”

“That’s just the way it works.”

“It can’t be changed.”

History is filled with ideas once believed to be permanent.

Curiosity is what prevented them from remaining so.

Without curiosity we stop learning.

When we stop learning, we stop improving.

When we stop improving, we slowly surrender one of the defining characteristics of being human.

Curiosity is not merely an engineering skill.

It is a way of seeing the world.

It is the quiet refusal to believe our understanding is ever complete.

In Practice

A curious practitioner:

  • Questions inherited assumptions before accepting them.
  • Seeks evidence before forming conclusions.
  • Looks for evidence that disproves a belief, not only evidence that confirms it.
  • Revisits decisions when circumstances change.
  • Asks “Why?” until the real problem becomes visible.
  • Is willing to abandon a favorite idea when a better one is found.
  • Finds joy in learning something that was unknown yesterday.

Failure Modes

Curiosity without discipline becomes distraction.

Questioning everything forever becomes paralysis.

Likewise, accepting the first plausible explanation creates false confidence.

Good judgment knows when enough evidence exists to move forward while remaining willing to change course when better evidence appears.

Curiosity should delay certainty.

It should never delay progress indefinitely.

Questions to Ask Yourself

  • What assumptions am I making?
  • What evidence would change my mind?
  • What am I treating as fact that is actually inference?
  • What question has nobody asked yet?
  • If I were approaching this problem for the first time today, would I solve it the same way?
  • What am I afraid I might discover?

Closing Thought

The world does not improve because people accept it.

It improves because someone becomes curious enough to question it.

Principle II — Ask One More Question

Foundational Truth

The question that feels too simple, too obvious, or too late to ask may be the one that changes everything.

Understanding requires more than curiosity. It requires the courage to risk being seen as the person who does not yet understand.

Why It Matters

People rarely remain silent because they have no questions.

They remain silent because they fear what the question might cost them.

They fear appearing inexperienced.

They fear interrupting the room.

They fear exposing something they believe everyone else already understands.

They fear that asking may weaken their reputation.

So they assume.

They interpret.

They build explanations around incomplete information.

They overthink what could have been resolved with a single honest question.

That is how drift begins.

A small misunderstanding becomes an incorrect assumption. The assumption influences a decision. The decision shapes every action that follows. By the time the error becomes visible, an entire solution may have been built in the wrong direction.

The smallest missing detail can dramatically change an outcome.

A date.

A unit of measurement.

A definition.

A forgotten dependency.

A different understanding of what success means.

One more question can expose it before the consequences become expensive.

The Courage to Appear Uncertain

Asking a simple question requires a particular kind of confidence.

It means valuing the truth more than the appearance of already knowing it.

The conforming side of the room is often quiet. People nod because others are nodding. They accept the premise because no one else has challenged it. Each person mistakes the silence of the group for shared understanding.

Then someone asks:

“Are we certain that is what they meant?”

The room pauses.

The assumption becomes visible.

The conversation changes.

That person may briefly risk appearing uninformed. In reality, they may be the only person protecting the room from its collective certainty.

The willingness to look uninformed for a moment may prevent everyone from remaining wrong for much longer.

The Wisdom of Not Knowing

More than two thousand years ago, Socrates confronted the same tension.

According to Plato’s Apology, the Oracle at Delphi declared that no one was wiser than Socrates. Socrates found this difficult to believe because he did not consider himself wise. He began questioning people who were widely regarded as knowledgeable and discovered a recurring pattern: they often believed they understood things they did not.

Socrates eventually concluded that he possessed only one small advantage.

He did not believe that he knew what he did not know.

His wisdom was not an abundance of answers.

It was an honest recognition of the limits of his understanding.

That lesson remains unchanged.

The person willing to ask the simple question is not necessarily the least informed person in the room.

They may be the only one wise enough to recognize that something is still unknown.

Wisdom does not begin when we have every answer.

It begins when we stop pretending that we do.

In Practice

Ask the question when:

  • A word could have more than one meaning.
  • Everyone appears to agree unusually quickly.
  • A decision depends on an assumption no one has verified.
  • The explanation is becoming more complicated than the problem.
  • You understand most of the discussion, but one small detail remains unclear.
  • The stated problem does not match the observed outcome.
  • You suspect others may be silent for the same reason you are.
  • The answer seems obvious, but the consequences of being wrong are significant.

The question does not need to be impressive.

It needs to be honest.

Sometimes the most useful contribution in the room is:

“Can we go back one step?”

“What do we mean by that?”

“How do we know?”

“What are we assuming?”

“Did we verify the simple thing first?”

Failure Modes

Asking one more question does not mean questioning forever.

Questions can become a way to postpone responsibility, avoid decisions, display intelligence, or challenge others without contributing anything useful.

Contrarianism is not curiosity.

A person who opposes every conclusion is no more thoughtful than a person who accepts every conclusion.

The purpose of the question is not to prove that the room is wrong.

It is to ensure that the room understands why it believes it is right.

Once the necessary understanding exists, judgment requires movement.

Questions to Ask Yourself

  • What am I assuming because I am afraid to ask?
  • Am I silent because I understand, or because everyone else appears to?
  • What small detail could change the entire outcome?
  • Has the room agreed, or has the room merely stopped questioning?
  • Am I making the problem more complicated than it is?
  • What would I ask if my reputation were not at risk?
  • Is there one more question that deserves to be spoken aloud?

Closing Thought

Never trade understanding for the appearance of understanding.

Ask one more question.

Principle III — Understand Before Optimizing

Foundational Truth

Do not improve what you do not yet understand.

Before changing a system, learn how it works, what constrains it, and where the actual problem lives.

The Wisdom of Simplicity

Like my grandmother always said:

“If it ain’t broke, don’t fix it.”

It is timeless advice.

But wisdom requires asking one more question.

What is actually broken?

People often mistake symptoms for problems.

They mistake inconvenience for failure.

They mistake age for inefficiency.

They mistake unfamiliarity for something needing improvement.

The true work is not fixing everything that appears imperfect.

The true work is discovering what is genuinely broken, what merely appears broken, and what should be left alone.

Only then can meaningful improvement begin.

Why It Matters

When people see a problem, they often feel pressure to act immediately.

The system is slow.

The process is failing.

The result is poor.

Something must be changed.

That urgency can create the illusion that action itself is progress.

But action without understanding is often only disturbance.

You do not begin building a house with the roof.

You do not look at an empty lot and dig a hole where you imagine a pipe might eventually belong.

You first study the ground.

You learn the soil.

You measure the lot.

You understand its boundaries.

You design the house inside the reality that already exists.

Only then do you begin to build.

This is not excessive caution.

It is the recognition that every solution rests on assumptions, and assumptions become expensive when they are buried beneath completed work.

Preparation feels slower at the beginning because its value has not yet become visible.

Its value appears later, when work does not have to be torn apart and done again.

Understanding is the work that prevents the work from having to be repeated.

Find the Problem Before Choosing the Solution

A slow database does not automatically need faster hardware.

More processing power may make an inefficient system perform inefficient work more quickly, but it does not correct the reason the work is inefficient.

The real problem may be elsewhere:

  • The data may be poorly normalized.
  • A query plan may be taking an unnecessary path.
  • A useful index may be missing.
  • An existing index may be ignored.
  • A join may use the wrong column.
  • The application may be retrieving far more data than it needs.
  • The design may be forcing the database to repeat avoidable work.

The symptom is slowness.

The cause is not yet known.

Treating the symptom before understanding the cause may produce a temporary improvement, but it also preserves the defect.

The same is true of a network.

When an application feels slow, it is easy to blame bandwidth.

But the network may be functioning correctly.

The delay may exist in the application, the database, name resolution, authentication, storage, or a dependency several systems away.

Buying more bandwidth does not make a slow application faster when bandwidth was never the constraint.

A visible symptom tells you where the pain appears. It does not always tell you where the problem begins.

Optimization Is a Conclusion

Optimization should not be the first instinct.

It should be the conclusion reached after observation, measurement, and understanding.

Before changing anything, ask:

  • What is the system supposed to do?
  • What is it actually doing?
  • Where does time, effort, or capacity accumulate?
  • What evidence identifies the constraint?
  • Which part of the system is doing unnecessary work?
  • What tradeoff will the proposed change introduce?
  • How will we know the change improved the right thing?

Without those answers, optimization becomes guesswork.

Sometimes the guess succeeds.

That does not make the method sound.

A lucky intervention can be more dangerous than an obvious failure because it teaches confidence without understanding.

The Temptation of the Obvious Fix

Obvious fixes are attractive because they are easy to explain.

The server is slow, so buy a larger server.

The network is slow, so buy more bandwidth.

The team is behind, so add more people.

The process is inconsistent, so add more steps.

The house needs to be built, so begin digging.

Each response may feel decisive.

Each may also deepen the problem.

More hardware can conceal poor design.

More bandwidth can hide application latency.

More people can increase coordination costs.

More process can create more friction.

More construction can make the eventual correction more expensive.

A solution should not be selected because it is available, familiar, or visible.

It should be selected because the evidence shows that it addresses the actual constraint.

In Practice

Before optimizing:

  • Establish the intended outcome.
  • Observe the current behavior.
  • Measure before changing.
  • Separate symptoms from causes.
  • Identify the real constraint.
  • Understand the dependencies.
  • Test the simplest plausible explanation.
  • Confirm that the proposed solution acts on the cause.
  • Define how success will be measured.
  • Change one meaningful variable at a time when possible.

Do not begin with:

“What should we buy?”

Begin with:

“What is actually happening?”

Do not ask first:

“How do we make it faster?”

Ask:

“Where is the time going?”

Do not assume:

“This component is the problem.”

Ask:

“What evidence points here?”

Failure Modes

Understanding before optimizing does not mean waiting until everything is known.

Complete understanding is rarely possible.

A person can use analysis as a shelter from action, continually requesting more information because making a decision carries risk.

That is not discipline.

It is avoidance.

The goal is not perfect knowledge.

The goal is sufficient understanding to make a responsible change.

There is also danger in becoming attached to a diagnosis.

Once people have invested time in studying a problem, they may resist evidence that contradicts their conclusion.

Understanding must remain provisional.

New evidence should be allowed to change the model.

Optimization is not a single act.

It is a cycle:

Observe.
Understand.
Change.
Measure.
Learn.

Questions to Ask Yourself

  • Am I solving the cause, or reacting to the symptom?
  • What evidence identifies the actual constraint?
  • What am I assuming about how this system works?
  • Have I measured the problem, or merely noticed it?
  • Is the proposed solution addressing wasted work or only adding capacity?
  • What might become worse if this change succeeds?
  • How will I know whether the optimization worked?
  • Am I preparing carefully, or hiding from the decision?
  • What is genuinely broken?
  • What merely appears broken?
  • What should be left alone?

Closing Thought

The true work is not fixing things.

The true work is discovering what is actually broken.

Understand first.

Then improve.

Principle IV — Challenge Your Assumptions

Foundational Truth

Every assumption is a shortcut.

Some shortcuts save time.

Some shortcuts hide the truth.

Wisdom increases the likelihood that your assumptions are correct.

It never removes the need to verify them.

The Expert’s Advantage… and Trap

Experience changes the way we solve problems.

A beginner examines everything.

An expert recognizes patterns.

Pattern recognition is one of experience’s greatest gifts.

It allows us to eliminate unlikely possibilities and focus on what history suggests is most likely.

Most of the time, those instincts are right.

But every shortcut carries risk.

The confidence earned through experience can quietly become certainty.

And certainty stops looking.

The moment we stop looking, we begin treating assumptions as facts.

What We Think We Know

When solving a problem, it is easy to think:

“I know this database.”

“I know this application.”

“I know this network.”

“I know this vendor.”

“I know how this works.”

Perhaps.

But you probably did not write every line of code.

You did not build every deployment.

You have not inspected every configuration.

You have not witnessed every decision that shaped the system.

You know how you would have built it.

That does not mean it was built that way.

Reality has no obligation to match your expectations.

The Cost of Certainty

I know this lesson personally.

Once I convince myself that the answer is X…

It takes real effort to convince me otherwise.

I do not believe I am unique.

We are all wired this way.

Once our minds assemble a coherent explanation, we naturally begin collecting evidence that supports it.

Evidence that disagrees becomes uncomfortable.

Sometimes we dismiss it.

Sometimes we explain it away.

Sometimes we never even look for it.

Assumptions become expensive not because they are always wrong.

They become expensive because once we believe them, we stop testing them.

Verify the Things You “Know”

Sometimes the most valuable thirty minutes of an investigation are spent proving yourself wrong.

Check the area you are convinced cannot be the problem.

Verify the dependency you are certain is functioning.

Read the configuration you believe you already understand.

Trace the path you know could not possibly fail.

Most of the time, your instincts will be correct.

The few times they are not, those thirty minutes may save days of frustration chasing a dead end created by your own certainty.

Verification is rarely wasted effort.

It is the discipline that keeps confidence from becoming arrogance.

In Practice

Before accepting an assumption, ask:

  • What evidence supports this belief?
  • What evidence would disprove it?
  • Have I verified the obvious?
  • Am I relying on experience instead of observation?
  • What part of this system have I never actually inspected?
  • If someone else built this, what might they have done differently?
  • Am I treating a belief as though it were a fact?

Look before you leap to the conclusion.

Your future self will thank you.

Failure Modes

Challenging assumptions does not mean distrusting everything.

Without assumptions, we would never make progress.

Experience exists to help us make informed judgments quickly.

The goal is not to eliminate assumptions.

The goal is to recognize them.

A good assumption accelerates investigation.

A bad assumption silently controls it.

Likewise, endlessly questioning every belief becomes paralysis.

There comes a point where evidence is sufficient and action must begin.

Wisdom lies in knowing which assumptions deserve verification and which have already earned confidence.

Questions to Ask Yourself

  • What am I assuming right now?
  • How do I know this is true?
  • What evidence would change my mind?
  • Am I defending my conclusion or investigating reality?
  • Have I confused familiarity with understanding?
  • What have I not actually verified?
  • If I were wrong, where would I discover it first?

Closing Thought

The most dangerous assumption is the one you no longer recognize as an assumption.

Remain curious.

Remain humble.

Verify what you believe.

Principle V — Learn Continuously

Foundational Truth

Learning is not something reserved for school, work, or moments of instruction.

It is a way of remaining alive to the world.

Every experience contains something to examine.

Every mistake contains something to recover.

Every quiet moment contains something to discover.

Learning as a Way of Life

Some people fear boredom.

Others fear loneliness.

I have difficulty relating to either.

When the world becomes quiet, my mind does not become empty.

It begins to learn.

I can sit alone in a dark room and revisit the events of the day.

I can consider why something happened.

I can examine the relationship between cause and effect.

I can question whether something worked as intended or merely appeared to work.

I can replay a decision and ask why its outcome differed from what I expected.

Silence does not remove the world.

It creates room to study it.

A quiet mind does not have to be an empty mind.

Nothing Is Wasted When It Teaches You

Not every choice produces the result we wanted.

Not every conversation goes as planned.

Not every effort succeeds.

Not every belief survives contact with reality.

But an unwanted outcome does not have to become a wasted one.

A mistake can become instruction.

A disappointment can expose an expectation.

A failure can reveal a weakness in judgment, preparation, timing, or understanding.

Even success deserves examination.

A good result may have come from skill.

It may also have come from timing, luck, favorable conditions, or help we failed to notice.

Continuous learning asks more than:

“Did this work?”

It asks:

“Why did it work?”

“Why did it fail?”

“What did I misunderstand?”

“What should I carry forward?”

The purpose is not to relive every moment endlessly.

It is to refuse to leave its lesson behind.

Learning Does Not Require an Audience

Learning is often treated as something delivered by another person.

A teacher explains.

A book instructs.

A speaker presents.

A course provides structure.

All of these are valuable.

None of them is required.

You can learn by observing.

You can learn by remembering.

You can learn by comparing what happened with what you expected to happen.

You can learn by imagining how something works and then testing whether your model matches reality.

You can learn by attempting to explain a difficult idea clearly enough that another person could understand it.

Teaching often exposes the boundaries of our own knowledge.

The sentence we cannot explain may reveal the idea we do not yet understand.

Seek What You Have Not Heard Before

Familiar things can be comforting.

There is nothing wrong with comfort.

But comfort and discovery are not the same experience.

I rarely listen to music the way many others do.

A familiar song gives them something they already know and love.

I am more often drawn toward science, history, ideas, current events, and conversations that may contain something I have never encountered before.

I want the next sentence to surprise me.

I want to discover a mechanism I did not understand.

I want to hear an explanation that changes the shape of something I thought I already knew.

The point is not that one form of listening is superior to another.

The point is to understand what nourishes you.

Some people seek familiarity.

I seek discovery.

Learning is how I keep the world from becoming smaller.

Learn From Yourself

One of the most valuable subjects you will ever study is your own mind.

Why did you make that choice?

Why did a particular comment anger you?

Why did you ignore evidence that now seems obvious?

Why did you succeed under one condition and struggle under another?

Why were you able to explain an idea clearly today when yesterday you could not?

Self-examination is not self-punishment.

The purpose is not to prosecute your past decisions with knowledge you gained afterward.

It is to understand how you reached them.

The person you were made the best choice they could see at the time.

The person you are now has the responsibility to see more next time.

The Discipline of Reflection

Experience alone does not guarantee growth.

A person can repeat the same year many times and call it a lifetime.

Learning requires reflection.

Without reflection, events pass through us without changing us.

With reflection, even an ordinary day becomes material for growth.

Ask:

  • What happened?
  • What did I expect to happen?
  • Where did reality differ from expectation?
  • What assumption shaped my response?
  • What did I notice too late?
  • What would I explain differently now?
  • What will I recognize sooner next time?

Continuous learning does not demand that every moment become a lesson while it is happening.

Sometimes life should simply be lived.

But afterward, when the noise settles, reflection can reveal what the moment contained.

The Desire to Share Understanding

Learning does not end when an idea enters your mind.

Sometimes the final stage is finding a way to give it to someone else.

Even while trying to sleep, I find myself searching for better ways to explain difficult concepts.

I imagine analogies.

I remove unnecessary complexity.

I search for the sentence that allows another person to see what I see.

This is not only teaching.

It is a desire for connection.

The things that excite us can become lonely when we have no language for sharing them.

Learning how to explain an idea creates the possibility that someone else may enter the conversation.

Understanding gives knowledge depth.

Explanation gives it reach.

In Practice

Learn continuously by:

  • Remaining attentive during ordinary experiences.
  • Revisiting decisions whose outcomes surprised you.
  • Studying causes rather than remembering only results.
  • Seeking unfamiliar ideas alongside familiar comforts.
  • Comparing expectations with reality.
  • Explaining what you believe you understand.
  • Listening for evidence that challenges your current model.
  • Recording lessons before time erases their details.
  • Asking what each failure revealed.
  • Asking what each success may be hiding.
  • Allowing new understanding to change old conclusions.

Learning does not always look productive from the outside.

It may look like reading.

Listening.

Observing.

Walking.

Remembering.

Imagining.

Questioning.

Sitting quietly in a dark room.

The form matters less than the attention.

Failure Modes

Continuous learning does not mean consuming information without rest.

More input does not always produce more understanding.

A person can read endlessly, listen constantly, and collect facts without allowing any of them to mature into wisdom.

Learning requires time for integration.

Silence matters.

Rest matters.

Experience matters.

There is also a danger in treating every activity only as an opportunity for improvement.

Not every conversation must be analyzed.

Not every hobby must become productive.

Not every moment of joy requires an explanation.

A life spent continually evaluating itself may forget how to experience itself.

Continuous learning should deepen life, not prevent us from living it.

Nor should learning become a substitute for action.

Eventually, an idea must be tested.

A lesson must influence a decision.

Knowledge that never enters life remains incomplete.

Questions to Ask Yourself

  • What did today teach me?
  • Where did reality differ from my expectations?
  • What mistake am I in danger of repeating?
  • What success have I not examined closely enough?
  • What have I recently learned that changed my mind?
  • Am I seeking knowledge or merely consuming information?
  • Can I explain this clearly to another person?
  • Am I allowing time for what I learn to become understanding?
  • What unfamiliar idea have I encountered lately?
  • Has learning changed how I live?

Closing Thought

Learning is not preparation for life.

Learning is one of the ways life remains alive.

As long as there is something left to notice, question, understand, reconsider, or explain, there is still more life to live.

As long as I am learning, I am fully alive.

Principle VI — Observe Deeply

Foundational Truth

Observation is the opposite of assumption.

Assumption replaces reality with expectation.

Observation returns our attention to what is actually happening.

Do not merely watch for the result.

Study the path that produced it.

Seeing Is Not the Same as Observing

It is possible to watch an entire process without truly seeing it.

A file is uploaded.

A pipeline begins.

A table is queried.

The data appears.

The test passes.

From the outside, the process seems understood.

We saw where it started.

We saw where it finished.

We confirmed that the expected result appeared.

But we may know almost nothing about what happened between those two points.

How was the schema interpreted?

How were the data types selected?

What transformations occurred?

What temporary structures were created?

What defaults were applied?

What errors were ignored?

What assumptions were made by the system on our behalf?

Ordinary observation confirms an outcome.

Deep observation reveals the mechanism.

The beginning and the end tell you that something happened. The middle tells you how.

Observation Begins When Certainty Becomes Insufficient

When a system appears to work, there is rarely a reason to inspect every internal detail.

Nor should there be.

No one can study everything at maximum depth all the time.

A data pipeline may load a CSV into a portal and populate a Snowflake table exactly as expected.

You would not ordinarily enable verbose logging and trace every schema conversion, character transformation, memory operation, and intermediate representation.

There is no need.

Then one column begins to show occasional corruption.

Most rows remain correct.

Only certain values fail.

Only certain characters change.

Now the visible result is no longer enough.

The failure gives you a reason to look more closely.

That is when observation becomes investigation.

The Internals Reveal Themselves

You begin with one damaged column.

You examine the source.

You compare successful and failed records.

You enable verbose logging.

You trace the value through each stage.

Eventually, you discover that the problem is not in the source file and not in the final table.

The issue appears during an intermediate conversion.

A language pack does not map certain characters correctly.

A collation mismatch causes the data to be transformed differently from what the system intended.

That discovery solves the immediate problem.

But it also teaches much more.

You may learn that the source schema is first converted into a SQLite dataset.

You may learn that the intermediate data is reconstructed in memory.

You may learn that the current environment’s collation settings influence the final conversion.

You may learn that the visible pipeline contains internal stages you had never considered because they had never caused a visible failure.

You went looking for the reason one column was corrupt.

You returned with a new mental model of the entire process.

A narrow problem can open a wide window into how a system truly works.

The Questions You Have Not Needed Yet

Deep observation often gives us answers to questions we have not yet learned to ask.

Today, you are investigating character corruption.

Tomorrow, you may encounter:

  • An unexpected truncation.
  • A failed comparison.
  • A sorting inconsistency.
  • A schema mismatch.
  • A regional formatting error.
  • A case-sensitivity problem.
  • A value that changes only in one environment.

The earlier observation may not directly solve the new problem.

But it expands the possibilities available to your mind.

You now know that the visible source and target are not the entire system.

You know that intermediate representations matter.

You know that language, collation, memory conversion, and environment settings may alter data in ways that are not obvious from the outside.

One observation becomes part of your future judgment.

The lesson waits quietly until another problem gives it relevance.

Sometimes a question gives you answers you will not need until much later.

Small Observations Build Large Understanding

Expertise is rarely created by one enormous revelation.

It is built from thousands of small observations.

A log entry that behaves differently than expected.

A configuration default no one mentioned.

A timeout that occurs only under one condition.

A data type that changes during conversion.

A process that retries silently.

A dependency that resolves differently in another environment.

Each detail may appear insignificant by itself.

Together, they create a richer model of reality.

Over time, those details become intuition.

But good intuition is not magic.

It is compressed observation.

The experienced person sees more possibilities because they have previously looked closely at more things.

What we call intuition is often the memory of details we once took the time to observe.

Observe Beyond the Expected Outcome

When we test something, we naturally look for what we expect to see.

Did the process complete?

Did the data arrive?

Did the application respond?

Did the error disappear?

Those questions matter.

But they can also narrow our attention.

A process may produce the correct result while hiding:

  • Repeated retries.
  • Silent warnings.
  • Discarded values.
  • Inefficient conversions.
  • Unexpected fallbacks.
  • Partial failures.
  • Dependencies that are close to breaking.
  • Assumptions that only happen to be valid today.

A successful result does not always mean a healthy process.

Sometimes success merely means the failure has not yet become visible.

Deep observation asks not only:

“Did it work?”

It also asks:

“What did it have to do in order to work?”

In Practice

Observe deeply by:

  • Comparing what you expected with what actually occurred.
  • Looking beyond the first and final step.
  • Studying intermediate states.
  • Increasing logging only when greater detail is justified.
  • Preserving evidence before changing the system.
  • Examining successful and failed examples together.
  • Following one value through the entire process.
  • Looking for transformations that occur outside the visible workflow.
  • Noticing defaults, retries, fallbacks, and silent corrections.
  • Recording discoveries that may matter in future investigations.
  • Asking what else the evidence reveals beyond the immediate problem.

Do not stop at:

“The data arrived.”

Ask:

“What happened to it along the way?”

Do not stop at:

“The process succeeded.”

Ask:

“Did it succeed cleanly?”

Do not stop at:

“I found the error.”

Ask:

“What else did this error teach me about the system?”

The Discipline of Attention

Deep observation requires patience.

The important detail may not announce itself.

It may appear only:

  • In one record.
  • Under one language setting.
  • At one time of day.
  • In one environment.
  • After one particular sequence of events.
  • When two otherwise harmless conditions occur together.

Observation means remaining attentive long enough for the pattern to emerge.

It also means resisting the temptation to see only what supports the explanation already forming in your mind.

This is where Principle VI returns to Principle IV.

Assumption tells observation what it expects to find.

Discipline allows observation to report what is actually there.

Failure Modes

Deep observation does not mean inspecting every detail of everything.

That would make ordinary work impossible.

Not every successful process requires verbose logs.

Not every system deserves complete reverse engineering.

Not every anomaly justifies an unlimited investigation.

Depth should follow purpose.

The goal is not to collect detail for its own sake.

The goal is to understand enough detail to explain the behavior, resolve the problem, and improve future judgment.

There is also a danger in gathering more evidence without interpreting it.

Logs are not understanding.

Metrics are not understanding.

Traces are not understanding.

They are records of what happened.

Learning begins when we connect those records into a model that explains why.

Questions to Ask Yourself

  • Am I observing the process, or only confirming the result?
  • What happened between the beginning and the end?
  • What internal transformation have I assumed away?
  • What evidence exists at a deeper level?
  • What differs between the successful and failed examples?
  • Am I looking for reality, or only evidence that supports my belief?
  • What else is this problem teaching me?
  • Could this discovery answer a question I have not encountered yet?
  • What detail should I preserve for my future self?
  • Have I converted evidence into understanding?

Closing Thought

Do not merely watch something happen.

Follow it closely enough to learn how it happened.

The problem you are solving today may teach you how to recognize a problem you have not encountered yet.

Observation gives us answers to questions we have not needed to ask yet.

Principle VII — Own the Outcome

Foundational Truth

Finding the problem is not the end of the work.

It is the beginning of responsibility.

An issue is not complete merely because its cause has been identified.

Resolve what is happening now.

Protect against what may happen later.

Carry the problem as far toward conclusion as your ability allows.

The Last Place You Look

People sometimes ask:

“Where are my keys?”

My answer has always been:

“They will be in the last place you look.”

Logically, they must be.

Once you find them, you stop looking.

The answer is obvious enough to be funny.

But we often follow the same pattern when solving problems.

We search until we find an explanation.

Then we stop.

The error came from a failed dependency.

The account lacked a permission.

The application used the wrong configuration.

The process encountered corrupt data.

We found the cause.

Investigation complete.

Except it is not.

Finding the issue gives us the first answer:

“What happened?”

We still have to answer:

“How do we resolve it?”

And then:

“How do we prevent it from happening again?”

The first answer explains the past. Ownership improves the future.

Discovery Is Not Resolution

Knowing why a customer cannot work does not restore their ability to work.

Knowing why a process failed does not complete the process.

Knowing why data became corrupt does not repair the data.

Knowing why an application crashes does not prevent the next crash.

Diagnosis matters.

Without it, we may apply random changes, conceal symptoms, or create additional damage.

But diagnosis alone delivers understanding without relief.

A complete response has at least three stages:

  1. Identify what happened.
  2. Restore what is needed now.
  3. Reduce the chance that it happens again.

The immediate fix and the permanent solution may not be the same.

Restarting a service may restore availability.

It does not explain why the service stopped.

Correcting one damaged record may help one customer.

It does not prevent the next record from becoming damaged.

A workaround may be necessary.

It should not be mistaken for a conclusion.

Restoring service ends the interruption. Preventing recurrence ends the problem.

“That Is Not My Job”

One of the easiest ways to abandon a problem is to say:

“That is not my job.”

Sometimes this statement is technically accurate.

You may not own the application.

You may not have access to the source code.

You may not control the vendor.

You may not have permission to change the environment.

You may not possess the specialized skill required to create the permanent fix.

Those limitations are real.

But they do not erase responsibility.

Your job may not be to write the correction.

It may be to:

  • Preserve the evidence.
  • Document the behavior.
  • Identify the conditions that reproduce it.
  • Explain the impact.
  • Route it to the person who can act.
  • Remain engaged until ownership is clearly transferred.
  • Verify that the problem reaches a meaningful conclusion.

You do not have to possess every tool.

You do have to use the tools available to you.

Lack of authority may limit the action you can take. It does not excuse the action you can take.

Ownership Is Not the Same as Control

We often hesitate to own problems because we confuse ownership with complete control.

Ownership does not mean:

“I personally must perform every action.”

It means:

“I will not knowingly allow this issue to disappear between people, teams, or systems.”

You may need another engineer.

A developer.

A security administrator.

A vendor.

A manager.

A product owner.

A customer.

Ownership may require coordination rather than direct repair.

The person who discovers a problem is often the only person who currently understands:

  • What happened.
  • How it was discovered.
  • What evidence exists.
  • What conditions trigger it.
  • Who is affected.
  • Why it matters.

Walking away at that point destroys context.

Passing the issue forward without passing the understanding is not ownership.

It is relocation.

Push the Problem Toward Conclusion

Not every issue can be solved immediately.

Some fixes require:

  • Additional funding.
  • Architectural changes.
  • Vendor development.
  • Extended testing.
  • Maintenance windows.
  • Approvals.
  • Skills that are not yet available.

A delayed solution can still be responsibly managed.

Document the issue clearly.

Record the reproduction steps.

Preserve logs, screenshots, examples, and timestamps.

Describe the impact.

Separate the workaround from the permanent correction.

Identify the next owner.

Track the remaining action.

A problem does not have to be solved today to be carried forward responsibly.

But it must not be allowed to become invisible.

When you cannot complete the solution, create the path by which someone else can.

The Customer Does Not See Your Boundaries

Organizations are divided into departments, teams, roles, queues, permissions, and contracts.

Customers do not experience those boundaries.

They experience one service.

When something fails, the customer rarely cares whether the cause belongs to networking, identity, storage, development, security, a vendor, or another department.

They care whether the experience works.

Internal boundaries may determine who performs the work.

They should not determine whether the work continues.

“That belongs to another team” may be an important routing decision.

It should never become the end of the sentence.

The complete thought is:

“That belongs to another team, and I will make sure they receive the evidence and context required to continue.”

Solve for the Next Person

The immediate customer is not the only person affected by your work.

There is also the next customer.

The next operator.

The next engineer.

The next person who encounters the same failure at 2:00 in the morning without the context you possess now.

A temporary correction helps the person standing in front of you.

A documented and durable correction helps people you may never meet.

That is one of the quiet forms of service.

You may never see the future incident that did not occur.

You may never meet the person who avoided hours of investigation because you preserved what you learned.

You may never receive credit for the problem that disappeared permanently.

The absence of recognition does not reduce the value of prevention.

The best resolution may be the one no future customer ever realizes they needed.

In Practice

When you identify a problem, ask:

  • What must be restored now?
  • What is the actual cause?
  • Is the current action a fix or a workaround?
  • What would prevent recurrence?
  • Do I have the access and skill to make that change?
  • Who does?
  • What evidence must be preserved?
  • Can the problem be reproduced?
  • Has ownership been clearly transferred?
  • How will we know the permanent solution worked?
  • What should be documented for the next person?

The Difference Between Escalation and Abandonment

Escalation is a responsible action.

Abandonment is not.

Escalation says:

“I have carried this as far as my authority or expertise allows. Here is what I found, what I tested, what remains, and why your involvement is needed.”

Abandonment says:

“This belongs to someone else.”

The goal is not to remove the issue from your queue.

The goal is to move it closer to resolution.

Failure Modes

Ownership does not mean refusing to let others help.

It does not mean holding every issue personally forever.

It does not mean operating outside your authority.

There is a difference between ownership and control.

A deferred problem is still being managed.

A forgotten problem is not.

Questions to Ask Yourself

  • Have I found the cause, or have I completed the work?
  • Did I restore service without preventing recurrence?
  • Am I calling a workaround a solution?
  • What happens to the next person who encounters this?
  • Have I preserved enough evidence for someone else to continue?
  • Have I pushed the issue toward a real conclusion?
  • What would a customer consider complete?

Closing Thought

The problem is not finished when you find where it was hiding.

It is finished when the immediate need has been addressed, the future risk has been considered, and responsibility has reached someone capable of carrying it forward.

Do not stop at the first answer. Own the outcome.

Principle VIII — Practical Beats Clever

Foundational Truth

There is usually more than one way to accomplish something.

The most sophisticated solution is not automatically the best one.

The most fashionable design is not automatically the most appropriate one.

The cleverest answer may impress the person who created it while burdening everyone who must operate, support, repair, or replace it.

Choose the solution that works clearly, reliably, and sustainably within the reality you actually have.

A solution should be judged by what it accomplishes, not by how impressive it appears.

There Is More Than One Way to Win

Success does not always arrive in the form we expect.

Some people succeed through speed.

Others through patience.

Some through creativity.

Others through consistency.

Some dominate visibly.

Others quietly create the conditions that make everyone around them better.

Michael Jordan is remembered as one of basketball’s most extraordinary individual scorers and shot creators.

Bill Russell represented a different path to winning.

Russell did not need to produce the same kind of offensive spectacle.

His influence came through defense, rebounding, positioning, anticipation, transition, leadership, and the ability to shape the game around him.

The comparison should not be used to declare one style universally superior to the other.

That would miss the lesson.

The lesson is that there is more than one way to create the desired outcome.

One method may be more exciting.

Another may fit the team, circumstances, and objective better.

The scoreboard does not award additional points for complexity.

The goal is not to look like the person solving the problem. The goal is to solve it.

Use the Right Vehicle for the Job

Years ago, a customer was struggling to understand the difference between IOPS and throughput.

I explained it using two vehicles.

Imagine that you need to deliver a package and can choose between a Porsche and a pickup truck.

If you need to deliver one small package as quickly as possible, the Porsche is the obvious choice.

It accelerates faster.

It travels faster.

For that particular job, speed matters most.

But suppose you need to deliver 300 packages.

The Porsche is still the faster vehicle.

That fact has not changed.

But it cannot carry the entire load.

It must make repeated trips while the pickup carries far more packages at once.

Even though the pickup moves more slowly, it may deliver the complete load sooner.

The fastest vehicle is not always the fastest way to finish the work.

Performance depends on what must move, how much must move, and what outcome actually matters.

The same distinction appears throughout technology.

Some workloads depend on how quickly individual operations can be completed.

Others depend on how much total work can pass through the system over time.

A storage system may handle many small requests very quickly but struggle with large volumes of data.

Another may complete fewer individual operations while moving far more data during the same period.

Neither is universally faster.

Each is suited to a different kind of work.

The mistake is measuring one quality and treating it as the entire definition of performance.

Speed matters.

Capacity matters.

Latency matters.

Throughput matters.

Reliability matters.

The correct priority depends on the job.

Do not choose the fastest tool. Choose the tool that completes the whole task most effectively.

Cleverness Has a Cost

Clever solutions are attractive.

They demonstrate skill.

They compress many actions into a small amount of code.

They use advanced patterns.

They solve several theoretical problems at once.

They may even be genuinely elegant.

But cleverness often carries hidden costs.

A clever solution may be:

  • Harder to explain.
  • Harder to test.
  • Harder to observe.
  • Harder to support.
  • Harder to modify safely.
  • More dependent on its original creator.
  • More fragile when circumstances change.
  • More expensive than the problem justifies.

The person who designed it may understand every choice.

The person awakened at 2:00 in the morning may not.

A design is not complete when its creator can operate it.

It is complete when the people responsible for its future can understand and support it.

Elegance that cannot survive a handoff is often disguised fragility.

Design for the Whole Life of the Solution

Development is only one stage of a system’s life.

A solution must also be:

  • Deployed.
  • Configured.
  • Secured.
  • Observed.
  • Maintained.
  • Troubleshot.
  • Upgraded.
  • Documented.
  • Transferred.
  • Eventually replaced.

A design that is convenient to build but painful to operate has moved complexity rather than removed it.

A single application stack may allow a development team to move quickly.

That may be the practical design.

But as the system grows, one large code path may become difficult to test, isolate, deploy, and support.

At that point, separating well-defined capabilities may allow teams to:

  • Isolate faults.
  • Deploy changes independently.
  • Scale specific components.
  • Establish clearer interfaces.
  • Assign responsibility more effectively.
  • Replace one capability without rebuilding everything.

Yet distribution also creates new burdens:

  • Network failure.
  • Authentication between services.
  • API compatibility.
  • Distributed logging.
  • Dependency management.
  • Deployment coordination.
  • More infrastructure to operate.

The practical answer is therefore not:

“Distributed systems are better.”

Nor is it:

“Monoliths are simpler.”

The practical answer is:

“Choose the amount of separation that reduces the total burden of the system.”

Sometimes that is one application.

Sometimes it is several services.

Sometimes it is a modular monolith with clear internal boundaries.

Architecture should serve the work.

The work should not be forced to serve the architecture.

Simplicity Is Not the Same as Fewer Pieces

A system with one visible component may appear simpler than a system with ten.

But visible size is not the same as operational simplicity.

One enormous application may contain:

  • Hidden dependencies.
  • Shared state.
  • Intertwined business rules.
  • Unclear ownership.
  • Unpredictable side effects.
  • A release process in which every change risks everything.

Ten well-defined components may be easier to understand because each has a clear purpose and boundary.

The reverse can also be true.

Ten services may each require:

  • Separate deployment.
  • Separate monitoring.
  • Separate credentials.
  • Separate versioning.
  • Separate failure handling.

What looks clean on an architecture diagram may become exhausting in production.

Do not count components and call the smaller number simple.

Measure the effort required to understand, change, operate, and recover the whole system.

Simplicity is not the absence of parts. It is the absence of unnecessary difficulty.

Practical Data Design

Database design reveals the same tension.

A single wide table may appear convenient.

Frequently used values are available without several joins.

Queries may initially seem easier to write.

But convenience at the point of reading can create costs elsewhere:

  • Repeated data.
  • Inconsistent updates.
  • Larger indexes.
  • More expensive writes.
  • Greater storage use.
  • Ambiguous ownership of values.
  • Increased risk that two records disagree about the same fact.

Normalization separates distinct concepts.

Customers belong in a customer structure.

Orders belong in an order structure.

Products belong in a product structure.

Relationships are represented deliberately rather than repeated everywhere.

Foreign keys help preserve those relationships.

Joins rebuild the view needed by the application.

This often improves integrity, maintainability, and clarity.

But even here, the practical answer is not always maximum normalization.

Some workloads benefit from:

  • Summary tables.
  • Materialized views.
  • Cached results.
  • Reporting structures.
  • Purposeful duplication.
  • Denormalized analytical models.

The practical question is not:

“Which design is academically pure?”

It is:

“Which design preserves the required integrity while meeting the real workload?”

A clever schema demonstrates knowledge of database theory.

A practical schema applies that knowledge to the system that must actually run.

Solve the Problem You Have

Cleverness often begins solving problems that do not yet exist.

A small internal application is designed for millions of users.

A simple workflow receives an elaborate orchestration platform.

A report needed once per week becomes a real-time streaming architecture.

A modest database receives a globally distributed design.

A short script becomes a framework.

These designs may be technically impressive.

They may also consume more time, money, attention, and support effort than the original problem deserved.

Future growth should be considered.

It should not be imagined without limits.

Design for reasonable change.

Preserve paths for expansion.

Avoid decisions that make growth impossible.

But do not burden today with every possible version of tomorrow.

Do not build a cathedral when the need is shelter.

Practicality Includes People

A technically superior solution can fail when it ignores the people expected to use it.

A process may be mathematically optimal but too complicated to follow consistently.

An interface may offer complete control but overwhelm the person performing an ordinary task.

An automation may save several minutes while making failures almost impossible to diagnose.

A security control may be theoretically perfect but encourage users to create unsafe workarounds.

Practical design considers:

  • Available skills.
  • Staffing.
  • Budget.
  • Time.
  • Existing tools.
  • Support coverage.
  • Regulatory requirements.
  • Failure tolerance.
  • Human behavior.

The real environment is not an inconvenience to design around.

It is part of the design.

A solution that ignores the people operating it does not understand the problem it claims to solve.

Make the Obvious Choice Easy to Understand

Practical solutions often look unsurprising after they are finished.

The workflow is clear.

The components have understandable purposes.

The failure modes are visible.

The documentation matches the implementation.

A new person can follow the reasoning.

That lack of mystery is a strength.

The goal is not to create something no one else could have imagined.

The goal is to create something others can understand, trust, and continue.

The best design may not produce admiration.

It may produce something more valuable:

Confidence.

People know what it does.

They know why it exists.

They know where to look when it fails.

They know how to change it without guessing.

The highest form of cleverness may be creating something that no longer looks clever.

In Practice

Before choosing a solution, ask:

  • What outcome are we actually trying to produce?
  • Who must operate this after it is built?
  • What does failure look like?
  • How easily can the failure be isolated?
  • Can another person understand the design?
  • Are we removing complexity or relocating it?
  • Does the solution fit our current scale?
  • What future change is reasonably likely?
  • Which parts truly require sophistication?
  • Are we using this pattern because it fits, or because it is fashionable?
  • Would a simpler approach meet the same need?
  • What is the total cost across development, operation, support, and replacement?
  • Are we optimizing one measurement while making the complete task slower?
  • Which option completes the whole job most effectively?

Prefer the simplest solution that satisfies the real requirements.

Not the fewest lines of code.

Not the fewest components.

Not the least advanced technology.

The least unnecessary difficulty.

Failure Modes

“Practical beats clever” does not mean innovation is bad.

It does not mean choosing the oldest technology.

It does not mean avoiding advanced designs.

It does not mean accepting poor quality because improvement requires effort.

Some problems are genuinely complex.

Their solutions may require sophisticated algorithms, distributed components, specialized tools, or unconventional thinking.

Oversimplifying a complex problem is not practical.

It merely hides complexity until the system fails.

There is also danger in using practicality as an excuse for short-term thinking.

A quick workaround may feel practical today while creating years of maintenance debt.

The easiest immediate action is not always the most practical total solution.

Practicality considers the complete lifespan and the full group of people affected.

Simple is not careless. Practical is not temporary.

Questions to Ask Yourself

  • Am I solving the problem or demonstrating my skill?
  • Is this complexity required?
  • Who will inherit this decision?
  • What burden does this design place on support?
  • Does this solution fit the environment we actually have?
  • What becomes easier?
  • What becomes harder?
  • Have I measured the entire system or only the part I am building?
  • Is this approach resilient enough to justify its complexity?
  • Could I explain this design without relying on jargon?
  • Will the next person understand why we chose it?
  • Is there a less impressive solution that would work better?
  • Am I choosing the fastest component or the fastest complete outcome?
  • What is the actual load this solution must carry?

Closing Thought

There are many ways to produce an outcome.

Some are beautiful.

Some are sophisticated.

Some are exciting.

The best one is the approach that meets the need, survives reality, and remains understandable to the people responsible for what comes next.

The fastest component does not always create the fastest system.

Do not choose the solution that makes you look clever. Choose the one that keeps working.

Principle IX — Simplicity Is Earned

Foundational Truth

Simplicity rarely appears by accident.

It is discovered through attention.

Created through effort.

Tested through revision.

And earned by removing what does not serve the purpose.

The first version contains what entered our minds.

The refined version contains what another person actually needs.

Simplicity is not where thought begins. It is what disciplined thought leaves behind.

The Difficulty of Saying Less

For years, I wrote narratives for feature development in the form of press releases.

The format was intentionally restrictive.

Often, the entire idea had to fit on one page.

That sounds easier than producing a large technical document.

It was not.

When you care deeply about an idea, everything feels important.

You want to explain:

  • Why the problem matters.
  • How the idea emerged.
  • What the feature will do.
  • Who it will help.
  • Why the current approach is insufficient.
  • What makes the new approach different.
  • Every possibility you can already imagine.
  • Every reason others should be as excited as you are.

Then the page ends.

The limit forces a decision:

What does the reader truly need in order to understand this?

Reaching that answer could take weeks.

A dozen versions might be written.

Sentences would be shortened.

Sections would be moved.

Examples would be removed.

Words that seemed essential yesterday would disappear tomorrow.

The final page looked simple.

The process that produced it was not.

If I Had More Time

Blaise Pascal expressed this difficulty centuries ago when he apologized for the length of a letter because he had not had the leisure to make it shorter.

The thought is now commonly paraphrased:

“If I had more time, I would have written a shorter letter.”

The sentence survives because it exposes a truth far beyond writing.

The first answer is often long because it contains the entire path of discovery.

The refined answer is shorter because someone returned to distinguish the destination from the journey.

Brevity requires decisions.

What belongs?

What repeats?

What distracts?

What supports understanding?

What is present because the audience needs it?

What is present only because the creator enjoyed discovering it?

Making something shorter is not merely deleting words.

It is identifying meaning.

Reduction without understanding creates absence. Reduction with understanding creates clarity.

The Jumbled Mess

When we first explain an idea, we rarely present only the idea.

We also present:

  • The feelings attached to it.
  • The path we took to reach it.
  • Questions still moving through our minds.
  • Nearby ideas that happen to feel connected.
  • Defenses against objections no one has raised.
  • Details that interest us more than they help the listener.
  • Fragments that have not yet found their proper place.

This is not failure.

It is often how thinking begins.

Our first explanation may contain the truth, but the truth is surrounded by the process of finding it.

Perhaps only 60 percent of what we say is essential to the person listening.

The remaining 40 percent may consist of emotion, context, repetition, or passing thoughts from the crowded state of our minds.

That excess can still be valuable.

It may help us discover what we believe.

But discovery and delivery are different tasks.

The unfiltered version helps the creator think.

The refined version helps the audience understand.

Your audience should not have to untangle your thoughts in order to receive your meaning.

Simplicity Must Be Revealed

A simple answer is often hidden inside a complicated one.

We do not always know which parts are essential when we begin.

We find them by working.

We explain the idea.

We test it.

We hear where others become confused.

We notice what must be repeated.

We discover which examples clarify the concept and which merely lengthen it.

We remove one piece and see whether the structure still stands.

We restore what was necessary.

We remove what was merely familiar.

Gradually, the essential shape reveals itself.

This is why premature simplicity can be dangerous.

Removing complexity before understanding it may erase an important condition, dependency, exception, or risk.

True simplicity comes after complexity has been examined.

Not before.

You cannot reliably remove what you have not taken the time to understand.

Simplicity Is Refinement

A rough stone can be made smaller by breaking it.

That does not make it refined.

Refinement is selective.

It preserves what gives the thing its identity and removes what obscures it.

The same is true of ideas, systems, processes, and explanations.

Refinement may require:

  • Rewriting the same paragraph repeatedly.
  • Removing a feature that adds more burden than value.
  • Combining several steps into one clear action.
  • Separating concepts that were forced together.
  • Renaming something until its purpose becomes obvious.
  • Reordering information so the audience receives it when needed.
  • Replacing technical language with a familiar analogy.
  • Eliminating an exception by improving the underlying design.
  • Turning tribal knowledge into a visible process.

The work is not finished when nothing more can be added.

It is closer to finished when nothing unnecessary remains.

Simple Does Not Mean Shallow

A simple explanation may contain years of experience.

A clear interface may conceal extensive design work.

A short procedure may represent dozens of eliminated failure modes.

A well-named function may replace pages of explanation.

A calm response may come from a lifetime of learning which details matter.

The result appears easy because the difficulty has already been absorbed by the creator.

This can cause simplicity to be undervalued.

People see the final sentence.

They do not see the twelve drafts.

They see the clean workflow.

They do not see the abandoned designs.

They see the obvious answer.

They do not see the investigation required to make it obvious.

The simpler the result appears, the easier it is to overlook the work that made it possible.

Simplicity in Systems

Technical systems often accumulate complexity naturally.

A requirement is added.

An exception is introduced.

A temporary workaround becomes permanent.

A second path is created because the first cannot be safely changed.

A new tool is placed beside an old one.

Documentation falls behind.

Each individual decision may appear reasonable.

Together, they produce a system no one fully understands.

Simplification requires more than deleting components.

It requires discovering why each component exists.

Some may protect against failures that still matter.

Some may preserve compatibility.

Some may be compensating for constraints that no longer exist.

Some may remain only because no one has taken ownership of removing them.

The practical work is to separate necessary complexity from accumulated complexity.

Necessary complexity belongs to the problem.

Accumulated complexity belongs to the history of how we responded to it.

A system becomes simpler when its complexity reflects the problem rather than its past.

Simplicity in Communication

Clear communication is not achieved by saying everything we know.

It is achieved by understanding what the other person needs next.

A useful explanation should consider:

  • What the listener already knows.
  • What they are trying to accomplish.
  • Which concept must be understood first.
  • Which details would distract too early.
  • What analogy fits their experience.
  • What action should follow the explanation.
  • Where precision matters more than brevity.
  • Where brevity would improve understanding.

Sometimes one sentence is enough.

Sometimes the honest answer requires several pages.

Simplicity is not measured only by length.

A short explanation can be confusing.

A longer explanation can be clear.

The goal is not fewer words at any cost.

The goal is the least burden necessary for accurate understanding.

The simplest explanation is not always the shortest. It is the one that makes understanding require the least unnecessary effort.

Simplicity Requires Empathy

What feels simple to the creator may not feel simple to anyone else.

Familiarity hides complexity.

We forget which terms once required explanation.

We skip steps that have become automatic.

We assume relationships that seem obvious only because we have spent years seeing them.

To create simplicity for another person, we must temporarily leave our own perspective.

What will they recognize?

Where will they hesitate?

Which assumption are they likely to make?

What information do they need now?

What can safely wait?

This is why simplicity is not merely an intellectual achievement.

It is an act of consideration.

You accept more work so that someone else must perform less.

Simplicity is often the effort one person makes to spare unnecessary effort for another.

In Practice

To earn simplicity:

  • Begin with the complete thought.
  • Allow the first version to be imperfect.
  • Identify the intended audience.
  • Define the single outcome the work must produce.
  • Separate essential information from the path used to discover it.
  • Remove repetition that does not reinforce understanding.
  • Preserve conditions and exceptions that materially change the result.
  • Replace unnecessary jargon with clear language.
  • Test the explanation on someone without your context.
  • Ask where they became confused.
  • Revise more than once.
  • Stop defending a detail merely because you worked hard to discover it.
  • Keep complexity that belongs to the problem.
  • Remove complexity that belongs only to the presentation.

Ask of every sentence, step, feature, and component:

“What necessary work is this doing?”

If there is no clear answer, it may not need to remain.

Failure Modes

Simplicity can become a slogan used to justify incomplete thinking.

A short answer may omit the condition that makes it true.

A simplified process may conceal risk.

A clean interface may remove controls that advanced users genuinely need.

A reduced architecture may place too many responsibilities into one fragile component.

Simplicity must not be confused with minimalism for its own sake.

The goal is not to remove the most.

The goal is to remove what is unnecessary while preserving what is true.

There is also a danger in endless refinement.

A person can revise forever.

At some point, the explanation is clear enough.

The process is usable enough.

The solution meets the need.

Perfection may consume time that could produce greater value elsewhere.

Simplicity is earned through effort.

Wisdom determines when enough effort has been spent.

Remove what obscures the truth. Do not remove the truth in pursuit of neatness.

Questions to Ask Yourself

  • What is the essential idea?
  • What does the audience actually need?
  • Which parts reflect the message, and which reflect my process of discovering it?
  • Am I adding this because it helps or because it interests me?
  • What can be removed without losing meaning?
  • What appears simple only because I already understand it?
  • Have I preserved important conditions and exceptions?
  • Is the complexity inherent to the problem or inherited from its history?
  • Have I tested this with someone who lacks my context?
  • Am I refining toward clarity or merely shortening?
  • What unnecessary effort am I asking someone else to perform?
  • Is this complete enough to release?

Closing Thought

The first version shows us everything that was in the creator’s mind.

The refined version reveals what truly needed to be there.

Simplicity is not the absence of thought.

It is the result of thought examined, organized, reduced, and shaped around its purpose.

Simplicity is earned by doing the difficult work of deciding what deserves to remain.

Principle X — Readability Is Reliability

Readability Is Reliability

Code is read far more often than it is written.

Every engineer becomes a teacher the moment they commit code.

Readable systems reduce mistakes.

Readable documentation prevents outages.

Readable architecture shortens learning curves.

Write for the next engineer.

One day, that engineer may be you.

In Practice

  • Prefer descriptive names.
  • Document intent, not the obvious.
  • Keep functions focused.
  • Let structure explain itself.

Ask Yourself

Would someone unfamiliar with this system understand my intent?

Principle XI — Consistency Builds Confidence

Foundational Truth

Trust is not created by what happens once.

It is created by what happens repeatedly.

A single success proves that something is possible.

Consistent success gives people confidence that it will happen again.

Reliability is success made repeatable.

Success Once Is an Event

Almost anyone can succeed once.

A meal can turn out perfectly.

A project can finish on time.

A person can keep one promise.

A system can survive one demanding day.

A product can delight one customer.

That success matters.

But one result does not yet establish a pattern.

It may have depended on:

  • Favorable conditions.
  • Unusual effort.
  • Good timing.
  • A particular person.
  • An unnoticed advantage.
  • Luck.

The first success answers:

“Can this be done?”

Consistency answers:

“Can this be depended upon?”

Those are different achievements.

The first creates possibility.

The second creates confidence.

The Same Big Mac

One of the reasons a large restaurant chain becomes familiar is not that every meal is extraordinary.

It is that the customer generally knows what to expect.

A person ordering a Big Mac in New York does not expect it to become an entirely different sandwich from the one ordered in Chicago or Los Angeles.

The surroundings change.

The employees change.

The building changes.

The weather changes.

The customer may be thousands of miles away from the last restaurant they visited.

Yet the expectation remains:

This should taste like the product I already know.

That expectation is valuable.

The customer does not have to investigate the restaurant from the beginning.

They do not have to wonder whether the name means something different in this location.

Consistency reduces uncertainty.

The product becomes familiar before it is even received.

A consistent experience allows trust to travel from one encounter to the next.

Control What Should Not Change

Consistency does not occur merely because people intend to reproduce the same result.

Conditions differ.

Ingredients differ.

Equipment differs.

People differ.

Environments differ.

Even water differs.

Water drawn from different places can contain different minerals and characteristics that affect taste.

A beverage bottled in one location may therefore begin with different local conditions than the same beverage bottled somewhere else.

If the manufacturer wants the finished drink to taste consistent, it cannot simply ignore those differences.

It must identify which characteristics influence the outcome and control them.

The lesson is larger than beverage production:

Consistency requires us to control variation that matters.

Not every difference must be eliminated.

The factory does not need the same weather.

The building does not need the same paint.

The people do not need identical voices.

But the conditions that materially affect the promised product must remain within acceptable boundaries.

Consistency begins by knowing which variation is harmless and which variation changes the experience.

Confidence Comes From Prediction

Confidence is our willingness to act without repeatedly questioning the result.

We enter a familiar restaurant because we believe the meal will resemble the one we remember.

We use a familiar tool because we expect it to behave as it did before.

We ask a dependable person for help because their previous actions suggest what they will do next.

We follow a process because it has repeatedly produced the intended outcome.

Confidence grows because experience makes the future easier to predict.

Confidence grows when experience makes the next outcome easier to predict.

A Good Boy Is a Consistent Boy

My grandmother used to say:

“A good boy is a consistent boy.”

Good character is not demonstrated by occasional good behavior.

It is demonstrated by patterns.

A dependable person repeatedly keeps commitments.

An honest person repeatedly chooses truth.

A caring person repeatedly shows concern.

Consistency transforms isolated actions into character.

We become known not by our exceptional moments, but by the behavior others learn to expect from us.

Repetition Creates Identity

Brands are expectations.

Leaders are expectations.

Teams are expectations.

Families are expectations.

Repeated behavior teaches others what something means.

Identity forms through repetition.

Reputation is the memory of repeated behavior.

Consistency Is Not Perfection

Reliable people make mistakes.

Reliable systems fail.

Reliable organizations experience setbacks.

Confidence comes from how consistently they recover.

Do they acknowledge the problem?

Do they investigate?

Do they improve?

Do they prevent unnecessary repetition?

Confidence does not require flawless performance. It requires dependable response.

Consistency Requires Design

Repeatability improves when success is designed into the work.

  • Standards
  • Templates
  • Checklists
  • Automation
  • Validation
  • Testing
  • Monitoring
  • Documentation
  • Feedback

These tools reduce unnecessary variation.

Good systems make the desired result easier to repeat and unwanted variation easier to detect.

Repeat the Outcome, Not Every Motion

Consistency should preserve value, not unnecessary ritual.

Methods evolve.

Tools improve.

Processes mature.

The promise should remain recognizable.

Consistency protects the outcome without worshipping the procedure.

Standardization and Judgment

Standards guide ordinary work.

Judgment handles extraordinary situations.

Neither succeeds without the other.

A standard creates confidence when it guides ordinary work without preventing intelligent response to the extraordinary.

Consistency in Engineering

Repeatable deployments.

Repeatable backups.

Repeatable builds.

Repeatable restores.

Repeatable tests.

Repeatable infrastructure.

Engineering confidence comes from knowing success can be reproduced.

If success cannot be reproduced, it remains an achievement rather than a system.

Consistency in Leadership

People learn who leaders are by watching ordinary behavior.

Do principles change under pressure?

Do promises survive inconvenience?

Do actions match values?

Predictable principles create psychological safety.

Predictable principles create safer environments than unpredictable personalities.

Consistency in Relationships

Trust grows through repeated ordinary moments.

Showing up.

Keeping promises.

Listening.

Remembering.

Being truthful.

Grand gestures are memorable.

Consistency makes them believable.

Trust is accumulated in ordinary moments that agree with one another.

Consistency Creates Freedom

Reliable foundations create room for creativity.

Stable systems allow experimentation.

Predictable operations allow innovation.

Confidence reduces unnecessary attention.

Reliability frees attention for work that has not yet been solved.

In Practice

Build repeatability.

Measure drift.

Control meaningful variation.

Improve the process.

Document success.

Automate where appropriate.

Design for dependable outcomes.

Ask:

“Could another capable person reproduce this result under similar conditions?”

Failure Modes

Consistency is not sameness.

Consistency is not stagnation.

Consistency is not repeating poor decisions forever.

Repeat what deserves repeating.

Improve what deserves improving.

Do not consistently repeat what no longer deserves to continue.

Questions to Ask Yourself

  • What promise am I making?
  • Can someone else reproduce this result?
  • What variation matters?
  • What variation does not?
  • Does quality depend upon one person?
  • What gives people confidence in this?
  • Are we repeating outcomes or merely habits?
  • Is this worthy of becoming our standard?

Closing Thought

People gain confidence when experience teaches them what to expect.

The meal tastes familiar.

The system behaves predictably.

The person keeps their word.

The process produces the intended result.

Consistency transforms isolated successes into trust.

As Granny said:

“A good boy is a consistent boy.”

And perhaps that simple wisdom explains more than we first realize:

Do what is worthy of trust, then do it often enough that others no longer have to wonder who you will be.

Principle XII — Build for Tomorrow

Foundational Truth

We cannot know what tomorrow will bring.

We can study patterns.

We can imagine possibilities.

We can prepare for likely changes.

But no person, organization, or machine can describe the future with certainty.

The goal is therefore not to predict tomorrow perfectly.

It is to avoid building today in a way that makes tomorrow unnecessarily difficult.

We cannot know the future, but we can decide whether our work will be ready to meet it.

The Future Has Always Been Imagined

Writers, filmmakers, scientists, and engineers have spent generations imagining what the future might become.

Jules Verne imagined technologies and journeys that seemed impossible to many people of his time.

Gene Roddenberry imagined a world of communicators, intelligent computers, universal translation, and human cooperation beyond Earth.

Stanley Kubrick gave audiences HAL, an artificial intelligence whose calm voice helped make the unknown feel frightening.

Later stories gave us Skynet and machines capable of turning against their creators.

These visions shaped how society thought about technology long before much of that technology existed.

Some ideas proved surprisingly close.

Others did not.

Many arrived in forms no one expected.

Artificial intelligence is finally becoming part of ordinary work, but it did not arrive exactly as fiction promised.

It is not one red-eyed machine making a single decision for humanity.

It is a collection of tools, models, systems, interfaces, and capabilities being adopted unevenly across nearly every field.

The lesson is not that the storytellers were wrong.

The lesson is that imagining the future and knowing the future are different things.

Vision can point toward possibility, but it should not be mistaken for certainty.

Fear of the Unknown

New technology often arrives surrounded by fear.

Sometimes the fear is justified.

Powerful tools create powerful risks.

But fear can also cause us to treat uncertainty as evidence of inevitable disaster.

HAL taught generations to distrust the intelligent machine behind the voice.

Skynet turned automation into an image of human extinction.

Those stories matter because they warn us about control, responsibility, alignment, and dependence.

But artificial intelligence is still a tool.

Like every powerful tool, its value and danger depend upon:

  • Who designs it.
  • What purpose guides it.
  • Which data shapes it.
  • What authority it receives.
  • What boundaries constrain it.
  • How closely its outcomes are observed.
  • Whether humans remain accountable.

We should not build recklessly because the future is uncertain.

We should also not refuse to build because uncertainty exists.

The unknown deserves preparation, not paralysis.

Build for Change, Not for Prediction

Building for tomorrow does not mean guessing which exact technology, platform, or market will dominate.

It means expecting change.

Requirements will change.

Users will change.

Data volumes will grow.

Regulations will evolve.

Vendors will appear and disappear.

Tools will improve.

Integrations will be replaced.

The system may be used in ways its creators never anticipated.

A design that assumes nothing important will change may work beautifully at first.

Then every new requirement becomes a disruption.

A field cannot be added without rewriting the application.

A new customer cannot be supported without duplicating the system.

A vendor cannot be replaced without rebuilding the workflow.

A larger dataset cannot be processed without redesigning the storage layer.

A new interface cannot be introduced because the logic and presentation were fused together.

The system was built for the day it was created.

Tomorrow was treated as an exception.

Build for tomorrow by making change a normal condition rather than an emergency.

Modular

A modular system separates responsibilities into understandable parts.

Each part has a purpose.

Each part has a boundary.

Each part interacts with the others through defined relationships.

This does not mean splitting everything into the smallest possible pieces.

Excessive fragmentation can create its own complexity.

The goal is not maximum separation.

The goal is useful separation.

A modular design allows one part to change without forcing every other part to change with it.

The storage layer can evolve without rewriting the entire interface.

The authentication method can change without replacing the business logic.

A reporting component can be added without redesigning transaction processing.

A new model can be introduced without coupling the entire system to one vendor.

A module is valuable when it contains change instead of spreading it.

Flexible

Flexibility is the ability to respond without abandoning the original purpose.

A flexible system can accept new inputs.

Support new users.

Operate in new environments.

Integrate with new tools.

Adjust to new constraints.

But flexibility does not mean building every imaginable option before it is needed.

That creates complexity in anticipation of possibilities that may never arrive.

True flexibility comes from well-chosen boundaries, clear interfaces, accessible data, and limited assumptions.

It leaves room for change without attempting to pre-build the entire future.

Flexibility is not preparing for every possible future. It is avoiding unnecessary dependence on only one.

Expandable

Many systems succeed and then become victims of their own success.

The first version works.

More people adopt it.

More data arrives.

More teams depend on it.

The workload exceeds the assumptions of the original design.

Growth exposes hidden limits.

An expandable system does not need infinite capacity.

It needs a credible path to greater capacity.

That may mean:

  • Adding compute resources.
  • Partitioning data.
  • Introducing queues.
  • Expanding storage.
  • Separating workloads.
  • Supporting additional regions.
  • Adding new services behind an existing interface.
  • Moving from manual operation toward automation.
  • Allowing one environment to become many.

Scalability is not only a technical concern.

Teams, processes, support models, documentation, and ownership must also expand.

A system that can serve ten times as many users but still requires one person to approve every action has not truly scaled.

Growth is sustainable only when the surrounding system can grow with the workload.

Purpose Driven

Future readiness does not justify architecture without purpose.

A system should not become modular merely because modularity is fashionable.

It should not move to the cloud because the cloud exists.

It should not adopt artificial intelligence because every presentation now includes it.

It should not create a data lake when the real need is a small, well-structured database.

It should not create dozens of services when one application would serve the work better.

Tomorrow matters.

But today still has requirements, limits, budgets, users, and responsibilities.

Building for tomorrow means creating a design that can evolve while remaining anchored to the problem it exists to solve.

The future should influence the design without replacing the purpose.

Every Flavor of Tool

Modern technology offers nearly unlimited choices.

There are tools for:

  • Organization.
  • Communication.
  • Cloud storage.
  • File sharing.
  • Relational databases.
  • Data lakes.
  • Data warehouses.
  • Data marts.
  • Analytics.
  • Automation.
  • Integration.
  • Machine learning.
  • Artificial intelligence.
  • Model hosting.
  • Observability.
  • Security.
  • Collaboration.

For nearly every problem, there are multiple platforms claiming to solve it.

Choice creates opportunity.

It also creates temptation.

We may select tools because they are new.

Because they are popular.

Because they appear powerful.

Because the architecture will look impressive.

But a collection of advanced tools does not automatically become a future-ready system.

Future readiness comes from how the parts are arranged.

Can they be replaced?

Can the data be moved?

Are interfaces documented?

Are dependencies visible?

Does the system preserve ownership of its essential logic and information?

Can a future team understand why each component exists?

A platform is not future-ready merely because it contains modern tools. It is future-ready when those tools can evolve without taking the purpose hostage.

GitHub as a Platform Built for Tomorrow

GitHub began with a clear purpose: helping people store, manage, and collaborate on code.

But its enduring strength came from not treating source storage as the final boundary of the problem.

Around that foundation, it became possible to support:

  • Distributed collaboration.
  • Branching and merging.
  • Issue tracking.
  • Code review.
  • Documentation.
  • Automated testing.
  • Deployment workflows.
  • Security scanning.
  • Package management.
  • Integrations.
  • Extensibility.
  • Large communities of developers.

Its value is not that every future feature was known at the beginning.

Its value is that the foundation allowed new capabilities to be added without abandoning the core purpose.

The platform grew around a durable center.

That is what building for tomorrow often looks like.

Not predicting every destination.

Creating a foundation from which many useful destinations remain reachable.

The best future-ready platforms do not predict every use. They preserve the ability to support uses not yet imagined.

Preserve the Core

Systems should evolve, but not everything should be in constant motion.

Future-ready design requires knowing what should remain stable.

That may be:

  • The core purpose.
  • The business rules.
  • The data ownership model.
  • The security principles.
  • The customer promise.
  • The interface contract.
  • The source of truth.
  • The values guiding decisions.

Around that stable center, implementation can change.

Tools can be replaced.

Interfaces can improve.

Storage can expand.

Models can evolve.

New capabilities can appear.

Without a stable core, flexibility becomes drift.

The system changes, but no one knows what it is changing toward.

Build the edges to evolve and the center to endure.

Avoid the Dead End

A dead-end design may work well until the first significant change arrives.

Then the organization discovers that:

  • The data cannot be exported.
  • The vendor cannot be replaced.
  • The logic exists only inside one proprietary workflow.
  • The application cannot support another tenant.
  • The schema cannot accept a new relationship.
  • The process cannot be automated.
  • The system cannot expose an interface.
  • The environment cannot be reproduced.
  • The product cannot grow without rebuilding from the beginning.

Some limitations are unavoidable.

Every design makes tradeoffs.

But many dead ends are created by convenience that ignores future ownership.

The faster path today may quietly remove every path tomorrow.

A shortcut becomes expensive when it closes the road behind it.

Reversible Decisions

One of the most useful ways to prepare for an uncertain future is to distinguish reversible decisions from irreversible ones.

A reversible decision can be changed with limited cost.

A library can be replaced.

A feature flag can be disabled.

A noncritical service can be moved.

A workflow can be adjusted.

An irreversible or expensive decision may shape the system for years.

A proprietary data format may trap information.

A tightly coupled architecture may make every change global.

A permanent identifier may become embedded across many systems.

A poorly designed security boundary may be extremely difficult to correct.

Future-ready teams move quickly where decisions are reversible.

They slow down where decisions create long-term constraint.

Move quickly through doors that remain open. Think carefully before walking through doors that lock behind you.

Data Outlives Applications

Applications change.

Data often remains.

A user interface may last three years.

A vendor platform may last seven.

A database may contain records that must survive for decades.

Building for tomorrow means treating data as a durable asset rather than a temporary byproduct of the current application.

That requires attention to:

  • Ownership.
  • Portability.
  • Structure.
  • Meaning.
  • Lineage.
  • Security.
  • Retention.
  • Accessibility.
  • Documentation.
  • Migration.

A future system may use the same data in ways no one currently imagines.

Artificial intelligence makes this especially important.

Models improve.

Tools change.

But their usefulness depends heavily on whether information was preserved clearly, legally, accurately, and accessibly.

Applications serve the present. Well-managed data can serve futures the application will never see.

Interfaces Create Possibility

A system becomes more useful when it can interact safely with other systems.

Clear interfaces allow new capabilities to connect without rewriting the original foundation.

That may involve:

  • APIs.
  • Events.
  • Export formats.
  • Import standards.
  • Command interfaces.
  • Message queues.
  • Documented schemas.
  • Stable contracts.

An interface is a promise about how another system may interact with yours.

Good interfaces create room for extension.

Poor interfaces expose internal complexity, create fragile dependencies, or force every consumer to understand the entire implementation.

A strong interface reveals what others need while protecting them from what they should not have to know.

Build So Others Can Continue

A system prepared for tomorrow cannot depend entirely on the people who built it today.

Its structure must be readable.

Its choices must be documented.

Its operations must be repeatable.

Its ownership must be clear.

Its data must be accessible to those responsible for it.

Its failure modes must be understandable.

This connects directly to the Principles that came before:

  • Practical choices reduce unnecessary burden.
  • Simplicity makes future change easier.
  • Readability allows knowledge to survive.
  • Consistency makes successful operation repeatable.

Building for tomorrow brings those disciplines together.

The future begins when someone else must continue what you started.

Do Not Overbuild the Future

There is a danger hidden inside this Principle.

People can use “future-proofing” to justify nearly unlimited complexity.

They build for millions of users before finding ten.

They introduce distributed systems before the workload requires them.

They create abstraction layers for technologies that may never change.

They design extension points without any credible extension.

They attempt to solve every hypothetical need.

This does not prepare the system for tomorrow.

It burdens today with imaginary requirements.

Nothing is completely future-proof.

Every architecture will eventually face a condition it did not anticipate.

The goal is not immunity from change.

The goal is a reasonable capacity to absorb it.

Build for plausible change, not unlimited imagination.

In Practice

To build for tomorrow:

  • Define the enduring purpose.
  • Identify what is likely to change.
  • Separate concerns where change should be contained.
  • Use clear interfaces between components.
  • Preserve ownership and portability of essential data.
  • Avoid unnecessary vendor dependence.
  • Document major decisions and their tradeoffs.
  • Prefer reversible choices when uncertainty is high.
  • Ensure capacity has a credible path to expand.
  • Design operations to scale with the technology.
  • Make environments reproducible.
  • Keep security and governance part of the foundation.
  • Allow tools to change without losing the system’s identity.
  • Revisit assumptions as reality evolves.
  • Do not build speculative complexity without a credible need.

Ask:

“Will this design help the next change, or will the next change require us to escape the design?”

Failure Modes

Building for tomorrow can become an excuse for building too much today.

Modularity can become fragmentation.

Flexibility can become ambiguity.

Expandability can become permanent overcapacity.

Abstraction can hide simple work behind complex structures.

Vendor independence can become refusal to use valuable managed services.

Preparing for change can consume so much effort that the current need is never delivered.

The opposite failure is equally dangerous.

A system may be optimized so narrowly for the present that every future requirement becomes a rebuild.

Wisdom lies between these extremes.

Build enough structure to preserve options.

Avoid building options that have no credible value.

Future readiness is not maximum complexity. It is minimum unnecessary constraint.

Questions to Ask Yourself

  • What purpose should remain stable?
  • What is likely to change?
  • Which decisions would be expensive to reverse?
  • Can one component change without forcing every component to change?
  • Can the data outlive the current application?
  • Can another tool integrate without learning the entire system?
  • Does growth have a credible path?
  • Are we preparing for plausible needs or imaginary ones?
  • Are we creating flexibility or merely adding abstraction?
  • What happens if the current vendor disappears?
  • Can another team continue this work?
  • Does the design preserve options or quietly eliminate them?
  • Are we solving tomorrow’s uncertainty without neglecting today’s responsibility?

Closing Thought

No one knows exactly what tomorrow will bring.

The great storytellers imagined futures that inspired us, warned us, and sometimes frightened us.

Some of their visions came close.

Others arrived differently.

Many possibilities still remain beyond our sight.

Our responsibility is not to predict every one of them.

It is to build with enough purpose, clarity, flexibility, and humility that change does not require us to begin again each time it arrives.

Build the center to endure.

Build the edges to evolve.

Preserve the data.

Keep the doors open.

We do not build for tomorrow by pretending to know it. We build for tomorrow by refusing to make today a dead end.

Principle XIII — Quality Compounds

Foundational Truth

Quality does more than improve a single outcome.

When quality is repeated, it creates confidence.

Confidence creates preference.

Preference creates opportunity.

Opportunity creates experience.

Experience creates the ability to improve quality again.

That is how quality compounds.

Quality repeated over time becomes an advantage larger than any single product, decision, or success.

Quality Is More Than a Good Result

A good result can happen once.

Quality is the discipline that makes good results increasingly likely.

One excellent product may attract attention.

One successful project may earn praise.

One exceptional interaction may impress a customer.

But lasting advantage comes when the next product is also good.

And the next.

And the next.

Each quality result adds evidence to the one before it.

Eventually, customers stop asking whether the organization can deliver.

They begin expecting that it will.

Quality begins as performance and matures into expectation.

When the Market Changed

For much of the postwar era, the American automobile market was dominated by General Motors, Ford, and Chrysler.

Large vehicles and powerful engines reflected the conditions and preferences of the time.

Fuel was comparatively inexpensive.

Performance, size, comfort, and style mattered greatly to buyers.

The familiar attitude could be summarized:

“Here is five dollars. Fill it up and check the oil.”

Under those conditions, fuel consumption did not feel like the defining constraint.

Then the conditions changed.

The oil crises of the 1970s brought fuel shortages, higher prices, and long lines at filling stations.

Consumers who had once admired size and horsepower began paying much closer attention to efficiency.

The market did not gradually whisper that its priorities were changing.

It announced the change through inconvenience, expense, and uncertainty.

By 1975, imports were already gaining ground as American consumers looked toward smaller and more fuel-efficient vehicles.

Congress also established federal fuel-economy requirements that forced manufacturers to improve fleet efficiency.

The companies that had dominated yesterday suddenly had to compete under tomorrow’s expectations.

A changing market does not erase past success, but it can expose what past success allowed an organization to neglect.

Efficiency Opened the Door

Japanese and European manufacturers were better positioned to offer the smaller, more efficient cars Americans suddenly wanted.

Fuel economy gave consumers a reason to look.

But it was not the only thing they found.

They also found vehicles with reputations for reliability and comparatively fewer repair problems.

That distinction mattered.

If fuel economy had been the only advantage, customers might have returned immediately to their old preferences when fuel prices declined.

Instead, many remained.

The new automobiles had not merely answered the crisis.

They had begun earning trust.

Reliability, manufacturing discipline, and steadily improving quality helped foreign manufacturers establish a lasting competitive position.

A market disruption may earn you a customer once. Quality determines whether the customer remains when the disruption ends.

Quality Cannot Be Added Overnight

A company can redesign the shape of a vehicle.

It can install a smaller engine.

It can introduce a compact model.

It can publish new fuel-economy numbers.

But mature quality cannot be created merely by changing the specification.

Quality depends on an entire system:

  • Product design.
  • Material selection.
  • Supplier relationships.
  • Manufacturing discipline.
  • Process control.
  • Testing.
  • Feedback.
  • Workforce knowledge.
  • Management priorities.
  • Willingness to correct recurring defects.
  • Years of learning what fails and why.

When organizations attempt to reproduce only the visible features of a successful product, they may copy the appearance without reproducing the capability behind it.

A smaller engine does not automatically create a dependable small car.

A modern interface does not automatically create good software.

A new medical facility does not automatically create excellent care.

A quality label does not automatically create a quality system.

You can imitate the product faster than you can imitate the discipline that made it trustworthy.

Quality Has Memory

Every customer interaction leaves evidence.

The product worked.

Or it did not.

The appointment began on time.

Or it did not.

The system recovered successfully.

Or it did not.

The organization kept its promise.

Or it did not.

Customers remember these outcomes.

Markets remember them collectively.

A company does not begin every morning with a blank reputation.

Today’s product enters the market carrying yesterday’s experiences with it.

When quality has been strong, the next product receives the benefit of accumulated confidence.

Customers are more willing to try it.

Reviewers are more willing to believe it.

Partners are more willing to support it.

Employees are more willing to stand behind it.

When quality has been poor, the opposite occurs.

Even an improved product begins under suspicion.

Every new offering inherits the reputation of what came before it.

The Compounding Cycle

Quality compounds through a reinforcing cycle.

A quality product creates satisfaction.

Satisfaction creates trust.

Trust creates repeat business.

Repeat business creates revenue and market share.

That growth creates more opportunities to learn.

Learning improves the process.

The improved process creates better quality.

Then the cycle begins again from a stronger position.

The compounding is not purely financial.

It accumulates in:

  • Knowledge.
  • Experience.
  • Customer loyalty.
  • Employee confidence.
  • Supplier relationships.
  • Operational maturity.
  • Brand recognition.
  • Diagnostic ability.
  • Design judgment.
  • Institutional memory.

Over time, the organization is no longer merely producing quality results.

It is becoming better equipped to produce them.

Quality compounds because every dependable result strengthens the system that produces the next one.

Defects Compound Too

The cycle works in both directions.

Poor quality also compounds.

A defect creates dissatisfaction.

Dissatisfaction creates support demand.

Support demand consumes resources.

Those resources are no longer available for improvement.

Teams rush.

Rushed work introduces more defects.

Customers lose confidence.

Revenue weakens.

Experienced employees become frustrated and leave.

The organization loses knowledge.

Quality declines further.

A small quality problem that is ignored does not remain isolated.

It begins creating conditions that make additional quality problems more likely.

Quality compounds into confidence. Neglect compounds into recovery work.

Trust Takes Longer to Restore

A company can improve its product faster than it can improve its reputation.

The engineering team may correct the defect.

The factory may adopt better controls.

The software may be rewritten.

The clinical process may be redesigned.

But customers cannot immediately see the internal transformation.

They see only the next result.

Then the next.

And the next.

The same repetition that originally built confidence is required to rebuild it.

One strong release does not erase years of frustration.

One successful appointment does not repair a history of poor care.

One stable month does not restore confidence in a system known for outages.

Trust returns only when improved quality persists long enough to become the new expectation.

Quality may be repaired in the product before it is repaired in the customer’s memory.

Two Generations of Trust

When trust has been deeply damaged, recovery may extend beyond the customers who experienced the original failure.

Parents tell children which brands they trust.

Engineers warn new employees about systems that once failed.

Communities remember how organizations treated them.

Patients share stories about healthcare providers.

Teams inherit assumptions from the people who trained them.

Reputation travels socially.

A lesson learned by one generation may shape the buying decisions of the next.

That is why restoring trust can feel disproportionately difficult.

The organization is not competing only against the quality of another product.

It is competing against accumulated memory.

A reputation can outlive the conditions that created it.

Market Share Is Borrowed Confidence

Market share is often described through sales numbers.

But beneath those numbers is a decision repeated by many people:

“I believe this product is more likely to meet my needs than the alternatives.”

That belief may come from personal experience.

It may come from the experience of friends.

It may come from reviews, service records, professional recommendations, or decades of brand reputation.

Market share therefore represents more than successful advertising.

It represents confidence converted into choice.

An organization can temporarily purchase attention through promotion.

It can discount prices.

It can benefit from tariffs, incentives, scarcity, or regulation.

Those forces may influence the decision.

But they cannot permanently substitute for quality.

The customer eventually encounters the product itself.

Attention can be purchased. Preference must be earned.

Protection Does Not Create Quality

Organizations sometimes respond to competitive pressure by seeking protection.

Tariffs may increase the price of competing goods.

Regulations may favor domestic providers.

Contracts may make switching difficult.

Market dominance may reduce alternatives.

Internal politics may protect a failing system.

These measures can provide time.

Time can be valuable when it is used to improve.

But protection does not itself create quality.

It can even conceal the urgency of the problem.

A protected organization may preserve market share temporarily while continuing to fall behind in capability.

The advantage lasts only as long as the protection.

Quality creates an advantage that customers carry voluntarily.

Protection may delay the consequences of poor quality. It cannot transform poor quality into excellence.

Quality in Systems

A technical system earns confidence through repeated behavior.

It deploys cleanly.

It produces accurate results.

It handles expected failures.

It exposes useful errors.

It restores successfully.

It performs within known limits.

It protects data.

It behaves consistently across environments.

Each successful operation strengthens confidence in the system.

That confidence changes behavior.

Teams become willing to automate around it.

Customers adopt it more broadly.

Leaders permit it to support more critical work.

Engineers build new capabilities on top of it.

The system’s quality creates additional opportunity.

But once more depends on it, the consequences of declining quality also become greater.

Quality earns a system the privilege of becoming important.

Quality in Hardware

Hardware quality is rarely visible at first glance.

Two devices may look nearly identical.

Both may function on the first day.

The difference appears over time:

  • One tolerates heat better.
  • One uses stronger components.
  • One survives vibration.
  • One maintains performance under sustained load.
  • One fails predictably rather than destructively.
  • One can be repaired.
  • One receives replacement parts.
  • One is supported by accurate documentation.

Customers learn these differences through ownership.

A manufacturer that repeatedly produces durable hardware gains the benefit of every device still operating years later.

Each surviving product becomes evidence for the next purchase.

Durability is quality continuing to speak after the sale is complete.

Quality in Healthcare

Healthcare reputations compound through countless human experiences.

A patient remembers whether they were heard.

Whether the diagnosis was careful.

Whether results were communicated.

Whether medications were accurate.

Whether the team coordinated care.

Whether the same standard appeared at the next visit.

Clinical quality matters profoundly.

So does operational quality.

A brilliant physician working inside an unreliable system may still produce a poor patient experience.

Missed follow-ups, inconsistent records, scheduling failures, confusing billing, and fragmented communication can erode confidence in otherwise excellent care.

Likewise, one positive interaction cannot compensate indefinitely for a system that repeatedly fails patients.

In healthcare, quality is not one successful procedure. It is the dependable coordination of every action surrounding the patient.

Quality in People

The Principle applies to personal reputation as well.

One excellent performance may reveal talent.

Repeated excellent performance reveals discipline.

A person who consistently produces quality work receives greater responsibility.

Greater responsibility creates more experience.

Experience improves judgment.

Improved judgment increases the quality of future work.

The person’s opportunities compound alongside their capability.

But personal quality includes more than technical output.

It includes:

  • Preparation.
  • Honesty.
  • Follow-through.
  • Care.
  • Accuracy.
  • Willingness to revise.
  • Respect for others.
  • Ownership of mistakes.
  • Attention to details that affect the outcome.

Talent may open the first door. Quality determines how many doors remain open afterward.

Quality Is a System, Not an Inspection

Inspection can detect defects.

It cannot create quality by itself.

If quality is considered only at the end, the organization must discover problems after effort, materials, time, and customer expectations have already been invested.

Quality must begin earlier.

It belongs in:

  • Requirements.
  • Design.
  • Architecture.
  • Procurement.
  • Development.
  • Testing.
  • Deployment.
  • Operations.
  • Support.
  • Feedback.
  • Improvement.

The objective is not merely to catch bad output.

It is to design work that produces less bad output.

Inspection finds quality problems. A quality system makes them less likely to exist.

Quality Requires Feedback

No organization can improve quality without learning from reality.

Assumptions must meet evidence.

Products must meet customers.

Systems must meet workloads.

Processes must meet exceptions.

Feedback reveals the distance between intention and outcome.

Useful feedback may come from:

  • Defect reports.
  • Customer complaints.
  • Return rates.
  • Support cases.
  • Performance measurements.
  • Clinical outcomes.
  • Reliability testing.
  • Post-incident reviews.
  • Employee observations.
  • Lost sales.
  • Repeated workarounds.
  • Near misses.

A mature organization does not treat every complaint as an attack.

It asks what the complaint may reveal.

Feedback is the interest quality pays on attention.

Quality Must Be Reproduced

A brilliant result created through extraordinary effort is difficult to compound.

If every success requires heroics, the system is not yet mature.

Quality compounds when it can be reproduced under ordinary conditions.

That connects directly to consistency.

The method must work:

  • Across teams.
  • Across locations.
  • Across shifts.
  • Across deployments.
  • Across customers.
  • Across time.

This does not require identical treatment in every circumstance.

It requires a dependable standard adapted intelligently to the context.

Quality becomes an organizational advantage only when excellence no longer depends on an exceptional day.

Quality and Confidence Collaborate

Consistency without quality creates predictable disappointment.

Quality without consistency creates uncertain excellence.

Neither is enough.

A customer must receive something worth trusting.

Then they must receive it often enough for trust to form.

Quality creates the reason for confidence.

Consistency supplies the evidence.

Together, they create reputation.

Quality gives confidence its foundation. Consistency gives confidence its history.

Improve the Standard

Quality compounds only when repetition includes learning.

Producing the same acceptable result forever may preserve confidence, but it eventually allows others to surpass it.

Standards should stabilize what works.

Feedback should improve the standard.

The organization must be able to say:

“This is how we produce quality today.”

And later:

“This is what we learned, and this is how we will produce it better tomorrow.”

Quality should be dependable without becoming stationary.

The purpose of a standard is not to freeze quality. It is to give improvement a stable place to begin.

In Practice

To allow quality to compound:

  • Define what quality means for the customer.
  • Build quality into the process rather than relying only on final inspection.
  • Measure outcomes that actually matter.
  • Make successful work repeatable.
  • Capture defects and near misses.
  • Investigate recurring failures rather than repeatedly treating symptoms.
  • Preserve lessons learned.
  • Improve standards when evidence supports change.
  • Give teams enough time to correct foundational problems.
  • Avoid incentives that reward speed while hiding rework.
  • Make ownership of quality visible.
  • Treat customer confidence as an asset.
  • Remember that every release contributes to the reputation of the next one.
  • Ensure improvement continues after the immediate crisis passes.
  • Build systems that become more capable through use rather than more fragile.

Ask:

“Will completing this work improve only today’s outcome, or will it also improve our ability to produce quality tomorrow?”

Failure Modes

Quality can become an empty slogan.

Organizations may display quality statements while rewarding volume, speed, or cost reduction regardless of defects.

They may treat inspection as proof of quality while ignoring the process producing the failures.

They may pursue perfection where good performance would be sufficient.

They may add controls that increase bureaucracy without improving outcomes.

Quality must remain connected to purpose.

A product can be beautifully manufactured and still solve the wrong problem.

A system can be technically perfect and unusable.

A healthcare process can satisfy internal metrics while frustrating patients.

Quality is not maximal effort applied indiscriminately.

It is dependable excellence in the characteristics that matter.

There is also danger in assuming that a strong reputation will protect an organization forever.

Past quality creates opportunity.

It does not excuse current decline.

A reputation built over decades can be borrowed by today’s product, but it must be repaid through today’s quality.

Questions to Ask Yourself

  • What does quality mean to the person receiving this?
  • Which characteristics most influence confidence?
  • Are we producing quality or merely inspecting for defects?
  • Can this result be reproduced under ordinary conditions?
  • What is each failure teaching us?
  • Are repeated problems consuming the resources needed for improvement?
  • Does today’s work make tomorrow’s work better?
  • Are our incentives aligned with quality?
  • What reputation will this outcome contribute to?
  • Are customers choosing us because of habit, protection, or earned confidence?
  • Has our standard improved as our knowledge has improved?
  • Are we relying on past quality to excuse present decline?
  • Is excellence embedded in the system or dependent on heroics?

Closing Thought

Quality rarely captures a market in a single moment.

It earns one customer.

Then another.

It produces one dependable result.

Then another.

Each success strengthens confidence in the next.

Each lesson improves the system that follows.

Over time, quality becomes more than a characteristic of the product.

It becomes the reputation of the organization, the confidence of the customer, the knowledge of the workforce, and the foundation of future opportunity.

Quality compounds when every good result makes the next good result more likely—and makes others more willing to trust that it will arrive.

Principle XIV — Details Matter

Foundational Truth

A number is only a number.

It may describe the size of a problem.

It may reveal a pattern.

It may show movement over time.

But the number alone does not tell the whole story.

The details explain what produced it, what it means, and what should happen next.

Metrics point us toward the problem. Details reveal the truth behind it.

The Number Is Not the Story

Numbers are useful because they compress information.

A report can summarize thousands of events into a few measurements.

A manager can review productivity.

A physician can review test results.

An engineer can review performance.

A teacher can review grades.

A government can review unemployment, inflation, crime, or public health data.

That compression is valuable.

Without it, large systems would become impossible to observe.

But compression always removes context.

Two identical numbers may have been produced by entirely different circumstances.

Two employees may have the same output.

One may be learning quickly in a difficult assignment.

The other may be avoiding complex work while selecting only the easiest tasks.

Two systems may show the same error rate.

One may be experiencing harmless retries.

The other may be silently losing important transactions.

Two patients may report the same symptom.

One may need rest.

The other may need immediate intervention.

The number creates similarity.

The details reveal difference.

Equal measurements do not always describe equal situations.

Managing by the Numbers

Many average managers manage almost entirely through reports.

They review totals.

Rankings.

Percentages.

Targets.

Dashboards.

Red, yellow, and green indicators.

Then they make decisions as though the report contains the person.

It does not.

Performance metrics can reveal that an employee is below expectation.

They cannot, by themselves, explain why.

The employee may lack training.

They may be assigned the most difficult cases.

They may be resolving problems that take longer but create greater value.

They may be new to the role.

They may have extraordinary potential but need coaching.

They may be in the wrong position.

They may be disengaged.

They may be struggling with circumstances outside work.

They may simply be unwilling to meet the standard.

Those possibilities require different responses.

Coaching is appropriate for one.

Training for another.

A change in role for another.

Clear accountability for another.

No responsible manager can know which response is appropriate merely by looking at the final number.

Management begins with measurement, but leadership begins when someone asks what produced it.

Not All Underperformers Are Alike

Two people may miss the same target.

That does not make them the same employee.

One may be working hard but using the wrong method.

One may understand the work but lack confidence.

One may have been given incomplete instructions.

One may have inherited a damaged customer relationship.

One may be performing responsibilities that are not represented in the metric.

One may have strong potential but little experience.

Another may lack the interest, temperament, or capability required for the role.

Their numbers may look alike.

Their paths forward may be completely different.

Treating them identically is easier for the manager.

It is not necessarily fair to the employee or useful to the organization.

Fairness does not always mean giving everyone the same response. It means responding honestly to the situation that actually exists.

Potential Hides in the Details

Some employees appear ordinary when measured only by current output.

But their details reveal something more.

They ask strong questions.

They absorb feedback.

They improve quickly.

They take ownership.

They support teammates.

They recognize patterns others miss.

They remain calm under pressure.

They care about the quality of the result.

Their current performance may not yet be exceptional.

Their trajectory may be.

A thoughtful leader does not evaluate only where someone stands.

They also observe the direction in which that person is moving.

Performance describes the present. Potential is often visible in the pattern behind it.

Not All High Performers Are Your Best Employees

High numbers can also mislead.

An employee may appear exceptional because they understand how the metric is calculated.

They may optimize their behavior around the number rather than the purpose behind it.

They may select easy work.

Avoid difficult customers.

Close cases prematurely.

Transfer problems to others.

Delay tasks that would reduce their average.

Claim credit for collaborative work.

Produce volume while creating rework downstream.

Ignore responsibilities that are important but difficult to measure.

The dashboard shows success.

The surrounding system carries the cost.

Meanwhile, another employee may appear less productive because they accept the difficult cases, mentor others, repair incomplete work, and solve problems thoroughly enough that they do not return.

The first employee produces a better metric.

The second may produce a better organization.

A high score does not always indicate high value. Sometimes it only indicates mastery of the scoring system.

When the Measure Becomes the Target

Measurements are created to represent reality.

But once rewards, promotions, penalties, or recognition become attached to them, people begin changing their behavior.

This is not always dishonest.

People naturally respond to incentives.

If speed is rewarded, work becomes faster.

If volume is rewarded, output increases.

If customer satisfaction is rewarded, more attention may be given to the customer.

But every measure captures only part of the desired result.

Simon Sinek wrote:

“People don’t buy what you do; they buy why you do it.”

The same distinction applies inside an organization.

The what is often easy to measure:

  • Tickets closed.
  • Calls completed.
  • Units produced.
  • Revenue booked.
  • Appointments processed.

The why is the purpose those activities are meant to serve:

  • Problems resolved.
  • Customers helped.
  • Products made well.
  • Needs understood.
  • Patients cared for.

When people are rewarded only for the visible activity, they may preserve the what while abandoning the why.

A support organization can reduce resolution time by closing tickets too early.

A hospital can improve a metric by redirecting difficult patients elsewhere.

A sales team can increase revenue by creating commitments the delivery team cannot fulfill.

A school can improve test scores while narrowing education to what appears on the test.

The moment a measure becomes the goal, we must watch carefully for what the measure no longer reveals.

Details Reveal the Hidden Work

Some of the most valuable work is difficult to count.

Preventing an incident.

Mentoring a colleague.

Calming an unhappy customer.

Documenting a process.

Correcting a risk before it becomes visible.

Building trust.

Asking the question that prevents the wrong project from moving forward.

Helping another person succeed without claiming credit.

These contributions may not appear in the most convenient report.

That does not make them unimportant.

Metrics tend to reward visible output.

Details often reveal the invisible work that made the visible output possible.

What is easiest to count is not always what matters most.

Details Matter in Engineering

A system is slow.

That statement is not yet useful.

Slow for whom?

During which operation?

At what time?

Under what load?

In which environment?

Did latency increase in the application, database, network, storage layer, or an external service?

Did the average increase, or only the highest percentile?

Did one customer experience the problem, or everyone?

Was the system actually slow, or did a timeout occur elsewhere?

The metric points toward the problem.

The details locate it.

An engineer who reacts only to the headline number may scale the wrong component, restart the wrong service, or hide the symptom without correcting the cause.

Troubleshooting begins when the general observation becomes a specific question.

Details Matter in Healthcare

A patient has a fever.

A blood pressure reading is elevated.

A laboratory value falls outside the normal range.

A scan reveals an abnormality.

Each measurement matters.

But none should be interpreted without context.

Age matters.

Medical history matters.

Medications matter.

Duration matters.

Associated symptoms matter.

Recent procedures matter.

Baseline values matter.

The difference between an unusual number and a dangerous condition often lives in the surrounding details.

Healthcare becomes unsafe when people are reduced to isolated measurements.

A test result is evidence about a patient. It is not the patient.

Details Matter in Relationships

A child takes a toy from another child.

The visible event appears simple.

One child took something.

The other became upset.

But even among toddlers, the details may matter.

Was the toy abandoned?

Was it taken by force?

Had the children been sharing?

Did one misunderstand the game?

Was one child excluded repeatedly?

Was the reaction about this toy or the fifth similar event that morning?

The response should still be simple and appropriate for their age.

But understanding the details allows an adult to teach rather than merely punish.

The objective is not only to stop the immediate conflict.

It is to help children understand boundaries, sharing, communication, and the feelings of others.

Correction becomes more useful when it addresses the reason, not only the visible act.

Details Matter at Every Scale

The same principle extends from a disagreement over a toy to disputes involving communities, corporations, sovereign nations, and armed groups.

At greater scale, the details become more complex.

History matters.

Borders matter.

Treaties matter.

Resources matter.

Identity matters.

Security fears matter.

Leadership incentives matter.

Past violence matters.

Civilian experience matters.

Propaganda matters.

External influence matters.

This does not mean every action is justified by its context.

Understanding is not the same as approval.

Details do not erase responsibility.

They help explain what produced the situation and what actions may improve it.

A response based only on the latest visible event may intensify the conditions that caused it.

Context does not excuse every action, but without context we may choose actions that make the problem worse.

Facts Before Judgment

Human beings are remarkably good at forming conclusions.

We are far less disciplined about gathering evidence first.

A single number.

A single conversation.

A single news headline.

A single review.

A single interaction.

Each provides only a fragment of reality.

The details help us determine whether our first impression deserves our confidence.

Responsible judgment begins with curiosity.

It asks:

What happened?

What led to it?

What evidence supports this conclusion?

What evidence challenges it?

What am I missing?

The first explanation is often the easiest—not necessarily the truest.

The Story Behind the Average

Averages simplify complexity.

Sometimes they simplify it too much.

A department may average excellent customer satisfaction while one location struggles.

A student may earn an average grade despite mastering some subjects and failing others.

A business may report average profitability while one product quietly loses money.

An infrastructure platform may appear healthy while one critical component approaches failure.

The average conceals variation.

Variation often contains the most valuable information.

The average describes the crowd. Improvement often begins by understanding the exceptions.

Outliers Are Often Clues

Organizations sometimes dismiss unusual events because they are rare.

Engineers call them edge cases.

Analysts call them anomalies.

Managers call them exceptions.

Scientists call them unexpected observations.

Sometimes they are merely noise.

Sometimes they reveal the beginning of a larger pattern.

Many discoveries begin as an outlier that someone refused to ignore.

Likewise, many failures begin as a small exception that everyone assumed would never happen again.

The challenge is not treating every exception as a crisis.

It is refusing to dismiss every exception as unimportant.

An outlier is not always a mistake. Sometimes it is reality introducing itself before everyone else notices.

Details Create Better Questions

The purpose of gathering details is not to accumulate information forever.

It is to improve the questions we ask.

Instead of asking:

“Who made the mistake?”

We ask:

“What conditions allowed the mistake to happen?”

Instead of asking:

“Who should we blame?”

We ask:

“How do we prevent this from happening again?”

Instead of asking:

“Why is this person underperforming?”

We ask:

“What obstacles are limiting success?”

Better questions produce better investigations.

Better investigations produce better decisions.

Questions shape the quality of the answers we receive.

Details Without Losing the Whole

There is another danger.

One can become so fascinated by details that the larger picture disappears.

Every decision eventually reaches the point where additional information provides little additional value.

Analysis becomes delay.

Perfection becomes paralysis.

Leaders must know when enough evidence exists to act.

The purpose of details is better decisions.

Not endless investigation.

Wisdom lives between two extremes.

Too little information creates reckless decisions.

Too much information prevents decisions entirely.

Details should sharpen judgment, not replace it.

Detail Is Not Micromanagement

Some leaders avoid asking questions because they fear becoming micromanagers.

Others demand every detail because they confuse information with control.

Neither approach serves people well.

Micromanagement attempts to control every action.

Attention to detail attempts to understand reality.

One removes ownership.

The other improves understanding.

Healthy leadership moves comfortably between altitude and ground level.

It understands the broad direction while remaining willing to descend into the details whenever the situation requires.

Then it returns to the larger view.

Great leaders know when to zoom in—and when to zoom back out.

Details Protect Fairness

Fairness requires more than equal treatment.

It requires honest understanding.

When we ignore details, we often reward appearances instead of contribution.

We may praise the loudest voice rather than the wisest.

We may discipline the person closest to the problem instead of the person who created it.

We may promote confidence over competence.

The details do not guarantee fairness.

But without them, fairness becomes little more than guesswork.

Justice begins by seeing clearly before deciding confidently.

Details Preserve Humanity

Systems naturally reduce people to categories.

Employee.

Customer.

Patient.

Student.

Citizen.

User.

Each label serves a purpose.

None captures the whole person.

The details remind us that every number represents a human story.

Every ticket belongs to someone frustrated.

Every diagnosis belongs to someone afraid.

Every employee evaluation belongs to someone trying to build a life.

Every statistic contains individual experiences that disappear when viewed only from a distance.

The larger our systems become, the more intentional we must be about remembering the people inside them.

The details remind us that behind every metric is a person.

In Practice

When you encounter a number that surprises you:

Pause before drawing conclusions.

Ask what the measurement actually represents.

Identify what it does not represent.

Look for the surrounding circumstances.

Seek multiple perspectives.

Separate observation from interpretation.

Then decide.

This process is slower than reacting.

It is also more likely to produce a decision that solves the real problem instead of merely responding to the visible symptom.

Failure Modes

Ignoring details can lead to:

  • Managing appearances instead of outcomes.
  • Rewarding the wrong behaviors.
  • Solving symptoms instead of causes.
  • Punishing the wrong people.
  • Missing emerging risks.
  • Oversimplifying complex systems.
  • Mistaking correlation for causation.
  • Losing trust through unfair decisions.

Focusing only on details can also create problems:

  • Analysis paralysis.
  • Endless investigation.
  • Delayed action.
  • Loss of strategic perspective.
  • Micromanagement.
  • Difficulty making timely decisions.

Wisdom requires balancing both views.

Questions to Ask Yourself

When I reach a conclusion, what evidence am I relying on?

What important details might still be missing?

Am I measuring the right thing?

Does this metric reflect the purpose I actually care about?

What assumptions am I making?

Could someone else reasonably interpret these facts differently?

Have I mistaken a symptom for a cause?

What would change my mind?

Closing Thought

Numbers help us see patterns.

Details help us understand reality.

The most effective leaders, engineers, teachers, physicians, parents, and citizens learn to move comfortably between both perspectives.

They use measurements to find where attention is needed.

Then they use details to discover what deserves to be done.

A number tells us that something happened. The details tell us what happened, why it happened, and what we might do to make it better.

Founder’s Commentary

Why This Principle Exists

Modern organizations measure almost everything.

Dashboards are updated in real time.

Key performance indicators are reviewed weekly.

Artificial intelligence can summarize millions of records in seconds.

Yet poor decisions continue to occur because measurements are often mistaken for understanding.

This Principle reminds us that metrics are invaluable, but they are not reality.

They are representations of reality.

Wise leaders know when to leave the dashboard and investigate the story behind it.

Start with Why

This chapter intentionally includes a single quotation from Simon Sinek:

“People don’t buy what you do; they buy why you do it.”

The quotation reinforces an important distinction.

Organizations frequently become excellent at measuring what people accomplish while slowly forgetting why those activities exist.

The Principle is not about rejecting measurement.

It is about ensuring that purpose remains connected to performance.

Relationship to Other Principles

This Principle naturally follows Quality Compounds.

Quality requires careful attention to details.

Without details, quality eventually becomes appearance.

Without quality, confidence eventually fades.

Together these Principles encourage thoughtful observation before confident action.

Universality Test

This Principle applies equally to:

  • Families
  • Classrooms
  • Hospitals
  • Engineering teams
  • Businesses
  • Governments
  • Scientific research
  • Military planning
  • International diplomacy
  • Personal relationships

Anywhere people rely on measurements to make decisions, the surrounding details remain essential.

They are where understanding lives.

Principle XV — Leave It Better Than You Found It

Foundational Truth

We inherit more than we create.

We inherit the natural world.

We inherit institutions.

We inherit organizations.

We inherit infrastructure.

We inherit software.

We inherit traditions.

We inherit unfinished work.

Very little of what surrounds us was created by us.

Yet while these things are in our care, they become our responsibility.

We inherit conditions we did not create, but we are still responsible for what happens while they are in our care.

We Did Not Build the Environment

We did not create the forests, rivers, oceans, or atmosphere.

Nature existed long before us and, with good stewardship, will continue long after us.

Our responsibility is not ownership.

It is stewardship.

The question is not whether we created the world.

The question is whether we leave it healthier, cleaner, and more resilient than we found it.

We Did Not Architect the System

Most professionals inherit systems designed by someone else.

We maintain servers we did not install.

We troubleshoot applications we did not write.

We support networks we did not design.

We inherit technical debt we did not create.

None of those facts reduce our responsibility.

Maintenance is only the threshold.

Professional stewardship means improving what has been entrusted to us.

Make it more secure.

Make it easier to understand.

Make it more resilient.

Document it.

Remove unnecessary complexity.

Reduce future risk.

You may inherit the architecture, but you still shape its future.

Maintenance Is Only the Threshold

Keeping something operational is the minimum expectation.

Stewardship asks more.

Can it be stronger?

Safer?

Cleaner?

Simpler?

Better documented?

More resilient?

Every improvement reduces the burden on those who follow.

A Job Worth Doing

My grandmother often said:

“A job worth doing is a job worth doing right—the first time.”

That does not mean perfection is always possible.

It means we should never knowingly leave avoidable problems for someone else because correcting them is inconvenient.

Craftsmanship is not measured by what passes inspection.

It is measured by what continues working long after we have moved on.

Responsibility Without Blame

We often inherit problems we did not create.

Broken processes.

Poor documentation.

Outdated policies.

Environmental damage.

Aging infrastructure.

Institutional weaknesses.

The easy response is blame.

The responsible response is stewardship.

Responsibility does not require guilt for the past. It requires ownership of the future.

Leave It Better

Leave your code better.

Leave your documentation better.

Leave your team better.

Leave your organization better.

Leave your community better.

Leave your environment better.

Leave your country better.

Leave people better than you found them.

The scale changes.

The responsibility does not.

The Generational Test

Every generation inherits both blessings and burdens.

The question history eventually asks is simple:

Did we strengthen what was entrusted to us?

Or did we consume its benefits while leaving the costs to those who followed?

You are not responsible for everything that came before you. You are responsible for what you pass on.

Closing Thought

We may not have built the world we inherited.

But every decision we make helps build the world someone else will inherit from us.

Temporary Fixes Become Permanent Burdens

Most temporary solutions last far longer than anyone intends.

A shortcut becomes standard practice.

A quick script becomes production software.

A workaround becomes institutional knowledge.

A missing document becomes tribal knowledge.

Deferred maintenance becomes technical debt.

The next person inherits every compromise we choose not to resolve.

Every shortcut has an eventual owner. Make sure it is not someone else.

The Next Person Is Your Customer

Often, the next person who touches your work will never meet you.

It may be another engineer.

A new employee.

A customer.

A volunteer.

A family member.

Your future self.

Good stewardship respects people we may never know.

Clean documentation.

Clear naming.

Thoughtful organization.

Reliable testing.

Predictable behavior.

Each one is a quiet act of generosity.

Leave instructions, not mysteries.

Stewardship Requires Care

The difference between acceptable work and exceptional work is rarely intelligence.

More often, it is care.

People who care notice the loose bolt.

They update the document.

They sweep the floor.

They remove the obsolete firewall rule.

They fix the warning before it becomes an outage.

They ask whether something can be better instead of whether it is merely good enough.

Care cannot always be measured.

Its results can.

Leave Technology Better

Every system accumulates entropy.

Security drifts.

Documentation ages.

Dependencies become outdated.

Threats evolve.

The responsible professional continually strengthens the systems they maintain.

Harden them against attack.

Reduce unnecessary complexity.

Automate repetitive work.

Remove obsolete components.

Improve observability.

Design for recovery instead of assuming failure will never occur.

Resilience is built one thoughtful improvement at a time.

Leave Organizations Better

Organizations also require stewardship.

Processes should become clearer.

Knowledge should become easier to share.

Future leaders should be developed before they are needed.

Healthy cultures are created through thousands of small decisions repeated consistently over time.

When people leave an organization stronger than they found it, the organization becomes stronger than it was before they arrived.

Leave People Better

Perhaps our greatest responsibility is to people.

Every conversation teaches something.

Every correction leaves an impression.

Every encouragement builds confidence.

Every act of patience creates possibility.

Knowledge multiplies when it is shared.

Experience becomes legacy when it is taught.

Success is measured not only by what we accomplish ourselves, but by what others become because we invested in them.

The greatest improvements are often measured in people, not projects.

Leave Communities Better

Communities are built through ordinary people making ordinary decisions repeatedly over time.

A neighborhood becomes cleaner because someone picked up litter that was not theirs.

A volunteer stays late.

A coach teaches one more lesson.

A citizen attends one more meeting.

A business owner hires and mentors someone new.

Healthy communities are rarely transformed by one extraordinary act.

They are strengthened by countless ordinary acts of stewardship.

Communities improve when enough people decide that someone should be them.

Leave Institutions Better

Every generation inherits institutions it did not create.

Schools.

Courts.

Hospitals.

Businesses.

Charities.

Governments.

Some work remarkably well.

Others need repair.

Some traditions deserve preservation.

Others deserve thoughtful change.

Stewardship requires the wisdom to know the difference.

Destroying everything because some things are broken is not progress.

Preserving everything because it is familiar is not wisdom.

Stewardship preserves what is valuable while improving what is necessary.

Stewardship Is Not Ownership

Ownership often asks:

“What am I allowed to do?”

Stewardship asks:

“What is the right thing to do?”

A steward understands that what has been entrusted to them will eventually belong to someone else.

That perspective changes decisions.

It encourages long-term thinking over short-term convenience.

It values sustainability over exploitation.

It favors investment over extraction.

Good stewards think beyond the length of their own involvement.

Improvement Without Destruction

Not everything old is obsolete.

Not everything new is better.

Progress requires discernment.

The strongest bridges are repaired rather than abandoned.

The healthiest organizations improve proven processes instead of replacing them simply because they are old.

Wise engineers modernize systems without discarding the lessons that made them successful.

The goal is not constant change.

The goal is continuous improvement.

Improvement begins by understanding what deserves to remain.

The Legacy We Leave

Every decision becomes part of someone else’s starting point.

Every improvement becomes another person’s foundation.

Every neglected responsibility becomes another person’s obstacle.

Long after our names are forgotten, the effects of our choices often remain.

This is true in families.

It is true in engineering.

It is true in leadership.

It is true in citizenship.

Legacy is rarely created in a single moment.

It is built through thousands of small choices that consistently place the future ahead of immediate convenience.

Our legacy is not defined by what we possessed. It is defined by what we improved.

Closing Thought

We are temporary custodians of people, places, systems, and opportunities that existed before us and will continue after us.

Character is revealed not by what we inherit, but by what we choose to leave behind.

We may not have built the world we inherited, but every day we help build the world someone else will inherit from us.

Principle XVI — Documentation Is a Feature

Foundational Truth

Documentation is not administrative overhead.

It is not the final box to check after the real work is complete.

It is part of the solution.

If the work is not documented, the work is not finished.

A system without documentation may function today.

That does not mean it can be understood tomorrow.

What We Forget

I have worked in information technology for more than twenty years, and I still have text files saved in the cloud from 1999.

Some of them document solutions I developed during Y2K.

The technology has changed.

The systems have changed.

The people have changed.

But the value of the documentation remains.

I have forgotten more than most people will ever know in this industry.

That is not arrogance.

It is the natural consequence of time, complexity, and a career spent solving thousands of problems.

Human memory is not a reliable knowledge-management platform.

Documentation preserves what experience eventually erases.

The Two-Paragraph README

I routinely see engineers build enormous solutions.

They ask me to help test them.

We work through design problems, edge cases, failures, and recovery paths.

Then I ask a simple question:

“Where is the documentation?”

Sometimes they point to a two-paragraph README.

Sometimes they point to scattered comments in the code.

Sometimes they look at me as though I just ruined their first date.

The assumption is that the solution itself is the accomplishment.

It is not.

A solution that only its creator understands is not complete.

It is a dependency disguised as an achievement.

Documentation Is Part of the Product

A feature is not complete merely because it works.

It must be understandable.

Supportable.

Recoverable.

Transferable.

Auditable.

Repeatable.

Documentation is what makes those qualities possible.

The code may tell you what the system does.

It rarely tells you why it was built that way.

It does not reliably explain what alternatives were rejected.

It does not capture the incident that forced the design.

It does not preserve the operational knowledge required at two in the morning when the original engineer is unavailable.

Code explains behavior. Documentation preserves intent.

You Should Get Credit for the Recovery

Imagine that you spent three days without sleep overseeing the rollback of a change that took down the eastern seaboard.

You diagnosed the failure.

You coordinated the recovery.

You restored service.

You prevented further damage.

That work matters.

You should receive credit for it.

But if you did not document it, the work is only partially complete.

The organization may remember the recovery for a few weeks.

The people involved may remember it for a few years.

Eventually, the details disappear.

When they disappear, the organization loses the value of the lesson.

The incident becomes pain without progress.

The Thirty-Forty-Thirty Rule

For a major incident or complex change, I think of the work in three parts:

Thirty Percent: What Happened

Document the event.

What changed?

What failed?

When did it begin?

What systems were affected?

What symptoms were observed?

What decisions were made?

This creates the factual record.

Forty Percent: How We Recovered

Document the recovery in enough detail that another qualified person could repeat it.

What stopped the damage?

What restored service?

What commands were run?

What dependencies mattered?

What temporary measures were used?

What verification proved the environment was healthy?

Recovery documentation is often the most operationally valuable part of the entire event.

Thirty Percent: Cause of Event

Every significant incident should end with a formal Cause of Event.

Not a blame document.

Not a political exercise.

Not a collection of vague statements.

A Cause of Event should explain:

  • what actually failed
  • why safeguards did not prevent it
  • why detection did not occur sooner
  • what made recovery difficult
  • what must change to prevent recurrence

An incident is not closed when service is restored. It is closed when the organization understands what happened and has acted on what it learned.

Recover in Minutes, Not Days

Good documentation changes the next incident.

Without it, teams rediscover the problem from the beginning.

They repeat old tests.

They search old logs.

They contact former employees.

They argue over incomplete memories.

They lose hours proving what someone already knew years earlier.

With good documentation, the response begins further ahead.

The team recognizes the pattern.

They know where to look.

They understand the dependencies.

They follow a tested recovery path.

What once required hours or days can be resolved in minutes.

Documentation turns experience into reusable speed.

The Most Dangerous Dependencies

Every system has dependencies.

Most are obvious.

Some are invisible until everything else has already failed.

One incident I participated in taught this lesson in unforgettable fashion.

A backup generator existed exactly as designed.

Fuel was available.

The contingency plan appeared complete.

But one critical dependency had never been questioned.

The fuel pump that supplied the generator was powered by the generator itself.

When the generator exhausted its immediate fuel supply, it stopped producing electricity.

The moment it stopped, the fuel pump also stopped.

There was fuel available.

There was a generator available.

But there was no way to connect the two because the recovery mechanism depended upon the very system it was attempting to recover.

It was a single design oversight with enormous consequences.

The most dangerous dependencies are often the ones no one realized were dependencies.

That lesson deserved far more than a verbal story.

It deserved documentation.

Institutional Memory

Organizations forget.

Not because people are careless.

Because people move.

They retire.

They change teams.

They accept promotions.

Companies merge.

Knowledge leaves every day.

Without documentation, organizations slowly suffer from institutional amnesia.

Every generation of engineers rediscovers problems that another generation already solved.

The same mistakes are repeated.

The same outages occur.

The same lessons are relearned at full price.

Experience compounds only when knowledge survives the people who gained it.

Documentation Is Leadership

Documentation is often viewed as an engineering task.

It is actually an act of leadership.

When you document your work, you respect the people who will inherit it.

You reduce onboarding time.

You increase confidence.

You eliminate guesswork.

You empower others to succeed without requiring your presence.

The greatest engineers do not make themselves indispensable.

They make the organization resilient without them.

Write for the Person Who Knows Nothing

One of the hardest habits to develop is writing for someone who has no context.

Not because they are unintelligent.

Because they have not lived your experience.

Avoid unexplained acronyms.

Define assumptions.

Record prerequisites.

Explain why decisions were made.

Document failed approaches as well as successful ones.

The goal is not to impress the reader.

The goal is to help them succeed.

Write documentation for the person you once were, not the expert you are today.

Good Documentation Answers Questions

The best documentation anticipates the next question before it is asked.

What does this system do?

Why does it exist?

How is it built?

How do I monitor it?

How do I recover it?

What breaks if I change it?

Who depends on it?

When documentation answers these questions, support becomes predictable instead of investigative.

Closing Thought

Every solution eventually becomes someone else’s inheritance.

Leave them more than functioning systems.

Leave them understanding.

Leave them confidence.

Leave them the knowledge to succeed without having to repeat your mistakes.

Documentation is the only way experience continues working after its author has gone home.

Documentation Builds Trust

Well-documented systems inspire confidence.

Not because they never fail.

Because people know how they work.

They know how to maintain them.

They know how to recover them.

Confidence is not created by perfection.

It is created by understanding.

People trust systems they understand. Documentation creates that understanding.

Documentation Is an Investment

Writing documentation feels slower today.

Searching for missing knowledge is far slower tomorrow.

Every hour invested documenting a system is an hour that may save dozens—or hundreds—of hours over its lifetime.

Documentation compounds exactly like experience.

The return is rarely immediate.

It is almost always substantial.

The Documentation Test

Before declaring any project complete, ask yourself:

Could a competent engineer who has never seen this system successfully operate it?

Recover it?

Upgrade it?

Troubleshoot it?

Explain why it exists?

If the answer is “no,” the project is still incomplete.

Failure Modes

Documentation often fails in predictable ways.

It becomes outdated because nobody owns it.

It becomes enormous because nobody curates it.

It becomes so technical that nobody can read it.

Or it never gets written because everyone intends to “come back later.”

Later rarely arrives.

Documentation should be living knowledge.

Reviewed.

Improved.

Versioned.

Maintained with the same discipline as the systems it describes.

Outdated documentation is frustrating. Missing documentation is dangerous.

In Practice

Before you close a project:

  • Explain what was built.
  • Explain why it was built.
  • Record the assumptions.
  • Identify the dependencies.
  • Document monitoring.
  • Document backups.
  • Document recovery.
  • Record known limitations.
  • Capture lessons learned.
  • Write the Cause of Event after every significant incident.

Future engineers should never have to reverse-engineer your thinking.

Questions to Ask Yourself

  • If I left tomorrow, could someone continue this work?
  • Have I documented why, not just how?
  • What assumptions exist only in my head?
  • Have I captured the recovery process?
  • Would my documentation help someone at two in the morning during a major outage?

Founder’s Commentary

Why This Principle Exists

Technology changes constantly.

Human memory does not improve with complexity.

Every year our systems become larger, more interconnected, and more dependent upon people understanding decisions made years earlier.

Documentation transforms personal knowledge into organizational capability.

It allows experience to survive retirement, promotion, mergers, acquisitions, and the simple passage of time.

That is why I consider documentation a feature—not an afterthought.

Relationship to Other Principles

Documentation supports stewardship.

It leaves systems better than we found them.

It demonstrates that details matter.

It respects the next engineer as much as the current one.

Universality Test

This Principle applies far beyond technology.

Doctors document patient care.

Pilots document incidents.

Scientists document experiments.

Teachers document lesson plans.

Families document history.

Civilizations document knowledge.

Whenever people hope that wisdom survives them, documentation is the mechanism that makes it possible.

Closing Thought

One day, someone you will never meet will inherit something you built.

Whether they inherit confusion or clarity depends on the documentation you leave behind.

Your greatest contribution may not be the system you built. It may be the understanding you left behind.

Principle XVII — Teach Through Building

Foundational Truth

Teaching through building is not limited to teaching other people. You will often teach yourself just as much through a development project as you teach anyone watching you complete it.

I have always been a hands-on learner. I can learn in a classroom, read documentation, and follow the guidance of a capable mentor. Those methods provide the foundation, but they rarely answer every question.

Not because the teacher failed.

Because some questions do not exist yet.

They only appear after you are deep inside the work, when the clean example from the classroom collides with an unexpected dependency, an undocumented limitation, or a wall no one knew was there.

A lesson can explain how something is supposed to work. A project forces you to discover how it actually works.

“What I hear, I forget. What I see, I remember. What I do, I understand.”
— Often attributed to Confucius

The exact origin of that quotation is uncertain, but the lesson it expresses is enduring: understanding becomes deeper when knowledge is put into practice.

The Questions That Do Not Exist Yet

Classroom instruction is valuable because it gives us a map. It introduces the language, explains the principles, and shows us the paths others have already traveled.

But a map cannot predict every obstacle.

There are always lingering questions that remain unanswered—not because the mentor or teacher was careless, but because neither the student nor the teacher could see every question in advance. Some questions only become visible when theory meets a real system, a real deadline, or a real failure.

You may understand the architecture until two components interact in a way the diagram never described. You may understand the process until an undocumented dependency blocks the next step. You may understand the tool until the environment behaves differently from the example.

That unexpected wall is not separate from the lesson.

It is the lesson becoming real.

Building exposes the gaps between theory and reality. It reveals which assumptions were incomplete, which details were overlooked, and which parts of your knowledge were memorized rather than understood.

Building Teaches the Builder

A project does more than test what you know. It teaches you what you did not know enough to ask.

When you build, you are forced to make decisions. You must choose between competing approaches, investigate failures, weigh tradeoffs, and adapt when the original plan no longer fits reality.

Those decisions create a kind of knowledge that cannot be transferred completely through lecture or documentation. It becomes part of you because you earned it through experience.

The obstacle teaches you where the design was weak. The failed attempt teaches you which assumption was wrong. The workaround teaches you what the system truly requires. The recovery teaches you what must be documented before anyone tries it again.

This is why hands-on learning is so powerful. It does not merely provide answers. It reveals the questions.

Teaching Completes the Circle

Teaching others extends that learning even further.

When you explain a subject, people ask questions from perspectives you may never have considered. They notice gaps that have become invisible to you. They challenge assumptions you no longer remember making. Their confusion forces you to clarify your own understanding, and their curiosity may lead you into parts of the subject you had never explored.

The learner is not merely receiving your knowledge. The learner is helping test it.

A question you cannot answer is not a failure of teaching. It is an invitation to deepen the lesson for both of you.

You may discover that you know how to perform a task but cannot yet explain why it works. You may realize that your instructions depend on experience you never wrote down. You may learn that what seemed obvious to you was only obvious because of years of accumulated context.

Teaching reveals those hidden assumptions.

It turns instinct into explanation and experience into knowledge that can be transferred.

The 360-Degree Moment

This creates a complete learning cycle.

You learn enough to begin.

You build enough to encounter what the lesson could not predict.

You struggle enough to replace assumption with understanding.

You teach what you discovered.

Then the questions of others reveal what you still did not know.

Knowledge moves from theory, to experience, to explanation, and then back into deeper understanding.

That is the 360-degree moment.

The teacher becomes the learner again, but returns with better questions, stronger judgment, and a more complete view of the subject.

Teach Beside People

The strongest teachers are not always the people with the most answers. They are often the people willing to build beside others, encounter the unknown honestly, and turn every obstacle into part of the lesson.

Teaching through building does not require pretending that everything is known in advance. In fact, some of the most valuable lessons occur when the answer is not immediately available.

A teacher who says, “I do not know yet, but let us find out,” demonstrates more than technical knowledge. They demonstrate curiosity, humility, persistence, and a repeatable method for confronting the unknown.

That lesson may matter more than the answer itself.

When people watch you troubleshoot, revise an assumption, recover from a mistake, and document what you learned, they are not merely learning how to complete one project. They are learning how to think when the next project does not go according to plan.

In Practice

Teach through building by inviting people into the real process, not merely showing them the polished result.

Explain the goal, but also explain the reasoning behind the approach. Let them see the decisions, tradeoffs, failed attempts, and corrections. Ask them what they notice. Encourage questions that challenge your assumptions. When neither of you knows the answer, investigate it together.

Then document what the project taught you.

The value is not limited to the thing that was built. The project also produces stronger judgment, reusable knowledge, and people who are better prepared for the next unexpected wall.

Questions to Ask Yourself

  • Am I only studying the subject, or am I building with it?
  • What has the project revealed that the lesson did not predict?
  • Which parts of my knowledge can I perform but not yet explain?
  • What questions are other people asking that I have never considered?
  • Am I teaching only the answer, or also the process used to discover it?
  • What should be documented so the next person begins further ahead?

Founder’s Commentary

I have always been a hands-on learner. I can learn in a classroom, and I have benefited from talented teachers and mentors throughout my life. But there are always lingering questions that do not get answered.

That is rarely intentional. Sometimes you simply do not see all the questions that need to be answered until you are knee-deep in the project and facing an unexpected wall.

That is where some of the best learning begins.

The project forces you to confront what you assumed, what you misunderstood, and what no one thought to mention. Then, when you teach someone else, they bring a point of view you may never have considered. Their questions round out your understanding of the subject and often send you back into the work with better questions of your own.

You begin as the student. You become the builder. You become the teacher. Then the person you are teaching makes you a student again.

That is the full circle.

Building creates experience. Teaching reveals understanding. Together they create mastery.

We do not truly understand what we know until we have built with it, struggled through it, and taught it to someone else.

Principle XVIII — Respect the Next Engineer

Respecting the next engineer begins with understanding that no two engineers arrive with the same experience.

We all have strengths, and we all have opportunities to grow. Those differences are shaped by many factors: previous responsibilities, formal training, the quality of past mentorship, exposure to difficult problems, and the level of curiosity a person has brought to the work.

One engineer may be exceptional at troubleshooting but inexperienced with architecture. Another may understand systems deeply but struggle to explain what they know. Someone may have spent years mastering one narrow technology while another has developed broad knowledge across many environments.

None of those differences automatically make one engineer better than another.

They make them different.

By the time someone reaches the engineering level, temperament has usually been tested. The work itself tends to expose people who cannot remain patient, accept correction, work through uncertainty, or take responsibility for their decisions. The engineers who remain may still have different levels of skill, but they have generally demonstrated the ability to learn and contribute.

That deserves respect.

Respecting the next engineer does not mean assuming they already know everything you know. It means refusing to treat unfamiliarity as incompetence.

You may have solved a problem dozens of times that they are encountering for the first time. You may recognize a failure pattern immediately because a similar incident once consumed three days of your life. The next engineer does not yet have access to that experience unless you leave something behind that allows them to benefit from it.

That is where workflows become important.

Not every engineer naturally thinks outside the box. Some people are comfortable experimenting without a clear path. Others work best when the process is defined and the expected outcome is visible. Both can contribute meaningfully.

Every capable engineer can follow a well-designed workflow.

More importantly, the right workflow can teach them how to move beyond it.

A good workflow should not merely say:

Click this button, enter this command, and proceed to the next step.

It should explain what is being tested, what the expected result means, and what decision should follow from each possible outcome.

That turns a checklist into a teaching tool.

An engineer who repeatedly follows a workflow built around observation, validation, and decision-making begins to recognize the reasoning beneath the steps. Eventually, they stop seeing the workflow as a rigid path and begin seeing it as a model for approaching unfamiliar problems.

That is how thinking outside the box can be taught.

You first give someone a reliable box.

You show them how it was constructed, why each wall exists, and what conditions would justify stepping beyond it.

Without that foundation, telling someone to “think outside the box” is not guidance. It is an expectation without instruction.

Respect also means leaving the environment in a condition that allows the next engineer to succeed.

Document what you changed.

Record why you changed it.

Preserve the commands, evidence, assumptions, dependencies, and rollback path.

Do not leave behind a puzzle simply because you were able to solve it.

The next engineer should not have to reverse-engineer your thinking from scattered logs, unexplained settings, or a configuration that only makes sense to the person who created it. Their time is no less valuable than yours.

This does not mean removing every challenge from their path. Engineers grow by solving difficult problems. But there is a difference between a meaningful challenge and unnecessary confusion.

A meaningful challenge develops judgment.

Unnecessary confusion merely wastes time.

Respecting the next engineer also requires humility. The person who follows you may know something you do not. They may see a weakness in your design, identify an assumption you overlooked, or discover a better solution.

Your work should invite improvement rather than defend itself from it.

The goal is not to build something that proves how clever you were.

The goal is to build something another capable person can understand, operate, challenge, and improve.

Respect the next engineer enough to leave them a path—and trust them enough to let them improve it.

The strongest engineering cultures are not built around a few indispensable experts. They are built by people who make their knowledge transferable, their decisions understandable, and their systems supportable.

Respect is not merely how we speak to the engineer standing beside us.

It is what we leave for the engineer who comes after us.

Principle XIX — Reliability Is Respect

Reliability is often described as a technical achievement.

It is measured in uptime percentages, response times, service level agreements, redundant hardware, backup generators, monitoring dashboards, and maintenance schedules.

Those measurements matter.

But they are not what reliability truly represents.

Reliability is respect.

Every time someone depends on your work, they place a small amount of trust in you.

Sometimes that trust lasts only a few moments.

Sometimes it lasts for decades.

Whether you realize it or not, people are constantly making decisions based on the expectation that your work will continue to function tomorrow just as it did today.

Reliability honors that trust.

It says to the people who depend on your work:

“I respected your time enough to prevent this problem from becoming yours.”

That philosophy extends far beyond engineering.

A bridge that safely carries traffic for fifty years.

A surgeon who prepares before entering the operating room.

A pilot who completes every checklist, even after thousands of flights.

An accountant whose numbers are consistently accurate.

A friend who always keeps their word.

In every case, reliability creates confidence because consistency removes uncertainty.

The highest compliment many professionals will ever receive is not brilliance.

It is dependability.

People eventually stop asking whether you will deliver.

They simply assume you will.

That trust is earned one decision at a time.

Reliability is rarely built during emergencies.

It is built long before anyone notices.

It is found in routine maintenance.

Preventive inspections.

Testing backups before they are needed.

Replacing worn components before they fail.

Reviewing documentation before knowledge disappears.

Monitoring systems before alarms sound.

The most respected professionals spend much of their careers preventing problems that no one else ever sees.

Ironically, success often looks like nothing happened.

No outage.

No emergency.

No crisis meeting.

No headlines.

No celebration.

When reliability succeeds, its greatest achievement is often invisible.

People remember spectacular recoveries because disasters capture attention.

Few people notice the disaster that never occurred because someone quietly prevented it.

That quiet consistency is one of the purest forms of professionalism.

It demonstrates respect for everyone who depends upon your work.

Reliability also shapes reputation.

Skill may earn someone’s attention.

Reliability earns their trust.

Organizations eventually learn who can be counted on when the pressure is highest.

Not because those people perform miracles.

Because they consistently do the ordinary things exceptionally well.

They maintain discipline after success.

They verify instead of assuming.

They inspect instead of hoping.

They prepare instead of reacting.

Reliability is not exciting.

It is deliberate.

Some people mistake preventive work for unnecessary effort because they never witness the failure that was avoided.

The engineer who patches a vulnerability before ransomware strikes may receive no recognition.

The administrator who verifies backups every week may never be thanked.

The architect who designs redundancy may appear overly cautious until the day redundancy saves the business.

Success often erases the evidence that the work was ever necessary.

That is the paradox of reliability.

The better you become at preventing failure, the less visible your contribution appears.

Do it anyway.

Because reliability is not performed for recognition.

It is performed out of respect.

Respect for the customer.

Respect for your teammates.

Respect for your organization.

Respect for the next person who will depend on the work you leave behind.

Consistency compounds.

Every promise you keep strengthens trust.

Every commitment you honor reinforces your reputation.

Eventually people stop evaluating your words and begin evaluating your history.

That history becomes your character.

Respect may be earned in a single moment. Reliability is earned every day.

Principle XX — This Knowledge Is Meant to Be Shared

Knowledge is one of the few resources that grows when it is given away.

Money decreases when it is spent.

Time disappears once it is used.

Knowledge is different.

When you share it, you still possess it. The only difference is that someone else now possesses it as well.

That is how individuals become teams.

That is how teams become organizations.

That is how organizations endure beyond the people who built them.

Unfortunately, many people misunderstand the relationship between knowledge and job security.

They believe the more knowledge they keep to themselves, the more valuable they become.

At first, that belief appears to be true.

Every difficult question comes to them.

Every complex issue requires their involvement.

Every critical system depends upon their expertise.

They become indispensable.

Or so they believe.

In reality, they have quietly assigned themselves ownership of every recurring problem associated with that knowledge.

Every outage interrupts their day.

Every vacation includes a phone call.

Every emergency waits for them to become available.

Every new employee eventually finds their desk because no one else knows the answer.

What began as expertise has become dependency.

The irony is that this dependency often prevents the very career growth they hoped to achieve.

Eventually, the organization launches something new.

A major migration.

A cloud transformation.

An acquisition.

A modernization effort.

A leadership initiative.

These are the projects that expand careers.

These are the assignments that expose engineers to new technologies, new responsibilities, and new opportunities.

Leadership begins looking for people who have the capacity to take on the challenge.

But you are unavailable.

You are too busy answering the same questions you answered yesterday.

Too busy fixing the same recurring problems.

Too busy maintaining the dependency that only you created.

Meanwhile, the engineers you refused to teach have something you no longer possess.

Bandwidth.

They are assigned the new initiative.

They gain the experience.

They build relationships.

They become visible to leadership.

You remain exactly where you are—protecting knowledge that has quietly protected you from your own advancement.

Knowledge hoarding may ensure you have a paycheck next week.

It may also ensure you have the same paycheck three years from now.

That is not career security.

It is career stagnation.

The purpose of expertise is not to become permanently attached to yesterday’s problems.

It is to prepare someone else to solve them so that you are free to solve tomorrow’s.

That is how careers grow.

That is how organizations grow.

That is how people grow.

Knowledge was never meant to be stored.

It was meant to move.

Principle XXI — Protect What Matters

Protection is one of the highest forms of respect.

When something has been entrusted to your care, you inherit a responsibility that extends beyond using it.

You become responsible for preserving it.

Whether that responsibility lasts for a few minutes or an entire lifetime, stewardship requires protection.

People often think of protection only after something has been lost.

After the data breach.

After the fire.

After the identity theft.

After the outage.

After trust has been broken.

But protection is not measured by how well we recover from disaster.

It is measured by how diligently we worked to prevent the disaster in the first place.

The most valuable things we possess are often invisible.

Trust.

Reputation.

Identity.

Privacy.

Knowledge.

Relationships.

Opportunity.

Once lost, each can be extraordinarily difficult to restore.

That is why protecting them deserves intentional effort.

In technology, protection has many forms.

Personally identifiable information.

Encryption keys.

Passwords.

Certificates.

Source code.

Financial records.

Medical information.

Customer data.

These are not merely files stored on a server.

They represent people’s identities, livelihoods, privacy, and trust.

When an organization collects that information, it accepts an obligation.

Not simply to use it.

To protect it.

Security is therefore not an IT expense.

It is an ethical responsibility.

Updating certificates before they expire.

Rotating secrets before they are compromised.

Patching vulnerabilities before they are exploited.

Hardening servers before attackers arrive.

Testing backups before disaster strikes.

These are rarely celebrated accomplishments because success often appears uneventful.

Nothing happened.

Exactly.

That is the objective.

Engineers cannot secure an organization by themselves.

Leadership must decide that protection matters enough to invest in it.

Secure infrastructure requires time.

Training.

Monitoring.

Modern hardware.

Current software.

Professional development.

Independent audits.

Incident response planning.

None of those exist without organizational commitment.

Expecting engineers to protect critical systems without providing the necessary tools is like expecting firefighters to protect a city without water.

Responsibility must be matched with capability.

Organizations that truly value security demonstrate it through sustained investment, not annual speeches.

Eventually every profession discovers its own version of security.

Parents protect children.

Doctors protect patients.

Lawyers protect confidences.

Teachers protect potential.

Leaders protect culture.

Friends protect trust.

Protection is simply stewardship expressed through preparation.

You rarely receive praise for the disaster that never happened.

The attack that never succeeded.

The secret that was never exposed.

The relationship that never fractured.

The reputation that never needed repair.

But those invisible victories often become the foundation upon which every visible success is built.

What we choose to protect reveals what we truly value.

Protection is rarely accomplished by a single decision.

It is built through layers.

Each layer may seem small on its own, but together they create resilience. Remove enough of those layers, and even a strong system becomes vulnerable.

The same philosophy applies far beyond technology.

A castle was never protected by one wall.

It had gates, towers, guards, supplies, watchmen, and allies.

Each layer compensated for the possibility that another might someday fail.

Modern security follows the same principle.

Encryption protects information when storage or communication is compromised.

Strong authentication protects identities when passwords are stolen.

Least privilege limits the damage when an account is misused.

Server hardening removes opportunities before attackers can exploit them.

Certificate management preserves trust between systems.

Routine patching closes doors that should never have been left open.

Backups ensure that even when prevention fails, recovery remains possible.

None of these practices exists because engineers expect failure.

They exist because engineers understand reality.

Every system will eventually be tested.

Sometimes by accident.

Sometimes by neglect.

Sometimes by people who deliberately search for weakness.

Preparation acknowledges that possibility without surrendering to it.

Security is therefore not about fear.

It is about responsibility.

Organizations often purchase expensive security products while neglecting the habits that make those products effective.

Technology cannot compensate for poor discipline.

An unpatched server remains vulnerable regardless of how many security tools surround it.

A forgotten certificate can stop an entire business.

A shared administrator password can undo millions of dollars in security investments.

The strongest defense is almost always consistency.

The organizations with mature security cultures rarely depend upon heroics.

They depend upon routines.

They review permissions.

They rotate secrets.

They test backups.

They monitor unusual activity.

They verify that controls continue to work rather than assuming they always will.

These actions are repetitive.

That is precisely why they succeed.

Leadership also carries a responsibility that cannot be delegated.

Executives often ask their technology teams to protect the organization.

That expectation is reasonable.

Expecting them to do so without sufficient staffing, training, modern tooling, or executive support is not.

Security is an organizational commitment.

The board defines acceptable risk.

Leadership allocates resources.

Engineers implement protections.

Every level has a role to play.

When one layer fails to fulfill its responsibility, the entire organization becomes weaker.

Protection is strongest when responsibility is shared.

The same principle applies in our personal lives.

Healthy relationships require boundaries.

Financial security requires planning.

Physical health requires maintenance.

Reputation requires integrity.

None of these is protected by a single decision.

They are protected through consistent habits practiced over time.

Small disciplines prevent large consequences.

That is the quiet nature of stewardship.

You rarely notice protection while it is working.

You notice it only after it has been neglected.

Protection is not a product you purchase. It is a discipline you practice every day.

Eventually, every one of us discovers that the things which matter most in life cannot be replaced.

A server can be rebuilt.

A database can be restored.

Hardware can be replaced.

Even a business can recover from tremendous loss.

Some things are different.

Your integrity cannot be restored from a backup.

Your reputation cannot be recovered with a software update.

Your health cannot always be patched after years of neglect.

The moments you miss with your family cannot be downloaded later.

These are the assets that deserve our greatest protection.

Protect your integrity.

It is the foundation upon which every relationship is built.

People may forgive mistakes.

They rarely forget dishonesty.

Guard your reputation.

It takes years of consistent character to earn trust and only moments of poor judgment to lose it.

Your reputation often enters the room before you do.

Protect your health.

There will always be another project.

Another deadline.

Another email.

Your body quietly keeps score of every late night, every skipped meal, every ignored warning, and every excuse that tomorrow will be different.

Success has little meaning if you are too exhausted or too unhealthy to enjoy it.

Protect your family.

No promotion will remember your birthday.

No customer will attend your funeral.

No quarterly report will comfort those you love.

The people waiting for you at home are not interruptions to your work.

They are the reason your work matters.

Protect your time.

It is the only resource you can never earn back.

Spend it intentionally.

Give it generously.

Waste as little of it as possible.

And finally, protect your principles.

Technology will change.

Careers will change.

Industries will change.

The values that guide your decisions should not.

They are your compass when circumstances become uncertain.

Throughout this book we have explored observation, craftsmanship, stewardship, reliability, teaching, and service.

Each Principle has pointed toward a single truth.

The purpose of knowledge is not simply to make us more capable.

It is to help us become more responsible.

Responsible for the people we lead.

Responsible for the systems we build.

Responsible for the trust others place in us.

Responsible for the legacy we leave behind.

At the end of our lives, very few people will remember the servers we hardened.

The databases we migrated.

The code we wrote.

They will remember something far more important.

How safe they felt around us.

How faithfully we kept our word.

How well we cared for what had been entrusted to us.

That is the measure of a life well lived.

Protect what matters, and you will discover what truly matters.

Principle XXII — Complexity Is a Cost (Part 1)

People often think of complexity as a technical problem.

More code.

More servers.

More dependencies.

More configuration.

More moving parts.

Those are certainly costs, but they are only the costs we can easily measure.

The true cost of complexity extends far beyond the project plan or the budget spreadsheet.

A fragile application consumes support hours.

An unclear architecture slows every future enhancement.

A rushed workaround becomes a permanent dependency.

A difficult deployment erodes confidence.

An unstable system quietly steals evenings, weekends, and holidays from the people responsible for keeping it alive.

Complexity rarely sends its bill directly to the person who created it.

A developer builds a fragile application.

The deployment becomes unpredictable.

Support incidents multiply.

An engineer stays late to keep the system running.

Then he stays late again.

And again.

Dinner grows cold.

His children begin asking why Daddy is never home.

His wife carries the evening alone: meals, homework, baths, disappointment, and the burden of explaining an absence she did not create.

One night, already overwhelmed, the cat gets under her feet.

She kicks it away in frustration.

The cat has never seen the application.

It does not know the developer who designed it.

It has no understanding of technical debt, brittle dependencies, or missed refactoring.

Yet its fear is still connected to those decisions.

That is how complexity behaves.

Its consequences travel.

They move through systems, teams, schedules, relationships, and homes until someone far removed from the original choice is forced to pay.

The farther the consequence travels, the harder it becomes to trace back to its source.

That is why complexity is so easy to underestimate.

Its true cost is rarely contained in the project budget.

Complexity always sends a bill, but it rarely sends it to the person who created the debt.

Principle XXIII — Design for Failure

This one belongs near the center of an engineering philosophy because it separates hope from preparedness.

High availability matters.

Redundancy matters.

Fault tolerance matters.

Monitoring, clustering, replication, backups, and resilient architecture all matter.

But none of them eliminates failure.

They reduce its likelihood.

They limit its impact.

They buy time.

They do not make a system immortal.

Eventually, something will fail in a way the original design did not predict.

A dependency will become unavailable.

A certificate will expire.

A region will experience disruption.

A configuration change will behave differently than expected.

A backup will be needed.

A recovery process will have to work under pressure.

That is why disaster recovery cannot be treated as a document stored somewhere for an emergency.

It must be prepared.

Tested.

Measured.

Practiced.

A recovery plan that has never been exercised is not a recovery plan.

It is a theory.

The real question is not whether an outage will ever happen.

The question is whether you will be ready when it does.

How quickly will the problem be detected?

How long will it take to make a decision?

Who has the authority to declare a disaster?

Are the backups usable?

Are the credentials available?

Are the recovery steps current?

Does the team know what to do without searching through old emails?

Can the business survive long enough for the technology to return?

That last question should shape the entire strategy.

Disaster recovery is not designed around what the infrastructure team finds convenient.

It is designed around how long the client can continue operating without the service.

Some organizations can tolerate several days of downtime.

Others begin losing revenue within minutes.

Some systems are inconvenient when unavailable.

Others affect patient care, payroll, financial transactions, or public safety.

The correct recovery design begins with understanding that difference.

How much data can the client afford to lose?

How long can the client afford to remain offline?

Those answers define the recovery objectives.

The technology must then be designed to meet them.

If the business can survive four hours without a system, a recovery strategy that takes three days is not a strategy.

It is an apology waiting to happen.

And if the required recovery window cannot be achieved with the budget, staffing, or tools provided, leadership must understand that clearly.

Risk does not disappear because no one funded the solution.

It is simply being accepted, whether consciously or not.

Resilience is not proven by avoiding every failure. It is proven by recovering before the failure becomes irreversible.

There is also a strong human lesson here.

During an outage, people rarely rise to the level of their intentions.

They fall to the level of their preparation.

That is why drills matter.

That is why restore tests matter.

That is why contact lists, escalation paths, clean documentation, and clearly assigned responsibilities matter.

The middle of a crisis is the worst possible time to discover that no one knows the next step.

A calm environment gives teams the opportunity to practice decisions before stress narrows their thinking.

Testing may feel unnecessary when everything is stable.

That is exactly when it should be done.

You test the recovery process while you still have time to correct it.

You measure how long it actually takes.

You find the missing permissions.

You discover the outdated instructions.

You identify the backup that was never being validated.

You learn which assumptions were wrong.

Then you improve the plan before lives, livelihoods, or the business depend on it.

This Principle also follows Complexity Is a Cost beautifully.

Complex systems create more ways to fail.

That does not mean we avoid necessary complexity.

It means every layer we add must include an answer to one question:

How do we recover when this layer stops working?

Build for availability.

Prepare for interruption.

Practice recovery.

Measure the time.

Know what the business can survive.

Failure is inevitable. Being unprepared is a choice.

Principle XXIV — Automate to Remove Toil

Foundational Truth

Automation is not about replacing people.

It is about protecting human attention from work that does not deserve it.

The most valuable resource an engineer possesses is not time.

It is attention.

Time can be scheduled.

Attention can be exhausted.

Every repetitive task consumes a little of it.

Every identical sequence of clicks, commands, copy operations, validations, and confirmations creates another opportunity for fatigue to replace judgment.

That is where toil begins.

Toil is work that is manual, repetitive, predictable, and necessary, but does not become more valuable simply because a person performs it again.

Copying the same files into the same container.

Applying the same update to one hundred laptops.

Running the same report every morning.

Restarting the same service after the same failure.

Provisioning the same environment by following the same checklist.

None of those tasks is meaningless.

But when they are repeated by hand, they consume human capacity without requiring human creativity.

Never automate because people are replaceable. Automate because their attention is not.

Thought Rot

Repetition changes the way people think.

At first, the task feels manageable.

Then it becomes familiar.

Then it becomes automatic.

Eventually, the brain begins to drift.

You stop reading each prompt because you already know what it should say.

You stop checking every path because the last fifty were correct.

You begin thinking about dinner.

The next meeting.

The unresolved project.

The weekend.

Anything except the task in front of you.

I call this Thought Rot.

Not because the person has become careless.

Because the task has stopped demanding enough thought to hold the mind.

That is when errors begin.

A skipped checkbox.

The wrong destination folder.

A driver update selected instead of a service pack.

A production target chosen instead of staging.

A reboot postponed when it was required.

Most mistakes are not catastrophic.

They are small.

But small mistakes interrupt rhythm.

They create rework.

They add uncertainty.

They force the person to stop, recover context, verify what happened, and begin again.

The mistake may take only seconds.

Recovering focus may take much longer.

Automation Preserves Judgment

Computers are remarkably good at repetition.

They do not become bored.

They do not rush because it is late.

They do not skip a step because the previous ninety-nine succeeded.

They perform the instructions they were given.

Exactly.

Consistently.

Repeatedly.

That is their strength.

Human beings are valuable for different reasons.

We recognize ambiguity.

We interpret context.

We adapt to unexpected conditions.

We ask whether the task should exist at all.

We decide when the documented path no longer fits reality.

Automation should remove the work computers do well so people can concentrate on the work only people can do well.

Automation turns repetition into capacity.

Duplicate Your Best Work

Every automation is a copy of your best-known process.

A manual task can be performed by one person at one moment.

An automated task can run repeatedly, consistently, and in parallel.

While the automation performs the work, the engineer is free to design, investigate, improve, teach, or solve the next problem.

This is how engineers multiply themselves.

Not by working longer hours.

Not by moving faster.

By capturing their knowledge in a form that can continue working without their constant presence.

A script becomes another pair of hands.

A workflow becomes another operator.

A scheduled process becomes another dependable teammate.

The automation does not replace the engineer.

It extends the engineer.

The Automation Question

Not every task should be automated.

Some work occurs too rarely.

Some changes too often.

Some depends on human judgment at every step.

Automation also has a cost.

It must be designed.

Tested.

Documented.

Monitored.

Maintained.

The right question is not:

“Can this be automated?”

Almost anything can.

The better question is:

“Should this be automated, and will the value exceed the cost?”

A practical rule is:

If I must perform the same task twice, I should at least ask whether it deserves automation.

The answer may still be no.

But repetition should always trigger the question.

Closing Thought

Manual work scales by consuming more people.

Automation scales by preserving their attention.

The purpose is not to remove humans from the system.

It is to place them where their judgment matters most.

Automate the repetition. Preserve the thinking.

The Work That Should Have Taught the Machine

I have been the person who copied files into a Docker container one at a time.

Month after month.

I have been the person who manually applied Windows updates across a fleet of more than one hundred laptops.

I have walked through the same installer repeatedly.

I have watched the same progress bars.

I have answered the same prompts.

I have verified the same settings.

None of that work was beneath me.

But much of it should not have continued requiring me.

Every repeated action was evidence that the process had become predictable enough to capture.

The real failure was not that the task existed.

The failure was allowing the task to remain manual after its pattern was understood.

Speed Is Not the Primary Benefit

Automation is often justified with time savings.

That is useful, but incomplete.

The greater benefits are:

  • Consistency
  • Repeatability
  • Reliability
  • Auditability
  • Scalability
  • Reduced fatigue
  • Fewer preventable errors

A person may complete the task faster once they become experienced.

But experience also creates overconfidence.

The person begins to anticipate the next step.

That anticipation can increase speed.

It can also reduce attention.

Automation performs the same validated process every time.

That makes the result easier to trust, compare, and support.

Runbooks Become Scripts

A mature workflow often begins as documentation.

First, someone discovers the steps.

Then they write them down.

Then others repeat them.

Once the process becomes stable, the runbook becomes a candidate for automation.

The progression is natural:

Observation.

Documentation.

Standardization.

Automation.

Monitoring.

Improvement.

A script should not be a collection of mysterious commands.

It should be an executable form of a process the organization already understands.

That is why documentation and automation belong together.

A script without explanation becomes another dependency.

A documented automation becomes institutional knowledge.

Infrastructure as Knowledge

Automation is not limited to scripts.

Terraform captures architecture.

Configuration management captures operational standards.

CI/CD captures deployment practice.

Scheduled tasks capture timing and repetition.

Lambda and EventBridge capture event-driven behavior.

Container definitions capture runtime expectations.

Each one converts human memory into repeatable execution.

That matters because memory is fragile.

People forget.

Teams change.

Engineers move on.

Automation preserves the process in a form the organization can inspect, version, test, and improve.

The best automation does not merely execute work. It preserves how the organization learned to do the work well.

Errors Move Upstream

Manual processes discover errors during execution.

Automation gives us the opportunity to discover them before execution.

A good automated process validates prerequisites.

Checks permissions.

Confirms destinations.

Detects missing files.

Rejects invalid inputs.

Stops before causing damage.

Records what happened.

Reports failure clearly.

That shifts error handling from improvisation to design.

The mistake is no longer discovered after the wrong driver has been installed on thirty laptops.

It is prevented because the workflow checked the package before deployment began.

The engineer spends effort once to protect every future run.

Automation Must Remain Understandable

Automation can remove toil.

It can also hide complexity.

A process that no one understands is not truly reliable simply because it runs automatically.

Every automation should answer:

  • What does it do?
  • Why does it exist?
  • What inputs does it require?
  • What systems does it affect?
  • What happens when it fails?
  • How is it stopped?
  • How is it rolled back?
  • Who owns it?
  • How is success verified?

Automation without observability creates silent risk.

Automation without documentation creates dependency.

Automation without ownership becomes abandonment.

Human Judgment Still Matters

Some steps should remain human.

Approval of destructive actions.

Interpretation of unusual results.

Decisions involving ethics, risk, or incomplete context.

Communication during major incidents.

Automation should create guardrails around judgment, not eliminate judgment where it is still required.

The strongest systems combine both.

Machines handle repetition.

People handle meaning.

Closing Thought

The goal is not to automate everything.

The goal is to ensure that people are not spending their best attention on work that no longer requires it.

A mature engineer does not ask how much work can be automated. They ask how much human judgment can be protected.

Automation Exists Everywhere

Automation is not unique to software.

Pilots use checklists to standardize critical decisions.

Surgeons use protocols to reduce preventable variation.

Restaurants use recipes to reproduce quality.

Factories use jigs to guide precision.

Parents create routines because predictable structure reduces friction.

Organizations create templates because starting from a proven foundation is safer than rebuilding from memory.

In each case, knowledge has been captured so the result does not depend entirely on someone remembering every detail at the right moment.

That is automation in its broadest form.

Automation is captured knowledge executed consistently.

Checklists Are Human Automation

Not every automation requires code.

A checklist automates memory.

A template automates structure.

A standard operating procedure automates sequence.

A calendar reminder automates timing.

A naming convention automates interpretation.

These tools reduce cognitive load even when a person still performs the work.

The principle is the same.

Remove unnecessary decisions so attention remains available for the decisions that matter.

Automation Protects Creativity

Some people fear automation because they believe routine creates familiarity and familiarity creates expertise.

That is partly true.

Repetition can teach.

But once the lesson has been learned, continued repetition may stop adding value.

At that point, the task begins consuming the same attention that could be used for exploration, design, and discovery.

Automation does not reduce creativity.

It protects creativity from being buried beneath routine.

The person no longer spends the morning generating the report.

They spend the morning interpreting it.

They no longer copy the files.

They improve the pipeline.

They no longer patch one machine at a time.

They investigate why the environment remains difficult to maintain.

Automation gives people room to ask better questions.

Consistency Is a Form of Care

A consistent process respects the people who depend upon it.

Customers receive the same quality.

Engineers receive the same signals.

Auditors receive the same records.

Support teams receive predictable behavior.

Consistency reduces surprise.

That makes systems easier to trust.

Automation therefore connects directly to reliability.

Not because automated systems never fail.

Because they fail in ways that are easier to observe, reproduce, and improve.

Automation Should Remove Burden, Not Responsibility

A dangerous automation allows people to stop understanding the outcome.

A healthy automation reduces manual effort while preserving accountability.

The engineer still owns the result.

The organization still owns the risk.

The human still decides whether the automated action remains appropriate.

Automation should eliminate repetition.

It should not eliminate responsibility.

The Human Test

Before automating a process, ask:

  • What burden will this remove?
  • What errors will it prevent?
  • What attention will it return?
  • What new risks will it introduce?
  • Can a person understand and override it?
  • Does it preserve the right human decision points?
  • Will the people affected by it be better off?

That final question matters.

Efficiency alone is not enough.

The automation should improve the lives of the people who use, support, and depend upon it.

In Practice

  • Identify repetitive work that follows stable rules.
  • Document the current process before automating it.
  • Remove unnecessary steps before encoding them.
  • Add validation before action.
  • Log every significant result.
  • Make failures visible.
  • Preserve approval where judgment is required.
  • Test rollback and recovery.
  • Assign ownership.
  • Review the automation as the environment changes.

Do not automate a broken process merely because it is repetitive.

You will only make the failure happen faster.

Questions to Ask Yourself

  • Am I repeating work that has already taught me everything it can?
  • What mistakes occur because this process depends on attention?
  • Can the process be simplified before it is automated?
  • What knowledge should be captured?
  • What judgment must remain human?
  • Who benefits from the time and attention returned?
  • Will this automation still be understandable after I leave?

Closing Thought

The highest purpose of automation is not to save time.

It is to preserve human attention for problems worthy of human thought.

Automate what repeats so people can improve what changes.

Founder’s Commentary

People Were Never the Problem

People often assume that engineers automate because they dislike repetitive work.

That was never my motivation.

I automate because I hate watching intelligent people spend their lives doing work that a computer should have been doing all along.

Over more than twenty years in IT, I have copied thousands of files by hand.

I’ve updated fleets of laptops one machine at a time.

I’ve walked through endless installation wizards, clicked the same buttons hundreds of times, and waited for progress bars to crawl across a screen while knowing there had to be a better way.

At first, repetition feels harmless.

Then something begins to happen.

Your brain gets ahead of your hands.

You stop reading the screens because you’ve already seen them a hundred times.

Your thoughts drift toward dinner, tomorrow’s meeting, your kids’ soccer game, or the project waiting for you after this one.

I call this Thought Rot.

Not because you’ve become careless.

Because you’ve become human.

The brain is remarkably good at recognizing patterns.

Unfortunately, it is equally good at assuming the next step will always be the same as the last.

That is where mistakes are born.

A skipped checkbox.

The wrong driver.

A forgotten reboot.

A file copied into the wrong directory.

Most mistakes aren’t catastrophic.

They’re interruptions.

And interruptions destroy momentum.

Once you’ve broken your rhythm, it takes real effort to find it again.

Automation isn’t about replacing people.

It’s about protecting people from work that doesn’t deserve their attention.

A computer never gets bored.

It never wonders what it wants for lunch.

It never rushes because it’s Friday afternoon.

It simply performs exactly what it was instructed to perform.

Every.

Single.

Time.

That consistency allows people to do something computers still struggle to do well.

Think.

Solve new problems.

Design better systems.

Ask better questions.

When I automate a task, I’m not trying to eliminate a job.

I’m trying to give someone their mind back.

Every script I write captures a little piece of experience.

Every workflow removes another opportunity for fatigue to create an error.

Every automation becomes another engineer working beside me while I move on to something that actually requires judgment.

That’s the part people often miss.

Automation isn’t about making people less valuable.

It’s about making human attention more valuable by spending it where it matters most.

If a computer can perform the task reliably, let it.

Save your best thinking for the problems only people can solve.

Looking back over my career, I do not remember every script I wrote, every workflow I automated, or every deployment I simplified.

What I remember are the people who no longer had to spend their weekends babysitting servers, manually copying files, or repeating the same mistakes because a computer could do the work instead.

If the best automation is invisible, then perhaps the best compliment an engineer can receive is that nobody noticed the work anymore.

They simply noticed that life became a little easier.

When I automate a task, I’m not trying to eliminate a job. I’m trying to give someone their mind back.

Principle XXV — Every Dependency Has a Price

Foundational Truth

No dependency is free.

Every library.

Every framework.

Every API.

Every cloud service.

Every package.

Every vendor.

Every plugin.

Every integration.

Every database.

Every certificate.

Every external system.

Each one promises new capability.

Each one also introduces new responsibility.

That responsibility may not be visible on the day the dependency is added.

It arrives later.

During upgrades.

During outages.

During security reviews.

During deployments.

During incident response.

Every dependency you introduce becomes another component you must understand, monitor, patch, document, test, secure, and eventually replace.

Functionality is only half of the transaction.

Maintenance is the other half.

Every dependency adds value today. It also creates an obligation tomorrow.

Newton’s Third Law of Software

Newton observed that every action has an equal and opposite reaction.

Software architecture often behaves the same way.

Every dependency you add creates an opposing force.

You gain capability.

You lose independence.

You gain speed of development.

You increase operational complexity.

You reduce the amount of code you must write.

You increase the amount of code someone else controls.

You gain features.

You inherit release schedules.

You gain convenience.

You inherit another potential point of failure.

The question is never whether a dependency has a cost.

The question is whether its long-term value exceeds that cost.

The Hidden Invoice

When engineers evaluate a dependency, they often focus on the obvious benefits.

How quickly can it solve today’s problem?

How many features does it provide?

How much code will it save us from writing?

Those are important questions.

They are not sufficient.

Every dependency also creates an invisible invoice.

Someone must:

Read the documentation.

Understand its behavior.

Monitor security advisories.

Upgrade versions.

Test compatibility.

Review licensing.

Handle breaking changes.

Update deployment pipelines.

Troubleshoot failures.

Document its purpose.

Train future engineers.

Eventually replace it.

None of that work disappears simply because someone else wrote the software.

The responsibility merely changes hands.

Dependencies Multiply

One dependency rarely remains alone.

That library depends on another.

That framework requires a runtime.

That runtime requires a supported operating system.

That operating system depends upon updated drivers.

That cloud service requires authentication.

Authentication requires certificates.

Certificates require renewal.

Renewal requires monitoring.

Monitoring requires alerting.

Alerting requires ownership.

The dependency graph grows.

Soon, a single feature relies upon dozens of interconnected systems.

Most engineers never intended to build that complexity.

It emerged one convenient decision at a time.

That is why architectural discipline matters.

Small decisions compound.

Ask Before You Add

Before introducing any dependency, ask:

  • What problem does this solve?
  • Is the problem significant enough to justify another dependency?
  • Can we accomplish the same goal with what we already have?
  • Who will maintain this five years from now?
  • How often is it updated?
  • What happens if the vendor disappears?
  • What happens if the API changes?
  • What happens if the license changes?
  • Can we remove it later?
  • Is the long-term value greater than the long-term cost?

If those questions cannot be answered confidently, the dependency deserves another look.

Sometimes the right architectural decision is not to add another component.

Sometimes the better decision is to simplify.

Deliberate Architecture

Good engineers do not avoid dependencies.

Modern software would be impossible without them.

Good engineers choose dependencies deliberately.

They understand the value being purchased.

They understand the responsibility being accepted.

Every dependency is an investment.

Some generate extraordinary returns.

Others become technical debt before the first release.

The difference is rarely the technology.

It is the discipline of evaluating the full cost before accepting it.

Closing Thought

Every dependency is a promise.

A promise that someone will maintain it.

A promise that someone will understand it.

A promise that someone will respond when it fails.

Choose those promises carefully.

Every dependency has a price. Make sure you’re buying more value than you’re inheriting in responsibility.

The Architecture You Don’t Own

One of the greatest misconceptions in software engineering is believing that using someone else’s code means someone else owns the problem.

They don’t.

You do.

The moment you add a dependency to your application, it becomes part of your architecture.

Your users will never know—or care—which company wrote the library.

They won’t distinguish between your code and someone else’s.

If the application fails, they won’t blame the package author.

They will blame your system.

That responsibility cannot be outsourced.

Ownership follows integration.

Every Dependency Creates Operational Work

When a dependency is first introduced, the conversation usually revolves around features.

“This library already solves that problem.”

“This API saves us months of development.”

“This framework has everything we need.”

Those statements may all be true.

What is discussed far less often is everything that happens after the dependency is installed.

Someone must monitor security advisories.

Someone must review new releases.

Someone must test compatibility before every upgrade.

Someone must update deployment pipelines.

Someone must document configuration changes.

Someone must respond when the dependency behaves differently after an update.

Someone must explain why yesterday’s deployment worked and today’s no longer does.

That “someone” is almost always your team.

The dependency reduced development effort.

It increased operational responsibility.

Vendor Risk Is Still Your Risk

Cloud services have transformed engineering.

Managed databases.

Hosted authentication.

Object storage.

AI services.

Monitoring platforms.

Payment gateways.

The list continues to grow.

Each one offers tremendous value.

Each one also introduces another organization into your critical path.

If their authentication platform becomes unavailable…

Your users cannot sign in.

If their DNS service fails…

Your application may become unreachable.

If their payment processor experiences an outage…

Your business may stop accepting orders.

If their API changes…

Your deployment may fail.

The outage belongs to the vendor.

The business impact belongs to you.

That is why vendor evaluation is never just a feature comparison.

It is an exercise in risk management.

The Cost of Convenience

Convenience is one of the easiest ways to accumulate technical debt.

A developer discovers an open-source package that solves today’s problem.

Installation takes minutes.

Writing the equivalent functionality would have taken days.

The decision seems obvious.

Sometimes it is.

Sometimes it is not.

The convenience lasts for one afternoon.

The maintenance may last for ten years.

Every dependency should therefore answer a simple question:

Will this continue creating more value than it costs to own?

That answer may change over time.

Dependencies should be reviewed periodically, not assumed permanent.

Build Versus Buy

One of the oldest engineering questions remains one of the most important.

Should we build it?

Or should we buy it?

There is no universal answer.

Building provides control.

Buying provides speed.

Building requires expertise.

Buying requires trust.

Building creates maintenance.

Buying creates dependency.

The decision should never be based solely on initial effort.

It should consider the entire lifecycle.

How often will the capability change?

How critical is it to the business?

Can we survive if the vendor disappears?

How difficult would it be to migrate away?

What happens if pricing changes dramatically?

What happens if licensing terms change?

Architecture is not only about choosing technology.

It is about choosing commitments.

Design for Replacement

Every dependency should have an exit strategy.

Not because it will certainly fail.

Because someday circumstances will change.

The vendor may discontinue the product.

The API may become obsolete.

The company may be acquired.

Security concerns may emerge.

Licensing may become incompatible.

Your own requirements may evolve.

The easiest dependency to replace is the one designed for replacement from the beginning.

Loose coupling.

Clear interfaces.

Well-defined boundaries.

Those decisions create freedom later.

Tightly coupled dependencies create expensive migrations.

A Dependency Budget

Organizations often manage financial budgets carefully.

Dependency budgets deserve similar attention.

Every new library.

Every new SaaS platform.

Every new vendor.

Every new integration.

Every new framework.

Should consume part of a deliberately managed budget.

Not a financial budget.

An operational budget.

How much additional complexity can this system reasonably support?

At what point does another dependency create more operational cost than engineering value?

That question rarely appears in project planning.

It should.

Closing Thought

The best architects are not those who use the most technology.

They are those who understand which technology is truly worth owning.

Every dependency is a long-term relationship.

Choose it with the same care you would choose someone responsible for your own work.

Good architecture is not measured by how much you can add. It is measured by how little you must depend upon to achieve the same result.

Dependencies Exist Beyond Software

Software engineers are not the only people who manage dependencies.

Families depend upon trust.

Businesses depend upon customers.

Hospitals depend upon electricity.

Airlines depend upon weather, fuel, and maintenance.

Communities depend upon volunteers.

Every meaningful system depends upon something outside itself.

The lesson is universal.

Dependencies are not inherently bad.

They simply require stewardship.

Every dependency creates both capability and responsibility.

Independence Is Rare

Complete independence is usually impossible.

No company manufactures every component it uses.

No engineer writes every line of code.

No organization owns every piece of infrastructure.

The goal is therefore not independence.

The goal is intentional dependence.

Choose relationships that strengthen the whole.

Understand the obligations they create.

Avoid collecting dependencies simply because they are available.

Simplicity Is a Strategic Advantage

Every unnecessary dependency competes for attention.

It requires documentation.

Training.

Monitoring.

Upgrades.

Support.

Eventually, retirement.

A simpler system is often easier to understand, easier to secure, easier to recover, and easier to teach.

Simplicity is not the absence of capability.

It is the absence of unnecessary obligation.

The Dependency Test

Before accepting any dependency, ask:

  • Does it solve an important problem?
  • Is the value durable or temporary?
  • What new responsibilities will it create?
  • Who will own it after the original engineer leaves?
  • Can the system continue if it disappears?
  • Would I choose it again five years from now?

If the answers are uncertain, the dependency deserves another review.

In Practice

  • Prefer proven solutions over fashionable ones.
  • Remove obsolete dependencies regularly.
  • Review third-party libraries and vendors as part of architecture reviews.
  • Keep clear ownership for every dependency.
  • Design interfaces that make replacement possible.

Closing Thought

The strongest systems are not those with the most integrations.

They are those whose dependencies are understood, deliberate, and worth their cost.

Choose dependencies as carefully as you choose commitments. Both become part of your future.

Founder’s Commentary

Convenience Is Easy. Ownership Is Hard.

Early in my career, I loved discovering a new library that promised to solve a difficult problem.

It felt like finding a shortcut.

Sometimes it was.

Sometimes it became a decade-long commitment disguised as a five-minute installation.

That lesson took years to appreciate.

Every dependency enters the project with excitement.

Nobody schedules a meeting to celebrate maintaining it five years later.

But someone will.

Someone will patch it.

Someone will explain it.

Someone will troubleshoot it during an outage.

Someone will answer for it when a vulnerability is published on a Friday afternoon.

If the dependency is part of your application, it becomes part of your reputation.

Over time I stopped asking, “Can this solve my problem?”

I started asking, “Do I want to own everything that comes with this solution?”

That simple change has influenced almost every architectural decision I’ve made since.

Some dependencies have earned their place many times over.

Others delivered a week of convenience followed by years of maintenance.

Experience has taught me that architecture is less about accumulating technology than it is about protecting the future from unnecessary obligations.

The best engineers I have worked with were not impressed by the number of tools they could assemble.

They were impressed by the number of problems they could solve with the fewest moving parts.

There is wisdom in restraint.

Not every feature deserves another framework.

Not every challenge deserves another vendor.

Not every convenience deserves another lifetime commitment.

When I inherit a system today, I no longer count the features first.

I count the dependencies.

That number usually tells me far more about the future than the feature list ever will.

Good architecture is measured not only by what it enables today, but by what it asks future engineers to carry tomorrow.

Principle XXVI — Build Small. Think Big.

Foundational Truth

Large outcomes do not always begin with large ideas.

Sometimes the smallest change reorganizes everything around it.

A vacuum tube becomes a transistor.

A glowing filament becomes a light-emitting diode.

An analog signal becomes digital information.

Each transition began at a scale small enough to overlook.

Yet each one changed what humanity could build.

Smaller components made machines faster.

More efficient.

More reliable.

More portable.

More affordable.

Eventually, those small changes reshaped communication, medicine, transportation, science, entertainment, and daily life.

The size of an idea does not determine the size of its consequence.

Small Changes Rebuild the World

The transistor did not resemble a revolution.

It was a small device replacing a larger one.

But that smaller device consumed less power, generated less heat, failed less frequently, and could be manufactured at extraordinary scale.

One improvement enabled another.

Smaller components allowed smaller circuits.

Smaller circuits enabled more complex machines.

More complex machines became general-purpose computers.

Computers became networks.

Networks became the digital world.

The transformation did not begin with one impossibly large machine.

It began by making one essential component smaller and better.

The same pattern appears repeatedly.

Incandescent bulbs produced light by heating a filament until it glowed.

LEDs produced light through a far more efficient physical process.

The immediate change was the light source.

The broader consequences included longer service life, lower energy consumption, smaller devices, reduced heat, new display technologies, and lighting in places where traditional bulbs were impractical.

Small improvements create new possibilities because they remove constraints.

The Power of a Compact Idea

Some ideas are powerful not because they explain everything, but because they reveal a relationship so fundamental that entire fields can build upon it.

Einstein’s mass-energy relation is remembered through one of the shortest equations in science:

E = mc²

Its strength comes from compression.

A small expression captures an idea with consequences far beyond its length.

That is what elegant engineering often does.

It identifies the right relationship, defines it clearly, and allows larger systems to emerge from it.

A powerful design does not need to be large. It needs to be fundamental.

Build from Composable Parts

Software should follow the same principle.

A small function is easier to understand.

A small service is easier to test.

A small interface is easier to document.

A small component is easier to replace.

When those pieces have clear responsibilities and predictable boundaries, they can be composed into systems far larger than any one piece.

Build small enough to understand. Think big enough to compose.

Security Is Measured by Effectiveness

It is possible to create an architecture with firewalls behind firewalls, NAT behind NAT, multiple DMZs, honeypots, proxies, overlapping inspection systems, and dozens of security products.

It may look impressive.

It may also become impossible to operate.

Every additional layer must be configured, monitored, patched, documented, tested, and understood.

Complexity alone does not create security.

Strong authentication.

Least privilege.

Current patching.

Clear segmentation.

Useful logging.

Tested recovery.

Applied consistently, these often provide greater value than adding another layer that few people understand.

The objective is not fewer controls.

The objective is better controls.

Small Does Not Mean Shortsighted

Build each component with one clear responsibility.

Understand how it fits into the larger vision.

Keep the implementation small.

Keep the ambition large.

Closing Thought

History is filled with small discoveries that removed large constraints.

Do not confuse scale with significance.

Build pieces people can understand.

Connect them with intention.

Let their combined value become greater than any individual component.

Build small enough to remain clear. Think big enough to change what becomes possible.

The Power of Composition

Every great system is built from smaller systems.

A computer is not one invention.

It is millions—or billions—of transistors working together.

The Internet is not one network.

It is thousands of independently managed networks agreeing on common standards.

A skyscraper is not one beam.

It is thousands of carefully engineered components sharing the load.

Nature follows the same pattern.

Cells become tissues.

Tissues become organs.

Organs become living organisms.

Small parts.

Large purpose.

The lesson is remarkably consistent.

The greatest systems are rarely created by making one thing enormous.

They are created by making many small things dependable.

Scale is achieved through composition, not accumulation.

The Myth of Bigger

Engineers are often tempted to solve problems by adding more.

Another firewall.

Another monitoring tool.

Another middleware layer.

Another proxy.

Another framework.

Another abstraction.

Another service.

Sometimes another layer is exactly what the system needs.

Often it is not.

Every new layer increases the number of interactions.

Every interaction increases the number of possible failure modes.

Every failure mode creates another troubleshooting path.

The architecture becomes harder to understand.

Harder to explain.

Harder to secure.

Harder to recover.

Large systems do not fail because they are large.

They fail because nobody fully understands how all of the pieces interact.

Growth without clarity eventually becomes fragility.

Simplicity Creates Leverage

One elegant function can eliminate hundreds of repeated lines of code.

One well-designed API can support dozens of applications.

One authentication platform can secure an entire organization.

One deployment pipeline can standardize hundreds of releases.

The impact of these solutions is far greater than their physical size.

That is leverage.

Leverage occurs when a small improvement is reused repeatedly.

The engineer who automates one deployment does not save five minutes.

They save five minutes every time the deployment occurs.

The engineer who simplifies authentication does not improve one login.

They improve every login.

The value compounds.

Small improvements become organizational advantages.

Design for Growth

Small components should never be designed with small ambitions.

A reusable module may begin supporting one application.

Tomorrow it may support fifty.

An API built for one customer may eventually serve thousands.

A script written to solve one problem may become the organization’s standard.

Thinking big means asking:

  • What happens if this succeeds beyond my expectations?
  • Will this component still make sense?
  • Will people understand it?
  • Can it evolve?
  • Can it be replaced?
  • Can it be tested independently?
  • Can it fail without bringing everything else down?

Thinking big is not about predicting the future perfectly.

It is about leaving room for the future to happen.

Resist Cleverness

Some engineers build systems to impress other engineers.

The code becomes clever.

The architecture becomes intricate.

The solution becomes difficult to explain.

Complexity begins masquerading as intelligence.

The strongest engineers usually move in the opposite direction.

They simplify.

They remove.

They clarify.

Anyone can add another layer.

It takes discipline to remove one.

An elegant design often appears obvious in hindsight.

That is not because it was easy.

It is because someone worked very hard to eliminate everything unnecessary.

If your architecture requires a lengthy explanation, the design may not yet be finished.

Build Foundations, Not Monuments

Large systems eventually change.

Requirements evolve.

Businesses merge.

Technologies improve.

Teams grow.

Architectures built around enormous, rigid components struggle to adapt.

Architectures built from clear, dependable building blocks evolve naturally.

The goal is not to predict every future requirement.

The goal is to build foundations strong enough to support requirements you have not yet imagined.

Closing Thought

The world remembers remarkable outcomes.

Engineers should remember the small decisions that made those outcomes possible.

History is rarely changed by making one thing larger.

It is changed by making one important thing better.

Build components that are small enough to perfect, and visions that are large enough to inspire.

The Principle Is Universal

The greatest transformations in history rarely arrived all at once.

They emerged from a single improvement repeated until it reshaped the world.

One improved farming technique fed villages.

One printing press spread knowledge across continents.

One steam engine changed manufacturing.

One transistor launched the digital age.

One reliable shipping container transformed global commerce.

Each began as an improvement to something much smaller than the final outcome.

The lesson is timeless.

Lasting change is usually built one dependable improvement at a time.

History is not built by giant leaps alone. It is built by countless small steps moving in the same direction.

Excellence Compounds

People often underestimate the power of small improvements because they judge them in isolation.

Saving one minute appears insignificant.

Reducing one defect seems trivial.

Removing one unnecessary dependency feels unimportant.

Improving one process appears invisible.

But systems are not experienced once.

They are experienced repeatedly.

A one-minute improvement performed a thousand times becomes days.

One prevented mistake repeated across an organization becomes thousands of dollars.

One simplified process adopted by hundreds of engineers becomes an entirely different company.

Excellence compounds.

Not because any single improvement is extraordinary.

Because small improvements rarely remain alone.

Build for the Next Engineer

Every component you build teaches the next engineer something.

Clean interfaces teach clarity.

Good documentation teaches ownership.

Simple architecture teaches discipline.

Predictable behavior teaches trust.

The next engineer should not need to admire your intelligence.

They should appreciate your restraint.

The greatest compliment to a system is often this:

“I understood it immediately.”

That is not accidental.

That is craftsmanship.

Big Thinking Requires Humility

Thinking big does not mean believing your first design is perfect.

It means accepting that your work may eventually become part of something much larger than yourself.

Your script may become a platform.

Your utility may become a company standard.

Your API may support customers you have never met.

Your documentation may teach engineers you will never know.

That possibility should encourage humility.

Not ego.

Build so others can extend your work.

Not admire how difficult it is to understand.

The Legacy of Small Decisions

Architects often remember the large projects.

History remembers the small decisions that made those projects possible.

The naming convention that eliminated confusion.

The reusable library that prevented duplication.

The deployment script that removed human error.

The authentication model that protected thousands of accounts.

The logging standard that solved an outage in minutes instead of days.

Those decisions rarely make headlines.

They quietly become the foundation upon which everything else is built.

Questions to Ask Yourself

  • Can this be made simpler without losing capability?
  • Does this component have one clear purpose?
  • Will someone understand this five years from now?
  • Does every layer add measurable value?
  • Am I optimizing for elegance or complexity?
  • If this succeeds beyond expectations, will it still scale?
  • Am I building something impressive, or something useful?

Closing Thought

Never underestimate the influence of a well-designed small thing.

History repeatedly shows that the greatest revolutions begin with improvements that almost nobody noticed at first.

Build what is small enough to perfect, and meaningful enough to outlive you.

Founder’s Commentary

Small Ideas Built My Career

When I look back over my career, I don’t remember one defining moment where everything suddenly changed.

I remember hundreds of small improvements.

One PowerShell script that removed a repetitive task.

One deployment that became predictable.

One monitoring rule that detected failures before customers noticed them.

One naming convention that eliminated confusion.

One piece of documentation that prevented the same mistake from happening twice.

None of those felt revolutionary when I created them.

Looking back, they changed everything.

Engineers sometimes dream about building the next great platform.

There is nothing wrong with that.

But most great platforms begin exactly the same way.

Someone solves one problem exceptionally well.

Then another.

Then another.

Eventually those small solutions begin connecting together.

People call it innovation.

The engineer remembers it as Tuesday.

Over the years I have inherited systems that seemed incredibly sophisticated.

Some contained dozens of frameworks.

Hundreds of integrations.

Thousands of configuration settings.

Yet they were fragile because nobody truly understood them.

I’ve also inherited remarkably simple systems.

They weren’t exciting.

They weren’t fashionable.

But they were dependable.

Those systems kept businesses running while everyone else chased the next trend.

That taught me something I have never forgotten.

Sophistication is not measured by complexity.

It is measured by clarity.

I would rather inherit one thousand lines of code that everyone understands than one hundred lines that only the original author can explain.

I would rather support ten dependable services than one brilliant system that nobody dares to change.

Small pieces give organizations confidence.

Confidence allows organizations to grow.

Growth creates opportunities no one could have predicted when the first component was written.

That is why I believe this Principle applies far beyond software.

The strongest relationships are built one conversation at a time.

The strongest companies are built one customer at a time.

The strongest reputations are built one decision at a time.

The strongest engineers are built one lesson at a time.

Nothing truly remarkable begins fully grown.

Everything begins with one small decision made well.

If there is one lesson I hope future engineers remember, it is this:

Never underestimate what one well-designed idea can become.

The world is rarely changed by one enormous breakthrough. It is changed by thousands of small decisions made with extraordinary care.

Principle XXVII — Security Begins in Design

Foundational Truth

Security is not a feature.

It is not a product.

It is not a firewall.

It is not an antivirus application.

It is not something added after the system has already been built.

Security begins with design.

Every architectural decision either strengthens the system or creates another opportunity for it to fail.

Every exposed service.

Every shared credential.

Every unnecessary permission.

Every undocumented interface.

Every forgotten certificate.

Every unmanaged secret.

Every dependency.

Every assumption.

Each one contributes to the security posture of the entire system.

The strongest organizations do not build systems first and secure them later.

They build secure systems from the beginning.

Security is not added to a design. Security is part of the design.

Tomorrow Is Already Coming

Every generation believes its security standards are strong enough.

History repeatedly proves otherwise.

There was a time when 56-bit DES encryption was considered commercially sufficient.

Today it can be broken in practical time with modern hardware.

Keys that once required specialized equipment to attack can now be challenged by consumer-grade computing resources.

Processing power continues to improve.

GPUs perform massively parallel operations that were unimaginable only a generation ago.

Specialized hardware accelerates cryptographic workloads.

Artificial intelligence assists in discovering vulnerabilities, analyzing code, and identifying attack paths.

The world does not stand still.

Neither do attackers.

A security decision made today may still be protecting data twenty-five years from now.

Design accordingly.

Build for the Future You Cannot See

Today’s strongest algorithms will eventually become tomorrow’s legacy systems.

That does not mean today’s protections are inadequate.

It means they should never be assumed permanent.

Strong engineering anticipates change.

Keys should be replaceable.

Certificates should be renewable.

Secrets should be rotatable.

Authentication methods should evolve.

Systems should support cryptographic agility instead of assuming one algorithm will remain sufficient forever.

Good security architecture expects improvement.

Great security architecture expects replacement.

Design so that your security can evolve without rebuilding your entire system.

Security Is Layers with Purpose

Effective security is not created by collecting products.

It is created by combining complementary controls.

Authentication confirms identity.

Authorization limits capability.

Least privilege reduces exposure.

Network segmentation limits movement.

Encryption protects confidentiality.

Logging creates visibility.

Monitoring creates awareness.

Backups preserve recovery.

Testing validates assumptions.

Each layer exists because it solves a different problem.

The objective is not to accumulate security tools.

The objective is to understand the threat each control addresses and ensure those controls work together.

Security is strongest when every layer has a clear purpose.

Convenience Is the Enemy of Secure Design

Many security failures begin as attempts to make life easier.

Shared administrator accounts.

Passwords stored in configuration files.

Long-lived credentials.

Disabled MFA.

Broad permissions.

Permanent exceptions.

Temporary workarounds that quietly become permanent architecture.

Every shortcut feels justified when viewed in isolation.

Together they become the attack surface.

Convenience should never become the default design principle.

The Cost of Waiting

Security postponed is rarely security completed.

Retrofitting authentication is harder than designing for it.

Retrofitting encryption is harder than designing for it.

Retrofitting logging is harder than designing for it.

Retrofitting least privilege is harder than designing for it.

Every delay increases cost.

Every assumption compounds risk.

The cheapest time to solve most security problems is before the first deployment.

Think Beyond Today’s Threats

The computing landscape continues to evolve.

Quantum computing is progressing from research laboratories toward practical applications.

Artificial intelligence continues to accelerate software development, vulnerability research, and automation.

New technologies create new opportunities.

They also create new risks.

No one can predict exactly when these advances will change practical security requirements.

Engineers do not need to predict the exact timeline.

They need to design systems capable of adapting when that timeline arrives.

Security should not depend upon today’s limitations remaining true forever.

Closing Thought

A secure system is not one that has never been attacked.

It is one that was designed with the expectation that attacks will continue to evolve.

Build for today’s threats.

Prepare for tomorrow’s capabilities.

Leave room for security to become stronger than it is today.

The strongest security is not the security that survives today. It is the security that can still adapt tomorrow.

Secure by Default

The strongest security controls are often the ones users never notice.

A secure system should require less effort to use correctly than incorrectly.

Authentication should be enabled.

Encryption should already be configured.

Certificates should already be trusted.

Secrets should never appear in source code.

Permissions should begin with the minimum necessary access.

Logging should already exist before the first incident occurs.

When security becomes optional, convenience usually wins.

Design the secure path to be the easiest path.

The safest system is the one that makes the secure choice the default choice.

Trust Must Be Earned

One of the oldest assumptions in computing was that anything inside the network could be trusted.

Modern systems have shown how dangerous that assumption can become.

Networks grow.

Organizations merge.

Employees work remotely.

Cloud providers connect environments across continents.

Partners require temporary access.

Applications communicate through APIs.

The perimeter becomes increasingly difficult to define.

Trust should therefore never be granted simply because something exists inside a particular network.

Every request should prove who it is.

Every action should prove it is authorized.

Every privilege should be intentional.

Trust is no longer a location.

Trust is a continuously evaluated decision.

Design for Least Privilege

Every permission granted creates opportunity.

Every unnecessary permission creates unnecessary risk.

A user should possess only the access required to perform today’s responsibilities.

Nothing more.

Applications should receive only the permissions they actually use.

Services should communicate only with systems they genuinely require.

Administrators should elevate privileges only when necessary.

Least privilege is not about limiting productivity.

It is about limiting consequences.

When compromise eventually occurs, the damage should remain as small as possible.

Good security assumes compromise is possible. Great security limits what compromise can become.

Secrets Are Temporary

Passwords.

API keys.

Certificates.

Access tokens.

Encryption keys.

Connection strings.

These are all secrets.

Every secret should be treated as temporary.

Secrets should never be hard-coded.

Never emailed.

Never stored inside documentation.

Never committed into source control.

Every secret should have:

  • A clear owner.
  • A defined purpose.
  • A secure storage location.
  • A rotation strategy.
  • A replacement procedure.
  • An expiration plan.

The goal is not merely protecting secrets.

It is ensuring they can safely change.

Observe Before You Need To

Many organizations begin improving logging after experiencing a security incident.

By then, the opportunity to collect useful evidence may already be gone.

Observability should begin during design.

Successful authentication.

Failed authentication.

Privilege changes.

Configuration modifications.

Administrative actions.

Certificate renewals.

Unexpected network connections.

These events should already be visible before anyone needs them.

Security without visibility is largely based upon hope.

Hope is not a security strategy.

Recovery Is Part of Security

Security is often associated with prevention.

Prevention matters.

Recovery matters just as much.

Can you restore encrypted data?

Can you recover deleted secrets?

Can you revoke compromised credentials?

Can you rotate certificates quickly?

Can you rebuild infrastructure from trusted code?

Can you recover within your required recovery objectives?

If the answer is no, then security planning is incomplete.

The ability to recover from compromise is one of the strongest security controls an organization can possess.

Security Is an Ongoing Design Decision

Security is never finished.

Every software update changes the environment.

Every new dependency changes the attack surface.

Every employee changes organizational knowledge.

Every new technology changes what attackers can accomplish.

Secure systems evolve because the people responsible for them continue evaluating assumptions.

Yesterday’s best practice eventually becomes tomorrow’s legacy design.

The architecture should make improvement expected rather than disruptive.

Closing Thought

Secure design is not about building walls that never fall.

It is about building systems that continue protecting people even as the world around them changes.

Security should not depend upon yesterday’s assumptions remaining true.

It should expect tomorrow to be different.

The strongest security architecture is not the one that never changes. It is the one that was designed to keep changing.

Security Is the Preservation of Trust

When most people hear the word security, they immediately think about hackers.

Firewalls.

Encryption.

Passwords.

Viruses.

Those are certainly part of security.

They are not its purpose.

The true purpose of security is preserving trust.

Customers trust that their personal information remains private.

Employees trust that company data is protected.

Patients trust that their medical history remains confidential.

Citizens trust that critical infrastructure continues operating.

Families trust that their home remains safe.

Every security control ultimately protects a relationship built upon trust.

Without trust, systems stop being used.

Without trust, businesses lose customers.

Without trust, organizations lose their reputation.

Technology protects information.

Security protects confidence.

Security exists to preserve trust.

Reputation Is a Security Asset

Many organizations think of security as an expense.

It is better understood as an investment.

A company may spend years building a trusted reputation.

One preventable breach can damage that reputation overnight.

Customers rarely remember the encryption algorithm that protected their information.

They remember whether their information was exposed.

Reputation is one of the few assets that becomes more valuable over time.

It is also one of the easiest to lose.

That is why security decisions are rarely just technical decisions.

They are business decisions.

Leadership decisions.

Ethical decisions.

Every safeguard protects more than data.

It protects confidence.

Security Is Stewardship

Engineers often protect information they do not own.

Medical records.

Financial information.

Customer identities.

Trade secrets.

Government records.

Research.

Personal conversations.

That information belongs to someone else.

We are merely its caretakers.

Stewardship carries responsibility.

The question is not:

“Can I access this information?”

The question is:

“Should I?”

The strongest security cultures are built upon responsibility rather than permission.

Technology enforces rules.

Character determines how those rules are used.

Design for the Person Who Comes After You

Every secure system eventually changes hands.

Someone inherits your architecture.

Someone rotates your certificates.

Someone renews your secrets.

Someone investigates the next security incident.

Someone patches the next vulnerability.

Your responsibility extends beyond today’s deployment.

Document the reasoning behind security decisions.

Explain why permissions exist.

Record key rotation procedures.

Describe recovery processes.

Teach the next engineer.

A secure system that nobody understands eventually becomes an insecure system.

Knowledge is one of the most important security controls an organization possesses.

Security Is a Living Discipline

Threats evolve.

Technology evolves.

Organizations evolve.

Attackers evolve.

Security must evolve with them.

Yesterday’s strongest password policy becomes today’s baseline.

Today’s encryption eventually becomes tomorrow’s legacy algorithm.

Today’s best practices become tomorrow’s historical lessons.

That is not failure.

That is progress.

The purpose of security is not to remain unchanged.

The purpose is to remain effective.

Security Extends Beyond Technology

The same Principle appears everywhere.

Parents secure their homes before leaving.

Banks secure financial transactions before approving them.

Pilots verify aircraft before departure.

Hospitals verify patient identity before treatment.

Nations secure critical infrastructure before crisis occurs.

The details change.

The philosophy remains.

Protect what matters before someone reminds you why it mattered.

Questions to Ask Yourself

  • What trust am I protecting?
  • What assumptions does this design depend upon?
  • If today’s strongest control weakens tomorrow, can the system adapt?
  • Would I trust my own family with this design?
  • What information has been entrusted to me?
  • Have I made the secure path the easiest path?
  • Will the next engineer understand why these decisions were made?

Closing Thought

Security is not about fearing the future.

It is about preparing for it.

Every thoughtful design decision today becomes confidence tomorrow.

The strongest systems are not those that never change.

They are those that continue earning trust as the world changes around them.

Protect the trust, and the technology will have something worth defending.

Founder’s Commentary

We Were Never Protecting Servers

When I first entered IT, I thought security was about computers.

Firewalls.

Antivirus.

Passwords.

Encryption.

Certificates.

The longer I worked in this industry, the more I realized those things were never the real objective.

They were simply the tools.

The real responsibility was protecting people.

Every server I managed contained someone’s information.

Every database represented years of work.

Every backup protected someone’s livelihood.

Every authentication system represented a person’s identity.

Every firewall ultimately existed because someone trusted us to protect what mattered to them.

That realization changes the way you approach engineering.

You stop asking whether a control is technically impressive.

You begin asking whether it genuinely reduces risk.

You stop collecting security products because they look good in architecture diagrams.

You begin building systems people can actually operate, understand, and maintain.

Good security is rarely glamorous.

Most of the time it looks like discipline.

Applying patches before anyone notices they are missing.

Rotating certificates before they expire.

Removing permissions nobody should have retained.

Replacing outdated encryption before it becomes tomorrow’s headline.

Documenting recovery procedures before they are desperately needed.

Testing backups before someone depends upon them.

None of those tasks make exciting conference presentations.

Yet those are the decisions that quietly prevent disasters.

One lesson has stayed with me throughout my career.

Attackers only have to succeed once.

Defenders must succeed every day.

That reality can feel overwhelming.

Until you remember something equally important.

Most successful attacks do not begin because attackers were brilliant.

They begin because defenders assumed they had more time.

One postponed patch.

One forgotten certificate.

One shared administrator account.

One API key committed into source control.

One exception that quietly became permanent.

Security failures are often the accumulation of small compromises rather than one catastrophic mistake.

That is why I believe security is fundamentally a design problem.

Well-designed systems make the secure decision the natural decision.

Poorly designed systems rely upon people remembering every detail forever.

Eventually, people forget.

Systems should not depend upon perfect memory.

They should support imperfect humans.

The strongest security culture I have ever experienced was never built upon fear.

It was built upon ownership.

Every engineer understood that they were protecting something that belonged to someone else.

A patient’s medical history.

A family’s financial information.

A company’s intellectual property.

A child’s personal identity.

The technology changed.

The responsibility never did.

Looking back, I don’t measure successful security by the number of attacks we stopped.

Most of those stories are invisible.

I measure it by the trust that was never broken.

By the customers who never had to wonder whether their information was safe.

By the organizations that continued operating because someone took security seriously long before there was an emergency.

That’s the paradox of good security.

When you do it well, nobody notices.

Nothing happens.

And that is exactly the outcome you were hoping for.

The greatest success in security is often the disaster that never happened because someone cared enough to design the system correctly from the beginning.

Principle XXVIII — Measure What Matters

Foundational Truth

Every system has a limit.

The challenge is discovering which limit actually matters.

Performance problems rarely announce themselves clearly.

Users experience slow applications.

Administrators see high CPU.

Dashboards show increased latency.

Storage reports elevated I/O.

Network graphs display higher utilization.

These observations are symptoms.

They are not necessarily causes.

Treating symptoms without understanding the underlying constraint often moves the problem rather than solving it.

Measure the constraint, not the symptom.

The Wrong Metric

Imagine upgrading a network from one gigabit to one hundred gigabits.

The infrastructure becomes dramatically faster.

The application remains slow.

Why?

Because the bottleneck never existed inside the network.

Perhaps the database storage cannot deliver data quickly enough.

Perhaps the web server cannot process requests fast enough.

Perhaps every request waits for an external API.

Perhaps the application spends most of its time waiting on a poorly written SQL query.

The network was never the problem.

Improving the wrong component only makes the real bottleneck easier to reach.

The same mistake appears everywhere.

A server with one hundred twenty-eight processors cannot execute a query faster than the storage subsystem can return the required data.

Sixteen terabytes of memory cannot compensate for an inefficient execution plan.

A faster processor cannot eliminate unnecessary database round trips.

The slowest meaningful component determines the experience of the whole system.

Bottlenecks Move

One of the most interesting properties of optimization is that success changes the problem.

Eliminate one bottleneck…

Another appears.

Improve storage performance…

The database engine becomes the limit.

Optimize the database…

The application tier becomes the limit.

Improve the application…

The authentication provider becomes the limit.

Every successful optimization shifts attention to the next constraint.

That is progress.

It is also why performance engineering is never truly finished.

Measure Before You Change

Changing a system without measurement is guessing.

Guessing occasionally succeeds.

Engineering should not rely upon luck.

Before changing a system, understand:

  • What is slow?
  • When did it become slow?
  • Under what conditions?
  • Which resource reaches its limit first?
  • Is the limitation consistent?
  • Can it be reproduced?
  • What evidence supports the hypothesis?

The goal is not collecting more metrics.

The goal is collecting the right metrics.

Data without context becomes noise.

Measurements without understanding become expensive guesses.

The Cost of Assumptions

Assumptions often become the most expensive part of troubleshooting.

“We’ve always needed more memory.”

“The network is probably overloaded.”

“It has to be the firewall.”

“It must be DNS.”

Sometimes those assumptions prove correct.

More often, they delay discovery of the real issue.

Every incorrect assumption consumes time.

Every unnecessary upgrade consumes money.

Every misdiagnosed problem reduces confidence.

Good engineers remain curious longer than they remain certain.

Evidence should lead conclusions.

Not the other way around.

Systems Reveal the Truth

Good monitoring does not exist to produce attractive dashboards.

It exists to answer questions.

What changed?

What resource saturated first?

What happened immediately before the failure?

Can the behavior be reproduced?

Can we prove our hypothesis?

Metrics should tell a story.

Logs provide detail.

Tracing reveals relationships.

Together they transform observation into understanding.

Without context, numbers become decoration.

Closing Thought

The purpose of measurement is not to confirm what you already believe.

It is to reveal what the system is actually doing.

The best engineers are not those who collect the most data.

They are those who ask the best questions before changing anything.

Measure what matters. Optimize what limits. Ignore what merely distracts.

Every Optimization Creates a New Bottleneck

The first bottleneck is rarely the last.

Every successful optimization changes the system.

Remove one constraint…

Another becomes visible.

Increase network bandwidth…

Storage becomes the limitation.

Upgrade storage…

The database engine becomes the limitation.

Optimize the database…

Application processing becomes the limitation.

Improve the application…

Authentication becomes the limitation.

Eventually, users discover a new delay.

This is not failure.

This is progress.

Every improvement exposes the next opportunity.

The purpose of optimization is not to eliminate bottlenecks. It is to discover the next one.

Throughput Is a Chain

A system performs only as quickly as its slowest meaningful component.

Imagine water flowing through a series of pipes.

One section is twelve inches wide.

The next narrows to two inches.

No matter how large the first pipe becomes, the narrowest section still determines how much water reaches the destination.

Technology behaves the same way.

CPU.

Memory.

Storage.

Network.

Database.

Application.

External APIs.

Authentication.

Caching.

Every request passes through multiple stages.

Improving one stage beyond the capability of the next rarely changes the overall experience.

Performance is a chain.

The weakest link determines the result.

More Resources Are Not Always Better

One of the easiest mistakes in engineering is assuming additional hardware solves every performance problem.

It often doesn’t.

Adding processors cannot fix poor algorithms.

Adding memory cannot eliminate inefficient database queries.

Faster storage cannot compensate for unnecessary network round trips.

Higher bandwidth cannot accelerate an application waiting on an external service.

The objective is never to build the biggest system.

The objective is to build the most balanced system.

Balanced systems use resources efficiently because every major component grows together.

Oversized components frequently sit idle while waiting for the actual constraint.

Unused capacity is not performance.

It is opportunity waiting for the right bottleneck.

Utilization Is Not the Same as Saturation

High utilization does not automatically indicate a problem.

A processor operating at eighty percent utilization may have plenty of capacity remaining.

A storage system at thirty percent utilization may already be saturated because of latency.

A network link at fifty percent utilization may still experience packet loss caused by congestion elsewhere.

Numbers rarely explain themselves.

Metrics require interpretation.

Understanding what a metric actually represents is often more valuable than the number itself.

Measure behavior, not just percentages.

Follow the Request

The fastest way to identify a bottleneck is to follow a single request through the system.

Where does it wait?

Where does latency increase?

Which component finishes first?

Which component consistently finishes last?

Tracing transforms isolated metrics into a complete story.

Instead of asking, “Which server is busy?”

You begin asking,

“Where is this request spending its time?”

Those are very different questions.

One measures infrastructure.

The other measures experience.

Users care about experience.

Engineers should too.

Measure Before and After

Optimization without measurement is opinion.

Every performance change should answer three questions.

What was the baseline?

What changed?

Did the change actually improve the outcome?

Without a baseline, improvement cannot be demonstrated.

Without validation, optimization becomes guesswork.

Many organizations celebrate changes that produce no measurable improvement because nobody established success criteria before implementation.

Engineering deserves better evidence than assumptions.

Performance Is About the User

The most important metric in any system is often the simplest.

Did the user’s experience improve?

A dashboard may show lower CPU.

Network utilization may decrease.

Storage latency may improve.

If users still wait thirty seconds for the application to load, the problem remains.

Technology exists to serve people.

Performance should therefore be measured from their perspective first.

Everything else supports that objective.

Closing Thought

Great engineers optimize systems.

Exceptional engineers optimize outcomes.

Never mistake activity for progress.

Never mistake measurements for understanding.

Measure the constraint.

Understand the cause.

Improve the experience.

Then begin measuring again.

The most valuable metric is the one that changes your next decision.

You Improve What You Measure

Measurement changes behavior.

People naturally pay attention to whatever is being measured.

If an organization measures uptime…

Engineers improve reliability.

If leadership measures ticket closure speed…

Tickets close faster.

If developers are measured by lines of code…

They write more code.

Whether that code is better is another question.

Metrics influence priorities.

Priorities influence behavior.

Behavior determines outcomes.

That is why choosing the wrong metric can quietly move an entire organization in the wrong direction.

People optimize for whatever success looks like. Make sure success is measured correctly.

Vanity Metrics

Not every measurement creates understanding.

Some measurements merely create comfort.

Followers.

Downloads.

CPU utilization.

Lines of code.

Gigabits per second.

Storage capacity.

Memory usage.

Each may be useful.

None automatically proves success.

A web server may process one million requests.

If every request fails…

The metric is meaningless.

A network may support one hundred gigabits per second.

If customers still experience delays…

Bandwidth was never the problem.

Measure outcomes.

Not appearances.

The Difference Between Activity and Progress

Busy systems often look productive.

Busy people often appear effective.

Neither assumption is necessarily true.

An engineer can spend all day solving alerts generated by one poorly designed application.

The engineer worked hard.

The organization made little progress.

Another engineer may spend two hours fixing the root cause.

The alerts disappear forever.

One measured activity.

The other measured impact.

The distinction matters.

Effort is not the same as value.

Movement is not the same as progress.

Do not confuse motion with momentum.

The Human Side of Measurement

The same Principle applies outside technology.

Parents should not measure only grades.

They should also measure curiosity.

Managers should not measure only hours worked.

They should measure outcomes.

Teachers should not measure memorization alone.

They should measure understanding.

Doctors do not simply measure medication administered.

They measure patient recovery.

The numbers matter.

Choosing the right numbers matters even more.

Every System Tells a Story

Metrics rarely answer questions by themselves.

They provide clues.

Logs provide evidence.

Tracing reveals relationships.

Experience provides interpretation.

The story only emerges when those pieces are considered together.

A good engineer learns to ask,

“What is this system trying to tell me?”

rather than,

“What number looks unusual today?”

The first question uncovers causes.

The second often produces distractions.

Measure the Outcome

Organizations frequently measure the work performed.

Customers measure the experience received.

Those are not always the same thing.

The engineer may celebrate reducing CPU utilization.

The customer celebrates a page loading in two seconds instead of ten.

The business celebrates increased customer satisfaction.

Always remember who defines success.

Technology supports outcomes.

It is not the outcome itself.

Questions to Ask Yourself

  • What problem am I actually trying to solve?
  • Which metric best represents success?
  • Am I measuring causes or symptoms?
  • What behavior will this measurement encourage?
  • Could this metric be improved without improving the outcome?
  • If this number becomes perfect, will anyone actually benefit?
  • What would the customer choose to measure?

Closing Thought

Measurement is one of the most powerful tools in engineering.

Used wisely, it reveals truth.

Used carelessly, it creates illusions.

The purpose of measurement is not to collect numbers.

The purpose of measurement is to improve decisions.

Measure what changes outcomes, not what merely fills dashboards.

Founder’s Commentary

The System Was Trying to Tell Me

One of the hardest lessons I ever learned as an engineer was that computers almost never lie.

People do.

Assumptions do.

Incomplete information does.

But systems are remarkably honest.

They simply answer the questions we ask of them.

The problem is that we often ask the wrong questions.

Early in my career, I was convinced I could identify performance problems by intuition.

The server felt slow.

CPU usage looked high.

The network graph appeared busy.

Memory utilization seemed excessive.

I had an explanation before I had evidence.

Sometimes I guessed correctly.

Many times I didn’t.

Over the years I began noticing a pattern.

Every major outage seemed obvious…

After we found the real cause.

Looking backward, every clue had been there.

The storage latency.

The failed SQL execution plan.

The exhausted connection pool.

The saturated firewall session table.

The expired certificate.

The blocked replication queue.

The clues were always present.

I simply wasn’t measuring the thing that actually mattered.

That realization changed the way I troubleshoot.

I stopped looking for confirmation of my first theory.

I started looking for evidence that would prove me wrong.

That sounds like a small change.

It wasn’t.

Instead of asking,

“Why do I think the network is slow?”

I began asking,

“What evidence would prove the network isn’t the problem?”

That question forced me to follow the data instead of my assumptions.

More often than not, the real bottleneck lived somewhere completely different.

I’ve seen organizations spend hundreds of thousands of dollars upgrading hardware that was never the limiting factor.

Faster processors.

More memory.

Larger storage arrays.

Higher bandwidth.

The users barely noticed.

Not because the upgrades failed.

Because the wrong thing had been improved.

The constraint never moved.

Eventually I realized something that applies far beyond technology.

People often optimize what they can easily measure instead of what actually determines success.

Businesses measure activity instead of outcomes.

Managers measure hours instead of results.

Developers measure code instead of maintainability.

Students measure grades instead of understanding.

Even in our personal lives, we sometimes mistake being busy for making progress.

The Principle is always the same.

The metric shapes the behavior.

Choose the wrong metric…

You improve the wrong thing.

Choose the right metric…

Everything begins moving in the right direction.

Today, when I inherit a new environment, I don’t begin by looking for the biggest server or the busiest dashboard.

I begin by asking one simple question.

“What is this system trying to tell me?”

The answer is almost always there.

You simply have to be willing to listen.

The greatest breakthroughs in troubleshooting rarely come from finding new answers. They come from finally asking better questions.

Principle XXIX — Truth Over Comfort

Foundational Truth

Reality does not negotiate.

A system either works…

Or it doesn’t.

Documentation is either accurate…

Or it isn’t.

A backup either restores…

Or it doesn’t.

A deployment either succeeds…

Or it fails.

The truth exists whether we choose to acknowledge it or not.

Engineering begins the moment we stop wishing reality were different and start understanding it as it actually is.

Comfort delays problems. Truth solves them.

The Comfortable Path

Every engineer eventually encounters the same temptation.

Assume the documentation is correct.

Assume the previous deployment was done properly.

Assume someone already tested the backups.

Assume the certificates were renewed.

Assume the firewall rules are intentional.

Assume the architecture diagram reflects reality.

Assumptions are comfortable.

Verification is work.

Unfortunately, production systems do not care which path feels easier.

Reality eventually exposes every incorrect assumption.

Discovery Is Not Failure

Some of the most difficult projects I have worked on began with uncertainty.

Documentation was incomplete.

Diagrams were outdated.

Configuration drift had accumulated for years.

Nobody could confidently explain how the environment actually worked.

At first, that feels frustrating.

It is easy to ask,

“Why didn’t someone document this?”

Sometimes that question is justified.

It rarely moves the project forward.

Instead, I learned to view discovery as part of the work.

Every unanswered question became another piece of the puzzle.

Every verified configuration became another page of documentation.

Every corrected diagram became something the next engineer could trust.

I stopped treating missing documentation as someone else’s failure.

I treated it as my opportunity to leave the environment better than I found it.

Truth Is Often Uncomfortable

Truth has a way of challenging our assumptions.

The architecture isn’t as resilient as we believed.

The backups have never been tested.

The failover process only works on paper.

The security controls aren’t configured correctly.

The deployment checklist is incomplete.

These discoveries rarely make people happy.

They make systems better.

Avoiding uncomfortable truths never eliminates risk.

It simply postpones the moment you must deal with it.

Usually at the worst possible time.

The sooner you discover the truth, the less expensive it becomes.

Shortcuts Create Future Emergencies

There is always pressure to move faster.

Skip one validation.

Delay one security update.

Ignore one warning.

Document it later.

Test it in production.

Most shortcuts succeed…

Right up until they don’t.

The work you avoided today rarely disappears.

It simply waits.

Often until the deployment window has closed.

Until customers are affected.

Until executives are asking for answers.

Until your team is working through the night trying to repair something that could have been prevented with thirty extra minutes of discipline.

Time borrowed from quality always demands repayment.

Usually with interest.

The Courage to Tell the Truth

One of the most valuable qualities an engineer can develop is the willingness to speak uncomfortable truths.

“The backup has never been restored.”

“This architecture will not scale.”

“We don’t actually know why it failed.”

“We need more time.”

“We should rebuild this instead of patching it again.”

These conversations are rarely popular.

They are often necessary.

Good engineering requires technical skill.

Great engineering requires intellectual honesty.

Build on Reality

Strong foundations are built upon facts.

Not assumptions.

Not optimism.

Not convenience.

Reality is not your enemy.

Reality is your most reliable design partner.

The sooner you understand it…

The sooner you can improve it.

Closing Thought

Every engineer eventually faces a choice.

Protect your comfort.

Or pursue the truth.

One feels better today.

The other builds systems that still work tomorrow.

Truth may be uncomfortable in the moment. Ignoring it is almost always more painful later.

Technical Debt Begins with Small Compromises

Technical debt rarely appears overnight.

It accumulates one comfortable decision at a time.

“We’ll document it later.”

“We’ll clean that up after deployment.”

“We’ll leave that account for now.”

“We’ll test failover next quarter.”

“We’ll rotate those certificates during the next maintenance window.”

Individually, each decision seems reasonable.

Collectively, they become an environment nobody completely understands.

The debt is rarely created by one catastrophic mistake.

It is created by hundreds of small compromises that never quite get revisited.

Technical debt is often deferred truth.

Evidence Over Assumption

Every engineer forms hypotheses.

“The database is probably overloaded.”

“It looks like a network issue.”

“I think the firewall is blocking the traffic.”

Hypotheses are valuable.

Confusing them with facts is dangerous.

Good troubleshooting follows a simple progression.

Observe.

Measure.

Verify.

Only then conclude.

Every piece of evidence should strengthen or weaken your hypothesis.

If new evidence contradicts your original theory…

Celebrate.

The system has just taught you something.

Changing your mind because of evidence is not weakness.

It is engineering.

Documentation Is a Reflection of Truth

Documentation should describe reality.

Not intention.

Not historical architecture.

Not what someone believes the environment looks like.

Reality.

An inaccurate document is often worse than no document at all.

It creates confidence where skepticism would have been healthier.

When I inherit an undocumented environment, I don’t begin by writing documents.

I begin by verifying reality.

Only then do I document what actually exists.

Documentation should never become another assumption.

It should become verified knowledge.

Honest Assessments Build Better Systems

Some conversations are uncomfortable.

“We aren’t ready to deploy.”

“We don’t know enough yet.”

“This architecture won’t scale.”

“We need another week.”

Those statements can feel like failures.

They are not.

Pretending readiness does not create readiness.

Ignoring limitations does not remove them.

The sooner an organization accepts reality, the sooner it can improve it.

Leaders who reward honesty build stronger engineering cultures.

Leaders who punish honesty often receive comforting answers instead of truthful ones.

That trade eventually becomes expensive.

Leave It Better Than You Found It

One lesson has guided much of my career.

Every environment I touch should become easier for the next engineer.

If documentation is missing…

Write it.

If naming conventions are inconsistent…

Standardize them.

If scripts require manual intervention…

Automate them.

If diagrams are outdated…

Update them.

I cannot always solve every problem.

I can always reduce the number of unknowns.

The next engineer should spend less time rediscovering truth because I chose to record it.

That is respect.

That is stewardship.

Truth Creates Confidence

Confidence should never come from optimism.

It should come from evidence.

Backups have been restored successfully.

Disaster recovery has been tested.

Certificates have been renewed.

Monitoring has been validated.

Documentation matches reality.

These facts create confidence because they have been proven.

Hope is comforting.

Evidence is dependable.

Closing Thought

Comfort asks,

“Can we avoid this conversation?”

Truth asks,

“What must we understand before we move forward?”

Only one of those questions builds systems people can trust.

The strongest engineering decisions are rarely the most comfortable. They are the ones most firmly rooted in reality.

Reality Does Not Care

Reality is wonderfully impartial.

It does not care about intentions.

It does not care about deadlines.

It does not care about budgets.

It does not care about optimism.

Reality simply responds to the decisions we make.

A neglected backup eventually fails.

Ignored technical debt eventually compounds.

Deferred maintenance eventually becomes an outage.

The consequences arrive whether we acknowledge them or not.

Reality is patient.

It always waits.

Reality never loses an argument. It simply waits for evidence.

Comfortable Lies

Not every lie is malicious.

Some are simply comforting.

“We’ll fix it after this release.”

“It’s probably fine.”

“No one will notice.”

“It has worked this way for years.”

“We’ve never had a problem before.”

Comforting lies reduce today’s anxiety.

They increase tomorrow’s risk.

Eventually the system exposes the truth anyway.

The only difference is how expensive that lesson becomes.

Organizations Reflect Their Culture

Engineering culture is shaped by what leaders reward.

If engineers are rewarded for honesty…

Problems surface early.

If engineers are punished for bad news…

Problems remain hidden.

People naturally protect themselves.

Instead of reporting concerns, they begin reporting confidence.

Instead of asking difficult questions, they provide comfortable answers.

The organization becomes increasingly disconnected from reality.

That disconnect is dangerous.

Great organizations encourage truth, even when it is inconvenient.

Because today’s uncomfortable conversation often prevents tomorrow’s crisis.

Truth Builds Trust

People do not lose trust because mistakes happen.

Mistakes are inevitable.

Trust is lost when reality is hidden.

Customers forgive honest communication.

Teams forgive honest mistakes.

Leaders forgive honest uncertainty.

What people struggle to forgive is discovering that someone knew the truth and chose comfort instead.

Honesty creates credibility.

Credibility creates trust.

Trust creates resilient teams.

The same principle applies everywhere.

Improvement Begins with Acceptance

Nothing improves until it is acknowledged.

A struggling project.

An outdated architecture.

A broken process.

A failing relationship.

A declining business.

Ignoring reality delays improvement.

Accepting reality begins improvement.

Acceptance is not surrender.

Acceptance is simply agreeing to start from the correct location.

Every map begins by identifying where you actually are.

Engineering is no different.

Courage Is an Engineering Skill

Technical ability is only part of engineering.

Courage matters too.

The courage to admit uncertainty.

The courage to ask for help.

The courage to recommend delaying a deployment.

The courage to tell leadership that more time is needed.

The courage to say,

“I don’t know.”

Those words have never weakened my confidence.

They have strengthened it.

Because they leave room for learning.

Pride protects the ego.

Truth protects the system.

Questions to Ask Yourself

  • What assumption have I stopped questioning?
  • What evidence supports my conclusion?
  • What uncomfortable truth am I avoiding?
  • If I delay fixing this, what becomes more expensive?
  • Am I protecting the project, or protecting my comfort?
  • What would I discover if I verified instead of assumed?
  • Will the next engineer inherit confidence or confusion?

Closing Thought

The purpose of truth is not to make us uncomfortable.

The purpose of truth is to give us a foundation that reality cannot undermine.

Comfort fades.

Evidence endures.

Build upon what is true.

Everything else eventually shifts beneath your feet.

Truth may be difficult to hear today, but it is far easier than explaining tomorrow why you chose not to listen.

Founder’s Commentary

Reality Became My Best Teacher

If you work in engineering long enough, you’ll eventually inherit a project that nobody fully understands.

The documentation is incomplete.

The diagrams are outdated.

The original engineers have moved on.

The environment has evolved through years of emergency changes, temporary fixes, and undocumented decisions.

At first, that’s frustrating.

It’s easy to ask,

“Why didn’t they document this?”

“Why wasn’t this built correctly?”

“Who thought this was a good idea?”

Those questions might even be justified.

But they don’t solve the problem.

Somewhere along the way, I realized something.

I wasn’t being paid to judge the past.

I was being trusted to improve the future.

That realization changed my career.

Instead of becoming frustrated by missing documentation, I began creating it.

Instead of complaining about inconsistent naming conventions, I standardized them.

Instead of accepting tribal knowledge, I documented discovery.

Instead of leaving temporary fixes for someone else, I tried to remove them completely.

I stopped asking,

“Who created this mess?”

I started asking,

“How do I leave this better than I found it?”

That question has guided me for decades.

I’ve walked into environments where nobody could explain why systems worked.

Only that they somehow did.

I’ve watched deployment meetings begin with confidence…

Only to dissolve into uncertainty because reality didn’t match the documentation.

I’ve sat in conference rooms while Scrum Masters nervously reviewed the failures from yesterday’s deployment.

I’ve watched project managers ask for certainty when the honest answer was,

“We don’t know yet.”

Those moments are uncomfortable.

They are also where real engineering begins.

Truth is rarely convenient.

Sometimes it tells you the project needs another week.

Sometimes it tells you the architecture must be redesigned.

Sometimes it tells you the deployment should be postponed.

Sometimes it tells you the documentation you’ve relied upon for years is simply wrong.

Ignoring those truths never changes reality.

It only changes when you’ll be forced to deal with it.

I’ve learned that there are only two good times to fix a problem.

When you first discover it.

Or immediately after.

Every hour you postpone a known problem gives it another opportunity to become someone else’s emergency.

I’ve lived through enough production outages to know how that story ends.

The shortcut that saved thirty minutes during deployment eventually costs thirty hours during recovery.

The undocumented firewall rule eventually blocks the critical application.

The certificate that “still has plenty of time” expires on a holiday weekend.

The backup that “should probably work” becomes the only backup anyone has.

Reality keeps excellent records.

It remembers every compromise we’ve forgotten.

Looking back, I don’t think the most valuable skill I developed was technical.

It was becoming comfortable with uncomfortable truths.

Admitting I didn’t know.

Verifying instead of assuming.

Changing direction when the evidence demanded it.

Starting over when the foundation proved unstable.

Those decisions never felt good in the moment.

They almost always proved to be the right ones later.

Engineering isn’t about being right all the time.

It’s about becoming less wrong as quickly as possible.

Reality helps us do that…

If we’re willing to listen.

The truth has never been my enemy. It has been my most honest mentor. Every difficult lesson it taught me made me a better engineer than comfort ever could.

Principle XXX — Admit What You Don’t Know

Foundational Truth

No engineer knows everything.

No architect.

No developer.

No database administrator.

No network engineer.

No security expert.

Technology evolves too quickly for anyone to master every discipline.

The strongest engineers are not those who pretend otherwise.

They are the ones who understand where their knowledge ends.

Confidence earns attention. Honesty earns trust.

The Three Most Powerful Words

“I don’t know.”

Few sentences are more difficult for young engineers to say.

Pride resists them.

Fear avoids them.

Insecurity disguises them.

Yet those three words often mark the beginning of real learning.

The moment we admit we don’t know something…

We become teachable.

Until then, we’re simply defending assumptions.

The Interview Lesson

During my career I conducted hundreds of technical interviews.

More than four hundred and fifty, by the time I stopped counting.

One pattern appeared again and again.

I’d ask a technical question.

The candidate didn’t know the answer.

Instead of saying,

“I don’t know,”

they would invent one.

Sometimes the definitions sounded convincing.

Sometimes they were wildly creative.

Almost always they fell apart after one or two follow-up questions.

Not because I was trying to embarrass them.

Because I already knew the answer.

The interview was never about proving I was smarter.

It was about discovering where their knowledge ended.

That is exactly what interviews are supposed to accomplish.

We Can Teach Technology

One realization changed the way I interviewed engineers.

Technology is teachable.

Integrity is not.

I can teach someone Active Directory.

I can teach networking.

I can teach AWS.

I can teach SQL Server.

I can teach scripting.

I can teach cloud architecture.

What I cannot teach is honesty.

I cannot teach someone to value integrity.

I cannot teach someone to admit mistakes.

Those qualities already exist long before they arrive for the interview.

They are what determine whether I can trust them after they are hired.

Knowledge can be developed. Character must already be present.

The Cost of Pretending

Pretending to know something rarely ends with the interview.

It follows engineers into production.

A configuration is misunderstood.

A deployment proceeds anyway.

A warning is ignored.

A change is approved without full understanding.

Eventually the system fails.

Now the engineer faces another choice.

Admit uncertainty…

Or protect pride.

One accelerates recovery.

The other delays it.

The truth eventually appears in the logs.

Or the monitoring.

Or the postmortem.

Reality has a remarkable way of exposing what we hoped nobody would discover.

Engineering Is Continuous Learning

Technology changes continuously.

Today’s expert becomes tomorrow’s beginner.

New programming languages appear.

New cloud services emerge.

New security models replace old assumptions.

The engineer who cannot say,

“I don’t know,”

will eventually stop learning.

Not because opportunities disappear.

Because pride prevents curiosity.

Closing Thought

Every engineer has limits.

The strongest engineers know where theirs are.

There is no shame in not knowing.

The only shame is pretending you do.

The words “I don’t know” are not an admission of failure. They are an invitation to learn.

Curiosity Begins Where Certainty Ends

Every engineer eventually reaches the edge of their knowledge.

That is not failure.

That is where growth begins.

The engineer who says,

“I’ve never seen this before.”

has an opportunity.

The engineer who pretends they already understand it…

Has closed the door to learning.

Curiosity requires humility.

Humility begins with honesty.

The phrase “I don’t know” is often the first sentence in every meaningful lesson.

Interviews Reveal Character

Technical interviews are often misunderstood.

Candidates believe they are expected to answer every question correctly.

That has never been my objective.

During my career I conducted more than four hundred and fifty technical interviews.

The goal was never to discover everything someone knew.

The goal was to discover where learning would begin.

Eventually every interview reaches a question the candidate cannot answer.

That moment is the most valuable part of the interview.

Some candidates calmly say,

“I don’t know.”

Others panic.

They begin inventing definitions.

Connecting unrelated technologies.

Guessing at terminology.

Trying desperately to avoid admitting uncertainty.

The unfortunate reality is simple.

The interviewer already knows the answer.

Making something up rarely demonstrates intelligence.

It demonstrates fear.

One honest sentence tells me far more about someone’s character than five impressive answers ever could.

The interviewer isn’t looking for perfection. They’re looking for the point where learning begins.

Integrity Is More Valuable Than Expertise

Every technology can be learned.

Programming languages change.

Operating systems evolve.

Cloud platforms expand.

Security practices mature.

Database engines improve.

Technical knowledge has a shelf life.

Integrity does not.

When I hire an engineer, I am making a long-term investment.

I need to know that when something eventually goes wrong—and it will—that engineer will tell me the truth.

Will they admit the mistake?

Will they ask for help?

Will they help recover the system?

Or will they protect their ego while everyone else loses valuable time searching for answers?

That decision tells me far more than any certification ever could.

I can teach technology.

I cannot teach integrity.

Mistakes Are Expected

No engineer reaches retirement without making mistakes.

Deployments fail.

Scripts delete the wrong files.

Databases become unavailable.

Certificates expire.

Firewall rules block production traffic.

Every experienced engineer carries stories like these.

Mistakes are inevitable.

Dishonesty is optional.

The mistake usually costs time.

The cover-up costs trust.

Recovery begins the moment someone says,

“I made a mistake.”

Recovery is delayed every minute someone tries to hide it.

Errors test technical skill. Integrity tests character.

Questions Are a Sign of Strength

Young engineers often hesitate to ask questions because they fear appearing inexperienced.

Experienced engineers ask questions constantly.

Not because they know less.

Because they understand how much remains unknown.

Questions uncover assumptions.

Questions expose risk.

Questions prevent outages.

Questions build understanding.

The engineer asking thoughtful questions is usually the engineer preventing tomorrow’s incident.

The Best Teams Normalize “I Don’t Know”

The healthiest engineering teams I’ve ever seen shared one characteristic.

Nobody was afraid to admit uncertainty.

People asked questions freely.

Ideas were challenged respectfully.

Evidence mattered more than ego.

Learning happened continuously.

Those teams solved difficult problems faster because nobody wasted energy pretending to know everything.

Psychological safety is not about lowering standards.

It is about removing the fear of honesty.

When people feel safe admitting uncertainty, they begin solving problems together instead of protecting their reputations.

Closing Thought

Knowledge grows.

Technology changes.

Experience accumulates.

One quality should remain constant.

The willingness to tell the truth.

No engineer ever became weaker by admitting they didn’t know something.

Most became stronger because they chose to learn instead of pretend.

The fastest path to knowledge begins with the courage to admit where your knowledge ends.

Wisdom Begins with Humility

There is a profound difference between intelligence and wisdom.

Intelligence accumulates knowledge.

Wisdom recognizes its limits.

The more I learned throughout my career, the more I realized how much remained unknown.

Every answer uncovered another question.

Every solved problem revealed another layer of complexity.

Every new technology created another discipline to understand.

That realization never discouraged me.

It made me curious.

The wisest people are rarely the loudest. They know how much remains to be learned.

Pride Stops Learning

Pride has a remarkable way of disguising itself.

Sometimes it appears as confidence.

Sometimes it appears as certainty.

Sometimes it appears as silence because someone is afraid to ask a question.

Pride whispers,

“You should already know this.”

Humility asks,

“Would you explain that?”

One sentence protects the ego.

The other expands the mind.

Knowledge grows only where pride allows curiosity to enter.

Every Expert Was Once a Beginner

It is easy to admire experienced engineers.

The architect who understands distributed systems.

The database administrator who can diagnose a query in minutes.

The network engineer who instinctively understands packet flow.

What we often forget is that every one of them once knew nothing about those subjects.

They asked questions.

They made mistakes.

They misunderstood concepts.

They learned from mentors.

They admitted uncertainty.

Experience is not evidence that someone never struggled.

It is evidence that they continued learning.

Build Cultures That Welcome Questions

The healthiest organizations encourage questions.

Not because people are uninformed.

Because asking questions uncovers assumptions.

Questions expose risks.

Questions improve designs.

Questions prevent expensive mistakes.

When people fear appearing uninformed, they stop asking.

When they stop asking…

Organizations stop learning.

The strongest teams create environments where saying,

“I don’t understand.”

is treated as the beginning of collaboration rather than the end of credibility.

Integrity Creates Trust

People trust those who tell the truth.

Even when the truth is,

“I don’t know.”

Especially when the truth is,

“I made a mistake.”

Integrity does not require perfection.

It requires honesty.

Customers forgive honest mistakes.

Teams recover from honest failures.

Organizations improve because someone had the courage to speak honestly before a small problem became a large one.

Trust grows through consistency.

Every honest conversation strengthens it.

Every dishonest one weakens it.

Learning Never Ends

Technology changes.

Industries change.

People change.

The engineer who believes they have finished learning quietly begins falling behind.

The engineer who remains curious continues growing long after formal education ends.

Learning is not an event.

It is a lifelong habit.

The sentence,

“I don’t know,”

should never be followed by a period.

It should always be followed by,

“…but let’s find out.”

That is the mindset that builds extraordinary careers.

Questions to Ask Yourself

  • What am I pretending to understand?
  • What question am I afraid to ask?
  • What assumption have I accepted without verifying?
  • Would admitting uncertainty improve this decision?
  • Am I protecting my reputation or expanding my understanding?
  • If I make a mistake, will I own it immediately?
  • What can I learn today that I didn’t know yesterday?

Closing Thought

There is no shame in reaching the edge of your knowledge.

That edge is where discovery begins.

Every remarkable engineer has stood there countless times.

The difference is not whether they knew the answer.

The difference is whether they had the courage to admit they didn’t.

Humility opens the door that pride keeps locked. Every great engineer walks through that door again and again.

Founder’s Commentary

The Best Answer I Ever Heard

After conducting more than four hundred and fifty technical interviews, people often ask me what the best answer I ever heard was.

It wasn’t an explanation of BGP.

It wasn’t an elegant discussion about distributed databases.

It wasn’t an architect explaining cloud networking.

It was three simple words.

“I don’t know.”

Those words immediately changed the conversation.

Not because the interview was over.

Because the interview had finally become honest.

The purpose of a technical interview is often misunderstood.

Many candidates believe they are competing to prove they know everything.

That has never been what I was looking for.

I already knew the answers to the questions I was asking.

I wasn’t testing whether someone could fool me.

I was trying to discover the edge of their knowledge.

That edge tells me something incredibly valuable.

It tells me where teaching begins.

When a candidate confidently admitted they didn’t know something, I smiled.

Not because they failed.

Because I had just learned something important about their character.

They valued truth more than appearance.

That matters.

Technology changes every year.

Character rarely does.

I’ve watched candidates invent astonishing definitions for technologies they had clearly never encountered.

Some were genuinely creative.

Some almost sounded believable.

But every invented answer created another question.

Within minutes, the story collapsed under its own weight.

Not because I was trying to embarrass anyone.

Because truth is remarkably consistent.

Fabrication requires constant maintenance.

Reality does not.

That lesson extends far beyond interviews.

Every engineer will eventually make a mistake.

I’ve made plenty.

Deployments don’t always go as planned.

Scripts don’t always behave as expected.

Architectures sometimes reveal weaknesses that nobody anticipated.

Those moments define careers.

Not because mistakes happened.

Because of what happens next.

I’ve always had far more respect for the engineer who walked into my office and said,

“I made a mistake.”

than the engineer who quietly hoped nobody would notice.

The first engineer became part of the solution.

The second became part of the problem.

Recovery begins with honesty.

Every minute spent protecting pride is a minute not spent restoring service.

Eventually the logs tell the truth.

The monitoring tells the truth.

The postmortem tells the truth.

Reality always catches up.

Integrity simply gets there first.

As my career progressed, I realized I was hiring for something much larger than technical skill.

I was hiring people I could trust when everything went wrong.

Could they admit uncertainty?

Could they ask for help?

Could they tell a customer the truth?

Could they own a mistake without looking for someone else to blame?

Those qualities cannot be measured by certifications.

They cannot be proven by memorizing interview questions.

They appear naturally when someone values honesty more than ego.

Looking back, I no longer believe the strongest engineers are the ones who know the most.

I believe they are the ones who never stop learning because they are never afraid to admit what they don’t know.

That attitude has served me better than any certification, programming language, or technology ever could.

If there is one lesson I hope every young engineer carries throughout their career, it is this:

Never be embarrassed by the words,

“I don’t know.”

Be embarrassed only if you stop there.

Say,

“I don’t know…

…but I’ll find out.“

That’s the engineer I would hire every single time.

Knowledge earns respect. Integrity earns trust. In the end, trust is what every great engineer is truly hired to protect.

Principle XXXI — Own the Outcome

Foundational Truth

Ownership does not end when the work is complete.

It ends when the outcome is achieved.

Many people enjoy accepting credit for success.

Far fewer are willing to accept responsibility for failure.

True ownership requires both.

If the deployment succeeds…

Celebrate the team.

If the deployment fails…

Join the recovery.

Ownership is not measured when everything goes according to plan.

It is measured when reality refuses to cooperate.

If you accept the credit, you must also accept the responsibility.

Success Has Many Parents

When projects succeed…

Everyone remembers their contribution.

Ideas are recalled.

Late nights become stories.

Victories become shared.

Failure often follows a different pattern.

“It was the vendor.”

“It was the network.”

“It was the database.”

“It was the API.”

“It was another team’s responsibility.”

Sometimes those statements are technically correct.

They rarely improve the situation.

Customers do not care whose fault it was.

They care whether the problem is being solved.

Engineers should too.

Your Name Is Still on the Solution

Every application depends upon something else.

Databases.

Networks.

Operating systems.

Cloud providers.

Third-party APIs.

Identity platforms.

Storage.

Power.

Nothing exists in isolation.

When one dependency fails, it is easy to declare,

“That isn’t my problem.”

Technically, perhaps it isn’t.

Practically…

Your users still cannot accomplish their work.

Ownership means asking,

“What can I do to improve the outcome?”

rather than,

“Who should I blame?”

That question changes everything.

Perfection Is an Illusion

The first version of every application contains flaws.

Every architecture evolves.

Every deployment process improves.

Every monitoring strategy becomes more complete.

Every engineer eventually discovers something they wish they had designed differently.

That is normal.

Growth requires iteration.

What confuses me is watching organizations embrace continuous improvement during development…

Then abandon it after deployment.

The application suddenly becomes “finished.”

Every future issue becomes someone else’s fault.

That mindset quietly stops improvement.

Software is never perfect.

It simply becomes better through continuous refinement.

If you still own the application, you still own the opportunity to improve it.

The Imaginary Line

Somewhere in many organizations, an imaginary line appears.

Before deployment…

Everything is our responsibility.

After deployment…

Everything becomes somebody else’s.

Support.

Operations.

Infrastructure.

The vendor.

The cloud provider.

The customer.

I have never believed in that line.

The customer doesn’t experience departments.

They experience outcomes.

If the system isn’t meeting the promise we made…

The work isn’t finished.

Ownership Creates Trust

People naturally trust those who remain present when things become difficult.

The engineer who joins the outage bridge.

The developer who stays through the rollback.

The architect who helps investigate the root cause.

The manager who accepts responsibility before assigning it.

Those people become trusted because they never disappear when accountability arrives.

Ownership builds credibility.

Credibility builds leadership.

Closing Thought

Blame explains the past.

Ownership improves the future.

Every problem presents the same choice.

Ask,

“Whose fault is this?”

Or ask,

“What do we do next?”

Only one of those questions moves the system forward.

The outcome belongs to everyone willing to improve it. Be one of those people.

Ownership Continues After Delivery

Many people believe ownership ends when the project is delivered.

The code compiles.

The deployment succeeds.

The customer signs off.

The ticket closes.

The work is finished.

Except it isn’t.

That is often where the real work begins.

Users discover new workflows.

Unexpected edge cases appear.

Performance changes under production load.

Dependencies behave differently than expected.

Business requirements evolve.

The first deployment is not the finish line.

It is the beginning of understanding how the system behaves in the real world.

Shipping software ends development. It does not end ownership.

The Difference Between Fault and Responsibility

One lesson took me years to fully appreciate.

Fault and responsibility are not the same thing.

A cloud provider may experience an outage.

A third-party API may fail.

A certificate authority may revoke a certificate.

A vendor may release a defective update.

None of those situations may be your fault.

They are still your responsibility.

Not because you caused them.

Because your users still depend upon you.

The customer rarely asks,

“Who caused this?”

They ask,

“When can I work again?”

Ownership begins at exactly that moment.

Recovery Is Part of the Product

Customers judge software differently than engineers do.

Engineers remember the architecture.

Customers remember the experience.

When something breaks, they remember:

How quickly someone responded.

Whether communication was honest.

Whether updates were frequent.

Whether confidence inspired calm.

Whether the issue stayed fixed afterward.

Recovery becomes part of the product.

The outage may be unavoidable.

A poor recovery rarely is.

Blame Solves Nothing

One of the fastest ways to stop progress is to begin assigning blame before understanding the problem.

Blame answers one question.

Who should feel responsible?

Ownership asks a different question.

What must happen next?

The first question satisfies emotion.

The second restores service.

After decades of incident response, I’ve learned something simple.

The outage does not care whose fault it is.

The outage only ends when someone starts solving it.

Blame explains yesterday. Ownership builds tomorrow.

Continuous Improvement Never Stops

The best engineering teams I’ve worked with shared one common habit.

Every incident became a lesson.

Every lesson became an improvement.

Every improvement reduced the likelihood of repetition.

A deployment failed.

The checklist improved.

A certificate expired.

Monitoring improved.

A backup restore took too long.

Recovery procedures improved.

The goal was never perfection.

The goal was making the next version better than the last.

Organizations that stop learning eventually stop improving.

Organizations that own outcomes continue evolving.

Ownership Inspires Confidence

People naturally follow those who remain engaged when situations become difficult.

The engineer who stays on the bridge call.

The developer who helps Support troubleshoot.

The architect who assists Operations during recovery.

The manager who shields the team while accepting accountability.

Those people become leaders long before anyone gives them the title.

Leadership is not demonstrated during success.

It is revealed during adversity.

Build Systems You Are Proud to Support

One question has quietly guided many of my engineering decisions.

“If this system fails at two o’clock in the morning…

…would I feel confident supporting it?“

If the answer is no…

The design is not finished.

Ownership changes how we build.

Because someday we may be the ones answering the phone.

Design accordingly.

Closing Thought

Ownership is not measured by how proudly you launch a system.

It is measured by how faithfully you improve it.

Stay after the deployment.

Join the recovery.

Write the documentation.

Improve the monitoring.

Fix the root cause.

Then leave the system stronger than yesterday.

Anyone can celebrate success. Engineers earn trust by owning everything that happens afterward.

Ownership Is a Mindset

Ownership is not a job title.

It is not determined by an organizational chart.

It is not granted during a promotion.

Ownership is a decision.

A decision to remain engaged.

A decision to improve what is within your influence.

A decision to leave things better than you found them.

Some people are assigned responsibility.

Others choose ownership.

The difference becomes obvious the moment something unexpected happens.

Responsibility may be assigned. Ownership is always accepted.

Excuses Limit Growth

There will always be reasons something failed.

The requirements changed.

The documentation was incomplete.

The vendor introduced a defect.

Another department missed a deadline.

The budget was reduced.

The timeline was unrealistic.

Sometimes every one of those statements is true.

None of them improve tomorrow.

Excuses explain why something happened.

Ownership asks,

“What can we learn?”

That simple question transforms every setback into an opportunity.

Every Outcome Teaches Something

The best projects I’ve worked on weren’t perfect.

Neither were the worst.

The difference wasn’t the number of mistakes.

The difference was what happened afterward.

Did the team become defensive?

Or did they become curious?

Did they look for someone to blame?

Or did they search for the root cause?

Did they protect reputations?

Or improve the system?

Every outcome leaves behind a lesson.

Whether we choose to learn it determines whether the experience becomes wisdom or simply history.

Build a Culture of Ownership

Ownership spreads.

When one engineer stays late to help recover a deployment…

Others notice.

When a manager accepts responsibility before assigning it…

People remember.

When an architect joins the troubleshooting bridge instead of simply requesting updates…

Trust grows.

Culture is rarely created by policies.

It is created by repeated examples.

Teams become remarkably similar to the behaviors their leaders consistently demonstrate.

If leaders own outcomes…

Ownership becomes normal.

If leaders assign blame…

Blame becomes culture.

Improvement Is the Best Apology

Mistakes deserve acknowledgement.

But apologies alone rarely restore confidence.

Improvement does.

Customers remember that the issue never happened again.

Coworkers remember the new documentation.

Future engineers appreciate the automation that prevented the same failure.

The strongest apology is a better system.

Real ownership is measured by what changes after the mistake, not by how eloquently we explain it.

Ownership Extends Beyond Engineering

The same Principle applies everywhere.

Parents own the environment they create for their children.

Teachers own the culture inside their classrooms.

Leaders own the direction of their organizations.

Coaches own the preparation of their teams.

Communities own the standards they choose to accept.

Ownership is not about controlling everything.

It is about accepting responsibility for the part that is yours to influence.

That is where meaningful change always begins.

Questions to Ask Yourself

  • What part of this outcome belongs to me?
  • What can I improve before this happens again?
  • Am I looking for causes or someone to blame?
  • What lesson is this experience trying to teach me?
  • What will the next engineer inherit because of my decisions?
  • Did I leave the system stronger than I found it?
  • If this happened again tomorrow, would we respond better than we did today?

Closing Thought

Anyone can explain why something happened.

Leaders ask what happens next.

Ownership is not about carrying every burden alone.

It is about refusing to walk away while the burden still exists.

Every system.

Every project.

Every relationship.

Every team.

Be remembered not for avoiding responsibility…

But for embracing the opportunity to improve the outcome.

The measure of ownership is not whether you caused the problem. It is whether you stayed long enough to help create the solution.

Founder’s Commentary

There Was Never an Imaginary Line

One question has stayed with me throughout my career.

At what point does a problem stop being mine?

I’ve never found a good answer.

Early in a project, ownership feels obvious.

We gather requirements.

Design the architecture.

Write the code.

Review the documentation.

Test the deployment.

Everyone agrees the project belongs to us.

Then something changes.

The application ships.

Users arrive.

A dependency fails.

An unexpected edge case appears.

Performance doesn’t meet expectations.

Suddenly the conversation changes.

“It must be the database.”

“It has to be the network.”

“The vendor changed their API.”

“Operations owns that now.”

Support.

Infrastructure.

Security.

Development.

Somewhere along the way, organizations invent an imaginary line where ownership quietly ends.

I’ve never believed that line exists.

The customer certainly doesn’t.

They don’t experience departments.

They experience results.

If they cannot place an order…

They don’t care whether the problem is networking, storage, DNS, SQL Server, Active Directory, or a third-party API.

Their experience is simply,

“The system isn’t working.”

I’ve spent enough years building systems to understand something important.

Every application is imperfect.

The first release always contains bugs.

There will always be another optimization.

Another refactor.

Another deployment.

Another lesson.

We accept that reality while we’re building.

Then, for some reason, many organizations begin acting as though the application became perfect the moment it reached production.

Every future issue becomes someone else’s responsibility.

That has never made sense to me.

If I built it…

If I designed it…

If I recommended it…

If my name is attached to it…

Then I still have a responsibility to make it better.

That doesn’t mean I caused every problem.

It means I care about the outcome.

There is an important difference.

One lesson has remained remarkably consistent throughout my career.

Customers remember outcomes.

Not organizational charts.

Not escalation paths.

Not departmental boundaries.

They remember whether someone stayed until the problem was solved.

Some of the engineers I respect most were not the smartest people I ever worked with.

They were the people who stayed.

They joined the bridge calls.

They read the logs.

They tested theories.

They updated documentation.

They improved monitoring.

They refused to leave while work remained.

Nobody asked them to.

Ownership had already made the decision.

I’ve also seen the opposite.

People who became experts at explaining why something wasn’t their fault.

Sometimes they were absolutely correct.

The outage still continued.

Fault and ownership are different conversations.

One explains the past.

The other changes the future.

If there is one lesson I hope engineers carry throughout their careers, it is this:

Never become so focused on protecting your reputation that you stop protecting the outcome.

Your reputation will take care of itself.

People remember the engineer who stayed.

The one who owned the mistake.

The one who helped recover the system.

The one who improved it afterward.

That reputation cannot be manufactured.

It is earned one decision at a time.

Looking back, I don’t think the most valuable engineers I’ve known were the ones who made the fewest mistakes.

They were the ones who treated every mistake as their opportunity to make the system stronger than it had been the day before.

That is ownership.

Not because someone assigned it.

Because someone accepted it.

Your name should never be remembered because your system failed. It should be remembered because you never stopped improving it until it succeeded.

Principle XXXII — Earn Trust Quietly

Foundational Truth

Trust is not requested.

It is earned.

Not through speeches.

Not through titles.

Not through certifications.

Not through self-promotion.

Trust grows because people repeatedly observe the same thing.

Competence.

Integrity.

Consistency.

Humility.

Over time, those qualities become a reputation.

A reputation that no longer requires explanation.

The strongest reputation is the one other people describe before you ever have to.

Let Your Work Speak

Early in our careers, many of us feel pressure to prove ourselves.

We list accomplishments.

Explain every certification.

Describe every successful project.

Some confidence is healthy.

But confidence becomes far more powerful when it is supported by consistent results.

The engineers I have admired most rarely spent time explaining how talented they were.

They were too busy solving problems.

Helping teammates.

Improving systems.

Teaching others.

When they spoke, people listened.

Not because they were loud.

Because experience had already earned them credibility.

A Lesson from James Gosling

One of the privileges of my career was working with James Gosling.

If you don’t recognize the name immediately, you almost certainly recognize his work.

He created the Java programming language.

Yet during the time I worked with him, he never introduced himself by listing his accomplishments.

He never said,

“By the way, I invented Java.”

He didn’t need to.

He was approachable.

Curious.

Quick to laugh.

Generous with his knowledge.

His confidence came from who he was, not from reminding everyone what he had done.

That experience taught me something I have never forgotten.

The people who have made the greatest contributions are often the least interested in talking about them.

Reputation Is Built in Small Moments

Trust is rarely earned through one extraordinary achievement.

It is earned through hundreds of ordinary moments.

Answering the late-night call.

Helping a teammate without being asked.

Documenting a difficult solution.

Owning a mistake.

Meeting commitments.

Keeping your word.

Treating people with respect.

Over time, those moments become your reputation.

People stop asking whether you can be trusted.

They already know.

Trust is built quietly, one consistent decision at a time.

Confidence Does Not Need an Audience

There is a difference between confidence and self-promotion.

Confidence says,

“I know how to solve this.”

Self-promotion says,

“Let me remind everyone how capable I am.”

One creates reassurance.

The other seeks validation.

True confidence remains steady whether anyone notices or not.

It is grounded in preparation, experience, and character.

Not applause.

Becoming Someone Others Seek

Every organization has a few people everyone hopes will join the difficult project.

Not because they have the loudest voice.

Because they consistently make the project better.

They bring calm.

Judgment.

Perspective.

Integrity.

People trust them because history has taught them they can.

That kind of trust cannot be demanded.

It must be earned.

Closing Thought

Do your work well.

Keep your promises.

Help others succeed.

Accept responsibility.

Remain curious.

Stay humble.

Eventually your reputation will begin arriving before you do.

And by then, you won’t need to talk about it.

The loudest reputation is often built by the quietest engineer.

Trust Is Built Through Consistency

Trust is rarely created in a single moment.

It grows through repetition.

People begin noticing patterns.

You arrive prepared.

You keep your promises.

You communicate honestly.

You admit mistakes.

You help others succeed.

You stay until the problem is solved.

One decision rarely changes someone’s opinion of you.

Hundreds of consistent decisions do.

That is how trust quietly grows.

Trust is built in drops and lost in buckets.

Competence Earns Respect

When someone consistently solves difficult problems…

People notice.

When someone calmly handles pressure…

People remember.

When someone explains complicated ideas clearly…

People seek their advice.

Competence naturally earns respect.

People begin asking for your opinion because experience has taught them it is worth hearing.

Respect is earned through capability.

Trust, however, requires something more.

Character Earns Trust

Imagine two engineers.

Both are exceptionally talented.

Both understand the technology.

Both consistently deliver excellent work.

One admits mistakes immediately.

The other quietly hopes nobody notices.

One shares knowledge freely.

The other protects information to remain indispensable.

One celebrates the team’s success.

The other seeks personal recognition.

Both possess competence.

Only one earns trust.

Character determines whether people feel safe depending upon you.

That is why integrity will always outweigh talent.

Competence gets you invited into the room. Character determines whether people want you back.

The Quiet Professionals

Throughout my career, I’ve noticed something about the engineers everyone respected.

They rarely dominated conversations.

They asked thoughtful questions.

They listened before speaking.

When they offered an opinion, it carried weight because they had already demonstrated good judgment.

They didn’t need to convince people they were experts.

Their consistency had already done that.

The loudest voice in the room is rarely the most influential.

Influence comes from credibility.

Credibility comes from trust.

Recognition Is a Byproduct

Many people chase recognition directly.

Recognition rarely responds well to pursuit.

Instead, focus on doing meaningful work.

Help your team succeed.

Improve the systems around you.

Teach others.

Accept responsibility.

Continue learning.

Recognition often arrives as a consequence of those choices.

Not because you demanded it.

Because others noticed it.

The best reputations are built while no one is watching.

Let Others Tell Your Story

One of the most satisfying moments in any career is hearing someone else describe your work.

Not because you asked them to.

Because they genuinely valued your contribution.

That kind of reputation cannot be manufactured.

It grows naturally from years of consistency.

People become your advocates because your actions gave them a reason.

Those recommendations carry far more weight than anything you could say about yourself.

Trust Compounds

Trust behaves remarkably like compound interest.

Every promise kept increases it.

Every honest conversation strengthens it.

Every difficult project completed adds another layer.

Over years, small moments become extraordinary reputations.

People stop remembering individual successes.

They remember the person who was always dependable.

That reputation becomes one of the most valuable assets an engineer can possess.

Closing Thought

Do not spend your career trying to convince people that you deserve their trust.

Spend your career becoming the kind of person who naturally earns it.

The difference may seem small.

One seeks admiration.

The other earns confidence.

The greatest compliment an engineer can receive is simple: “If they’re involved, I know it will be done right.”

Reputation Is Borrowed

Every introduction carries a reputation.

Sometimes it arrives before you do.

“I’ve worked with her.”

“He’s the person you want on this project.”

“If they’re leading it, you’ll be in good hands.”

Those recommendations cannot be requested.

They must be earned.

Every interaction either strengthens your reputation…

Or quietly weakens it.

Over time, people begin lending you their trust before you’ve even spoken.

That is one of the greatest professional gifts you can receive.

Your reputation is built by what people say after you’ve left the room.

Influence Without Authority

Some of the most influential people I’ve ever worked with had no management title.

They didn’t need one.

People naturally sought their advice.

Asked for their review.

Trusted their judgment.

Included them in difficult conversations.

Authority can assign responsibility.

Trust invites influence.

One is granted by an organization.

The other is granted by people.

The second is far more valuable.

Teach More Than You Impress

Knowledge can be used in two very different ways.

One person uses it to demonstrate superiority.

Another uses it to help someone else succeed.

The first earns admiration.

The second earns trust.

The engineers I remember most rarely tried to impress anyone.

They explained difficult concepts patiently.

They encouraged questions.

They celebrated learning.

When someone left a conversation with them, they felt more capable than before.

That is a remarkable gift.

Knowledge multiplies when it is shared.

Quiet Confidence

Confidence speaks calmly.

Ego speaks constantly.

Quiet confidence has no need to dominate every conversation.

It does not interrupt.

It does not compete.

It does not seek recognition.

It simply contributes.

There is tremendous strength in someone who knows exactly what they are capable of and feels no need to convince everyone else.

That kind of confidence creates safety.

People trust it because it feels authentic.

Legacy Is Measured in People

Projects eventually end.

Applications are replaced.

Programming languages evolve.

Technologies become obsolete.

People remain.

The greatest engineers rarely measure their careers by products alone.

They measure them by people.

The engineers they mentored.

The leaders they developed.

The teammates they encouraged.

The confidence they helped build in someone who was just beginning.

Long after today’s technology has disappeared, those people will still be carrying part of your influence.

That is a legacy worth pursuing.

Your greatest contribution may never be the software you wrote. It may be the engineer you helped become extraordinary.

Success Needs No Announcement

I’ve noticed something throughout my career.

The people who have accomplished the most rarely spend much time talking about themselves.

Their work already introduced them.

Their reputation already opened the door.

Their character already earned the invitation.

The louder someone works to establish credibility…

The more I wonder why the work isn’t speaking for itself.

That doesn’t mean we should hide our accomplishments.

It means we should let them stand on their own.

Recognition becomes more meaningful when someone else is telling the story.

Questions to Ask Yourself

  • Would my teammates describe me as dependable?
  • Do I leave people more confident than I found them?
  • Am I trying to impress people or help them succeed?
  • What do others consistently trust me to do?
  • If I left tomorrow, what reputation would remain?
  • Am I building influence or simply visibility?
  • Does my work speak clearly enough that I don’t have to?

Closing Thought

Trust is one of the few things that cannot be demanded, purchased, or accelerated.

It grows slowly.

Quietly.

Almost invisibly.

Until one day people begin saying,

“We need them on this project.”

Not because of what you’ve claimed.

Because of who you’ve consistently been.

The most respected engineers don’t spend their careers building their image. They spend their careers building their character. Everything else follows.

Founder’s Commentary

The Engineers I Remember Most

Over the years, I’ve had the privilege of working with some incredibly talented engineers.

Some were experts in operating systems.

Some understood networking at a level that seemed almost impossible.

Some could diagnose database problems in minutes that would have taken others days.

A few changed the industry itself.

What surprised me most wasn’t how much they knew.

It was how little they talked about themselves.

One experience has stayed with me throughout my career.

I had the opportunity to work with James Gosling.

If you work in software, you probably know his name.

If you don’t…

You almost certainly know his work.

James created the Java programming language.

Think about that for a moment.

Entire industries have been built upon something he created.

Millions of developers have written billions of lines of Java code.

Yet during the time I worked with him, he never once introduced himself by saying,

“By the way, I created Java.”

He didn’t have to.

He was approachable.

Curious.

Quick to laugh.

Genuinely interested in the people around him.

His confidence didn’t come from reminding everyone what he had accomplished.

It came from knowing exactly who he was.

That experience quietly changed the way I viewed expertise.

The engineers I respected most were almost never the loudest people in the room.

They listened.

They asked thoughtful questions.

They helped others understand difficult problems.

When they spoke, people naturally paid attention.

Not because they demanded attention.

Because they had earned it.

I’ve also met engineers who spent enormous amounts of energy explaining how talented they were.

Every conversation eventually returned to another accomplishment.

Another project.

Another technology.

Another reason they deserved recognition.

There’s nothing wrong with being proud of your work.

You should be.

But I learned that the strongest reputations rarely require constant maintenance.

Other people tell those stories for you.

Trust works that way.

You don’t announce it.

You earn it.

One project.

One decision.

One promise kept.

One difficult conversation handled honestly.

One teammate helped.

One mistake owned.

One lesson shared.

Over enough years, those moments become your reputation.

Not because you designed them that way.

Because people remember how consistently you showed up.

Looking back, I don’t remember the engineers who talked the most about their careers.

I remember the engineers who quietly made everyone else’s career better.

The mentor who stayed after the meeting to explain something.

The architect who reviewed my design without making me feel small.

The senior engineer who remained calm while everyone else was panicking.

The teammate who took responsibility before anyone asked.

Those people earned something much more valuable than admiration.

They earned trust.

Eventually, something remarkable happens.

People begin recommending you before you’ve applied.

Inviting you before you’ve volunteered.

Trusting your judgment before you’ve spoken.

Not because you asked them to.

Because your character arrived before you did.

If there is one lesson I hope every engineer carries through their career, it is this:

Don’t spend your energy building an impressive image.

Spend your energy becoming an impressive human being.

The image will take care of itself.

The greatest engineers are remembered not because they convinced the world they were exceptional, but because they quietly spent years proving it through their character, their work, and the people they helped along the way.

Principle XXXIII — Choose the Long View

Foundational Truth

Every decision creates two outcomes.

The immediate outcome…

And the eventual outcome.

Most people evaluate only the first.

Great engineers learn to anticipate the second.

A shortcut may save an hour today.

It may cost days during recovery.

A rushed deployment may satisfy this week’s deadline.

It may create months of technical debt.

A well-tested disaster recovery plan may appear unnecessary.

Until the day it becomes the most valuable investment the organization ever made.

The true cost of a decision is rarely visible at the moment it is made.

The best decisions often look expensive today and invaluable tomorrow.

Time Reveals Value

History is filled with ideas that appeared insignificant in the beginning.

Early investors sold Bitcoin because they believed its value had peaked.

Old hard drives containing thousands of Bitcoin were discarded because nobody imagined what those digital coins might someday become.

Apple spent years struggling before becoming one of the most valuable companies in history.

The Rocky Horror Picture Show received disappointing reviews during its initial release.

Some cast members reportedly sold participation rights because they believed the film had little future.

Today it has become one of the longest-running theatrical experiences in history.

None of those outcomes were obvious at the beginning.

Time revealed their value.

Engineering works the same way.

Many of the most valuable decisions are recognized only years later.

The Shortcut Illusion

Shortcuts are attractive because their benefits are immediate.

The costs are delayed.

Skip testing.

Delay documentation.

Ignore one warning.

Postpone the backup validation.

Leave the temporary firewall rule in place.

Everything appears successful.

Until one day…

The restore fails.

The documentation is wrong.

The certificate expires.

The dependency changes.

The shortcut quietly presents its invoice.

The engineer who chose the shortcut rarely intended to create future problems.

They simply valued today’s convenience over tomorrow’s resilience.

Design for the Engineer You Haven’t Met Yet

Every decision you make today becomes someone else’s starting point tomorrow.

That someone might even be you.

Six months from now.

Five years from now.

Long after you’ve forgotten why a configuration exists.

The long view asks a different question.

Instead of,

“Can I make this work today?”

It asks,

“Will this still make sense years from now?”

That question changes architecture.

Documentation.

Automation.

Security.

Testing.

Everything.

Invest in Future Confidence

Some engineering work produces no immediate reward.

Testing backups.

Writing documentation.

Refactoring code.

Rotating certificates.

Improving monitoring.

Removing technical debt.

Nobody applauds these activities.

Until the day they prevent disaster.

The long view recognizes that confidence is an investment.

Not an expense.

Preparation often appears unnecessary right up until the moment it becomes indispensable.

Success Is Measured Over Time

Many engineering decisions appear successful on the day they are implemented.

Only time reveals whether they were truly good decisions.

Did the architecture remain maintainable?

Did the security model continue adapting?

Did the automation survive future growth?

Did the disaster recovery plan actually restore the environment?

Time is the most honest reviewer every engineer will ever have.

Closing Thought

Every decision asks the same question.

Are you building for today…

Or for tomorrow?

Today’s convenience disappears quickly.

Tomorrow’s consequences often remain for years.

Choose accordingly.

The engineer who thinks furthest ahead often builds the systems that last the longest.

Future Problems Begin Today

Very few disasters begin on the day they occur.

They begin months…

Sometimes years…

Earlier.

The certificate that expires during a holiday weekend.

The backup that has never been restored.

The undocumented firewall exception.

The aging hardware that “still works.”

The temporary script that quietly became permanent.

Each one began as a small decision.

None appeared urgent at the time.

Time transformed them into critical problems.

Tomorrow’s emergencies are often yesterday’s conveniences.

Technical Debt Is Borrowed Time

Technical debt is sometimes necessary.

Business deadlines exist.

Budgets have limits.

Customers need solutions.

There are moments when shipping today is the correct decision.

The mistake is pretending the debt no longer exists.

Every shortcut creates an obligation.

Every deferred improvement carries interest.

Every temporary solution deserves a plan for becoming permanent—or for being removed entirely.

The long view doesn’t forbid technical debt.

It insists that debt eventually be repaid.

Disaster Recovery Is the Perfect Example

Few investments illustrate the long view better than disaster recovery.

Testing backups feels expensive.

Documenting recovery procedures consumes valuable time.

Running disaster recovery exercises interrupts productive work.

Until disaster arrives.

Then nothing becomes more valuable.

I’ve never heard anyone say,

“I wish we had tested our disaster recovery plan less.”

I’ve heard the opposite many times.

Preparation always appears costly before the emergency.

It appears priceless afterward.

Build for the Engineer You Will Become

One day you will inherit your own work.

Six months from now…

You’ll open a script you barely remember writing.

A year later…

You’ll troubleshoot a system you originally designed.

Five years later…

You’ll wonder why a configuration exists.

The long view reminds us that future engineers are not strangers.

Sometimes…

They’re simply older versions of ourselves.

Design accordingly.

Document accordingly.

Test accordingly.

Decisions Compound

Small decisions rarely remain small.

One naming convention becomes an organizational standard.

One reusable library supports dozens of applications.

One automation saves thousands of hours.

One poorly documented process confuses every engineer who follows.

Compounding works both ways.

Good decisions accumulate.

Poor decisions accumulate too.

That is why consistency matters more than isolated moments of brilliance.

The future is built one ordinary decision at a time.

Think Beyond the Deadline

Deadlines matter.

Customers matter.

Budgets matter.

None of them disappear because we choose the long view.

The challenge is balancing today’s needs without sacrificing tomorrow’s stability.

Ask yourself:

Will this decision still make sense one year from now?

Five years from now?

If someone else inherits this system, will they understand why I built it this way?

If the answer is no…

The design deserves another look.

Great Engineers Plant Trees

There is an old proverb that says:

“A society grows great when old men plant trees whose shade they know they shall never sit in.”

Engineering works the same way.

Some of your best work will benefit people you will never meet.

Documentation.

Automation.

Standards.

Security.

Mentorship.

Architecture.

The engineer who chooses the long view plants those trees willingly.

Not because they will personally benefit.

Because someone eventually will.

Closing Thought

The easiest decision is often the one that solves today’s problem.

The wisest decision is often the one that prevents tomorrow’s.

Think beyond the sprint.

Beyond the release.

Beyond the project.

Build for the future that has not arrived yet.

Great engineers don’t simply solve today’s problems. They quietly prevent tomorrow’s.

Every Decision Is an Investment

Every engineering decision invests in something.

Sometimes it invests in speed.

Sometimes it invests in stability.

Sometimes it invests in maintainability.

Sometimes it invests in learning.

The important question is not whether you’re investing.

The question is what future you’re choosing to invest in.

Every shortcut spends tomorrow’s time.

Every thoughtful design deposits confidence into the future.

The future is built by the decisions nobody notices today.

Patience Is a Competitive Advantage

Modern engineering rewards speed.

Continuous deployment.

Rapid iteration.

Immediate feedback.

Those are valuable practices.

But speed without direction simply gets you to the wrong destination faster.

The engineers who consistently build exceptional systems understand something others often overlook.

Patience is not the opposite of progress.

It is often what makes lasting progress possible.

Taking another day to test disaster recovery.

Spending another hour documenting a deployment.

Refactoring code before adding another feature.

Replacing a temporary workaround with a permanent solution.

These decisions rarely make headlines.

Years later, they become the reason a system remains dependable.

Build Things That Outlive You

Every engineer eventually moves on.

Projects change.

Companies evolve.

Careers take unexpected turns.

The systems we build often remain long after we leave.

Someone else inherits our architecture.

Someone else supports our automation.

Someone else reads our documentation.

Someone else responds to the outage at two o’clock in the morning.

The long view asks one simple question.

Will they silently thank me…

Or silently curse me?

That question has influenced more of my engineering decisions than almost any technical standard ever could.

Legacy Is Measured in Stability

Some accomplishments receive applause.

A successful launch.

A major release.

A keynote presentation.

Others go almost completely unnoticed.

The server that never crashes.

The backup that restores flawlessly.

The certificate that is renewed before anyone notices.

The automation that quietly saves thousands of hours.

The documentation that prevents another engineer from making the same mistake.

Those successes rarely appear in annual reports.

Yet they are often the most valuable work an engineer performs.

Quiet reliability is one of the highest forms of craftsmanship.

The greatest engineering success is often the problem nobody ever experiences.

Think in Decades

Technology changes rapidly.

Principles change slowly.

Programming languages appear and disappear.

Cloud providers introduce new services.

Hardware becomes obsolete.

Entire industries evolve.

Good engineering principles survive every one of those changes.

Design for failure.

Document your work.

Measure what matters.

Protect what matters.

Tell the truth.

Own the outcome.

Those ideas remain valuable regardless of what technology replaces today’s tools.

When making decisions, ask yourself:

“Will this still be the right decision ten years from now?”

That question often changes the answer.

The Long View Creates Freedom

Many people believe long-term thinking slows progress.

In reality, it often accelerates it.

Good documentation reduces future troubleshooting.

Automation eliminates repetitive work.

Testing increases deployment confidence.

Security reduces future incidents.

Refactoring simplifies future development.

Every investment in tomorrow creates more freedom later.

The opposite is also true.

Every shortcut quietly limits future options.

The future rewards preparation.

Questions to Ask Yourself

  • Am I solving today’s problem or tomorrow’s as well?
  • Will this decision become easier or harder to support over time?
  • If I inherit this system five years from now, would I thank my younger self?
  • What technical debt am I intentionally creating?
  • What investment today will save the most effort tomorrow?
  • Am I building something temporary or something enduring?
  • What legacy will this decision leave behind?

Closing Thought

Time eventually evaluates every engineering decision.

Some designs become easier to maintain.

Others slowly become impossible to understand.

The difference rarely comes from intelligence.

It comes from choosing the long view.

Every thoughtful decision today becomes tomorrow’s quiet success.

Build systems that become more valuable with time, not more expensive.

Founder’s Commentary

The Future Has Always Been Patient

One of the most interesting things I’ve noticed throughout my career is that the best engineering decisions often look like poor business decisions in the moment.

Testing disaster recovery instead of building another feature.

Writing documentation instead of closing another ticket.

Refactoring code instead of adding functionality.

Replacing temporary fixes before they become permanent.

None of those decisions generate immediate excitement.

In fact, they often look slower.

More expensive.

Less productive.

Until enough time passes.

Then everyone wonders how the system remained so dependable.

The truth is simple.

Dependability is rarely an accident.

It’s the result of thousands of small decisions made by people who were willing to think beyond today.

History is filled with examples of people underestimating the future.

Early Bitcoin miners discarded hard drives because they believed the coins would never become valuable.

Others sold their holdings for amounts that seemed life-changing at the time.

Nobody imagined what those same coins would eventually be worth.

The same pattern appears throughout history.

Apple spent years struggling before becoming one of the most valuable companies ever created.

The Rocky Horror Picture Show opened to disappointing reviews.

Some of the people involved reportedly believed its future was so limited that they parted with long-term participation for immediate certainty.

Time had different plans.

Engineering teaches exactly the same lesson.

I’ve never regretted spending extra time validating a backup.

I’ve never regretted documenting a complex environment.

I’ve never regretted testing disaster recovery one more time.

I have regretted assuming those things could wait.

One lesson eventually became impossible for me to ignore.

The future always arrives.

Whether we’re prepared for it…

Is entirely up to us.

I’ve worked on enough recovery efforts to know something that every experienced engineer eventually learns.

The day you need your disaster recovery plan is the worst possible day to discover it doesn’t work.

That isn’t the day to write documentation.

That isn’t the day to verify backups.

That isn’t the day to discover your restore procedure was copied from an environment that no longer exists.

Those decisions belong to yesterday.

The organizations that recover well are almost never lucky.

They’re prepared.

Preparation is simply long-term thinking made visible.

As my career progressed, I found myself asking a different question before making important technical decisions.

Not,

“Will this work today?”

But,

“Will I still be proud of this decision five years from now?”

That question changed everything.

Sometimes it meant delaying a deployment.

Sometimes it meant redesigning an architecture.

Sometimes it meant accepting a more difficult path because I knew the shortcut would eventually become someone else’s burden.

Engineering has taught me that the future is remarkably honest.

It doesn’t care why we skipped testing.

It doesn’t care why documentation was postponed.

It doesn’t care why we accepted unnecessary technical debt.

It simply reflects the decisions we made when nobody was paying attention.

If there is one lesson I hope every engineer carries throughout their career, it is this:

Think beyond the deadline.

Beyond the sprint.

Beyond the quarterly objectives.

Build systems that become easier to support with time instead of harder.

Leave environments that grow stronger instead of more fragile.

Because one day someone else will inherit every decision you make today.

Very often…

That someone will be you.

The greatest engineering decisions are rarely the ones that make today easier. They are the ones that quietly make the future stronger for everyone who follows.

Principle XXXIV — Be Humble

Foundational Truth

Humility is not weakness.

It is not insecurity.

It is not the absence of confidence.

Humility is the willingness to believe that someone else may see something you do not.

No matter how experienced you become…

There will always be another perspective.

Another lesson.

Another idea.

Another engineer.

The moment we believe we have nothing left to learn…

We quietly stop growing.

Humility does not diminish confidence. It keeps confidence teachable.

Beware the Echo Chamber

One of the most dangerous environments I have ever seen is a room where everyone agrees.

Not because everyone is correct.

Because nobody feels safe enough to disagree.

I’ve sat in boardrooms where the leader surrounded themselves with people who simply confirmed every decision.

No questions.

No challenges.

No alternative viewpoints.

At first, that kind of agreement feels efficient.

Eventually, it becomes dangerous.

Organizations improve when ideas are challenged.

Not when they are protected.

If you are the only voice you hear…

Speak less.

Or find a different room.

Strong Ideas Welcome Strong Questions

Every engineer becomes attached to their work.

Their architecture.

Their design.

Their solution.

That’s natural.

The difficult part is remembering that criticism of an idea is not criticism of the person.

The strongest designs survive because someone challenged them.

The strongest architectures improve because someone questioned an assumption.

The strongest engineers invite those conversations.

Not because they expect to be wrong.

Because they want to discover if they are.

If your idea cannot survive respectful questions, it is not ready for production.

Confidence Without Ego

There is nothing wrong with believing in your abilities.

Confidence allows engineers to make difficult decisions.

Ego prevents them from reconsidering those decisions.

Confidence says,

“Here’s why I believe this is the right approach.”

Humility adds,

“What am I missing?”

Those six words have prevented more mistakes than almost any technical standard I’ve ever followed.

Every Person Knows Something You Don’t

One lesson has become increasingly obvious throughout my career.

Every person I meet knows something I don’t.

Sometimes it’s technical.

Sometimes it’s leadership.

Sometimes it’s communication.

Sometimes it’s life.

The challenge is remaining humble enough to recognize it.

The engineer with ten years of experience may teach you architecture.

The engineer with six months of experience may ask the question that exposes your biggest assumption.

Wisdom isn’t determined by seniority alone.

Humility Creates Better Decisions

Engineering is a discipline of continuous refinement.

Designs evolve.

Architectures improve.

Ideas mature.

That process depends upon one thing.

The willingness to change your mind when presented with better evidence.

Humility is not the absence of conviction.

It is the courage to replace conviction with understanding when reality demands it.

Closing Thought

The smartest person in the room is rarely the one doing the most talking.

It is often the one doing the most listening.

Speak with confidence.

Listen with humility.

Grow continuously.

The engineer who believes they have nothing left to learn has already begun falling behind.

Success Can Become a Blind Spot

Success is a wonderful teacher.

It can also become a dangerous one.

A successful deployment reinforces confidence.

A successful architecture builds credibility.

Years of experience create valuable instincts.

Those are good things.

The danger comes when success quietly convinces us that our judgment no longer needs to be challenged.

Every experienced engineer has been wrong.

The difference is whether they remained humble enough to discover it before production did.

Experience should increase wisdom, not reduce curiosity.

Listen Before You Lead

The strongest leaders I have worked with shared a common habit.

They listened first.

Not because they lacked opinions.

Because they understood the value of hearing perspectives they hadn’t considered.

Leadership is not demonstrated by speaking first.

It is demonstrated by creating an environment where others feel safe contributing.

The quiet engineer in the corner may see the risk everyone else overlooked.

The junior administrator may notice the assumption the architects accepted without question.

Good leaders create space for those voices.

Great leaders actively seek them.

Disagreement Is a Gift

Many people experience disagreement as conflict.

Healthy engineering teams experience it as refinement.

Every respectful challenge strengthens an idea.

Every thoughtful question exposes another assumption.

Every alternative perspective improves the final design.

The goal is not to win the discussion.

The goal is to discover the best solution.

That requires separating our identity from our ideas.

Ideas should be challenged.

People should be respected.

Those are not contradictory principles.

Together they produce remarkable engineering.

Humility Creates Psychological Safety

People contribute their best ideas when they believe they will be heard.

Not ridiculed.

Not ignored.

Not punished for asking difficult questions.

Humble leaders create that environment naturally.

They admit mistakes.

They ask questions.

They thank people for finding problems.

They encourage respectful disagreement.

Eventually something remarkable happens.

The team begins solving problems together instead of protecting individual reputations.

Innovation grows where humility creates safety.

Every Conversation Is an Opportunity

I’ve learned to approach conversations with a simple assumption.

The person across from me knows something I don’t.

I may not know what it is yet.

It may have nothing to do with technology.

It may challenge one of my assumptions.

It may completely change my perspective.

If I spend the entire conversation waiting for my turn to speak…

I’ll probably miss it.

Listening is one of the highest forms of learning.

Humility makes listening possible.

Every conversation offers the opportunity to become a little less wrong than you were yesterday.

Convictions Should Be Strong

One misunderstanding about humility deserves clarification.

Being humble does not mean having weak convictions.

Believe strongly.

Defend your ideas with evidence.

Share your experience confidently.

But remain willing to change your mind when better evidence appears.

The strongest engineers don’t avoid conviction.

They avoid certainty that cannot be questioned.

Confidence without humility becomes arrogance.

Humility without confidence becomes hesitation.

Great engineers cultivate both.

Build Teams That Challenge You

If everyone around you agrees with every decision you make…

Be concerned.

Either you’ve hired people who have stopped thinking independently…

Or you’ve unintentionally created an environment where disagreement feels unsafe.

Neither outcome produces excellent engineering.

The most valuable teammate is often the one who respectfully says,

“I see it differently.”

Those conversations prevent expensive mistakes.

Invite them.

Closing Thought

Humility is not measured by how little you know.

It is measured by how willing you remain to learn.

The moment you stop asking questions…

You stop growing.

Keep asking.

Keep listening.

Keep learning.

The strongest ideas are rarely protected from criticism. They are strengthened by it.

Humility Protects Wisdom

Knowledge accumulates.

Wisdom refines.

The longer I have worked in technology, the less interested I have become in proving I am right.

I have become much more interested in discovering what is true.

Those are not always the same thing.

Pride asks,

“How do I defend my position?”

Humility asks,

“What evidence would change my mind?”

One protects the ego.

The other protects the outcome.

Wisdom begins the moment truth becomes more important than being right.

Great Ideas Belong to Everyone

One of the biggest mistakes we can make is believing good ideas only come from experienced people.

They don’t.

Sometimes the newest engineer asks the question everyone else overlooked.

Sometimes a customer describes the problem differently than the development team imagined.

Sometimes another department identifies a risk you’ve never considered.

Sometimes someone completely outside your field sees the solution immediately because they aren’t constrained by the same assumptions.

Ideas do not care about titles.

Neither should we.

The best solution deserves to win, regardless of who suggested it.

Debate the Idea, Never the Person

Healthy disagreement strengthens engineering.

Personal attacks weaken it.

When someone challenges an idea, remember what is actually happening.

They are trying to improve the outcome.

Not diminish your value.

Separate your identity from your work.

Architectures evolve.

Designs improve.

Code changes.

You remain the same person.

When ideas become extensions of our identity, every suggestion feels like criticism.

When ideas become collaborative efforts, every question becomes an opportunity.

That shift changes everything.

Certainty Is Dangerous

Absolute certainty has ended more learning than lack of knowledge ever has.

Every generation believes it has finally discovered the correct answer.

History rarely agrees.

Technology evolves.

Research advances.

Experience reveals new evidence.

The engineer who remains humble adapts.

The engineer who becomes certain slowly stops growing.

The goal is not to eliminate confidence.

The goal is to eliminate confidence that cannot survive new evidence.

The moment you become impossible to teach, you become impossible to improve.

Build a Circle That Challenges You

Surround yourself with people who think differently.

Not because disagreement is enjoyable.

Because blind spots are inevitable.

Invite people who ask difficult questions.

Value people who respectfully disagree.

Appreciate those willing to point out weaknesses before customers do.

A room filled with agreement feels comfortable.

A room filled with thoughtful discussion builds better decisions.

The strongest leaders I know are rarely surrounded by followers.

They are surrounded by thinkers.

Humility Leaves Room for Wonder

One of the greatest gifts humility provides is the ability to remain amazed.

There will always be another technology to discover.

Another scientific breakthrough.

Another engineering achievement.

Another perspective.

Another lesson.

Humility allows us to experience each of those moments with curiosity instead of defensiveness.

The world remains fascinating because we never truly finish learning.

Questions to Ask Yourself

  • Am I defending my idea or searching for the best one?
  • What evidence would cause me to change my mind?
  • Have I truly listened to the people who disagree with me?
  • What blind spot might I have today?
  • Does everyone around me feel safe challenging my thinking?
  • What can I learn from the person least expected to teach me?
  • Am I trying to win the discussion or improve the outcome?

Closing Thought

Humility is not thinking less of yourself.

It is thinking more about learning than proving.

The world will always know more than any one engineer.

Remain curious enough to keep discovering it.

The strongest minds are not those that never change. They are the ones willing to become wiser every time they do.

Founder’s Commentary

The Older I Get…

When I was younger, I thought confidence came from having the answers.

The more experience I gained, the more I realized confidence comes from something entirely different.

It comes from knowing you can find the answer.

That realization changed the way I approached engineering.

Early in my career, I wanted to prove I belonged in the room.

I wanted my ideas to be accepted.

I wanted people to recognize my knowledge.

Over time, those goals quietly changed.

Today, I care much more about whether the room arrives at the best answer than whether it was my answer.

That shift has made me a better engineer than any certification or technology ever could.

I’ve sat in boardrooms where every voice sounded exactly the same.

Every proposal received immediate agreement.

Every concern disappeared before it was fully explored.

At first glance, that environment looks efficient.

It isn’t.

It’s fragile.

Organizations become dangerous when leaders only hear their own opinions echoed back to them.

The strongest teams I’ve worked with weren’t built on agreement.

They were built on respectful disagreement.

People challenged assumptions.

They questioned architectures.

They offered alternative perspectives.

Nobody viewed those conversations as personal attacks.

Everyone viewed them as opportunities to improve the outcome.

That’s what humility creates.

It allows truth to become more important than ego.

One lesson has stayed with me throughout my career.

Every person I meet knows something I don’t.

Sometimes it’s a junior engineer asking a question I never considered.

Sometimes it’s a customer describing a problem differently than I understood it.

Sometimes it’s an executive explaining a business priority I hadn’t appreciated.

Sometimes it’s a mentor sharing decades of experience.

If I stop listening because I believe I already know enough…

I lose every one of those opportunities.

Humility keeps those doors open.

One of the greatest misconceptions about humility is that it requires uncertainty.

It doesn’t.

I can confidently explain why I believe an architecture is the right choice.

I can defend it with evidence.

I can explain every design decision.

Then someone asks one thoughtful question.

If that question reveals a better solution…

I change my mind.

Not because I lacked conviction.

Because I value the truth more than I value being right.

That isn’t weakness.

That’s engineering.

I’ve learned that the smartest person in the room is rarely the one speaking the most.

It’s usually the person asking the questions everyone else forgot to ask.

Those questions have saved me from mistakes more times than I could ever count.

Looking back, I don’t think humility ever limited my career.

I think it accelerated it.

People trusted me with increasingly difficult problems because they knew I wasn’t trying to prove I was the smartest engineer in the room.

I was trying to help the room make the smartest decision.

Those are very different goals.

If there is one lesson I hope every engineer carries with them, it is this:

Never confuse confidence with certainty.

Confidence says,

“This is the best answer I know today.”

Humility quietly adds,

“And if tomorrow reveals a better answer, I’ll gladly learn from it.”

That’s how engineers grow.

That’s how organizations improve.

That’s how innovation survives.

The day you care more about discovering the truth than defending your opinion is the day experience begins transforming into wisdom.

Principle XXXV — Keep Your Word

Foundational Truth

Trust is earned slowly.

One promise.

One conversation.

One commitment.

One project.

One honest answer at a time.

Losing that trust can happen in a single moment.

The easiest way to protect your reputation is surprisingly simple.

Keep your word.

If you say you’ll do something…

Do it.

If circumstances change…

Communicate early.

If you make a mistake…

Own it immediately.

Your word is one of the few things you truly own.

Protect it.

A reputation is simply a history of promises kept.

Don’t Promise What You Cannot Deliver

One of the easiest ways to disappoint people is to tell them what they hope to hear instead of what you honestly believe.

“We’ll have it ready Friday.”

“It shouldn’t take more than an hour.”

“That migration will be easy.”

“The outage won’t affect anyone.”

Sometimes we make these promises with the best intentions.

We want to be encouraging.

Optimistic.

Helpful.

The problem is that reality is not influenced by optimism.

People remember promises.

Much longer than they remember explanations.

It is far better to make a careful commitment and exceed expectations than to make an ambitious promise you cannot keep.

Honesty Creates Long-Term Relationships

I’ve learned that honesty doesn’t always win immediate business.

Sometimes the honest answer is,

“We’re not ready.”

“This will take longer than you expect.”

“I don’t recommend that approach.”

“We need more information.”

Those answers may disappoint someone today.

But they also communicate something far more valuable.

Integrity.

Customers may not always choose the person who gives them the answer they wanted.

They often remember the person who gave them the answer they needed.

Trust has remarkable staying power.

People forgive difficult truths far more readily than broken promises.

Small Commitments Matter

Keeping your word isn’t only about major projects.

It appears in ordinary moments.

Returning a phone call when you said you would.

Following up after a meeting.

Sending the documentation you promised.

Arriving prepared.

Meeting deadlines.

Acknowledging delays before someone has to ask.

Character is rarely demonstrated through extraordinary moments alone.

It is revealed through consistent attention to ordinary commitments.

Those moments accumulate into a reputation.

Reliability Is Quiet Leadership

The people I have trusted most throughout my career shared one quality.

Reliability.

When they committed to something…

I stopped worrying about it.

Not because they never encountered problems.

Because they always communicated honestly.

They never disappeared.

They never avoided difficult conversations.

They never left people wondering.

Reliability creates confidence.

Confidence creates trust.

Trust creates leadership.

Your Word Is Your Signature

Every email you send…

Every meeting you attend…

Every estimate you provide…

Every commitment you make…

Carries your signature.

Over time, people stop evaluating individual promises.

They evaluate the person making them.

Your name quietly becomes associated with either confidence…

Or uncertainty.

Choose carefully.

Closing Thought

Speak carefully.

Promise thoughtfully.

Deliver consistently.

If you cannot keep your word…

Communicate before someone has to ask.

People rarely expect perfection.

They almost always appreciate honesty.

Your word should become something people never have to verify because history has already proven its value.

Commit Carefully

One of the easiest mistakes engineers make is committing too quickly.

“We can have that finished tomorrow.”

“That migration should only take an hour.”

“We’ll definitely hit that deadline.”

Sometimes we’re optimistic.

Sometimes we’re trying to be helpful.

Sometimes we simply haven’t gathered enough information.

Good intentions do not change reality.

Before making a commitment, understand the work.

Ask questions.

Identify dependencies.

Consider the unknowns.

A thoughtful estimate builds confidence.

An unrealistic promise slowly erodes it.

Underpromise with honesty. Overdeliver through discipline.

Communication Preserves Trust

Sooner or later, every engineer encounters a commitment they cannot keep.

Requirements change.

A dependency fails.

Testing uncovers unexpected problems.

The schedule slips.

That moment reveals character.

Some people become silent.

They hope the delay will somehow resolve itself before anyone notices.

Others communicate immediately.

“Here’s what changed.”

“Here’s why.”

“Here’s our new plan.”

The first response damages trust.

The second often strengthens it.

People can adapt to changing circumstances.

They struggle with uncertainty.

Reliability Is Predictability

When someone says,

“I’ll take care of it,”

what happens next?

Do people feel confident?

Or do they begin making backup plans?

Reliability is not about never encountering obstacles.

It is about becoming predictable.

People know you’ll communicate.

They know you’ll follow through.

They know you’ll ask for help before the situation becomes a crisis.

That predictability creates confidence.

Confidence becomes trust.

The Little Things Matter

Most reputations are not built through extraordinary achievements.

They are built through ordinary discipline.

Returning calls.

Answering emails.

Starting meetings on time.

Sending follow-up notes.

Documenting changes.

Closing the loop after a problem has been resolved.

None of these actions are glamorous.

Together they create something incredibly valuable.

Dependability.

People remember how consistently you handled the small things long before they remember the biggest project you completed.

Character is demonstrated most clearly in the commitments nobody is watching.

Say What You Mean

Clear communication is one of the greatest acts of respect.

Avoid vague promises.

Instead of saying,

“I’ll try.”

Say,

“I can have it completed by Thursday.”

Instead of saying,

“It shouldn’t take long.”

Explain what you know.

Describe what you don’t.

Set realistic expectations.

Precision prevents disappointment.

Honesty prevents misunderstanding.

People trust clarity far more than optimism.

Consistency Builds Confidence

Every kept promise strengthens your reputation.

Every honest update reinforces it.

Every difficult conversation handled early adds another layer.

Trust compounds quietly.

Eventually people stop asking,

“Will it get done?”

They already know.

That kind of confidence cannot be purchased.

It is earned through hundreds of small moments of consistency.

Closing Thought

Your word becomes your reputation one commitment at a time.

Protect it carefully.

Speak honestly.

Communicate early.

Deliver consistently.

And when circumstances change…

Tell people before they have to ask.

Trust is not built because everything goes according to plan. It is built because people know exactly where they stand with you.

Your Word Defines You

Long before people understand your technical ability…

They begin evaluating your character.

Do you follow through?

Do you communicate honestly?

Do you admit delays?

Do you own mistakes?

Do you keep your commitments?

These questions are answered long before anyone reads your résumé.

Your word quietly becomes your identity.

People eventually stop asking,

“Can they do the work?”

They begin asking,

“Can I trust them?”

Those are two very different questions.

Skill may earn an opportunity. Your word determines whether the opportunity returns.

Trust Is Built Before It Is Needed

One of the remarkable things about trust is that it must exist before the difficult moments arrive.

You cannot manufacture credibility during an outage.

You cannot invent integrity during a crisis.

You cannot suddenly become dependable when the organization is counting on you.

Trust has already been established…

Or it hasn’t.

Every ordinary commitment you keep becomes preparation for the extraordinary moment when people need to believe you.

The Courage to Deliver Difficult News

Keeping your word does not always mean delivering good news.

Sometimes the most honorable promise you can keep is honesty itself.

A deadline cannot be met.

The budget is no longer realistic.

The migration uncovered unexpected risks.

The architecture needs to change.

Those conversations are uncomfortable.

Avoiding them only makes them worse.

Integrity is not measured by how often circumstances go your way.

It is measured by how honestly you respond when they don’t.

Reliability Creates Opportunity

Throughout my career, I’ve noticed something interesting.

The biggest opportunities rarely go to the loudest engineer.

They usually go to the engineer everyone trusts.

The difficult customer.

The critical migration.

The high-profile deployment.

The strategic project.

Leaders naturally assign important work to people whose commitments have consistently proven dependable.

Trust quietly creates opportunity.

Not overnight.

Over years.

People don’t gamble critical work on uncertainty. They invest it in reliability.

Every Promise Shapes Your Legacy

Think about every promise you make.

Not only to customers.

To coworkers.

To your family.

To your friends.

To yourself.

Each commitment either strengthens your character or weakens it.

The habit of keeping your word eventually becomes automatic.

So does the habit of breaking it.

Character is rarely built through dramatic moments.

It is built through ordinary promises consistently honored.

Protect Your Name

There are many things in life that can be replaced.

Technology.

Careers.

Companies.

Titles.

Your reputation is different.

It travels ahead of you.

Long before someone meets you…

They may already know your name.

The question is simple.

What does that name communicate?

Dependability?

Integrity?

Consistency?

Or uncertainty?

Your name becomes whatever your promises repeatedly demonstrate.

Questions to Ask Yourself

  • Am I making promises I know I can keep?
  • Have I communicated early when circumstances changed?
  • Do people feel confident when I accept responsibility?
  • What reputation am I building one commitment at a time?
  • Have I ever sacrificed long-term trust for short-term approval?
  • What does my name represent to the people who know me best?
  • If someone recommended me today, what would they say?

Closing Thought

Keeping your word is not about perfection.

It is about consistency.

The world remembers people whose promises become dependable enough that they no longer require verification.

Become one of those people.

Your reputation is built every time your actions quietly confirm what your words already promised.

Founder’s Commentary

Your Name Is Worth More Than Your Résumé

Looking back over my career, I’ve forgotten a surprising number of technical details.

I’ve forgotten version numbers.

Product names.

Specific command syntax.

The exact sequence of steps in projects that consumed months of my life.

Technology changes.

Memory fades.

One thing has remained remarkably consistent.

People remember whether you kept your word.

Every opportunity I’ve ever been given started with trust.

Someone believed I would finish what I started.

Someone believed I would tell them the truth.

Someone believed I would communicate honestly when things became difficult.

That belief wasn’t created by a résumé.

It wasn’t created by certifications.

It certainly wasn’t created by titles.

It was created by years of doing exactly what I said I would do.

I’ve learned that it’s very easy to win business by telling people what they hope to hear.

It’s much harder to tell them what they need to hear.

Sometimes the honest answer is,

“This project is going to take longer.”

“This architecture isn’t ready.”

“We need more testing.”

“I don’t think that’s the right solution.”

Those answers don’t always win the contract.

But they often earn something much more valuable.

Respect.

People remember honesty.

Especially when honesty costs you something.

I’ve never wanted my customers to wonder whether I was telling them the truth.

If I didn’t know…

I told them.

If I made a mistake…

I admitted it.

If the schedule changed…

I communicated it immediately.

None of those conversations were enjoyable.

Every one of them strengthened trust.

One lesson has stayed with me throughout my career.

People can forgive almost anything except feeling misled.

They can accept delays.

Unexpected costs.

Changing priorities.

Even mistakes.

What they struggle to forgive is discovering someone knowingly told them what they wanted to hear instead of what they needed to know.

That moment changes every future conversation.

Trust is difficult to rebuild because people begin questioning every promise that follows.

I eventually realized something that changed how I approached every commitment.

Every promise I make becomes part of my reputation.

Not just the large ones.

The meeting I promised to attend.

The documentation I agreed to send.

The phone call I said I would return.

The estimate I confidently provided.

Every one of those commitments quietly answers the same question.

“Can I believe this person?”

Over enough years, your name begins answering that question before you ever speak.

That is one of the greatest professional compliments anyone can receive.

I’ve met incredibly talented engineers who struggled because people didn’t trust their commitments.

I’ve also met engineers who were still learning but received extraordinary opportunities because everyone knew one thing.

If they gave you their word…

You could stop worrying.

That kind of reputation cannot be purchased.

It cannot be accelerated.

It cannot be manufactured through clever marketing or persuasive presentations.

It is built one promise at a time.

One honest conversation at a time.

One difficult decision at a time.

If there is one lesson I hope every reader carries with them, it is this:

Guard your reputation as carefully as you guard your integrity.

Because in the end…

They become the same thing.

Your résumé may open a door.

Your reputation determines whether people keep inviting you back.

Long after people forget what you built, they will remember whether your word was something they could build their confidence upon.

Principle XXXVI — Every Product Should Teach

Foundational Truth

A great product does more than perform a function.

It leaves the user more capable than before.

Every interaction is an opportunity to teach.

Sometimes through documentation.

Sometimes through thoughtful design.

Sometimes through meaningful feedback.

Sometimes by simply making the next step obvious.

The best products don’t require users to memorize them.

They quietly help users understand them.

The greatest products don’t simply solve problems. They create more capable people.

Teaching Is a Feature

Many teams think of education as something separate from the product.

Training manuals.

Knowledge bases.

Documentation.

Support articles.

Those are valuable.

But teaching can also exist inside the product itself.

Helpful error messages.

Logical workflows.

Clear naming.

Sensible defaults.

Progressive discovery.

Well-designed interfaces naturally guide users toward understanding.

Every unnecessary support ticket represents something the product failed to teach.

Discoverability Creates Confidence

One of my favorite moments with any technology is discovering a feature I didn’t know existed.

Not because someone told me.

Because the product naturally led me there.

Great products encourage exploration.

They reward curiosity.

They help users grow from beginners into experts.

Not through complexity.

Through thoughtful design.

The product becomes its own teacher.

The best documentation is sometimes an interface that needs almost none.

Documentation Is Part of the Product

Documentation is not an afterthought.

It is not something created after the product is finished.

It is part of the experience itself.

Good documentation answers questions before they become frustrations.

It explains not only how something works…

But why it was designed that way.

It shortens onboarding.

Reduces support.

Builds confidence.

And leaves every user better prepared for the next challenge.

A product without documentation is asking every customer to rediscover the same lessons.

Every Interaction Teaches Something

Whether we intend it or not…

Every product teaches.

Confusing interfaces teach hesitation.

Poor error messages teach frustration.

Unpredictable behavior teaches distrust.

Clear workflows teach confidence.

Helpful automation teaches best practices.

Thoughtful feedback teaches understanding.

The question isn’t whether your product teaches.

The question is…

What is it teaching?

Products Create Communities

The products that endure rarely succeed because of functionality alone.

They create communities.

Communities create knowledge.

Knowledge creates innovation.

Innovation attracts more users.

Eventually the product becomes larger than the company that created it.

That begins when users feel empowered rather than dependent.

Teaching creates that empowerment.

Closing Thought

Every release should improve more than the software.

It should improve the people using it.

Build products that solve problems.

Then build them so well that every interaction quietly teaches someone something valuable.

The greatest products leave their users smarter than they found them.

Design for Discovery

The best products rarely reveal everything at once.

Instead, they reward curiosity.

A new user learns the basics quickly.

An experienced user gradually discovers shortcuts.

An expert uncovers capabilities that dramatically improve productivity.

Great products grow with the user.

They never overwhelm beginners.

They never limit experts.

Teaching is not about presenting every feature immediately.

It is about revealing the right feature at the right time.

Great products don’t overwhelm. They illuminate.

Good Design Answers Questions Before They’re Asked

Every user approaches a product with uncertainty.

“What does this button do?”

“Can I undo this?”

“Is this safe?”

“What happens next?”

Thoughtful design answers those questions before the user has to search for them.

Clear labels.

Logical workflows.

Meaningful confirmations.

Helpful defaults.

Consistent behavior.

Every uncertainty removed increases confidence.

Confidence encourages exploration.

Exploration accelerates learning.

Error Messages Are Teachers

One of the greatest missed opportunities in software is the error message.

Too many applications simply announce failure.

“An unexpected error occurred.”

“Operation failed.”

“Unknown exception.”

Those messages teach nothing.

A useful error message explains:

What happened.

Why it happened.

What the user can do next.

The goal is not merely reporting failure.

The goal is helping the user succeed.

Every error becomes an opportunity to teach instead of frustrate.

Documentation Should Inspire Confidence

Documentation is often written as though it were a legal contract.

Technically accurate.

Practically unusable.

The best documentation teaches progressively.

It begins with simple examples.

Builds understanding.

Explains the reasoning behind decisions.

Answers common questions.

Provides practical guidance.

Good documentation doesn’t simply explain a feature.

It helps users understand the philosophy behind it.

When people understand the “why,” they remember the “how.”

Build Products That Reduce Dependence

Some products quietly encourage dependence.

Users constantly require support.

Training.

Clarification.

Expert assistance.

Other products do the opposite.

They steadily reduce the amount of help users need.

Each interaction builds confidence.

Each success encourages another.

Eventually the user becomes self-sufficient.

That is one of the highest compliments a product can receive.

A product succeeds when its users need you less because you’ve taught them more.

Every Feature Should Have a Purpose

Features are not accomplishments.

Outcomes are.

Every feature should answer one simple question.

“What problem does this solve?”

If the answer is unclear…

The feature probably isn’t.

Adding functionality simply because competitors have it creates complexity.

Adding functionality that teaches users a better way to work creates value.

Purpose should guide every decision.

Learning Creates Loyalty

People remember products that made them feel capable.

Not confused.

Not intimidated.

Capable.

Those products become recommendations.

Recommendations become communities.

Communities become ecosystems.

Customers rarely remain loyal to products they struggle to understand.

They remain loyal to products that helped them grow.

Closing Thought

Every interaction leaves the user with something.

More confidence.

More confusion.

More understanding.

Or more frustration.

Choose intentionally.

Build products that quietly teach with every click, every message, every workflow, and every success.

The most valuable feature you can build is the confidence your users gain from using your product.

Products Become Silent Mentors

Every product teaches something.

Sometimes intentionally.

Sometimes accidentally.

The products that endure become silent mentors.

They patiently guide users.

They answer questions.

They encourage exploration.

They reward curiosity.

They quietly build confidence one interaction at a time.

The creator may never meet the person learning from their work.

The lesson still reaches them.

The best products continue teaching long after their creators have gone home.

Empowerment Is the Goal

A product should not exist to make users dependent.

It should exist to make them capable.

The first interaction may require guidance.

The tenth should require confidence.

The hundredth should inspire mastery.

When users feel empowered, something remarkable happens.

They stop asking,

“How do I use this?”

They begin asking,

“What else can I accomplish?”

That is the moment a product becomes transformative.

Build Curiosity Into the Experience

Curiosity is one of the greatest accelerators of learning.

Thoughtful products encourage it.

They make exploration feel safe.

They reward experimentation.

They provide feedback without punishment.

Users discover features because they are naturally drawn toward them.

Not because they memorized a manual.

Learning becomes enjoyable instead of intimidating.

The best teachers don’t force curiosity.

They inspire it.

Teach Principles, Not Just Procedures

A button teaches a task.

A workflow teaches a process.

A thoughtfully designed product teaches principles.

Why this approach is safer.

Why this automation saves time.

Why this security setting matters.

When users understand the reasoning behind a feature…

They become capable of solving problems the product was never explicitly designed to address.

Teaching principles creates independent thinkers.

Not dependent operators.

Procedures create users. Principles create experts.

Products Shape Expectations

Every interaction establishes expectations.

A confusing product teaches users to hesitate.

An unreliable product teaches them to distrust.

An intuitive product teaches confidence.

A thoughtful product teaches discipline.

Eventually users begin expecting the same quality everywhere else.

That’s one of the greatest compliments any creator can receive.

Your product quietly raises the standard.

Not because it demanded attention.

Because it demonstrated a better way.

The Greatest Support Ticket Never Exists

Many organizations measure success by how quickly they resolve support requests.

That’s important.

A better question is:

How many support requests never needed to happen?

Clear documentation prevented one.

Helpful onboarding prevented another.

An intuitive interface prevented hundreds more.

The highest form of support is prevention.

Teaching makes prevention possible.

Products Multiply Knowledge

A mentor teaches one person.

A classroom teaches dozens.

A book teaches thousands.

A remarkable product teaches everyone who touches it.

Every improvement you make…

Every explanation you write…

Every thoughtful workflow you design…

Has the potential to educate someone you’ll never meet.

Knowledge scales remarkably well when embedded inside products.

Questions to Ask Yourself

  • What is my product teaching today?
  • Where do users become confused?
  • What question can I answer before it’s asked?
  • Does this feature create confidence or dependency?
  • Have I explained the “why” as clearly as the “how”?
  • What unnecessary support request could thoughtful design eliminate?
  • Will my users become more capable because of this release?

Closing Thought

Products have the power to do far more than complete tasks.

They can inspire curiosity.

Build confidence.

Create independence.

And quietly make every user a little more capable than they were yesterday.

Build products worthy of teaching.

The greatest products are remembered not because of what they did, but because of what they helped people become.

Founder’s Commentary

Teach Yourself Out of a Job

One lesson has followed me throughout my career.

If someone depends on me forever…

I haven’t really solved their problem.

I’ve only delayed it.

Early in my career, I thought expertise meant being the person with all the answers.

The one everyone had to call.

The engineer who could fix what nobody else understood.

At first, that felt valuable.

Important.

Even secure.

Then something changed.

I realized that every question only I could answer represented a failure somewhere.

Maybe the documentation wasn’t clear enough.

Maybe the automation wasn’t complete.

Maybe the product wasn’t intuitive enough.

Maybe I hadn’t shared what I knew.

Knowledge trapped inside one person doesn’t scale.

Knowledge embedded inside products changes organizations.

That realization transformed the way I build.

When I write documentation…

I want someone to solve the problem without calling me.

When I build automation…

I want someone to complete a task without memorizing dozens of manual steps.

When I write a script…

I include comments explaining not only what it does…

But why.

When I design dashboards…

I want the data to answer the question before someone asks it.

When I create products…

I want them to leave people more capable than when they started.

That’s success.

I’ve never believed support should be the primary goal of a product.

Independence should be.

The greatest compliment I’ve ever received isn’t,

“Can you help me again?”

It’s,

“I figured it out because of what you built.”

That tells me the product taught something.

It created confidence instead of dependence.

That’s exactly what I hoped it would do.

Some organizations unintentionally design products that require experts to operate.

Every new feature creates another support article.

Every update requires another training session.

Every workflow becomes more complicated.

I’ve always wanted the opposite.

I want complexity hidden behind simplicity.

I want difficult ideas explained clearly.

I want users to discover capabilities naturally.

I want people to become stronger because they used something I created.

Whether it’s software…

Documentation…

Books…

Research…

Automation…

Or AI tools…

The purpose is the same.

Teach.

I’ve come to believe that every product leaves something behind.

Sometimes it leaves confusion.

Sometimes frustration.

Sometimes dependence.

The products worth building leave understanding.

If there is one lesson I hope every creator carries with them, it is this:

Don’t ask,

“What can this product do?”

Ask,

“What will people become because this product exists?”

That’s a much more difficult question.

It’s also a much more meaningful one.

Technology changes.

Products evolve.

Companies come and go.

The knowledge you leave behind continues teaching long after you’ve moved on.

To me…

That’s one of the most worthwhile things an engineer can build.

The greatest products don’t create lifelong customers because people cannot live without them. They create lifelong advocates because people became better after using them.

Principle XXXVII — Solve Real Problems

Foundational Truth

Not every problem deserves a solution.

Some deserve observation.

Some deserve acceptance.

Some disappear on their own.

The discipline of engineering is not solving every problem you discover.

It is solving the problems that matter.

Time is finite.

Attention is limited.

Every hour spent solving the wrong problem is an hour unavailable for solving the right one.

The hardest engineering decision is often choosing what not to build.

Beware the Rabbit Hole

Engineers love puzzles.

It’s part of what makes us good at what we do.

We enjoy understanding systems.

Finding edge cases.

Improving efficiency.

Optimizing performance.

The danger comes when curiosity quietly becomes distraction.

One small issue leads to another.

Then another.

Eventually you’ve spent three days solving a problem that almost nobody experiences.

Meanwhile…

The issue affecting every customer remains untouched.

Curiosity is valuable.

Discipline decides where curiosity belongs.

Scope Creep Begins with Good Intentions

Few projects begin by saying,

“Let’s make this unnecessarily complicated.”

Scope creep usually sounds much more reasonable.

“While we’re here…”

“It shouldn’t take long…”

“We might as well…”

“It could be useful someday…”

Every one of those sentences adds another requirement.

Another dependency.

Another test case.

Another support document.

Another maintenance responsibility.

Eventually the original problem becomes almost impossible to recognize.

The project didn’t fail because the team lacked talent.

It failed because they forgot why they started.

Every new feature should earn its place by solving a real problem.

Ask Better Questions

Before solving any problem…

Ask yourself:

Who experiences this?

How often?

What happens if we do nothing?

Is this actually the root cause?

Does solving this improve the outcome in a meaningful way?

What problem are we really trying to solve?

Those questions often reveal something surprising.

The obvious problem isn’t the real one.

Elegance Is Not the Goal

Engineers naturally appreciate elegant solutions.

Beautiful architectures.

Clever algorithms.

Perfect abstractions.

Those things have value.

Only if they solve the right problem.

The simplest solution that completely solves a meaningful problem will almost always outperform the most elegant solution to an insignificant one.

Customers rarely admire elegant code.

They appreciate products that improve their lives.

Never confuse technical beauty with customer value.

Measure Success by Outcomes

A feature shipped.

A dashboard built.

An API optimized.

None of those automatically represent success.

Success asks a different question.

Did someone’s experience improve?

Did work become easier?

Did risk decrease?

Did understanding increase?

Did the customer accomplish something they couldn’t before?

If the answer is no…

The problem may never have needed solving.

Closing Thought

Engineers possess a remarkable ability to solve difficult problems.

Wisdom determines which ones deserve that effort.

Stay curious.

Remain disciplined.

Never lose sight of the reason you began.

Don’t become famous for solving problems nobody actually had. Become trusted for solving the ones that truly matter.

Protect the Problem You Came to Solve

Every project should begin with a clear problem.

Not a technology.

Not a feature.

Not an architecture.

A problem.

Something is too slow.

Something costs too much.

Something is unreliable.

Someone is performing unnecessary manual work.

A customer cannot accomplish something they need to accomplish.

That problem gives the project direction.

Once work begins, however, you will discover other things.

You always do.

Some will be important.

Some will be interesting.

Some will be genuinely broken.

That still does not mean they belong in this project.

Discovery identifies problems. Scope decides which ones you are solving.

Finding Something Does Not Create an Obligation to Fix It

This can be difficult for engineers.

We are naturally problem solvers.

If we see something broken…

We want to fix it.

If we find inefficient code…

We want to refactor it.

If we notice an old configuration…

We want to modernize it.

If we discover an architectural weakness…

We want to redesign it.

That instinct is valuable.

Uncontrolled, it is also one of the easiest ways to destroy a project’s scope.

You were asked to replace a leaking faucet.

You discovered the plumbing is old.

Then you noticed the water heater could be more efficient.

While investigating that, you realized the electrical panel should probably be upgraded.

Three weeks later, the house is under renovation…

And the faucet is still leaking.

Engineering projects can fail exactly the same way.

“While We’re Here” Is Expensive

There are three words that should immediately make every project manager and engineer pay attention.

“While we’re here…”

While we’re here, let’s upgrade the framework.

While we’re here, let’s redesign authentication.

While we’re here, let’s replace the database.

While we’re here, let’s rewrite that service.

While we’re here, let’s add another integration.

Every suggestion may be perfectly reasonable.

Together they can turn a two-week project into a six-month project.

Scope creep rarely arrives carrying a sign that says:

UNNECESSARY COMPLEXITY AHEAD.

It arrives disguised as opportunity.

Define What Done Means

One of the best defenses against scope creep is defining success before work begins.

What problem are we solving?

What outcome demonstrates that it has been solved?

What is explicitly outside the scope?

How will we measure success?

When can we confidently say,

“We’re done”?

Without those answers, projects expand indefinitely because there is no boundary against which new ideas can be evaluated.

“Done” should not mean:

“We cannot think of anything else to improve.”

There will always be something else to improve.

Done means:

The problem we agreed to solve has been solved to the standard we agreed upon.

That is enough.

Ship it.

Learn from it.

Then decide what deserves attention next.

Create a Parking Lot

Rejecting scope creep does not require ignoring good ideas.

Record them.

Create a backlog.

Open another issue.

Add the observation to the documentation.

Create a future improvement project.

I have discovered plenty of valuable problems while solving completely different ones.

The mistake would be believing I had only two choices:

Fix it immediately…

Or forget about it.

There is a third option.

Preserve the discovery without allowing it to interrupt the current mission.

That simple discipline protects both ideas.

The current project gets completed.

The new problem receives the attention it deserves later.

Severity Does Not Equal Relevance

Sometimes the problem you discover is more serious than the one you were originally solving.

That requires judgment.

If you discover an active security compromise while investigating printer performance…

The printer can wait.

Scope is not sacred when circumstances materially change.

But that should be an intentional decision.

Stop.

Evaluate.

Communicate.

Change the scope deliberately.

Do not allow the project to drift silently.

There is a tremendous difference between:

“We discovered a critical issue and intentionally changed priorities.”

and:

“Somehow we ended up rebuilding half the environment.”

The first is judgment.

The second is uncontrolled scope.

Do Not Invent Future Customers

Another source of unnecessary work begins with two dangerous words:

“What if…”

What if someday we need ten million users?

What if a customer wants to deploy this on six operating systems?

What if someone needs seventeen authentication providers?

What if we eventually expand internationally?

Some future planning is responsible engineering.

Designing entire systems around imaginary requirements is not.

Solve today’s real problem while leaving reasonable room for tomorrow.

Do not build tomorrow’s solution before tomorrow has told you what its problem actually is.

Design for change. Do not pretend you can predict every change.

Complexity Must Justify Itself

Every additional feature carries a cost.

Code.

Testing.

Documentation.

Security.

Support.

Dependencies.

Maintenance.

Training.

Every addition should therefore answer a simple question:

What real problem does this solve?

If nobody can answer clearly…

Stop.

Technical sophistication is not automatically value.

Sometimes the best architecture is boring.

Sometimes the best feature is the one you remove.

Sometimes the best code is the code you never write.

Curiosity Needs Boundaries

I never want engineers to stop exploring.

Curiosity is one of the qualities that makes great engineers great.

But professional engineering requires directing that curiosity toward an outcome.

Investigate enough to understand the problem.

Follow evidence far enough to identify the cause.

Then solve it.

You do not have to understand every strange thing you encounter along the way.

Some mysteries can remain mysteries.

If they do not affect the outcome…

They may not deserve today’s time.

Know When to Stop

There is a point in every project where another hour of work produces almost no meaningful improvement.

Recognizing that point is a skill.

Perfection can become another form of scope creep.

One more optimization.

One more feature.

One more refactor.

One more test.

One more dashboard.

At some point, the system already solves the problem.

Let it.

Engineering resources are finite.

There is another real problem waiting somewhere else.

Closing Thought

Good engineers discover problems everywhere.

Great engineers know which ones deserve their attention now.

Protect the scope.

Record worthwhile discoveries.

Change direction deliberately when evidence requires it.

And never confuse something interesting with something important.

You do not owe every problem a solution. You owe the right problems your full attention.

Prioritization Is Judgment

Engineering is not only the ability to solve problems.

It is the ability to decide which problems deserve attention first.

That distinction becomes more important as responsibility grows.

A junior engineer may be given one issue.

A senior engineer may be balancing ten.

An architect may be weighing problems that affect entire systems, teams, customers, and budgets.

At that level, technical skill alone is not enough.

Judgment becomes the scarce resource.

The more problems you are capable of solving, the more important it becomes to choose the right ones.

Urgent Is Not Always Important

Some problems are loud.

Alerts fire.

Customers call.

Dashboards turn red.

Executives begin asking questions.

Those problems feel urgent.

Sometimes they are important too.

Sometimes they are simply noisy.

Other problems are quiet.

A backup has never been restored.

A certificate will expire in six months.

An undocumented dependency is slowly becoming critical.

A manual process consumes hundreds of hours every year.

Nobody is calling.

Nothing is flashing red.

The problem still matters.

Engineering judgment means learning to distinguish between urgency and importance.

If we only respond to what is loudest, the quiet risks eventually become emergencies.

Interesting Is Not the Same as Valuable

Engineers are naturally attracted to interesting problems.

A strange packet capture.

An obscure performance anomaly.

An undocumented API behavior.

A fascinating edge case.

Those investigations can teach us a tremendous amount.

But learning something interesting does not automatically create customer value.

Sometimes the right decision is to stop.

Record what you found.

Preserve enough information to return later.

Then go back to the problem that actually matters.

Curiosity should expand our understanding.

It should not quietly replace our priorities.

Possible Does Not Mean Necessary

Technology creates endless possibilities.

We can add another dashboard.

Another integration.

Another automation.

Another security layer.

Another feature.

Another abstraction.

The question is rarely whether something can be built.

Given enough time and money, almost anything can.

The better question is:

Should it exist?

Every new capability carries a lifetime of consequences.

Support.

Documentation.

Testing.

Security.

Training.

Maintenance.

Dependencies.

Upgrades.

Retirement.

Possibility is not justification.

Value must justify complexity.

Solve the Constraint

Sometimes organizations work incredibly hard without improving the outcome.

They optimize components that are already fast enough.

Automate tasks that were never significant.

Redesign interfaces nobody complained about.

Build features customers never requested.

Activity increases.

Progress does not.

This is where earlier Principles become important.

Measure What Matters.

Complexity Is a Cost.

Every Dependency Has a Price.

The same question connects them all:

What is actually limiting the outcome?

Solve that.

Then measure again.

Know the Cost of Delay

Prioritization is not only about the value of solving something.

It is also about the cost of waiting.

A cosmetic issue may remain harmless for months.

A security vulnerability may not.

A slow manual process may cost hundreds of hours over a year.

An unreliable backup may become catastrophic tomorrow.

Ask:

What happens if we do nothing today?

Tomorrow?

Six months from now?

The answer often reveals priority more clearly than the problem itself.

A problem’s importance is sometimes best measured by the cost of leaving it unsolved.

Protect Finite Attention

Every team has limited capacity.

Every engineer has limited attention.

Every hour invested somewhere is unavailable somewhere else.

That makes prioritization an ethical responsibility as much as an operational one.

When leaders repeatedly send teams after low-value work, they are not merely wasting money.

They are consuming human attention that could have been used on something meaningful.

The opportunity cost is real.

Solve Real Problems means respecting that cost.

Avoid Solution Looking for a Problem

New technology creates excitement.

A new framework appears.

A new AI model launches.

A new cloud service promises remarkable capabilities.

Immediately someone asks:

“How can we use this?”

That is often the wrong first question.

Begin with the problem.

If the new technology genuinely provides a better solution, use it.

If not, admiration is not a business requirement.

Technology should serve the problem.

The problem should never be invented to justify the technology.

Do not build a problem around a solution you wanted to use.

Outcomes Define Priority

A useful way to rank work is to ask what changes when the work is complete.

Does reliability improve?

Does risk decrease?

Does the customer save meaningful time?

Does revenue increase?

Does support become easier?

Does someone gain a capability they genuinely need?

If the outcome is difficult to describe, the work may be difficult to justify.

Technical activity is easy to measure.

Meaningful impact is harder.

Measure the impact anyway.

Saying No Is Part of Engineering

Good engineers learn how to build.

Experienced engineers learn when not to.

Sometimes the most valuable contribution you can make is:

“No.”

Not because the idea is bad.

Because it is not important enough right now.

Not because the feature has no value.

Because another problem has greater value.

Not because the technology isn’t interesting.

Because curiosity alone does not define the mission.

Saying no protects the team’s ability to say yes to what truly matters.

Questions to Ask Yourself

  • What problem are we actually solving?
  • Who experiences it?
  • How often does it occur?
  • What happens if we do nothing?
  • Is this urgent, important, interesting, or merely possible?
  • What more valuable work will be delayed if we pursue this?
  • Are we solving a constraint or decorating the system?
  • Are we introducing technology because it helps, or because we want to use it?
  • What measurable outcome changes when this work is complete?
  • Is this still the problem we originally agreed to solve?

Closing Thought

Engineering capacity is precious.

Spend it deliberately.

Solve the problems that materially improve outcomes.

Preserve interesting discoveries without letting them hijack the mission.

Say no when necessary.

Change priorities when evidence demands it.

And remember that the ability to solve everything does not create an obligation to try.

Maturity is not solving every problem you can find. It is knowing which problems are worth solving at all.

Founder’s Commentary

The Rabbit Hole Will Always Be There

I have gone down more technical rabbit holes than I could possibly count.

Sometimes they were necessary.

Sometimes they uncovered something important.

Sometimes I learned something valuable that helped me years later.

And sometimes…

I spent hours solving a problem nobody actually had.

That is one of the dangers of being curious.

Engineers are trained to notice things that don’t look right.

A strange log entry.

An unexpected route.

A process using more memory than expected.

An old configuration nobody remembers creating.

A database query that could probably be faster.

Something catches your attention and you think,

“That’s odd.”

Those two words have probably consumed more engineering hours than anyone will ever calculate.

Because once I know something doesn’t make sense…

I want to understand why.

That instinct has served me extremely well throughout my career.

It has also taken me down some very long roads.

Experience has taught me that curiosity needs a partner.

Discipline.

The Problem Can Change Without Anyone Noticing

Scope creep doesn’t always happen because someone keeps adding requirements.

Sometimes the engineer does it to themselves.

You start troubleshooting one problem.

During the investigation, you discover something else.

The second issue is interesting, so you investigate it.

That exposes a third.

The third leads to an old configuration.

The old configuration points toward another system.

Several hours later, you suddenly realize something important.

You aren’t working on the original problem anymore.

Nobody changed the scope.

There wasn’t another meeting.

Nobody approved additional work.

The problem simply changed while you were following the evidence.

I’ve done it.

Most experienced engineers probably have.

The important lesson isn’t that you should never follow an unexpected clue.

Sometimes that clue is exactly what leads to the root cause.

The lesson is to periodically stop and ask:

Am I still solving the problem I came here to solve?

That question has saved me from plenty of unnecessary work.

Not Every Broken Thing Is Your Current Problem

This was difficult for me to learn.

If I find something broken, my instinct is to fix it.

That sounds responsible.

Sometimes it is.

But large environments contain thousands of things that could be improved.

Old configurations.

Technical debt.

Outdated documentation.

Inefficient processes.

Temporary solutions that somehow became permanent.

If every discovery becomes part of the current project, nothing ever gets finished.

Eventually I learned to separate two thoughts:

“This should be fixed.”

and:

“I should fix this right now.”

Those are not the same statement.

A problem can be completely legitimate and still belong in another project.

Document it.

Create the ticket.

Tell the appropriate person.

Preserve what you discovered.

Then return to the mission.

Recognizing a problem does not automatically make it the problem you are responsible for solving today.

Don’t Invent Problems to Justify Solutions

Technology makes this particularly tempting.

Engineers love new tools.

I do too.

A new cloud service appears.

A new automation platform.

A new framework.

A new AI capability.

A new security product.

And immediately our minds begin imagining what we could build with it.

There is nothing wrong with exploring technology.

Exploration is how we learn.

But production engineering should begin somewhere else.

With a real problem.

I don’t want to invent a business requirement because I found an interesting technology.

I want to understand the business requirement and then determine which technology solves it best.

Those approaches may eventually arrive at the same tool.

But the reasoning matters.

One begins with value.

The other begins with fascination.

I have learned to ask myself:

“Would I still recommend this solution if I weren’t excited about the technology?”

If the answer is no…

I probably need to think about it again.

Sometimes Good Enough Really Is Good Enough

Engineers don’t always like that phrase.

“Good enough” can sound like lowering standards.

That isn’t what I mean.

A system should be reliable enough.

Secure enough.

Fast enough.

Recoverable enough.

Documented enough.

Tested enough.

Enough must be defined by the actual requirement.

If a database query completes in 200 milliseconds and the application requires anything below one second, spending three days reducing it to 80 milliseconds may accomplish absolutely nothing meaningful.

Technically, I improved it.

Operationally, nothing changed.

The customer cannot tell.

The business cannot tell.

The application cannot tell.

I simply made a number smaller.

There may be circumstances where those 120 milliseconds matter.

If they do, optimize them.

If they don’t…

There is probably another problem somewhere that deserves those three days more.

That isn’t laziness.

That is prioritization.

Critical Discoveries Are Different

There is an important exception.

Sometimes the rabbit hole contains a dragon.

You begin investigating one problem and discover something materially more serious.

A security compromise.

A failing storage system.

A broken backup strategy.

A data integrity issue.

Something capable of causing significant harm.

At that point, continuing with the original scope simply because “that was the ticket” would be ridiculous.

Stop.

Communicate.

Evaluate the risk.

Change priorities deliberately.

The important word is deliberately.

I don’t object to changing scope.

I object to allowing scope to change without anyone realizing it happened.

There should be a moment where someone can say:

“We discovered new information. Based on that information, this is now the more important problem.”

That’s engineering judgment.

Finish Something

There is another reason I have learned to protect scope.

Finishing matters.

A half-finished brilliant solution provides less value than a completed practical one.

Organizations accumulate unfinished projects surprisingly easily.

Each started with good intentions.

Each acquired another requirement.

Then another dependency.

Then another improvement.

Eventually the project became too expensive, too complicated, or too difficult to complete.

I’ve learned to respect the power of a clearly defined finish line.

Solve the problem.

Validate the outcome.

Document what matters.

Deliver it.

Then move on to the next problem.

There will always be another one.

I promise.

Curiosity Is Still One of My Greatest Tools

None of this has made me less curious.

I hope it never does.

Curiosity has been responsible for some of the most important things I’ve learned throughout my career.

It has helped me understand systems nobody could explain.

Find root causes buried several layers beneath the obvious symptom.

Discover technologies I later depended upon.

And ask questions other people weren’t asking.

I don’t want to eliminate rabbit holes.

I simply want to know why I’m entering one.

Sometimes I enter because the evidence says the answer is down there.

Sometimes because the potential risk justifies the investigation.

Sometimes because I deliberately want to learn.

Those are all good reasons.

But I no longer want to emerge three days later carrying the perfect solution to a problem nobody asked me to solve.

Solve What Matters

As engineers become more capable, an interesting thing happens.

The number of problems we can solve becomes much larger than the number of problems we have time to solve.

That means technical ability eventually stops being the primary constraint.

Judgment becomes the constraint.

Where should I spend my time?

What matters most?

What happens if I don’t fix this?

Who benefits if I do?

What am I delaying by choosing this instead?

Those questions have become more important to me with every year I’ve spent in technology.

Because there will never be enough time to fix everything.

There will never be enough money to build everything.

And there will never be enough engineers to investigate every mystery.

So choose carefully.

Stay curious.

Follow evidence.

Change direction when reality demands it.

But remember why you started.

A great engineer can solve difficult problems. A wise engineer makes sure they are the right problems first.

Principle XXXVIII — Make It Better Than You Found It

A Job Worth Doing

When I was very young, my grandmother used to remind me of something I have carried with me for most of my life.

“A job worth doing is a job worth doing right, the first time.”

As a child, I understood the words.

It took experience to understand the lesson.

Imagine a twelve-year-old boy during summer vacation.

His friends are outside riding their bikes.

He wants to join them.

There is only one problem.

Dad told him he has to mow the lawn first.

He has several choices.

Choice A — Don’t Do It

The first option is obvious.

Don’t mow the lawn.

Go ride bikes.

Deal with the consequences later.

Maybe Dad gets angry when you come home.

Maybe you lose privileges.

Or worse…

Dad comes looking for you.

The twelve-year-old version of risk management sometimes concludes that this is worth the gamble.

Experience usually corrects that calculation.

Choice B — Get It Done

The second option is probably the most tempting.

Mow the lawn as quickly as possible.

Miss a few spots.

Don’t worry too much about the edges.

Leave the grass clippings on the sidewalk.

Push the mower back into the garage.

Done.

Maybe you save fifteen minutes.

Fifteen minutes is a lot of time when you’re twelve years old and your friends are waiting.

The problem is that the lawn tells the story after you leave.

Dad sees the missed spots.

He sees the clippings.

He sees exactly how much care went into the work.

You technically completed the task.

But you didn’t really finish the job.

And the fifteen minutes you saved today may cost you far more tomorrow.

Choice C — Do It Right

The third option requires a little more maturity.

Take the time to mow carefully.

Don’t leave patches.

Finish the edges.

Blow the grass clippings off the sidewalk.

Put the mower away.

Now the lawn looks good.

The work is complete.

Dad is happy.

You grab your bike and meet your friends.

This is what most people would reasonably describe as doing a good job.

And it is.

But there is still another choice.

Choice D — Leave It Better

Mow the lawn carefully.

Clean the edges.

Blow the clippings from the sidewalk.

Then empty the mower bag.

Clean the grass from around the mower guard.

Check the fuel.

Top off the tank so it is ready for next time.

Put the mower back where it belongs.

Put the cover over it.

Return the leaf blower to its place beside it.

Then look around before leaving the garage.

Everything is ready for the next time the job needs to be done.

Now go ride bikes.

That choice is extremely rare for a twelve-year-old boy.

It is still surprisingly rare among adults.

Not because people don’t care.

Not because they are lazy.

Usually because experience has not yet taught them the value of those final few steps.

The difference between doing the job and doing the job right is often the work nobody notices until the next time.

Experience Changes the Definition of Done

When you’re twelve, those extra steps feel like wasted time.

The lawn is already mowed.

Why clean the mower?

Why fill the tank?

Why organize everything?

Because someday you will walk into the garage ready to mow the lawn…

And discover the mower is empty.

The bag is full.

Dried grass is packed underneath it.

The leaf blower isn’t where it belongs.

Now the fifteen minutes someone saved last time belongs to you.

Except it isn’t fifteen minutes anymore.

Now it is frustration.

Interruption.

Searching.

Cleaning.

Preparation.

And delay.

Experience eventually teaches something childhood rarely understands.

The final steps of today’s job are often the first steps of tomorrow’s.

What feels like extra work today may simply be work you are choosing not to leave for tomorrow.

IT Has the Same Four Choices

I see the same decisions constantly in technology.

An engineer receives an issue.

They troubleshoot it.

They discover the cause.

They fix it.

The system works again.

Ticket closed.

That sounds like success.

Sometimes it is Choice B.

Because nothing was documented.

Nobody recorded the root cause.

The troubleshooting steps disappeared with the engineer who performed them.

The configuration change wasn’t explained.

The next engineer has no idea what happened.

Three months later…

The same problem returns.

And someone begins troubleshooting from the beginning.

Again.

We didn’t solve the problem.

We solved today’s occurrence of the problem.

There is a difference.

Documentation Is Part of the Job

I harp on documentation constantly.

Not because I enjoy paperwork.

Because I have spent too much of my career inheriting systems where the knowledge disappeared with the people who built them.

I have had to rediscover architectures.

Trace dependencies.

Reverse-engineer configurations.

Search old scripts.

Read logs.

Follow network paths.

And reconstruct decisions nobody thought were important enough to write down.

Those experiences changed the way I think about documentation.

Documentation should not be the final task added after the “real work” is complete.

It should be one of the first things started.

Record what you know.

Update it as you learn.

Correct it when reality proves it wrong.

Leave behind the reasoning that led to the solution.

Documentation is not something separate from engineering.

Documentation is part of the engineering.

Don’t Make Someone Solve the Same Problem Twice

A good solution fixes the immediate problem.

A better solution reduces the chance that the problem happens again.

A complete solution also makes the next investigation easier if it does.

That may mean documentation.

Monitoring.

Automation.

A better error message.

A configuration change.

A runbook.

A comment in the code.

A diagram.

Or simply cleaning up the things you touched while solving the issue.

The exact action changes.

The responsibility does not.

When you finish, ask:

If this happens again six months from now, will someone have to rediscover everything I learned today?

If the answer is yes…

There may still be work left to do.

Think About the Next Person

Eventually someone else will touch what you worked on.

Maybe tomorrow.

Maybe years from now.

Maybe that person will be you.

They should not have to begin where you began.

Leave them the diagram you wished existed.

Write the explanation you searched for.

Label the configuration nobody labeled for you.

Remove the obsolete dependency that confused your investigation.

Document the strange behavior that consumed three hours of troubleshooting.

Leave clues.

Leave knowledge.

Leave confidence.

The goal is not merely to finish ahead of where you started. Leave the next person ahead of where you started.

Better Does Not Mean Perfect

Making something better does not mean rebuilding everything you touch.

That would violate the lesson we just learned in Solve Real Problems.

You do not need to redesign an entire system because you discovered an imperfection.

Better can be small.

One corrected document.

One clearer name.

One removed obsolete configuration.

One automated step.

One useful comment.

One cleaned-up workspace.

One lesson preserved for the next engineer.

The improvement should be proportional to the work.

The important thing is direction.

When you leave…

The system should be slightly easier to understand, operate, support, or trust than it was when you arrived.

Closing Thought

My grandmother gave me the words long before I understood their value.

Experience supplied the rest of the lesson.

Doing something right is not simply completing the visible task.

It is thinking about what happens afterward.

Clean the mower.

Fill the tank.

Put the tools where they belong.

Write the documentation.

Preserve what you learned.

And leave things ready for whoever comes next.

A job worth doing is worth doing right the first time. And when the job is truly finished, the next person should begin from a better place than you did.

Finish the Whole Job

One of the easiest mistakes in engineering is confusing resolution with completion.

The service is running again.

The user can log in.

The database is responsive.

The deployment succeeded.

The ticket can be closed.

Maybe.

A problem can be resolved without the job being finished.

If the root cause was not documented…

If monitoring was not improved…

If temporary changes were left behind…

If the next engineer would have to rediscover everything…

Then part of the work remains.

Restoring service solves the immediate problem. Finishing the job reduces the chance that someone has to solve it again.

Clean Up After Yourself

Technical work leaves footprints.

Temporary files.

Old scripts.

Test accounts.

Emergency firewall rules.

Disabled monitoring.

Stale snapshots.

Unused permissions.

Half-finished comments.

Temporary credentials.

These things are often created for legitimate reasons.

The mistake is forgetting they were temporary.

Every troubleshooting session should eventually include cleanup.

Remove what is no longer needed.

Return protections you temporarily disabled.

Delete test artifacts.

Close temporary access.

Restore the environment to a known, supportable state.

The system should not require another engineer to guess which leftovers still matter.

Temporary Has a Dangerous Habit

Some of the most permanent things in technology began with the word “temporary.”

Temporary firewall rule.

Temporary administrator account.

Temporary script.

Temporary exception.

Temporary workaround.

Temporary server.

Then everyone moves on.

Months later, nobody remembers why it exists.

Years later, everyone is afraid to remove it.

Temporary solutions become permanent when the final cleanup step never happens.

If you create something temporary, give it:

  • An owner.
  • A reason.
  • An expiration.
  • A removal plan.

Otherwise, you are not solving a problem.

You are borrowing one from the future.

Preserve the Discovery

Troubleshooting creates knowledge.

Sometimes a great deal of it.

You may spend hours learning:

  • Which component actually failed.
  • Which log contains the useful evidence.
  • Which dependency behaves unexpectedly.
  • Which configuration matters.
  • Which assumptions were wrong.
  • Which recovery step actually works.

That information is valuable.

If it remains only in your memory, the organization has not really gained it.

Write it down.

Update the runbook.

Correct the diagram.

Add the comment.

Document the command.

Record the root cause.

Preserve the lesson.

A lesson learned but not preserved is a lesson waiting to be paid for again.

Documentation Should Begin with the Work

One reason documentation becomes incomplete is that people treat it as the final phase.

Finish the project.

Then document it.

That sounds reasonable.

It is often backwards.

By the end of a difficult project, everyone is tired.

The deadline has passed.

Leadership wants the team moving to the next task.

Details have already begun disappearing from memory.

Documentation becomes rushed.

Or postponed.

Or abandoned.

Start documenting while discovery is happening.

Record assumptions.

Capture commands.

Update diagrams as architecture changes.

Write down why decisions were made while the reasoning is still fresh.

Then, at the end, documentation is not a separate project.

It is simply another artifact already produced by the work.

Make the Next Incident Easier

Some problems cannot be eliminated completely.

Hardware fails.

Dependencies fail.

Networks experience disruption.

Humans make mistakes.

Making something better does not always mean preventing every recurrence.

Sometimes it means ensuring the next recurrence is easier to detect, understand, and recover from.

Add monitoring.

Improve the alert.

Capture the right logs.

Automate the diagnostic steps.

Write the recovery procedure.

Test the fallback.

If the same incident happens again and everyone responds faster…

You improved the system.

Remove One Piece of Toil

Every time you perform the same manual process repeatedly, ask whether one piece can be eliminated.

Maybe the entire task cannot be automated.

Automate the boring part.

Maybe the entire deployment cannot be standardized.

Standardize the validation.

Maybe troubleshooting still requires judgment.

Automate data collection.

Improvement does not always require rebuilding the system.

Sometimes making one repetitive step disappear is enough to leave the environment better.

Small improvements compound.

Leave Better Signals

One of the most useful improvements you can make is helping systems explain themselves.

A vague error message wastes time.

A meaningful error message teaches.

A log entry without context creates questions.

A useful log entry answers them.

A monitoring alert that says:

“Server unavailable”

is less useful than one that says:

“Database connection failures exceeded threshold after certificate renewal.”

Better signals shorten recovery.

They help the next engineer begin closer to the answer.

That is exactly what this Principle asks us to do.

Reduce Mystery

Mystery is expensive.

An undocumented scheduled task.

An unexplained service account.

An old DNS record.

A strange dependency.

A script nobody recognizes.

Each mystery adds hesitation.

People become afraid to make changes because they do not understand the consequences.

Good engineering steadily removes mystery.

Name things clearly.

Document ownership.

Explain dependencies.

Remove obsolete resources.

Reduce the number of things future engineers must treat as unknown.

Every mystery you eliminate today is one less assumption someone must make tomorrow.

Improve the Environment, Not Just the Symptom

Imagine a recurring disk-space problem.

You can delete temporary files.

Problem solved.

Until next month.

A better response might include:

  • Removing the files.
  • Identifying what created them.
  • Correcting retention.
  • Adding monitoring.
  • Documenting expected growth.
  • Alerting before capacity becomes critical.

The immediate symptom still gets fixed.

But now the environment is stronger.

That is the difference between maintenance and stewardship.

Respect Scope

Making something better does not mean fixing everything you discover.

This Principle must coexist with Solve Real Problems.

The goal is not:

“Improve every system I touch.”

The goal is:

“Do the work completely, and make proportional improvements that reduce future burden.”

Do not turn a password reset into an identity-platform migration.

Do not turn a storage alert into a data-center redesign.

Improve what belongs to the problem.

Record everything else worth revisiting.

Stewardship without discipline becomes scope creep.

Build the Handoff Into the Work

Every job eventually ends.

A ticket closes.

A project completes.

An engineer changes teams.

A vendor engagement ends.

A handoff should not depend upon a final conversation where someone tries to remember everything important.

Build the handoff as you work.

Documentation.

Diagrams.

Runbooks.

Repositories.

Comments.

Known issues.

Recovery procedures.

Ownership.

The person who follows should not require access to your memory.

They should inherit your understanding.

Ask the Final Question

Before declaring work complete, ask:

“What would I wish had been done if I were the next person opening this ticket six months from now?”

That question changes behavior.

You may notice the missing documentation.

The temporary rule.

The stale test account.

The absent monitoring.

The confusing script name.

The unfinished cleanup.

It is a simple question.

It has prevented me from leaving a great deal of unfinished work behind.

Closing Thought

Finishing well requires thinking beyond the visible result.

Clean up the temporary work.

Preserve the discovery.

Improve the signals.

Reduce the mystery.

Prepare the next person.

Then close the ticket.

A complete solution does more than restore the system. It improves the next engineer’s starting point.

Stewardship

There is a word that captures much of what this Principle means to me.

Stewardship.

A steward understands that something can be placed in their care without truly belonging to them.

A system.

A project.

A team.

A company.

A home.

A community.

A relationship.

Even knowledge.

For some period of time, you become responsible for it.

Eventually, someone else will inherit what you leave behind.

The question is:

What condition will it be in when they receive it?

Stewardship means treating temporary responsibility as though the consequences were permanent.

We Are All Temporary Owners

Technology makes this obvious.

Nobody owns a production environment forever.

Engineers change roles.

Administrators leave companies.

Applications are replaced.

Infrastructure is migrated.

Companies merge.

Technologies become obsolete.

Eventually, everything we build becomes someone else’s responsibility.

But while it is ours…

We have a choice.

Consume its value.

Maintain its value.

Or increase its value.

The same is true far beyond engineering.

We are temporary custodians of many things throughout our lives.

What matters is what condition they are in when our responsibility ends.

Leave Knowledge Behind

One of the most valuable things anyone can leave behind is understanding.

You may solve a difficult problem today.

That is useful.

Teach someone else how you solved it…

And the value multiplies.

Document why the solution works…

And the value survives your absence.

Improve the process…

And people you may never meet benefit from what you learned.

Knowledge becomes far more valuable when it stops belonging to one person.

This is why documentation matters so much to me.

It is not bureaucracy.

It is generosity.

You are leaving behind something you had to earn so the next person doesn’t have to pay the same price.

Experience becomes legacy when the lesson survives the person who learned it.

The Invisible Work Matters

Some of the most valuable work receives almost no recognition.

Cleaning up documentation.

Organizing a repository.

Removing obsolete resources.

Correcting a diagram.

Labeling equipment.

Updating a runbook.

Refilling the mower.

Nobody applauds.

There may not be a ticket for it.

There probably isn’t an award.

Sometimes nobody even knows you did it.

Until they need it.

Then the value becomes obvious.

Character is often revealed in those moments.

Do you only perform the work people can see?

Or do you finish the things that matter even when nobody is watching?

Think About the Person Who Follows

Imagine walking into a job someone else has just completed.

Everything is labeled.

The documentation is accurate.

The tools are where they belong.

The temporary changes were removed.

The reasoning behind important decisions was recorded.

You understand where to begin.

Now imagine the opposite.

Nothing is documented.

Nobody knows why configurations exist.

Files are scattered everywhere.

Temporary work became permanent.

The person who built everything is gone.

Both environments tell you something about the person who came before you.

One says:

“I finished my work.”

The other says:

“I thought about you.”

That difference matters.

The highest form of craftsmanship considers people who are not yet in the room.

Leave People Better Too

Systems are not the only things we influence.

People should be better because we were there too.

Teach the junior engineer.

Answer the question.

Explain why.

Share the shortcut.

Give someone credit.

Encourage curiosity.

Correct mistakes without humiliating the person who made them.

Create opportunities for someone else to succeed.

A great engineer can leave behind reliable systems.

A great leader leaves behind capable people.

The best do both.

Improvement Does Not Require Recognition

There is a temptation to associate value with visibility.

If nobody noticed…

Did it matter?

Of course it did.

The documentation still helps.

The clean workspace still saves time.

The automated process still eliminates toil.

The lesson still helps the engineer who learned it.

The mower still starts next Saturday.

Value exists whether someone applauds it or not.

Some of the best work you will ever do may be discovered only after you are gone.

Someone will encounter something you left behind and quietly think:

“I’m glad whoever did this thought ahead.”

You may never hear those words.

Do the work anyway.

Small Improvements Compound

Making something better does not require transforming it.

Small improvements matter.

One clearer instruction.

One corrected mistake.

One automated step.

One cleaned workspace.

One useful conversation.

One person taught something new.

Do that repeatedly for years and the effect becomes enormous.

This is how strong systems are built.

Strong teams too.

Rarely through one heroic act.

Usually through thousands of small decisions made correctly.

Better is usually built quietly, one thoughtful decision at a time.

Your Future Self Is Also the Next Person

Sometimes the person following you is you.

You return six months later.

You don’t remember the details.

Why did I configure this?

What did that script do?

Which command fixed this?

Where did I put that file?

Suddenly you discover whether your past self practiced stewardship.

Good documentation feels like receiving help from someone who already understands the problem.

Because you are.

Your past self left something behind.

This is one of the reasons I document while I work.

I know how much I will forget.

I don’t expect memory to become infrastructure.

Leave Places Better

This Principle extends beyond systems and careers.

Borrow something?

Return it in better condition.

Use a shared space?

Clean it.

Join a team?

Strengthen it.

Learn something valuable?

Teach it.

Discover a problem?

Leave enough information for someone to understand it.

Lead people?

Help them become capable of leading without you.

Every environment gives us an opportunity to leave something behind.

Not necessarily something dramatic.

Something better.

The Real Measure of Leadership

Leadership is sometimes measured by what happens while the leader is present.

I think another measurement matters more.

What happens after they leave?

Does everything collapse because one person held all the knowledge?

Or does the team continue succeeding?

Do people understand the systems?

Can someone else make decisions?

Was knowledge shared?

Were future leaders developed?

If an organization cannot function without you, you may have made yourself important.

You have not necessarily made the organization stronger.

The goal should not be to become indispensable.

The goal should be to make what you touched more capable of succeeding without you.

A Different Definition of Success

Early in life, success often means completing the assignment.

Later, success becomes completing it well.

Eventually, I think success becomes something larger.

What did the work leave behind?

Did the problem stay solved?

Did knowledge increase?

Did the system become easier to support?

Did someone learn?

Did the next person begin farther ahead?

That is a different standard.

It requires thinking beyond ourselves.

But that is exactly why it matters.

Closing Thought

We spend our lives passing through things.

Projects.

Jobs.

Teams.

Homes.

Organizations.

Relationships.

Eventually, someone else stands where we once stood.

They inherit some portion of what we leave behind.

Make their starting point better.

Leave knowledge.

Leave order.

Leave stronger systems.

Leave more capable people.

And whenever possible, leave evidence that someone cared enough to finish the whole job.

You may not own what you are responsible for forever. But you will always own the condition in which you chose to leave it.

Founder’s Commentary

What My Grandmother Was Really Teaching Me

When I was very young, my grandmother used to tell me:

“A job worth doing is a job worth doing right, the first time.”

I understood what she wanted me to do.

I didn’t understand everything she was teaching me.

At twelve years old, doing the job right meant getting through the chore so I could go do what I actually wanted to do.

Mow the lawn.

Put the mower away.

Get on my bike.

My friends were waiting.

Every additional minute spent cleaning the mower, emptying the bag, filling the tank, or putting everything neatly back where it belonged was one less minute of summer.

Choice B made perfect sense to a twelve-year-old.

Get it done quickly.

Good enough.

Go play.

Choice D required something I didn’t have much of yet.

Experience.

The Fifteen Minutes Never Disappeared

The interesting thing about saving those fifteen minutes is that they were never really saved.

They were transferred.

Someone still had to clean the mower.

Someone still had to empty the bag.

Someone still had to refill the tank.

Someone still had to clean the sidewalk.

Maybe Dad did it.

Maybe I had to do it later.

Maybe I discovered it the next time I went to mow the lawn.

The work didn’t disappear because I chose not to do it.

It simply waited for someone else.

Technology works exactly the same way.

Skip the documentation.

Leave the temporary configuration.

Ignore the cleanup.

Don’t record the root cause.

Save fifteen minutes.

The work hasn’t disappeared.

You have transferred it to the future.

And the future usually charges interest.

Shortcuts rarely eliminate work. They usually decide who will have to do it later.

I Have Been the Next Person

Much of my appreciation for this Principle came from spending years being the person who arrived afterward.

I have inherited systems with little or no documentation.

I’ve opened environments where nobody could explain why something was configured the way it was.

I’ve traced network paths because the diagram didn’t exist.

I’ve read scripts line by line trying to understand what someone intended.

I’ve searched through logs, repositories, old files, configurations, and whatever fragments of history remained.

Sometimes I eventually discovered an elegant system.

Sometimes I discovered years of accumulated compromises.

But before I could improve either one, I first had to understand it.

And without documentation, discovery becomes archaeology.

You reconstruct the past from whatever evidence survived.

That experience changes you.

After enough hours spent rediscovering knowledge someone else already possessed…

Documentation stops feeling like paperwork.

It starts feeling like respect.

Documentation Is Not the Last Step

I have said this repeatedly throughout my career:

Documentation is part of the job.

I don’t mean:

“Finish the work and then write some documentation if there is time.”

I mean documentation should begin when the work begins.

Create the document.

Write down what you know.

Record what you expect.

Then update it as reality teaches you more.

If an assumption turns out to be wrong, correct it.

If the architecture changes, update the diagram.

If troubleshooting reveals an undocumented dependency, document it.

If a command becomes part of recovery, preserve it.

By the time the project is complete, the documentation should tell the story of what actually exists.

Not what someone remembers building.

Not what the original design predicted.

What exists.

That distinction matters.

Documentation Is the Filled Gas Tank

I think about that lawn mower more often than you might expect.

Documentation is the filled gas tank.

It doesn’t make today’s lawn look any better.

Nobody driving past the house can see it.

There is no visible difference between a mower sitting in the garage with an empty tank and one ready for the next job.

The value becomes visible later.

Someone walks into the garage.

Pulls out the mower.

And starts working.

No searching for the gas can.

No cleaning yesterday’s mess.

No wondering what condition the equipment was left in.

Someone thought ahead.

That is exactly what good documentation feels like during an incident.

You open the runbook.

The information is accurate.

The architecture matches reality.

The commands are there.

The dependencies are explained.

You begin solving the problem immediately.

Someone filled the tank.

Solve It Once

This is probably the part I care about most.

I hate solving the same problem twice.

Not because recurring problems make me angry.

Because every recurrence is an opportunity to ask whether we learned enough the first time.

If I spend three hours troubleshooting an issue today and the same issue occurs three months from now…

I don’t want another engineer spending the same three hours rediscovering everything I already learned.

Maybe we can prevent the issue entirely.

Great.

Do that.

Maybe we can’t.

Then improve the monitoring.

Write the runbook.

Capture the commands.

Document the symptoms.

Explain the root cause.

Automate part of the recovery.

Give the next person a fifteen-minute problem instead of a three-hour problem.

That is progress.

If the problem must happen twice, the second recovery should benefit from everything the first one taught us.

I Don’t Blame the People Before Me

It would be easy to criticize engineers who didn’t document their work.

I try not to.

Because I understand how it happens.

The system is finally working.

The outage is over.

Everyone is relieved.

Another ticket is waiting.

Another project is already late.

Someone says:

“We’ll document it later.”

Later rarely comes.

Many of those engineers cared deeply about their work.

They simply hadn’t yet experienced enough moments on the other side of missing documentation.

They hadn’t spent enough nights asking:

“Why is this configured this way?”

They hadn’t yet paid the bill.

Experience changes your perspective.

Eventually you realize the final fifteen minutes are not slowing you down.

They are protecting everyone who follows.

Do the Invisible Work

Some of the work I am proudest of is work nobody will ever notice.

A document that prevented a phone call.

A script that eliminated a repetitive task.

A diagram that helped someone understand an environment without asking me.

A cleaned-up configuration that prevented confusion.

A recovery procedure that worked when someone needed it.

Nobody celebrates those things.

That’s fine.

The entire point is that nobody needed to.

The system simply worked better.

The next person had an easier starting point.

That is enough.

Leave Evidence That You Cared

Eventually, all of us leave.

We change jobs.

Change teams.

Finish projects.

Hand systems to other people.

Retire.

Someone else opens the repository.

Someone else inherits the server.

Someone else reads the documentation.

Someone else walks into the garage.

What we leave behind says something about how we approached our responsibility.

I want the next person to know that someone cared.

Not because my name is written everywhere.

Not because I need credit.

Because the system makes sense.

The documentation exists.

The tools are ready.

The knowledge survived.

The problem doesn’t have to be rediscovered.

I want them to begin ahead of where I began.

She Was Teaching Me About More Than Lawns

My grandmother wasn’t an engineer explaining technical debt.

She wasn’t teaching me incident management.

She wasn’t talking about documentation, automation, operational readiness, or knowledge transfer.

She was teaching a little boy how to approach responsibility.

Finish what you start.

Take pride in your work.

Think beyond the visible task.

Don’t leave your unfinished work for someone else.

And do things in a way that makes tomorrow easier.

It took me years to understand how far that lesson reached.

Today I can see it in almost everything I build.

Clean the mower.

Fill the tank.

Put the tools away.

Write the documentation.

Share what you learned.

Fix what reasonably belongs to the work.

And leave the next person with a better starting point.

That is what doing the job right means to me now.

A job worth doing is worth doing right the first time. And if you truly did it right, the evidence will remain long after you are gone: someone else’s job will be easier because you were there.

Principle XXXIX — Build Institutions, Not Projects

Foundational Truth

A project has an end date.

An institution has continuity.

Projects solve immediate problems.

Institutions preserve the solution.

Projects deliver outcomes.

Institutions make those outcomes repeatable.

There is nothing wrong with completing the work assigned to you and going home.

For many people, that is exactly the right relationship with work.

But principal and distinguished engineers operate differently.

They do not only ask:

“Did I finish the project?”

They ask:

“What remains after I leave?”

A project solves the problem once. An institution makes the solution durable.

Treat Your Work Like Your Name Is On It

I have always believed that the work you perform becomes part of your personal brand.

Not in the marketing sense.

In the reputation sense.

Imagine you were a subcontractor and every customer you served had the ability to recommend you to the next ten customers.

Would you do the minimum required?

Probably not.

You would want the customer to remember you as the person who understood the problem, delivered the solution, documented the result, and left everything easier to operate than before.

That is how I try to approach engineering.

Your name may not be printed on the application.

It may not appear on the server.

It may not be visible in the architecture diagram.

But your decisions are still there.

They become part of the system’s behavior.

That is your signature.

Meeting Expectations Is Not the Finish Line

Many projects begin with clearly defined expectations.

Those expectations matter.

But experience teaches you something important.

Initial expectations are often incomplete.

Customers know what they need.

They do not always know what the system will require to remain secure, resilient, maintainable, and supportable.

That is where engineering judgment matters.

If the request says:

“Deploy the application.”

The actual work may also require:

Documentation.

Monitoring.

Backup validation.

Security review.

Recovery procedures.

Automation.

Ownership.

Those are not unnecessary additions.

They are what make the application survivable.

The Extra Fifteen Minutes

This connects directly back to a lesson I learned long before I worked in technology.

Sometimes the difference between an acceptable job and an excellent one is another fifteen minutes.

Clean the workspace.

Update the documentation.

Verify the backup.

Label the configuration.

Test the recovery step.

Explain the handoff.

None of these tasks may be explicitly listed in the project plan.

They still matter.

Those fifteen minutes are often the difference between something that merely works today and something people can depend upon tomorrow.

Excellence often lives in the work that was never explicitly requested.

Install the Easy Button

One of the things that has always driven me is removing unnecessary difficulty.

If a task is complicated today…

Can I make it simple tomorrow?

If a process requires an expert…

Can I create a workflow that someone else can follow?

If a deployment requires twenty manual steps…

Can I automate fifteen of them?

If a recovery requires tribal knowledge…

Can I turn it into a runbook?

I think of that as installing the “easy button.”

Not by hiding the complexity irresponsibly.

By understanding the complexity well enough to make the correct path obvious.

Then show the customer where the button is.

Explain when to use it.

Explain when not to use it.

And make sure it still works after you are gone.

The Difference Between Completing and Institutionalizing

Consider two engineers.

Both successfully deploy the same system.

The first completes the installation.

The system works.

The ticket closes.

The second deploys the system…

Then documents the architecture.

Adds monitoring.

Creates the recovery procedure.

Automates routine maintenance.

Defines ownership.

Trains the next engineer.

Both completed the project.

Only one created something durable.

That difference is what I mean by building institutions.

Make Success Repeatable

One-time success is valuable.

Repeatable success is transformational.

A great engineer can solve a difficult problem.

A principal engineer asks:

“How do I make sure the organization can solve this without me next time?”

That question changes everything.

Scripts become automation.

Notes become documentation.

Experience becomes standards.

Lessons become training.

Projects become platforms.

Individual knowledge becomes organizational capability.

That is institutional thinking.

Build for the Customer You May Never Meet

Sometimes the person who benefits most from your work is not today’s customer.

It is the engineer who inherits the environment three years from now.

The administrator responding to an outage at midnight.

The new employee trying to understand the architecture.

The manager trying to estimate the next upgrade.

The customer trying to recover after a failure.

Build for them too.

You may never meet them.

That does not make their experience less important.

Closing Thought

Projects are temporary.

Standards endure.

Documentation endures.

Automation endures.

Knowledge endures.

The strongest engineers do more than complete work.

They leave behind systems that continue producing value after the project has ended.

Don’t just finish the project. Build something the organization can keep succeeding with after you’re gone.

Institutional Engineering

A project succeeds when the deliverable works.

An institution succeeds when the work continues to function without depending upon the person who originally created it.

That requires more than technical skill.

It requires structure.

Standards.

Documentation.

Automation.

Ownership.

Training.

Repeatability.

The goal is to remove unnecessary dependence on individual memory.

If the system only works because one person remembers how, you did not build an institution. You built a dependency.

Standards Create Continuity

Standards are one of the simplest ways to turn individual effort into organizational capability.

Naming conventions.

Repository structures.

Deployment patterns.

Logging formats.

Monitoring standards.

Security baselines.

Documentation templates.

Recovery procedures.

Standards reduce unnecessary decisions.

They make environments easier to understand.

They allow engineers to move between systems without starting from zero every time.

Good standards do not eliminate judgment.

They preserve judgment for places where it actually matters.

Automate the Repeated Work

A process that depends on someone manually performing the same sequence forever is fragile.

People leave.

People forget.

People get tired.

People make mistakes.

Automation captures a known process and makes it repeatable.

The more routine work you automate, the less the organization depends on who happens to be available.

That is institutional value.

A script can outlive its author.

A deployment pipeline can preserve best practices for years.

A scheduled workflow can continue creating value long after the project that created it has ended.

Automation turns personal expertise into shared capability.

Write the Runbook Before You Need It

Most organizations discover the value of runbooks at the worst possible time.

During an outage.

By then, everyone is trying to remember.

Which server?

Which credential?

Which command?

Which dependency?

Which sequence?

That is not the time to build institutional knowledge.

The runbook should already exist.

It should be tested.

It should reflect reality.

It should answer the questions someone will ask when the original engineer is not available.

If the recovery plan depends on calling one particular person…

The organization does not have a recovery plan.

It has a phone number.

Ownership Must Be Explicit

Every durable system needs ownership.

Who maintains it?

Who reviews updates?

Who monitors failures?

Who validates backups?

Who owns documentation?

Who decides when the technology should be retired?

Ambiguous ownership creates neglected systems.

Everyone assumes someone else is responsible.

Eventually nobody is.

Institutional engineering makes responsibility visible.

Not to assign blame.

To prevent abandonment.

Remove the Single-Person Dependency

Being the only person who understands a system may feel like job security.

It is not.

It is organizational risk.

If one person cannot take vacation without being called…

The system is too dependent on them.

If one engineer leaving would make a platform impossible to support…

Knowledge was never institutionalized.

Teach someone else.

Document the process.

Automate the routine.

Share access appropriately.

Create redundancy in knowledge just as you would create redundancy in infrastructure.

No critical system should have a human single point of failure.

Design the Handoff

Every system will eventually be handed to someone else.

The only question is whether that handoff is deliberate.

A good handoff contains:

  • Current documentation
  • Architecture diagrams
  • Known dependencies
  • Ownership
  • Access procedures
  • Recovery steps
  • Monitoring expectations
  • Known limitations
  • Upgrade procedures
  • Retirement considerations

The next engineer should not need a historical investigation before they can safely operate the system.

Build the handoff while you build the system.

Preserve the Why

One of the most valuable things documentation can contain is not what was done.

It is why.

Why was this architecture selected?

Why does this exception exist?

Why was this dependency chosen?

Why is this control intentionally different from the standard?

Configuration shows the decision.

Context preserves the reasoning.

Without the why, future engineers may remove something important because it looks strange.

Or keep something obsolete because nobody understands why it exists.

Institutional memory requires both.

Build Guardrails

Good institutions do not depend on everyone remembering every rule perfectly.

They create guardrails.

Validation scripts.

Automated tests.

Policy checks.

Approval workflows.

Monitoring.

Access controls.

Templates.

Defaults.

Guardrails make the correct path easier.

They reduce the number of ways routine work can go wrong.

That does not remove responsibility.

It supports people in carrying responsibility consistently.

Train the Next Person Before You Leave

Knowledge transfer should not happen only when someone resigns.

By then, it is too late.

Teach continuously.

Let someone else perform the deployment.

Have another engineer restore the backup.

Ask someone unfamiliar with the system to follow the documentation.

If they cannot succeed…

You just discovered where institutional knowledge is still missing.

That is valuable information.

Fix it before the handoff becomes permanent.

Projects Should Produce Assets

A project should leave more behind than the deployed system.

It should produce reusable assets.

Documentation.

Scripts.

Templates.

Standards.

Automation.

Lessons learned.

Recovery procedures.

Monitoring.

Training material.

These artifacts turn one project into a foundation for the next.

A successful project solves one problem.

A well-built institution makes future projects easier.

Avoid Hero Culture

Heroic recoveries make great stories.

They are terrible operating models.

If every major incident requires one exceptional engineer to save the day…

The organization is fragile.

The goal should not be creating more heroes.

The goal should be creating fewer emergencies that require them.

Build systems ordinary competent people can operate successfully.

Reserve extraordinary talent for extraordinary problems.

That is what mature institutions do.

Institutional Memory Is a Feature

Organizations forget.

People leave.

Teams reorganize.

Vendors change.

Acquisitions happen.

Priorities shift.

Without deliberate preservation, important knowledge disappears.

Treat institutional memory as a feature.

Record decisions.

Preserve history.

Maintain documentation.

Retire obsolete information.

Make the current truth easy to find.

Knowledge that cannot be found is functionally the same as knowledge that does not exist.

Make Yourself Replaceable

This may sound uncomfortable.

It should not.

A strong engineer should continuously make themselves easier to replace in their current responsibilities.

Not because they are less valuable.

Because it frees them to take on the next difficult problem.

If everything depends upon you…

You cannot move.

If others can operate what you built…

You become available to build what comes next.

That is career growth.

Institutionalizing your knowledge does not reduce your value.

It multiplies it.

Closing Thought

Projects produce deliverables.

Institutions produce capability.

The difference is what remains after the original engineer steps away.

Build standards.

Preserve knowledge.

Automate repetition.

Create ownership.

Train others.

Remove yourself as the single point of failure.

Then move on knowing the system no longer depends upon your presence.

The strongest thing you can build is something that keeps succeeding without you.

Build Something Larger Than Yourself

There is a natural progression in a career.

At first, you are measured by what you can do.

Can you solve the problem?

Can you configure the system?

Can you write the code?

Can you recover the server?

Can you complete the project?

Those are important questions.

But eventually another question becomes more important:

Can you make other people and systems more capable because you were there?

That is a different kind of contribution.

It is no longer measured only by your individual output.

It is measured by what continues to happen around you.

The highest level of contribution is not doing more work yourself. It is creating more capability around you.

Your Reputation Walks Into Rooms Before You Do

I think every engineer has a personal brand whether they intentionally create one or not.

Your personal brand is not your title.

It is not your résumé.

It is not your LinkedIn profile.

It is what people expect when they hear your name.

Does this person finish what they start?

Do they document their work?

Can we trust their design?

Will they tell us when they don’t know something?

Will they challenge us when the requirement creates unnecessary risk?

Will they make the environment better?

Will the next person understand what they built?

That reputation is created one project at a time.

Every ticket contributes to it.

Every outage contributes to it.

Every handoff contributes to it.

Every promise contributes to it.

Eventually people begin to know what your name means before you enter the room.

Think Like the Subcontractor

Imagine every project as though you were an independent subcontractor.

The customer has hired you once.

There is no guarantee they will hire you again.

There is no guarantee they will recommend you.

The only thing you control is the quality of the experience you provide.

You could perform exactly what the contract requires.

There is nothing inherently wrong with that.

Or you could look at the customer’s larger problem.

You could identify the small improvements that make the solution easier to operate.

You could explain risks they may not have considered.

You could document what you changed.

You could leave behind tools that make their next problem easier.

You could make them feel that bringing you into the environment created more value than they expected.

That is how referrals are earned.

Not by constantly telling people how valuable you are.

By leaving evidence.

Your best advertisement is the condition in which you leave the customer.

Expectations Are a Starting Point

Requirements matter.

Scope matters.

Budgets matter.

Deadlines matter.

But requirements describe what someone knows to ask for.

Engineering judgment exists partly to identify what they did not know they needed to ask.

A customer may ask for a backup.

An experienced engineer asks whether it can be restored.

A customer may ask for high availability.

An experienced engineer asks what happens when the entire region fails.

A customer may ask for automation.

An experienced engineer asks how failures will be detected and handled.

A customer may ask for access.

An experienced engineer asks how that access will eventually be revoked.

This does not mean expanding every project endlessly.

We already established that in Solve Real Problems.

It means understanding the difference between scope creep and professional completeness.

Do not invent requirements. But do not hide behind incomplete requirements either.

Challenge Expectations With Judgment

Sometimes the customer asks for exactly the right thing.

Build it.

Sometimes they ask for something that will work but leave unnecessary risk.

Explain the risk.

Sometimes they ask for something technically possible but operationally fragile.

Offer a stronger alternative.

Sometimes they ask for the cheapest solution because nobody has explained the long-term cost.

Explain the tradeoff.

Principal-level engineering is not simply accepting requirements and translating them into technology.

It is helping people understand the consequences of their choices.

That requires judgment.

It also requires humility.

You are not there to override the customer.

You are there to make sure the customer is making an informed decision.

The Easy Button Is Really a Transfer of Knowledge

I like installing the “easy button.”

But the button itself is not the important part.

What matters is what happened before the button existed.

Someone had to understand the complexity.

Someone had to identify the correct sequence.

Someone had to understand the failure conditions.

Someone had to determine what could safely be automated.

Someone had to build the guardrails.

Then all of that knowledge was compressed into something another person could use.

That is what good engineering does.

It converts expertise into capability.

The real accomplishment is not that I can perform a complicated task.

The accomplishment is that I understood it well enough to make it simple for someone else.

Expertise becomes institutional when someone else can benefit from it without requiring the expert to be present.

Teach People Where the Button Is

There is another part of the easy button that matters.

Show people where it is.

Explain what it does.

Explain when to push it.

Explain what success looks like.

Explain what failure looks like.

Explain when they should stop and ask for help.

Automation without understanding can create a different kind of dependency.

People learn to push buttons without understanding consequences.

That is not empowerment.

That is obscured complexity.

The goal is not to make people ignorant of the system.

The goal is to remove unnecessary complexity while preserving enough understanding for them to operate it responsibly.

Make Yourself Less Necessary

Early in a career, being needed feels good.

Someone calls because you know the answer.

A system breaks and everyone waits for you.

You become the expert.

There is satisfaction in that.

But eventually you realize something.

If every problem requires you…

You haven’t scaled.

Your knowledge is trapped inside your availability.

There are only so many hours in your day.

There are only so many problems you can personally solve.

The way forward is not becoming faster at answering every call.

It is reducing how many calls require you.

Document the answer.

Teach the team.

Build the tool.

Automate the process.

Improve the architecture.

Create the standard.

Then take the time you recovered and solve a harder problem.

Growth begins when yesterday’s expertise no longer requires today’s attention.

Build People Too

Institutions are not made only from technology.

They are made from people.

A strong engineer should leave other engineers stronger.

Explain why you made the decision.

Let someone else drive.

Review their work.

Give them room to make decisions.

Allow them to challenge yours.

Teach the principle behind the procedure.

When someone asks a question, resist the temptation to simply take the keyboard.

Sometimes the fastest way to finish today’s task is to do it yourself.

Sometimes the best way to improve tomorrow is to teach someone else how.

Those goals occasionally conflict.

Choose deliberately.

Success Should Survive Promotion

There is a useful test for the systems and teams you build.

What happens if you are promoted tomorrow?

What happens if you move to another team?

What happens if you take a month off?

What happens if you leave the company?

Does everything continue?

Or does your departure reveal how much knowledge was actually stored inside one person?

The goal is not to make your contribution invisible.

The goal is to make its value durable.

The best evidence that you built something well may be that people continue succeeding after you stop touching it.

Build a Reputation for Leaving Strength Behind

Over time, people notice patterns.

Some engineers leave environments that require cleanup.

Some leave mysteries.

Some leave undocumented dependencies.

Some leave systems nobody wants to touch.

Others leave clarity.

They leave standards.

They leave automation.

They leave documentation.

They leave trained people.

They leave confidence.

Be the second kind.

Not because you expect applause.

Because eventually your reputation becomes the accumulation of what people inherit from you.

Your legacy is often experienced by people who never worked with you.

The Institution Is the Multiplier

A single engineer has limits.

An institution multiplies.

One documented solution can help hundreds of people.

One automation can execute thousands of times.

One standard can shape hundreds of future systems.

One engineer you teach can eventually teach ten more.

One thoughtful project can become the foundation for years of work.

That is leverage.

And leverage is one of the defining differences between individual contribution and institutional contribution.

The goal is not simply to work harder.

It is to make good work repeatable.

Leave Capability Behind

At some point, every project ends.

The meeting closes.

The ticket is resolved.

The contract finishes.

The engineer moves on.

The question is what remains.

If only the deliverable remains, you completed a project.

If knowledge remains…

If standards remain…

If automation remains…

If stronger people remain…

If the organization can now do something reliably that it could not do before…

You built something larger.

You built capability.

That is the beginning of an institution.

Do not measure your career only by the things you built. Measure it by the things that kept working, the people who kept growing, and the capabilities that remained because you were there.

Founder’s Commentary

I Want Them to Call Me Back for a Different Problem

I have never been very good at looking at a job as simply a job.

Show up.

Do what was assigned.

Collect the paycheck.

Go home.

There is absolutely nothing wrong with that relationship with work.

For many people, work provides the resources that allow them to pursue the things that matter most in the rest of their lives.

I respect that.

But it has never really been how I am wired.

When someone gives me a problem, I want to solve it.

Then I start looking around.

Why did the problem happen?

What else depends on this?

How do we prevent it?

Can this be automated?

Can we make it easier?

Can someone else operate it?

Can I put an easy button here?

And once the button exists…

Does everyone know where it is and when to push it?

That instinct has followed me throughout my career.

I Think Like a Subcontractor

I often think about my work as though I were a subcontractor.

The customer has invited me into their environment.

That invitation carries trust.

They are giving me access to systems that matter to them.

Their data.

Their infrastructure.

Their applications.

Their business.

Sometimes the systems I touch are directly connected to people’s livelihoods.

That changes how I think about the work.

I don’t want to simply satisfy the statement of work.

I want the customer to be glad I was there.

I want them to look at the environment afterward and recognize that it is stronger.

More understandable.

More resilient.

Easier to operate.

Better documented.

Less dependent on tribal knowledge.

I want my work to earn the next opportunity.

Treat every project as though the next project will be awarded based entirely on the condition in which you leave this one.

My Name Is On It Anyway

Most of the systems I have worked on do not have my name anywhere on them.

That’s probably a good thing.

But my name is on them in another sense.

My decisions are there.

My standards are there.

My shortcuts would be there too.

If I knowingly leave something fragile…

That represents me.

If I leave something undocumented…

That represents me.

If I tell the customer something is finished when I know important work remains…

That represents me.

Nobody needs to engrave my name on the server.

I know what I left behind.

That has always been enough to make me care.

Meeting the Requirement Is the Minimum

There is a difference between meeting a requirement and solving the customer’s problem well.

Sometimes the requirement is perfectly written.

Sometimes it isn’t.

Sometimes nobody knew enough about the problem when the project began to anticipate everything we would discover.

That is normal.

Engineering is discovery.

As we learn more, our responsibility is not merely to point back at the original requirement and say:

“That wasn’t in scope.”

Sometimes that is exactly the right answer.

Scope matters.

Budgets matter.

Deadlines matter.

We cannot turn every project into an endless attempt to perfect the universe.

But sometimes experience tells you that another fifteen minutes will materially improve what you are leaving behind.

Take the fifteen minutes.

Write the documentation.

Add the check.

Clean up the temporary configuration.

Test the recovery.

Explain the dependency.

Automate the repetitive step.

Finish the whole job.

That isn’t gold-plating.

That is craftsmanship.

Challenge the Requirement When It Needs Challenging

One of the responsibilities that comes with experience is recognizing when the requested solution is not the strongest solution.

That can be uncomfortable.

It is much easier to say:

“Yes.”

Build exactly what was requested.

Close the project.

Move on.

But customers do not bring experienced engineers into the room simply because they need someone who can follow instructions.

They need judgment.

Sometimes my job is to say:

“Yes, we can do that, but here is the risk.”

Or:

“There is another way to accomplish the same thing that will be easier to support.”

Or:

“This works today, but I think we are creating a problem for ourselves later.”

That does not mean I always get my way.

I shouldn’t.

The customer owns the decision.

My responsibility is to make sure they understand the decision they are making.

Once they understand the tradeoffs, I can support the direction professionally.

Experience is valuable only if you are willing to use it before the mistake, not merely explain it afterward.

I Love the Easy Button

There is something deeply satisfying to me about taking a complicated process and making it simple.

Maybe today it requires twelve commands.

Maybe someone has to remember a strange sequence of steps.

Maybe only one engineer understands it.

My instinct is:

Can we make this a button?

Not literally every time.

But conceptually.

Can we automate it?

Can we script it?

Can we create a workflow?

Can we build a runbook?

Can we establish a standard?

Can we remove unnecessary decisions?

Can we make the safe path the easy path?

Then comes the part I think matters just as much:

Show everyone where the button is.

I don’t want to hide it so they have to call me.

I don’t want knowledge to remain valuable only because I control access to it.

I want them to use it.

I want them to understand it.

I want the problem I solved to stay solved.

I Don’t Want to Be Called for Yesterday’s Problem

Being needed can feel like validation.

The phone rings.

Someone has a difficult problem.

They need you.

There is satisfaction in knowing that people trust your expertise.

But I don’t want to spend my career answering the same phone call.

If I solved the problem yesterday, I want the organization to be capable of handling it tomorrow.

Document it.

Automate it.

Teach it.

Build monitoring around it.

Create the recovery procedure.

Whatever makes sense.

Then when the phone rings again, I want it to be because there is a new problem.

A harder problem.

A problem we haven’t solved yet.

That is much more interesting.

I don’t want customers to need me because I kept the answer. I want them to call me because the last answer worked.

That Is What a Referral Really Means

When a customer recommends you to someone else, they are doing something significant.

They are lending you part of their reputation.

They are telling someone:

“I trusted this person, and I think you can trust them too.”

That means more to me than almost any title.

You cannot demand that kind of trust.

You earn it.

One decision at a time.

One project at a time.

One promise at a time.

And often one extra fifteen minutes at a time.

The customer remembers whether you made their life easier.

The engineer who follows you remembers whether you left documentation.

The team remembers whether you shared what you knew.

People remember whether your work became a foundation or another problem they eventually had to replace.

Those experiences become your reputation.

Build Something That Does Not Need You

There is an interesting paradox in all of this.

The better I do my job, the less the customer should need me for the thing I just built.

That does not bother me.

It is the goal.

If I build a system that only I can operate, I haven’t created much leverage.

If I automate a process but only I understand the automation, I moved the dependency.

If I document something but nobody can follow the documentation, I haven’t transferred the knowledge.

If I create a platform that requires me to remain standing beside it forever…

I built myself a job.

I did not build an institution.

I would rather build something that works without me.

Then go find the next difficult problem.

Leave More Than a Deliverable

At the end of a project, I want there to be more than a completed task.

I want there to be knowledge.

Standards.

Automation.

Documentation.

Confidence.

Maybe a better engineer than the one who started the project with me.

Maybe a process that no longer requires an engineer at all.

Maybe an architecture the next project can reuse.

Maybe simply a customer who understands their environment better than they did before.

Those are all forms of value.

And unlike the project schedule, they don’t necessarily end when the project closes.

That is why I think of this as building institutions.

An institution is not necessarily a building.

It isn’t necessarily a company.

It is something capable of carrying knowledge, standards, and purpose forward without depending entirely on the people who originally created it.

That is what I want my work to do.

The Reputation I Want

Someday, I will have worked my last project.

Someone else will inherit whatever I was working on.

I hope they don’t need to know my name.

But I hope they can tell something about the person who was there before them.

The documentation makes sense.

The automation works.

The architecture has a reason.

The recovery process has been tested.

The strange decisions are explained.

The easy button is clearly labeled.

And the environment feels like someone cared about the person who would eventually inherit it.

If that is what remains…

I will consider the project successful.

Not because they still need me.

Because they don’t.

And if they ever do call me again, I hope it is for something new.

Something harder.

Something we haven’t solved yet.

Don’t build your reputation by making people depend on you. Build it by leaving behind systems, knowledge, and people strong enough to succeed without you. Then earn the next call by how well the last problem stayed solved.

Principle XL — Enable Others to Succeed

The Multiplier

There is a point in almost every career when being good at your own job is no longer the greatest contribution you can make.

You can solve the problem yourself.

Or you can teach ten people how to solve it.

You can become the highest performer on the team.

Or you can help the entire team perform at a higher level.

Those are different kinds of success.

The first is individual performance.

The second is multiplication.

Your greatest contribution may not be what you accomplish. It may be what other people become capable of accomplishing because you were there.

Gives Good Phone

Long before I became deeply involved in technology, I worked in a call center.

I was good on the phone.

Really good.

I had a natural ability to build rapport with people.

My nickname became:

“Gives Good Phone.”

One of the descriptions I remember hearing was:

“Voice smooth as butter.”

It was funny.

But underneath the jokes was something useful.

I had developed techniques that worked.

I understood how to speak with customers.

I understood pacing.

Tone.

Listening.

Rapport.

How to make a conversation feel natural instead of scripted.

Eventually I was given an opportunity that would teach me something much more important than simply being good on the phone.

I was asked to help other people become good at it too.

A-Bay

New employees went through approximately three weeks of initial training.

Afterward, they still had to make the transition from classroom knowledge to actual customer conversations.

We created a team concept we called “A-Bay.”

The new hires would rotate through this team after completing their training.

We watched their metrics closely every day.

But the metrics were not the real work.

The metrics told us where to look.

The real work was individual coaching.

I would sit with people one on one.

Listen to their calls.

Identify specific problems.

Explain what I was hearing.

Demonstrate techniques.

Listen again.

Adjust.

Repeat.

The coaching was intensive.

It was personal.

And it worked.

The First Group Taught Me How to Teach

The first class gave me an opportunity to refine the process.

Not every coaching technique worked equally well.

Not every new hire struggled with the same thing.

Some needed help with confidence.

Some needed help listening.

Some needed help controlling the conversation.

Some needed help sounding less mechanical.

The important thing was that I was not trying to turn everyone into me.

I was trying to identify what was preventing each person from succeeding.

Then help them remove that obstacle.

That distinction matters.

Enablement is not creating copies of yourself. It is helping people discover how to succeed with the abilities they already possess.

Then Something Unexpected Happened

After the first class allowed me to refine the process, the results became remarkably consistent.

Remember what this team was.

New hires.

People who had just completed training.

Every few weeks, the people I had been coaching would rotate out and another group of new hires would arrive.

We started again.

Yet month after month, the A-Bay team’s metrics remained near the top of the department.

Top three.

Repeatedly.

At one point, number one.

These were not seasoned representatives with years of experience.

They were new employees rotating through every three weeks.

And they were outperforming most of the established teams.

That got people’s attention.

I Wasn’t the Number Two Team

There is an important distinction here.

I wasn’t the number two team.

They were.

I may have built the coaching process.

I may have helped identify the techniques.

I may have watched the metrics and worked individually with the representatives.

But they had to answer the calls.

They had to apply what they learned.

They had to build rapport.

They had to perform.

Their success belonged to them.

My contribution was helping create an environment where their success became more likely.

That was the multiplier.

My Manager Looked Very Good

Naturally, the results reflected well on my direct manager.

His area had a development process producing exceptional results.

But the results also created an uncomfortable comparison.

A rotating group of new hires was outperforming many established teams.

That can create questions.

Why?

What is happening differently?

What techniques are being used?

Can they be repeated?

Those are exactly the questions a healthy organization should ask.

The department head became interested in what we were doing.

I documented the techniques.

The process was no longer just something I knew how to do.

It could be studied.

It could be taught.

It could potentially be reproduced.

That is what enablement should become.

When success depends on a person, you have talent. When the method can be taught and repeated, you have capability.

Six Months of Evidence

This was not one unusually strong group.

The pattern continued.

New people arrived.

We coached them.

They improved.

They rotated out.

Another group arrived.

We did it again.

Month after month.

For approximately six months, the A-Bay team remained among the top-performing teams in the department.

One month, we reached number one.

That consistency mattered more to me than any single month’s ranking.

One exceptional month can happen for many reasons.

Repeated results with constantly changing people suggest something different.

The process was working.

We had created a system for helping people succeed.

Then Leadership Changed

Eventually, the department head was promoted.

One of the floor managers moved into the department head position.

She listened to one of the training calls I was using with the new hires.

Her reaction was extremely complimentary.

She told me how good I was on the phone.

She believed that if I returned to being an individual representative, I could become the number one performer in the department.

She was probably right.

But I thought the conclusion was remarkably short-sighted.

Because the most valuable thing I was doing was no longer being good on the phone.

It was duplicating that ability in other people.

One Great Performer or an Entire Team?

Leadership faced a choice, whether anyone described it that way or not.

Use my skills to produce one exceptional individual performer.

Or use those same skills to help produce an entire team of stronger performers every three weeks.

I was moved back into an individual contributor role.

Someone else took over A-Bay.

The following month, something revealing happened.

I became the number one representative.

A-Bay fell to the bottom of the metrics.

The decision succeeded at exactly what it had optimized for.

It produced one outstanding individual performer.

And the multiplier disappeared.

If you take the person creating ten successful people and make them responsible only for their own success, do not be surprised when you get one success instead of ten.

Don’t Confuse Talent With Leverage

Organizations naturally notice talented individuals.

The best salesperson.

The best engineer.

The fastest troubleshooter.

The person everyone calls when something breaks.

Those people are valuable.

But individual performance and organizational leverage are not the same thing.

If the best engineer can solve ten incidents…

That is useful.

If the best engineer can teach ten engineers how to solve those incidents…

That is leverage.

If the engineer can then eliminate the incident entirely through architecture or automation…

That is even greater leverage.

The higher you progress, the more important this distinction becomes.

Your value should not be measured only by how much work can pass through your hands.

It should also be measured by how much capability you create around you.

Leadership Can Raise or Lower the Ceiling

Managers have tremendous influence over what their teams become.

They can surround themselves with strong people and help those people become stronger.

Or they can become uncomfortable when someone else’s success creates comparison.

They can preserve high standards.

Or they can make the standards easier to meet.

They can ask:

“How do we reproduce what is working?”

Or:

“How do we return things to the way they were?”

I cannot know every reason behind the decisions people made during that period of my career.

And with time, I have learned not to pretend that I do.

What I can evaluate are the results.

A repeatable development system existed.

It produced strong results.

The system was changed.

The results changed with it.

That is enough to teach the lesson.

Enablement Is Not Favoritism

There is another distinction worth making.

Enabling someone to succeed does not mean making success easier to claim.

It does not mean lowering the standard.

It does not mean protecting someone from measurement.

It does not mean giving opportunities only to people you like.

Real enablement does the opposite.

It gives people the tools, knowledge, coaching, feedback, and opportunity necessary to meet a meaningful standard.

Then it lets the results speak.

Helping someone succeed is not lowering the bar. It is giving them a better ladder.

Make Your People Dangerous

The best managers I have worked with were not threatened by capable people.

They wanted them.

They wanted engineers who challenged assumptions.

People who learned quickly.

People who could eventually perform work the manager could not.

People who might someday become managers, principal engineers, architects, directors, or leaders themselves.

That is how organizations grow.

A leader who must remain the most capable person in the room eventually becomes the ceiling of the room.

A leader who develops capable people raises the ceiling.

Your Success Changes as You Grow

Early in your career, success is often measured directly.

Your tickets.

Your sales.

Your code.

Your projects.

Your metrics.

That makes sense.

But as your influence grows, the definition of success should expand.

Did the team improve?

Did someone learn?

Did the process become easier?

Did knowledge spread?

Did the organization become less dependent on one expert?

Did someone succeed because you gave them the opportunity and tools to do so?

Eventually, those questions become more important than your personal scoreboard.

The Lesson I Carried Forward

I learned something important from A-Bay.

Being number one felt good.

But I already knew I could perform.

Watching an entire group of new people become successful was different.

That was far more interesting.

My individual performance had a limit.

There was only one of me.

But knowledge could multiply.

Coaching could multiply.

Standards could multiply.

Confidence could multiply.

And when people I helped became successful, their success could continue long after they stopped working with me.

That lesson eventually followed me into technology.

Teach the engineer.

Document the process.

Share the knowledge.

Build the tool.

Create the opportunity.

Then get out of the way and let people succeed.

The strongest leaders do not prove how much better they are than the people around them. They prove how much better the people around them can become.

Create Capability, Not Dependence

When you become experienced at something, an interesting problem develops.

You become fast.

You recognize patterns sooner.

You know where to look.

You have already made many of the mistakes someone else is about to make.

So when a less experienced person struggles with a problem, the temptation is obvious.

Take the keyboard.

Fix it.

Move on.

Sometimes that is exactly what the situation requires.

But if you do it every time, something else happens.

You become faster.

They remain dependent.

Solving the problem for someone creates an answer. Teaching them how to solve it creates capability.

Resist the Keyboard

Anyone who has mentored engineers knows this feeling.

You are watching someone troubleshoot.

You already see the problem.

They are looking in the wrong place.

They run a command.

Nothing.

They try another theory.

Wrong again.

You know that if you took control, you could probably resolve the issue in five minutes.

Watching them work through it may take thirty.

Those twenty-five minutes can feel incredibly expensive.

Sometimes they are.

During a major production outage, restoring service may matter more than creating a teaching opportunity.

Take the keyboard.

Fix the problem.

Teach afterward.

But not every problem is a production emergency.

Sometimes those extra twenty-five minutes are an investment.

Because if the engineer discovers the answer…

Understands why it worked…

And remembers the reasoning…

You may never need to spend those five minutes again.

Don’t Teach the Command

Teach the thought process.

This is one of the most important distinctions in technical mentoring.

Someone asks:

“What command should I run?”

You can give them the command.

Sometimes that is appropriate.

But the better lesson is often:

“What are you trying to learn from the command?”

What evidence are we looking for?

What hypothesis are we testing?

What would this result tell us?

What would cause us to investigate somewhere else?

The command will eventually change.

The operating system will change.

The platform will change.

The syntax will change.

The reasoning survives.

Procedures help people repeat your answer. Principles help them discover their own.

Ask Before You Answer

One of the easiest ways to enable someone is also one of the simplest.

Ask questions.

“What do you think is happening?”

“What evidence supports that?”

“What changed?”

“What would you check next?”

“What result would prove your theory wrong?”

“What is the risk of this change?”

“What happens if this doesn’t work?”

Questions force thinking.

They reveal understanding.

They expose assumptions.

And they allow you to coach the reasoning instead of merely correcting the result.

The goal is not to make someone guess what is inside your head.

The goal is to help them develop a reliable process inside theirs.

Give People Real Ownership

You cannot enable people while refusing to trust them with meaningful responsibility.

At some point, they need to drive.

Let them lead the troubleshooting call.

Let them write the script.

Let them perform the deployment.

Let them present the architecture.

Let them own the project.

Stay available.

Review the work.

Provide guardrails appropriate to the risk.

But give them something real.

People become capable by doing capable work.

You cannot prepare someone for responsibility while protecting them from responsibility.

Create Safe Places to Fail

Learning requires mistakes.

That does not mean allowing people to recklessly experiment in production.

Good enablement creates places where mistakes are inexpensive.

Development environments.

Labs.

Test accounts.

Sandboxes.

Code review.

Peer review.

Staged deployments.

Rollback procedures.

Feature flags.

Backups.

These are not only technical controls.

They are learning infrastructure.

They allow people to stretch beyond what they already know without making every mistake catastrophic.

The goal is not to eliminate failure.

It is to control the cost of learning from it.

Never Humiliate the Learner

There is an enormous difference between correcting someone and embarrassing them.

Experienced people sometimes forget how much they once did not know.

The answer seems obvious now.

It was not always obvious.

Someone taught us.

Or experience taught us.

Usually through mistakes.

When someone gives the wrong answer, you have a choice.

You can demonstrate how much more you know.

Or you can help them understand what they missed.

Only one of those creates a stronger engineer.

Knowledge used to make someone feel small is not mentorship. It is ego wearing expertise as a costume.

Keep the Bar High

Enabling others does not mean making success easier by changing the definition of success.

That distinction matters.

Suppose someone is expected to meet a meaningful standard.

There are two ways to make their performance look better.

Lower the standard.

Or help them become capable of reaching it.

Only one creates lasting value.

Give them better training.

Better documentation.

Better tools.

Better feedback.

Better examples.

Better opportunities to practice.

Remove unnecessary obstacles.

Then keep the standard.

Enablement removes obstacles to achievement. Favoritism removes accountability for achievement.

Those are not the same thing.

Coach the Person, Not the Metric

Metrics are useful.

A-Bay depended heavily on them.

We watched performance closely because the numbers helped identify where coaching might be needed.

But the metric was never the person.

A number tells you what happened.

It rarely tells you everything about why.

Two people can produce the same weak result for completely different reasons.

One may lack knowledge.

Another may lack confidence.

Another may misunderstand the process.

Another may have the knowledge but struggle to apply it consistently.

If you coach only the metric, you may prescribe the same solution to completely different problems.

Good coaching asks:

“What is preventing this person from succeeding?”

Then addresses that.

Feedback Must Be Specific

“Do better” is not coaching.

“Be more confident” is not coaching.

“Improve your troubleshooting” is not coaching.

Useful feedback identifies something actionable.

“You reached a conclusion before validating the DNS response.”

“You interrupted the customer before they finished describing the symptom.”

“You changed two variables simultaneously, so now we don’t know which one affected the result.”

“You solved the issue correctly, but you didn’t document the recovery steps.”

Now the person has something they can change.

Specific feedback creates specific improvement.

Praise What Should Be Repeated

Feedback should not exist only when something goes wrong.

When someone does something well, tell them what they did well.

Not simply:

“Great job.”

Explain why.

“You stopped before making the change and verified the rollback path.”

“You admitted you didn’t know instead of guessing.”

“You found the root cause instead of stopping when the symptom disappeared.”

“You documented the issue well enough that someone else can repeat the recovery.”

That reinforces behavior.

People learn from correction.

They also learn from knowing which decisions deserve to become habits.

Don’t Create Copies of Yourself

One of the mistakes mentors can make is believing their job is to create smaller versions of themselves.

It isn’t.

The people you teach will have different strengths.

Different personalities.

Different ways of communicating.

Different approaches to problems.

That is valuable.

Give them the principles.

Give them the standards.

Give them the boundaries.

Then allow them to develop their own style.

Someone may eventually discover a better method than yours.

Celebrate that.

If your student surpasses you, the mentorship worked.

Share the Credit

If you enable someone to succeed, let the success belong to them.

Do not stand behind every accomplishment reminding everyone who trained them.

Do not turn their success into another story about yourself.

You may have helped.

You may have coached.

You may have opened the door.

But they walked through it.

Give them visibility.

Let them present their work.

Mention their contribution when they are not in the room.

Recommend them for opportunities.

A leader who creates capable people should not need to compete with them for recognition.

If you helped someone become excellent, their excellence is evidence enough.

Sponsorship Matters Too

Mentorship teaches.

Sponsorship opens doors.

Sometimes someone is ready for the next challenge but does not yet have access to it.

Give them the opportunity.

Invite them to the architecture meeting.

Put them on the project.

Let them lead the presentation.

Recommend them for the role.

Introduce them to people who can help them grow.

Then let them prove themselves.

You are not guaranteeing their success.

You are making sure opportunity is not unnecessarily withheld.

Build Systems That Help People Succeed

Enablement is not limited to coaching.

Engineering itself can enable people.

A clear dashboard enables faster decisions.

A good runbook enables recovery.

Automation enables consistent execution.

Good defaults enable safer deployments.

Documentation enables independence.

Monitoring enables earlier intervention.

A well-designed interface enables people to use complicated technology without becoming experts in every layer beneath it.

This is one reason good engineering and good leadership have so much in common.

Both ask:

“How can I create an environment where success becomes easier to achieve correctly?”

Measure the Multiplier

As engineers become more senior, measuring them only by individual output becomes increasingly incomplete.

How many tickets did they close?

How many lines of code did they write?

How many incidents did they personally resolve?

Those numbers can matter.

But they miss something.

How many incidents no longer occur because of what they built?

How many engineers can now solve problems that previously required escalation?

How much manual work disappeared?

How much knowledge was transferred?

How many people became capable of operating independently?

How many future projects became easier?

The most valuable work may reduce the amount of visible work attributed to the person who created it.

That is the multiplier.

Make Success Portable

The real test of enablement comes when you leave.

Can the person still succeed?

Can the team still perform?

Does the process continue?

Does the knowledge remain?

If success disappears when the mentor disappears, the transfer was incomplete.

The goal is not permanent dependence.

It is independence.

Eventually the person you taught should stop needing you for the things you taught them.

Then perhaps they teach someone else.

Now the multiplier multiplies again.

Closing Thought

You can spend a career proving how capable you are.

Or you can use that capability to create more of it around you.

Teach the reasoning.

Give people ownership.

Create safe opportunities to learn.

Keep the standards high.

Give specific feedback.

Share the credit.

Open doors.

Then step back.

The measure of a great mentor is not how many people need their help. It is how many people no longer need it because they learned how to succeed on their own.

Success Should Spread

The best kind of success does not remain isolated.

It spreads.

One capable person helps another become capable.

That person teaches someone else.

A team improves.

A department improves.

Eventually the organization operates at a higher level because knowledge moved instead of staying trapped.

That is one of the most powerful forms of leverage any leader can create.

Success becomes durable when it stops belonging to one person.

Leadership Is Not Control

Some leaders measure their value by how many decisions pass through them.

Everything requires approval.

Every important conversation includes them.

Every difficult problem waits for them.

At first, this can look like leadership.

Often it is dependence.

The organization moves only as quickly as one person can think.

That does not scale.

Strong leaders create clarity.

They establish standards.

They explain intent.

They give people enough context to make good decisions without asking permission for every step.

Control may produce compliance.

Enablement produces capability.

Give People Context, Not Just Instructions

Instructions tell someone what to do.

Context helps them understand why.

That difference matters.

If I tell someone:

“Use this procedure.”

They may succeed when the situation matches the procedure exactly.

If I explain:

“This is the risk we are controlling, this is the outcome we need, and this is why the procedure works.”

Now they can adapt when reality changes.

Context creates judgment.

Judgment creates independence.

Instructions help people follow the path. Context helps them find the path when the map no longer matches the terrain.

Make Decisions Where the Knowledge Exists

Organizations sometimes push every decision upward.

That creates delay.

The person closest to the work often understands the problem best.

A customer-facing employee hears the customer’s frustration directly.

An engineer troubleshooting the system sees the evidence.

A technician working on the equipment understands the physical reality.

Leaders should define boundaries and risk tolerances.

Then allow informed decisions to happen as close to the problem as practical.

That does not mean removing accountability.

It means placing authority where useful knowledge already exists.

Create Clarity Around the Goal

People struggle when success is vague.

“Improve performance.”

“Make the customer happier.”

“Fix the process.”

Those statements sound useful.

They are difficult to act upon.

Enablement begins with clarity.

What does success look like?

What matters most?

What cannot be compromised?

What tradeoffs are acceptable?

What authority does the person have?

What requires escalation?

Clear goals give people room to think.

Ambiguous goals force people to guess.

Standards Create Freedom

Standards are sometimes viewed as restrictions.

Good standards create freedom.

If everyone agrees on:

  • Security requirements
  • Naming conventions
  • Deployment patterns
  • Documentation expectations
  • Review processes
  • Recovery objectives

Then engineers do not waste energy renegotiating the basics every time.

They can focus on the interesting parts.

Standards remove uncertainty from routine decisions.

That allows creativity to concentrate where it matters.

Leaders Should Create More Leaders

A leader who cannot tolerate another strong leader nearby will eventually weaken the organization.

Strong people should not be treated as threats.

They should be multiplied.

Give them responsibility.

Let them mentor.

Let them lead meetings.

Let them make decisions.

Let them represent the team.

Let them become better than you at things.

That last part can be uncomfortable.

It should also be the goal.

If everyone you teach remains below your level forever, something has gone wrong.

The success of a leader is not proven by having followers. It is proven by creating people capable of leading without them.

Enablement Requires Trust

You cannot enable someone while constantly overriding them.

Eventually you have to let people make decisions.

Sometimes they will choose differently than you would.

That does not automatically make the decision wrong.

There are often several good solutions.

A leader who insists everything must be done exactly their way may produce consistency.

They may also prevent growth.

Set the guardrails.

Define the outcome.

Let people think.

Review the result.

Then teach from what happened.

Allow People to Own Their Wins

One of the easiest ways to destroy motivation is to give someone responsibility and then take all the credit.

If someone led the project, let them present it.

If someone solved the issue, recognize them.

If someone developed the idea, say their name when you discuss it.

If someone improved the process, make sure people know who did the work.

Recognition reinforces ownership.

It also tells the organization something important:

Good work is seen.

Protect People When They Take Responsible Risks

If you want people to make decisions, you have to accept that not every decision will work.

There is a difference between negligence and a reasonable decision that produced an unexpected outcome.

People should be accountable.

They should also be able to learn.

If every mistake becomes punishment, people stop taking responsibility.

They escalate everything.

They hide uncertainty.

They wait for someone else to decide.

A culture that demands independent thinking must tolerate honest mistakes made within reasonable boundaries.

If people are punished every time they exercise judgment, eventually they stop exercising judgment.

Teach Recovery, Not Fear

People become more confident when they know failure is recoverable.

That is true in engineering.

It is true in life.

If the team knows:

We have backups.

We have rollback.

We have testing.

We have peer review.

We have people who will help.

Then they can attempt difficult work responsibly.

Fear creates paralysis.

Recovery creates courage.

One of the best ways to enable someone is to teach them not only how to succeed…

But how to recover when things do not go as planned.

This Applies Far Beyond Work

Enablement is not only a management philosophy.

Parents enable children.

Teachers enable students.

Coaches enable athletes.

Mentors enable careers.

Friends enable confidence.

Communities enable opportunity.

The methods differ.

The principle does not.

Give people the tools.

Give them knowledge.

Give them opportunities.

Give them honest feedback.

Then allow them to become capable.

Parenting Is Probably the Purest Example

A parent’s goal cannot be permanent dependence.

A child begins life completely dependent.

Over time, good parenting transfers capability.

Feed yourself.

Dress yourself.

Make decisions.

Manage money.

Solve problems.

Accept consequences.

Build relationships.

Eventually the child becomes an adult capable of succeeding without constant parental direction.

That independence is not evidence the parent became unnecessary.

It is evidence the parent succeeded.

Mentorship works the same way.

The purpose of guidance is not to remain necessary forever. It is to make independence possible.

Teaching Creates Multipliers

A person can perform one task at a time.

Knowledge can perform many.

Teach one person.

They teach another.

The effect grows.

This is why teaching is one of the most scalable things a human being can do.

The original lesson may continue spreading long after the original teacher is gone.

That is an extraordinary form of leverage.

Do Not Hoard Opportunity

Knowledge is not the only thing people need.

They need chances.

Someone may be capable of leading but never receive the opportunity.

Someone may understand the technology but never be invited into the architecture discussion.

Someone may be ready for the next role but lack visibility.

Enablement means noticing those moments.

Open the door.

Then let them walk through it.

There is no guarantee they will succeed.

That is okay.

Your responsibility was not to guarantee the outcome.

It was to make sure artificial barriers were not preventing the opportunity.

Strong Teams Make Everyone Better

The best teams have a compounding effect.

One person’s strength fills another person’s gap.

Someone teaches.

Someone challenges.

Someone documents.

Someone automates.

Someone asks the question nobody else considered.

Nobody has to be great at everything.

The team becomes strong because capability is shared.

That is a much healthier model than building everything around one indispensable expert.

Measure Yourself Differently

As responsibility grows, your scoreboard should change.

Do not ask only:

“What did I accomplish?”

Ask:

“Who became stronger?”

“What became easier?”

“What knowledge spread?”

“What opportunity did I create?”

“What work can now happen without me?”

“What did someone else accomplish because I helped remove an obstacle?”

Those answers reveal a different kind of success.

Often a more important one.

The Multiplier Is the Legacy

Eventually, every leader leaves.

Every mentor moves on.

Every manager changes roles.

Every parent grows older.

What remains?

If people are helpless without you…

You created dependence.

If people continue learning, deciding, teaching, building, and succeeding…

You created capability.

That is the multiplier.

And unlike individual performance, it can continue long after you stop contributing directly.

Closing Thought

The strongest people do not use their strength to remain above everyone else.

They use it to lift others.

Teach generously.

Set clear standards.

Give real responsibility.

Create safe places to learn.

Share credit.

Open doors.

Then let people surprise you with what they become.

Your success is not diminished when someone you helped becomes better than you. That may be the clearest evidence that you succeeded at all.

Founder’s Commentary

Being Number One Was the Smaller Achievement

There was a time in my career when being the number one performer would have meant everything to me.

Recognition.

Status.

Proof that I was good at what I did.

And when I was moved out of A-Bay and back into an individual contributor role, that is exactly what happened.

I became number one.

By the numbers, that looked like success.

But by then, I had already seen something much more powerful.

I had watched new hires, people with almost no experience, become top performers through coaching, repetition, feedback, and confidence.

I had watched entire groups improve.

Not once.

Repeatedly.

That changed how I thought about success.

One person being number one is impressive.

Helping an entire team become better is leverage.

I Already Knew I Could Perform

By the time leadership moved me back into an individual role, I already knew I was good on the phone.

That wasn’t the question anymore.

I had already proven that.

The more interesting question was:

Could I transfer what I knew?

Could I help someone else recognize the same patterns?

Could I help them build confidence?

Could I help them discover their own way to connect with customers?

A-Bay answered that question.

Yes.

And that felt much more meaningful than another personal metric.

Once you know you can succeed, the next challenge is learning whether you can help someone else succeed too.

The Real Product Wasn’t the Call

At first, I thought my skill was the ability to handle a customer call.

Eventually I realized that was only the visible output.

The more valuable skill was understanding why the call worked.

Tone.

Pacing.

Listening.

Rapport.

Confidence.

Control without sounding controlling.

Making a customer feel heard.

Those were principles.

Once I could explain them, I could teach them.

Once I could teach them, other people could use them.

That was the shift.

The call was no longer the product.

The capability was.

Metrics Showed the Result, Not the Cause

The A-Bay metrics became difficult to ignore.

New hires rotating every few weeks.

Yet the team consistently performed near the top.

That told us something.

The people were changing.

The results were not.

When inputs change but strong results remain consistent, you should look closely at the process.

Something in the system is working.

I wish more organizations understood that.

People often celebrate the top performer.

That is easy to see.

The more interesting question is:

What created the conditions that allowed multiple people to perform well?

That is where scale lives.

I Was Proud of Them

One thing I remember clearly is how satisfying it was watching someone improve.

A new hire would struggle with something.

We would talk through it.

Listen to the call.

Identify the issue.

Try again.

Then something clicked.

Confidence changed.

The conversation changed.

The numbers changed.

There is a different kind of satisfaction in that.

You know the success belongs to them.

You helped.

But they did the work.

That made me proud in a way that my own performance never quite did.

Leadership Can Multiply or Compress Talent

The decision to move me back into an individual role taught me another lesson.

Organizations can use talent in very different ways.

You can take someone who performs exceptionally well and ask them to produce exceptional individual results.

There is nothing wrong with that.

Or you can ask:

How do we spread what this person knows?

How do we reproduce the behavior?

How do we build the process?

How do we make the knowledge portable?

Those questions create different outcomes.

The first concentrates talent.

The second multiplies it.

Leadership decides whether talent remains concentrated in individuals or becomes capability across the organization.

I Don’t Need to Know Why the Decision Was Made

At the time, I had plenty of opinions about why leadership made the change.

Maybe there were politics.

Maybe some managers disliked the comparison.

Maybe the department wanted to return to a familiar model.

Maybe the new leader genuinely believed moving me to an individual role was the best use of my skills.

I cannot know that with certainty.

And after enough years, I have learned not to build lessons on motives I cannot prove.

The outcome is enough.

The development model changed.

I became number one.

A-Bay fell to the bottom of the metrics.

That contrast taught me everything I needed to learn.

Enablement Is Not Lowering the Bar

Another lesson stayed with me.

Helping people succeed does not mean making success easier to claim.

The standard still matters.

A-Bay worked because we watched the metrics closely.

People knew what good performance looked like.

We didn’t lower expectations.

We improved the path toward meeting them.

That distinction matters in every form of leadership.

Give people tools.

Training.

Context.

Feedback.

Opportunity.

Then let them meet the standard.

If the standard disappears, you have not enabled success.

You have changed the definition of success.

Those are not the same thing.

Do Not Become the Ceiling

One of the most dangerous things a leader can do is require everyone else to remain less capable than they are.

That creates a ceiling.

The team can never become stronger than the person at the top is comfortable allowing.

I never want that.

I want to work with people who know things I don’t.

People who challenge me.

People who eventually become better than me at areas I helped introduce them to.

That is not a threat.

That is the point.

If I teach someone and they eventually exceed my ability…

Good.

Now the organization has something it didn’t have before.

The Keyboard Lesson

I see the same pattern in technology all the time.

An engineer asks for help.

You know the answer.

You can take the keyboard.

Fix the issue.

Everyone moves on.

Or you can slow down.

Ask questions.

Let them investigate.

Let them make the decision.

Explain what they missed.

That takes longer.

Today.

But tomorrow, they may not need you.

That is the trade.

Short-term speed for long-term capability.

There are times when I will absolutely take the keyboard.

Production is down.

The customer is losing money.

We need recovery now.

But after the emergency…

Teach.

Explain.

Document.

Make sure the next call does not require the same rescue.

The Best Managers Made Me Bigger

When I think about the best managers and mentors I have had, they shared something important.

They expanded what I believed I could do.

They gave me difficult problems.

They trusted me.

They let me make decisions.

They challenged my thinking.

They gave me enough room to fail without allowing the failure to become catastrophic.

They didn’t need me to remain below them.

They wanted me to grow.

That is the kind of leader I try to be.

Share the Knowledge Freely

Knowledge should not be used as leverage over people.

I have never believed in hiding answers to remain indispensable.

If I know something that helps someone…

I share it.

If I have a script…

I give it to them.

If I know the shortcut…

I explain it.

If I understand why something works…

I teach the why.

The more people who can solve the problem, the stronger the organization becomes.

And the more interesting the next problem I get to work on becomes.

That seems like a much better bargain than spending a career protecting yesterday’s expertise.

The Goal Is Independence

Mentorship should eventually make the mentor unnecessary for that problem.

That can feel strange.

Someone used to ask you questions every day.

Then every week.

Then once in a while.

Eventually they stop asking.

That is not a loss.

That is success.

They learned.

They grew.

They became independent.

Maybe now other people are asking them.

The multiplier continued.

The moment someone no longer needs your help may be the moment your help proved most successful.

A-Bay Followed Me Into Engineering

I didn’t realize it at the time, but A-Bay shaped the way I eventually approached technology.

Documentation.

Automation.

Runbooks.

Training.

Mentorship.

Standards.

The easy button.

They are all forms of enablement.

Every one asks the same question:

How do I take something that currently requires specialized knowledge and make more people capable of succeeding with it?

That is what I was doing in that call center long before I knew I would spend decades in IT.

The technology changed.

The lesson did not.

The Scoreboard Changed

Early in my career, I cared about my number.

My performance.

My ranking.

My result.

I still believe in performing well.

Standards matter.

Results matter.

But the scoreboard became larger.

Now I also care about:

Who learned?

Who grew?

Who became more confident?

What can the team do now that it could not do before?

What no longer needs escalation?

What knowledge survived?

Who is ready for the next opportunity?

Those questions tell me far more about leadership than an individual ranking ever could.

Number One

I became the number one representative after leaving A-Bay.

I remember that.

But it is not the part of the story I value most.

What I remember most is that a rotating team of brand-new employees could compete with seasoned teams because someone invested in helping them succeed.

That taught me something I have carried for the rest of my career.

Being the best person on the team is useful.

Making the team better is more powerful.

And making people capable of succeeding after you are gone may be the most powerful contribution of all.

I was proud when I became number one. I was prouder when people I taught became successful without me. One proved what I could do. The other proved what I could multiply.

Principle XLI — Curiosity Never Ends

Never Stop Asking Why

Nearly everything interesting I have ever learned began with a question.

Why?

How?

What happens if?

What am I missing?

Could this be done differently?

What is actually happening underneath this?

Those questions are simple.

Children ask them naturally.

Somewhere along the way, many adults learn to stop.

Experts are especially vulnerable.

The more we know, the easier it becomes to believe we already understand.

That is dangerous.

Expertise should give you better questions, not fewer of them.

Curiosity Built the Engineer

Every engineer begins by not knowing.

The first computer.

The first program.

The first network.

The first database.

The first server.

The first failure.

At some point, something captured our attention.

We wanted to understand it.

So we opened it.

Changed it.

Broke it.

Fixed it.

Read about it.

Asked someone.

Tried again.

Curiosity came before expertise.

Expertise was simply what accumulated because curiosity kept asking questions.

“I Don’t Know” Is Where Curiosity Begins

Earlier in this book, I argued that admitting what you don’t know is a strength.

This is why.

“I don’t know” is not the end of the conversation.

It is the beginning of discovery.

I don’t know.

Let’s find out.

That second sentence changes everything.

The dangerous engineer is not the person who lacks an answer.

It is the person who has stopped looking for one.

Ignorance is temporary when curiosity survives it.

Do Not Let Experience Become Certainty

Experience is valuable.

It gives us patterns.

Instinct.

Context.

Judgment.

But experience can create another problem.

We begin recognizing situations so quickly that we stop investigating them.

“I’ve seen this before.”

Usually, that is useful.

Sometimes, it is exactly how we miss the thing that is different this time.

The symptoms may look familiar.

The cause may not be.

Use experience to form the hypothesis.

Use curiosity to test it.

Ask What Changed

One of the most useful troubleshooting questions in technology is remarkably simple:

What changed?

A system worked yesterday.

It does not work today.

Something changed.

Maybe the code.

Maybe the network.

Maybe the certificate.

Maybe the permissions.

Maybe the data.

Maybe the dependency.

Maybe the environment.

Maybe something nobody realized was connected.

Curiosity follows the evidence.

It does not become emotionally attached to the first explanation.

Look Underneath the Abstraction

Modern technology makes extraordinary complexity appear simple.

Click the button.

Call the API.

Deploy the container.

Run the query.

Open the application.

Most of the time, that is exactly what we should do.

Abstraction allows us to build enormous systems without understanding every transistor underneath them.

But occasionally the abstraction leaks.

Then curiosity matters.

What is the button actually doing?

Where does the request go?

What happens when the API fails?

Where is the data stored?

What assumption is the framework making for us?

What exists underneath the easy button?

You do not need to understand everything all the time.

You should remain willing to understand more when the problem demands it.

Curiosity and Humility Are Partners

Curiosity requires humility.

You cannot genuinely ask a question while believing you already possess every answer.

The sentence:

“What am I missing?”

contains an assumption.

There may be something I do not see.

That is humility.

And it is one of the reasons curious engineers continue growing long after others plateau.

They remain teachable.

Ask the Junior Engineer

Sometimes the person with the least experience asks the most important question.

“Why do we do it this way?”

The experienced people answer:

“Because that’s how we’ve always done it.”

That sentence should make you curious.

Maybe there is an excellent reason.

Find it.

Maybe the reason disappeared five years ago.

Find that too.

New people have an advantage.

They have not yet learned which assumptions everyone else stopped questioning.

Listen to them.

Fresh eyes often see the assumptions experience has learned to ignore.

Read the Error

Curiosity is often less glamorous than people imagine.

Sometimes it simply means reading.

The error message.

The log.

The documentation.

The source code.

The release notes.

The configuration.

The packet capture.

The query plan.

The evidence is frequently sitting directly in front of us.

Curiosity is the willingness to keep looking until the evidence makes sense.

Break Things Where Breaking Is Safe

Some lessons are difficult to learn by reading.

Build the lab.

Create the test environment.

Change the setting.

Stop the service.

Delete the test resource.

Restore it.

Introduce latency.

Remove the permission.

See what happens.

Controlled failure teaches systems in ways diagrams cannot.

The important word is controlled.

Curiosity without judgment creates incidents.

Curiosity with guardrails creates understanding.

The Rabbit Hole Still Exists

Curiosity has a weakness.

We already discussed it.

Rabbit holes.

Every answer reveals three more questions.

Every dependency reveals another dependency.

Every interesting discovery invites another hour of investigation.

That does not mean curiosity is bad.

It means curiosity requires discipline.

Principle XXXVII was not:

“Stop exploring.”

It was:

“Solve Real Problems.”

The distinction matters.

You can write the interesting question down.

Return to it later.

Experiment in the lab.

Research it after the project is finished.

Curiosity does not require abandoning responsibility.

Curiosity chooses the questions. Judgment decides which ones deserve today’s attention.

Learn Outside Your Lane

Some of the most valuable ideas come from crossing boundaries.

A database engineer learns networking.

A network engineer learns security.

A developer learns operations.

An operations engineer learns programming.

A technical leader studies psychology.

An engineer studies business.

A scientist studies history.

A teacher studies technology.

Fields that appear unrelated often contain patterns that transfer.

The broader your curiosity becomes, the larger your library of possible solutions becomes.

Ask Better Questions

Early questions are often broad.

“Why doesn’t it work?”

Experience improves them.

“Which layer is failing?”

“What evidence would distinguish these two causes?”

“What assumption must be true for this design to work?”

“What happens when that assumption stops being true?”

“What would prove me wrong?”

Better questions reduce the distance to useful answers.

That is one of the ways expertise and curiosity reinforce each other.

Knowledge helps you ask better questions.

Better questions create more knowledge.

Technology Will Not Wait for You

Technology changes too quickly for anyone to declare themselves finished.

The tools you master today will change.

Platforms will disappear.

Languages will evolve.

Architectures will shift.

Security assumptions will be challenged.

New capabilities will make old limitations irrelevant.

Some things you spent years learning will eventually become obsolete.

That is not wasted knowledge.

You learned how to learn.

That skill survives every platform.

The most durable technical skill is the ability to become a beginner again.

Stay Willing to Be a Beginner

Being a beginner becomes harder as your career advances.

People expect you to know things.

You expect yourself to know things.

Then you encounter something completely unfamiliar.

Good.

That feeling is valuable.

Read.

Ask questions.

Experiment.

Make mistakes somewhere safe.

Let someone younger teach you.

Let someone with less seniority know something you do not.

Your title does not require omniscience.

It should give you enough confidence to learn without pretending.

Curiosity Creates the Future

Every improvement begins with dissatisfaction about something we currently accept.

Why does this take twenty steps?

Why can’t this be automated?

Why does this fail every month?

Why do we need this dependency?

Why can’t the customer do this themselves?

Why are we solving the same incident again?

Why not?

That last question has built an extraordinary amount of the world.

Someone looked at an accepted limitation and became curious enough to challenge it.

There Is Always Another Question

After decades of working with technology, I know more than I did when I started.

I also know how much more there is to understand.

Every answer exposes another layer.

Every system connects to another system.

Every solution creates new possibilities.

That does not discourage me.

It is what keeps engineering interesting.

There will always be another problem.

Another technology.

Another mystery.

Another person who knows something I don’t.

Another question worth asking.

Good.

I hope that never changes.

The day you stop being curious is not the day you finally know enough. It is the day you stop discovering how much more there is to learn.

Follow the Question

Curiosity becomes valuable when it changes what you do.

Anyone can wonder.

Engineers investigate.

We form a theory.

Gather evidence.

Test the theory.

Discover that we were wrong.

Change the theory.

Test again.

That process may look less elegant than having the answer immediately.

It is also how many real answers are found.

Curiosity asks the question. Discipline follows it until the evidence answers.

Start With What You Know

When something fails, separate what you know from what you think.

These are not the same thing.

We know the application returned an error.

We think the database is slow.

We know authentication failed.

We think the password is wrong.

We know the server stopped responding.

We think the network dropped.

That distinction sounds small.

It is enormous.

Facts are evidence.

Theories are explanations for evidence.

Confusing the two is one of the fastest ways to spend hours solving the wrong problem.

Write Down the Assumption

Every system contains assumptions.

The DNS record resolves correctly.

The certificate is valid.

The service account still has permission.

The route exists.

The dependency is available.

The data has the expected format.

The clock is correct.

The configuration matches production.

Most of the time, these assumptions are true.

That is why they become invisible.

When troubleshooting becomes difficult, make them visible again.

Ask:

“What must be true for this to work?”

Then test those things.

The Most Dangerous Assumption Is the One Everyone Shares

A team can collectively be wrong.

In fact, agreement can sometimes make an incorrect assumption harder to discover.

Everyone “knows” the network is fine.

Everyone “knows” the application didn’t change.

Everyone “knows” that account has access.

Everyone “knows” the backup works.

Until someone checks.

Curiosity gives you permission to verify what everyone believes.

Not because you distrust the people.

Because systems do not care what people believe.

Consensus is not evidence. Verify the assumption that would hurt most if everyone were wrong.

Ask What Would Prove You Wrong

One of the best questions in troubleshooting is:

“What evidence would prove my theory wrong?”

This protects us from falling in love with our own explanation.

If I believe the network is causing the problem, what result would demonstrate that the network is working correctly?

If I believe CPU is the bottleneck, what measurement would make me investigate somewhere else?

If I believe a deployment caused the failure, what evidence would eliminate it?

A theory that cannot survive attempts to disprove it is not much of a theory.

Curiosity should attack its own conclusions.

Change One Thing at a Time

When people become frustrated, they often begin changing everything.

Restart the service.

Change the configuration.

Update the package.

Clear the cache.

Reboot the server.

Reset the account.

And suddenly…

It works.

What fixed it?

Nobody knows.

The immediate problem may be gone.

The understanding is gone too.

Controlled investigation changes one meaningful variable when practical and observes the result.

That takes patience.

It also preserves the lesson.

If you change everything at once, you may restore the system while destroying your ability to learn why it failed.

Reproduce Before You Repair

When practical, reproduce the problem.

Can you make it happen again?

Under what conditions?

Does it happen for every user?

Every server?

Every request?

Every dataset?

Every location?

Every time?

Intermittent failures are difficult precisely because the triggering condition is hidden.

Reproduction helps expose it.

A reproducible problem is usually much closer to becoming an understood problem.

Reduce the Problem

Large systems create large search spaces.

Reduce them.

Does the problem exist without the load balancer?

Without the application?

Against the database directly?

With a different account?

From another network?

Using a known-good file?

Against a single node?

Each test removes possibilities.

Eventually the giant mysterious system becomes a much smaller problem.

Curiosity does not mean randomly exploring everything.

It means narrowing intelligently.

Compare Good With Bad

One of the fastest ways to learn why something fails is to find something similar that works.

Working server versus failing server.

Working account versus failing account.

Yesterday’s configuration versus today’s.

Development versus production.

Successful request versus unsuccessful request.

What is different?

Sometimes the difference looks irrelevant.

Do not dismiss it too quickly.

The strange difference may be the clue.

Follow the Evidence Across Boundaries

Problems rarely respect organizational charts.

The application team may believe it is a network problem.

The network team may believe it is an application problem.

The database team may believe it is storage.

Storage may believe it is the operating system.

The customer does not care.

The system is failing.

Follow the evidence wherever it goes.

Across teams.

Across technologies.

Across layers.

Across ownership boundaries.

Principle XXXI told us to own the outcome.

Curiosity tells us how.

The root cause does not care which team owns the ticket.

Look Where Nobody Is Looking

Difficult problems often survive because everyone keeps investigating the same places.

The obvious logs have been checked.

The normal metrics look fine.

The common causes have been eliminated.

Good.

Now the investigation becomes interesting.

What are we not measuring?

What happens immediately before the failure?

What external dependency exists?

What changed outside the system?

What assumption have we never verified?

What component is so reliable that nobody thought to check it?

Curiosity expands the search only after evidence justifies expanding it.

Time Is Evidence

When did the problem begin?

Not approximately.

As precisely as possible.

2:17 PM.

Good.

What happened at 2:17 PM?

Deployment?

Certificate renewal?

Scheduled task?

Backup?

Network change?

Authentication event?

Resource spike?

Dependency failure?

Human action?

Logs from different systems become dramatically more useful when aligned by time.

A timestamp can connect events that otherwise appear unrelated.

Absence Is Evidence Too

Sometimes the clue is what did not happen.

A scheduled job never started.

A request never reached the server.

A log entry was never written.

A replication event never arrived.

A health check never returned.

The absence of an expected event helps locate where the chain broke.

Ask not only:

“What happened?”

Ask:

“What should have happened next?”

Then determine why it didn’t.

Read Beyond the First Error

The loudest error is not always the root cause.

A service crashes because a dependency failed.

The dependency failed because authentication expired.

Authentication failed because time drifted.

The application reports:

“Service unavailable.”

True.

Not useful enough.

Curiosity walks backward through the chain.

What caused this?

And what caused that?

And what allowed that condition to exist?

Eventually you stop treating the symptom and reach something worth fixing.

Five Whys Are Not Magic

Asking “why” repeatedly can be useful.

It can also become mechanical.

Real systems do not always have a single straight chain of causation.

Failures can involve several conditions interacting.

A capacity limit.

A configuration change.

An unusual workload.

Missing monitoring.

An incomplete rollback.

None alone may have caused the incident.

Together they did.

Curiosity should seek understanding, not force reality into a convenient template.

Know When You Have Enough Evidence

Investigation can continue forever.

There is always another log.

Another dependency.

Another theory.

Another layer.

At some point, you have enough evidence to act.

That requires judgment.

Can we explain the failure?

Can we reproduce or reasonably account for it?

Does the proposed fix address the cause?

Can we validate the result?

Can we recover if we are wrong?

If yes, act.

Curiosity should improve decisions.

It should not become an excuse to avoid them.

Preserve the Discovery

A difficult problem solved but not documented becomes someone else’s difficult problem later.

Write down:

The symptom.

The evidence.

The misleading clues.

The root cause.

The fix.

The validation.

The lesson.

This is where curiosity connects directly to Principle XXXVIII.

Make It Better Than You Found It.

Do not merely leave behind a working system.

Leave behind understanding.

Discovery that remains only in your head dies when your memory, role, or availability changes.

Automate the Question

Sometimes the investigation reveals something we should never need to investigate manually again.

We checked disk space.

Monitor it.

We checked certificate expiration.

Alert on it.

We compared configuration drift.

Detect it automatically.

We queried replication health.

Schedule the check.

We discovered a recurring pattern in logs.

Build detection for it.

The best investigation may produce a question the system learns to ask for us.

Curiosity Improves Design

Curiosity should begin before failure.

What happens if this server disappears?

What happens if the API becomes slow?

What happens if the credential expires?

What happens if the customer doubles their workload?

What happens if someone enters unexpected data?

What happens if the deployment fails halfway through?

What happens if the backup cannot be restored?

These questions sound pessimistic.

They are not.

They are design tools.

Curiosity imagines conditions the happy path would prefer to ignore.

Ask the Uncomfortable Question Early

Some questions become expensive when delayed.

Do we actually need this?

Who will support it?

How will we recover it?

What does this dependency cost?

What happens when the person who built it leaves?

Does the customer understand the limitation?

Are we solving the real problem?

Can we prove the backup works?

Is this secure?

The earlier those questions are asked, the cheaper the answers usually are.

Curiosity Needs Courage

Not every question is comfortable.

Sometimes curiosity discovers that the architecture is wrong.

The project assumption is wrong.

The documentation is wrong.

The metric is misleading.

The accepted explanation is unsupported.

Your own design is the problem.

Then curiosity requires something more.

Integrity.

Principle XXIX was Truth Over Comfort.

If the evidence contradicts what we wanted to believe, the evidence wins.

Especially when the mistake is ours.

Curiosity without honesty searches only until it finds the answer it wanted.

Share the Mystery

You do not have to solve everything alone.

Sometimes the fastest path forward is:

“I don’t understand this. Can you look at it with me?”

Another person sees a pattern you missed.

They ask a question you never considered.

They have experience you do not.

Curiosity is collaborative.

A room full of people honestly trying to understand a problem is far more powerful than a room full of people trying to prove they were right.

Teach People How You Investigate

When mentoring, do not show only the final answer.

Show the path.

“I checked this because…”

“This result eliminated…”

“I expected this, but instead we saw…”

“That made me question…”

“This evidence changed my theory…”

That teaches something far more valuable than the solution to one incident.

It teaches how to approach the next mystery.

Keep a Beginner Nearby

Beginners ask inconvenient questions.

Good.

They ask why a process has twelve steps.

Why two systems contain the same data.

Why the name makes no sense.

Why something must be done manually.

Why everyone ignores a warning.

Experienced people often stop seeing these things because we have adapted to them.

The beginner has not.

Do not dismiss the question because the person lacks experience.

Investigate whether the question exposed something experience taught everyone else to tolerate.

Curiosity Is a Practice

Curiosity is not merely a personality trait.

It is something you practice.

Read outside the immediate problem.

Build things you do not know how to build.

Talk to people outside your specialty.

Study failures.

Study successes.

Ask why.

Test assumptions.

Change your mind.

Remain interested.

The world is far too complicated to run out of things worth understanding.

Closing Thought

The mature engineer does not need to have every answer.

They need something more durable.

The willingness to investigate.

The discipline to follow evidence.

The humility to change their mind.

The judgment to know when to act.

And the curiosity to ask the next question after everyone else believes the problem is already understood.

Do not measure your expertise by how quickly you can say, “I know.” Measure it by how skillfully you can discover the truth when you don’t.

Stay Interested

Curiosity is larger than engineering.

It is a way of moving through the world.

There are people you have not met.

Places you have not seen.

Ideas you have not considered.

Skills you have never attempted.

Books you have not read.

Questions nobody has answered.

And perspectives you may never encounter unless you deliberately go looking for them.

A curious life remains unfinished.

That is not a flaw.

It is the opportunity.

There is always more world than there is time to understand it. Stay interested.

Be Curious About People

People are complicated systems too.

We see behavior.

We infer motive.

That inference is often where trouble begins.

Someone disagrees with us.

Why?

Someone reacts unexpectedly.

Why?

Someone approaches the same problem differently.

Why?

It is easy to substitute judgment for investigation.

“They don’t understand.”

“They don’t care.”

“They’re difficult.”

“They’re wrong.”

Maybe.

Or maybe we are missing context.

Ask.

Listen.

Understanding another person’s reasoning does not require agreeing with their conclusion.

It simply means being interested enough to understand how they arrived there.

Curiosity Makes Better Conversations

Most arguments are structured around responses.

While the other person is speaking, we prepare ours.

We identify the flaw.

Construct the rebuttal.

Wait for our turn.

Curiosity changes the objective.

Instead of asking:

“How do I prove my point?”

Ask:

“What does this person see that I don’t?”

Now disagreement becomes information.

Maybe they are wrong.

Maybe you are wrong.

Maybe both of you hold different pieces of the answer.

You cannot discover that while waiting only for your turn to speak.

Listen to understand the argument before deciding how to answer it.

Ask Before You Assume Motive

We rarely have direct access to another person’s intentions.

Yet we assign motives constantly.

They did that because…

They said that because…

They want…

They don’t care about…

Sometimes our interpretation is correct.

Sometimes it is a story we created from incomplete evidence.

Curiosity creates a pause.

“What else could explain this?”

That question can prevent unnecessary conflict.

It can also reveal problems that accusation would have hidden.

Learn From People You Disagree With

Agreement is comfortable.

Disagreement can be educational.

You do not need to adopt someone’s conclusions to learn from their reasoning.

Ask what evidence they consider important.

Ask which assumptions they are making.

Ask what experiences shaped their position.

Ask what would cause them to change their mind.

Then ask yourself the same questions.

If your position is strong, examination will strengthen it.

If it is weak, examination gives you an opportunity to improve it.

Either result is useful.

Changing Your Mind Is Not Losing

People sometimes defend old conclusions because changing them feels like admitting defeat.

It isn’t.

If new evidence changes your understanding, updating your conclusion is exactly what rational thinking should produce.

The alternative is much worse.

Imagine discovering better evidence and deliberately keeping the worse answer because you already said it publicly.

That is not consistency.

That is pride.

Changing your mind because the evidence improved is not weakness. It is evidence that your thinking still works.

Do Not Turn Opinions Into Identity

The more tightly an idea becomes attached to identity, the harder it becomes to question.

If changing an opinion feels like changing who you are, curiosity becomes threatening.

Separate yourself from the conclusion.

You are not your architecture.

Your programming language.

Your methodology.

Your theory.

Your favorite technology.

Your old decision.

Those are things you currently believe or prefer.

They can change.

You remain.

That freedom makes learning much easier.

Learn Something You Are Bad At

Expertise is comfortable.

Beginners are clumsy.

That is one reason adults sometimes stop learning completely new things.

We become accustomed to competence.

Then suddenly we are terrible again.

Good.

Learn the instrument.

Try the language.

Build the furniture.

Write the story.

Cook something unfamiliar.

Study mathematics you never understood.

Take apart something you have never repaired.

Ask the embarrassing question.

Being bad at something new reminds you what learning feels like.

It also makes you more patient with everyone who is still learning what you already know.

Read Outside Your Profession

An engineer who reads only engineering eventually limits the material available to their imagination.

Read history.

Science.

Economics.

Psychology.

Biographies.

Philosophy.

Fiction.

Art.

Business.

Medicine.

Architecture.

Learn how other disciplines think.

A problem in one field may resemble a problem solved centuries ago in another.

Human beings reuse patterns constantly.

Different vocabulary can hide remarkably similar ideas.

Curiosity crosses the vocabulary.

Study How We Got Here

The present makes more sense when you understand what came before it.

Technologies have histories.

Organizations have histories.

Processes have histories.

Ideas have histories.

Many strange decisions were once reasonable responses to conditions that no longer exist.

If you understand the original problem, you can make a better decision about whether the old solution still belongs.

Without history, we inherit rules.

With history, we inherit context.

Before calling an old decision foolish, understand the world in which it was made.

Ask Why the Rule Exists

Rules can encode lessons.

Sometimes expensive ones.

A strange security requirement may exist because someone was compromised.

A review process may exist because a deployment once failed catastrophically.

A checklist item may represent an accident nobody wants repeated.

Do not casually remove something simply because you do not understand it.

First ask why it exists.

Then investigate whether that reason still applies.

Curiosity protects us from two opposite mistakes:

Blindly preserving obsolete rules.

And blindly removing useful ones.

Look Back at Your Own Work

Curiosity should occasionally point backward.

Open something you designed five years ago.

Would you build it the same way today?

Probably not.

That is good.

It means you learned.

Do not be embarrassed by every old mistake.

Study it.

What did you believe then?

What did you not know?

What experience changed your thinking?

What would you teach your younger self?

Your own history is a dataset.

Use it.

Let Younger People Teach You

Years of experience provide enormous value.

They do not provide exclusive ownership of good ideas.

Someone entering the field today has learned in a different environment.

Different tools.

Different assumptions.

Different abstractions.

Different possibilities.

They may see a solution that would never occur to you.

Let them show you.

Seniority should increase your ability to recognize good ideas.

It should not increase your need to be the source of them.

Experience should make you easier to teach, because experience has already shown you how often certainty eventually becomes obsolete.

Let Older People Teach You Too

The opposite mistake happens just as easily.

New does not automatically mean better.

People who have been solving problems for decades carry lessons that may not appear in documentation.

They remember why certain safeguards exist.

They recognize failure patterns.

They have watched fashionable ideas disappear and return with different names.

Ask them what they learned.

Ask about the failures.

Ask what they would do differently.

Experience is expensive knowledge.

When someone is willing to share it, listen.

Curiosity Connects Generations

The younger person asks:

“Why do we still do this?”

The experienced person asks:

“What happens if we stop?”

That can be an excellent conversation.

One challenges assumptions.

The other supplies history.

Together they may discover a better answer than either would have produced alone.

Curiosity turns difference into collaboration.

Travel Without Moving

You will never visit every place.

Meet every person.

Experience every life.

But human beings discovered something extraordinary.

We can preserve experience.

Books.

Letters.

Research.

Stories.

Music.

Film.

Art.

Recorded conversations.

Documentation.

Someone can spend thirty years learning something and leave enough evidence for you to begin understanding it in an afternoon.

That does not replace experience.

But it gives curiosity reach far beyond one lifetime.

Ask Questions Without Immediate Utility

Not every question needs a business case.

Some things are worth learning because they are interesting.

How does that work?

Why does that happen?

Who discovered it?

What would happen if?

Curiosity sometimes produces value years after the original question.

Sometimes it produces no measurable value at all.

That is okay too.

A life optimized exclusively for immediate utility becomes very small.

Wonder deserves some room.

Protect Wonder

Children can spend an hour investigating something adults walk past without noticing.

A bug.

A rock.

A machine.

A shadow.

A strange sound.

Adults become efficient.

We learn what deserves attention.

That is useful.

It can also make the world invisible.

Occasionally stop.

Look.

Ask.

How does that work?

Why is it shaped that way?

Who built it?

What happened here?

You do not need to turn every observation into a project.

Sometimes noticing is enough.

Curiosity Requires Time

You cannot explore everything while moving at maximum speed.

Some understanding requires sitting with a problem.

Reading beyond the summary.

Following the footnote.

Testing another possibility.

Talking with someone longer than necessary.

Thinking.

Efficiency matters.

But a life with no room for exploration eventually optimizes away discovery.

Leave some unscheduled space for questions whose value you cannot predict yet.

Be Careful What You Think You Know

One of the strange effects of learning is discovering how simplified many early explanations were.

The simple explanation was not necessarily wrong.

It was appropriate for the level of understanding at the time.

Then another layer appeared.

And another.

This should make us cautious.

Some things we confidently understand today may eventually reveal deeper layers too.

That does not mean nothing can be known.

It means knowledge should remain open to refinement.

Certainty Should Be Earned

Different claims deserve different levels of confidence.

Some things are well established.

Some are probable.

Some are plausible.

Some are speculation.

Curiosity respects those differences.

Say:

“I know.”

“I think.”

“The evidence suggests.”

“I don’t know.”

Those are not interchangeable statements.

Precision about uncertainty is part of intellectual honesty.

Ask Better Questions of Yourself

Curiosity should not point only outward.

Why did that bother me?

Why am I avoiding this?

Why am I defending this decision so strongly?

Why do I want this answer to be true?

What am I afraid of discovering?

What would I do differently if nobody were watching?

What am I pretending not to know?

Those can be uncomfortable questions.

They can also be useful ones.

Systems are not the only things that benefit from honest investigation.

Curiosity Makes Humility Easier

The larger your understanding becomes, the easier it should be to see its boundaries.

Every field contains specialists who have spent entire careers studying a tiny portion of reality.

Then another specialist spent a career studying the layer underneath that.

And another studied the history.

And another studied the consequences.

There is too much to know.

That should not make us feel inadequate.

It should make us grateful that other people know things we do not.

We need each other.

Never Graduate From Learning

School eventually ends.

Training classes end.

Certifications expire.

Projects finish.

Careers change.

Learning should continue.

You do not need a classroom.

You need a question.

Find something you do not understand.

Begin there.

Read.

Ask.

Experiment.

Listen.

Build.

Fail.

Try again.

Then teach what you learned.

And find another question.

The World Is Still Interesting

After enough years, it is easy to become cynical.

You’ve seen the bad architecture.

The failed project.

The repeated mistake.

The unnecessary meeting.

The technology that promised to change everything.

Then another new idea appears.

It is tempting to dismiss it before looking.

Resist that.

Skepticism is useful.

Cynicism is lazy.

Ask whether there is something genuinely new.

Maybe there isn’t.

Sometimes there is.

Stay curious enough to find out.

There Will Never Be a Final Answer

That may sound strange in a book called Solve for 42.

But I think it belongs here.

We want answers.

We build models.

Create principles.

Develop systems.

Write documentation.

Pass knowledge forward.

And then reality gives us another question.

That is not failure.

That is life.

Every generation inherits answers from the one before it.

Then discovers questions those answers could not anticipate.

The work continues.

Closing Thought

Do not allow knowledge to make the world smaller.

It should make the world larger.

Every answer should reveal more connections.

More possibilities.

More people worth listening to.

More assumptions worth examining.

More things worth understanding.

Stay teachable.

Stay willing to change your mind.

Stay willing to become a beginner.

Stay interested.

Curiosity is not the search for one final answer. It is the decision to remain open to the next question for as long as you are capable of asking it.

Founder’s Commentary

I Still Want to Know

I have spent a large part of my life asking questions.

Some of them were important.

Some were probably ridiculous.

Some turned into projects.

Some turned into careers.

Some led me down rabbit holes that consumed far more time than they deserved.

And some changed the way I understood everything that came after them.

I don’t regret asking.

Curiosity has been one of the constants of my life.

I still want to know.

“I Don’t Know” Has Never Been the Problem

There are an extraordinary number of things I don’t know.

That list has not become shorter as I have gotten older.

It has become more visible.

When I was younger, knowing a little sometimes made me feel like I understood a lot.

Experience corrected that.

Every layer I learned revealed another layer underneath it.

Every specialty introduced me to people who knew vastly more about some part of it than I did.

Every difficult problem reminded me that systems are usually more complicated than the first explanation suggests.

Eventually, “I don’t know” stopped feeling like a problem.

The important question became:

What do I do next?

For me, the answer is usually:

Let’s find out.

There is no shame in not knowing. The opportunity begins with what you do after you realize you don’t.

I Have Always Wanted to Look Underneath

I have never been particularly satisfied with:

“It works.”

I want to know why it works.

What is underneath it?

What talks to what?

Where does the data go?

What happens when this part disappears?

Why was it designed this way?

What happens if I change that?

Sometimes this tendency is useful.

Sometimes it leads directly into a rabbit hole.

I have learned to recognize the difference better over the years.

Not perfectly.

Probably never perfectly.

But I don’t want to lose the instinct.

I Like Problems I Don’t Immediately Understand

There is something satisfying about encountering a problem where the answer is not obvious.

The easy problems are useful.

They need to be solved too.

But the strange ones are memorable.

The intermittent failure.

The impossible metric.

The configuration that should work but doesn’t.

The behavior that contradicts the documentation.

The problem everyone has already investigated.

Those are the ones that make me lean forward.

Something doesn’t make sense.

Good.

There is something here to learn.

The Best Problems Change Your Understanding

Sometimes you solve a problem and learn one fact.

A setting was wrong.

A service stopped.

A certificate expired.

Useful.

Then there are problems that change your mental model.

You discover that two systems interact differently than you believed.

You learn that an assumption you carried for years was incomplete.

You discover a dependency nobody documented.

You realize the symptom you had always associated with one cause can come from somewhere completely different.

Those lessons stay.

The system begins looking different because you understand more of what is happening underneath it.

That is one of the rewards of curiosity.

I Don’t Want to Be the Person Who Already Knows Everything

I have met people who seem uncomfortable admitting they do not know something.

I understand why.

Experience creates expectations.

Titles create expectations.

Customers expect answers.

Teams expect answers.

Sometimes you expect answers from yourself.

But pretending to know does not create knowledge.

It creates risk.

I would rather say:

“I don’t know.”

Then start investigating.

If someone else in the room knows, even better.

Teach me.

Some of My Teachers Were Not Teachers

I have learned from managers.

Engineers.

Customers.

Coworkers.

People I mentored.

People who mentored me.

People with decades more experience.

People with almost none.

I have learned from documentation.

Failures.

Bad designs.

Excellent designs.

Arguments.

Incidents.

Experiments.

Mistakes.

And occasionally from something someone said almost casually that changed the way I looked at a problem.

You never really know where the next useful lesson will come from.

That is another reason to keep listening.

Titles Should Not End Curiosity

The farther someone advances in a career, the easier it becomes to live inside what they already know.

That would be a terrible outcome for me.

I don’t want experience to become a museum of things I used to understand.

Technology will keep moving.

The next generation will build things differently.

Some of what I know today will become foundational.

Some will become obsolete.

Some will become trivia.

That’s fine.

I don’t need every old answer to remain valuable.

I need the ability to learn the next one.

Experience should not protect you from becoming a beginner again. It should teach you that you can survive being one.

I Want People to Challenge Me

I have said throughout this book that I want people around me who will challenge my thinking.

Curiosity is part of the reason.

If I am wrong, I want to know.

If there is a better design, show me.

If I missed something, tell me.

If you know something I don’t, teach me.

I may ask questions.

I may challenge your answer.

I may make you defend it.

That isn’t necessarily disagreement.

Sometimes that is how I learn.

And sometimes, after all the questions, I will still disagree.

That’s okay too.

Curiosity does not require universal agreement.

It requires willingness to understand.

Being Wrong Is Useful

I don’t enjoy being wrong.

I don’t think most people do.

But I have learned to appreciate what being wrong can provide.

Information.

If I expected one result and received another, I just learned something about my model.

Something is missing.

That is useful.

The worst response would be trying to force the evidence to agree with me.

Reality has no obligation to protect my opinion.

So change the opinion.

Change the theory.

Keep the evidence.

The Rabbit Holes Are Part of Me Too

I have spent ridiculous amounts of time investigating things simply because I wanted to understand them.

Some produced useful results.

Some produced ideas years later.

Some probably accomplished absolutely nothing.

I am okay with that.

Curiosity needs boundaries when customers, deadlines, budgets, and responsibilities are involved.

That is why judgment matters.

But outside those boundaries?

Sometimes I want to know just because I want to know.

Not everything interesting needs to become profitable.

Not everything learned needs to become productive.

Sometimes understanding is enough.

Technology Never Ran Out

One of the things I love about technology is that it never runs out.

Every time I thought I understood computers, there was another layer.

Hardware.

Operating systems.

Networks.

Databases.

Distributed systems.

Security.

Cloud computing.

Automation.

Artificial intelligence.

And underneath every category are hundreds more.

Nobody gets to the bottom.

There isn’t one.

There is simply another layer of understanding.

For a curious person, that is a pretty good place to spend a career.

Curiosity Became More Important, Not Less

When I was young, curiosity helped me acquire knowledge.

Now I think it serves another purpose too.

It keeps knowledge from becoming rigid.

It reminds me that today’s best answer may eventually improve.

That my experience is valuable but incomplete.

That someone else may see something I don’t.

That the next problem may not behave like the previous one.

Curiosity keeps experience alive.

Without it, experience can slowly become certainty.

And certainty eventually stops learning.

I Hope I Never Finish

There will probably never be a moment when I look around and think:

That’s it.

I understand enough now.

I hope not.

I hope there is always another technology I haven’t used.

Another book I haven’t read.

Another problem I haven’t seen.

Another person who knows something I don’t.

Another idea that makes me reconsider something I thought I understood.

Another question.

That sounds like a much more interesting life.

The Question Behind the Questions

After forty-one Principles, there is an obvious temptation to believe we have been collecting answers.

In a way, we have.

Lessons.

Patterns.

Failures.

Practices.

Beliefs earned through experience.

But none of these Principles are intended to end the conversation.

They are starting points.

Ways of thinking.

Things I believe are worth carrying forward.

Someone will improve them.

Someone will challenge them.

Experience may refine them.

The world will certainly test them.

It should.

Because the purpose was never to possess the final answer.

It was to become better at searching for one.

One More Question

And that brings us to the end.

Almost.

Forty-one Principles.

Forty-one attempts to describe things I have learned about engineering, leadership, responsibility, failure, trust, knowledge, people, and the work we leave behind.

There is one Principle remaining.

That seems appropriate.

Because after all the questions in this book, there should be one question left.

Not another technical question.

Not another troubleshooting problem.

Something larger.

After everything we have built…

Everything we have learned…

Everything we have taught…

Everything we have protected…

Everything we have left behind…

What was it all for?

That is a question worth saving for 42.

Never be afraid to reach the edge of what you know. That edge is not where knowledge ends. It is where the next question begins.

Principle XLII — Leave Something Better Behind

The Answer

Forty-one Principles brought us here.

We have talked about engineering.

Systems.

Failure.

Security.

Complexity.

Truth.

Trust.

Ownership.

Knowledge.

Teaching.

Leadership.

Curiosity.

And people.

We have asked how to build.

How to troubleshoot.

How to decide.

How to recover.

How to lead.

How to learn.

How to teach.

How to become better at the work.

But there is a larger question.

What was all of it for?

My answer is simple.

Leave something better behind.

More Than the Work

Eventually every project ends.

Every system is replaced.

Every technology becomes old.

Every architecture becomes legacy.

Every company changes.

Every career ends.

If the only evidence that we were here is the technology we personally built, time will eventually erase most of it.

That sounds discouraging.

I don’t think it is.

Because our work leaves behind more than artifacts.

It changes people.

It changes knowledge.

It changes expectations.

It changes what becomes possible next.

The system may disappear.

The effect does not necessarily disappear with it.

The First Thirty-Eight Principles Were Already Pointing Here

Build things that work.

Understand the problem before solving it.

Protect what matters.

Reduce unnecessary complexity.

Design for failure.

Automate toil.

Understand dependencies.

Measure what matters.

Tell the truth.

Admit what you don’t know.

Own the outcome.

Earn trust.

Keep your word.

Teach.

Solve real problems.

Make things better than you found them.

None of those ideas exist only to create better technology.

They describe a way of taking responsibility for the small piece of the world temporarily placed in your hands.

That is the larger lesson.

The work was never only about the work. It was about what became better because you did it well.

Temporary Custodians

Almost nothing we work on truly belongs to us forever.

We inherit systems built by other people.

Networks.

Applications.

Databases.

Documentation.

Processes.

Organizations.

Knowledge.

Then, for a while, they become our responsibility.

We change them.

Repair them.

Extend them.

Protect them.

Sometimes replace them.

Eventually someone else inherits what we leave.

We are custodians.

Temporary ones.

That should change how we work.

Someone Comes After You

This idea appears throughout this book because I believe it deeply.

Someone comes after you.

Another engineer will read the code.

Another administrator will inherit the server.

Another technician will troubleshoot the network.

Another manager will lead the team.

Another person will read the documentation.

Another customer will use the product.

Another generation will inherit the institution.

You may never meet them.

Your decisions still affect them.

Good stewardship is respect for people you may never have the opportunity to meet.

Leave Them a Better Starting Point

You do not need to solve every future problem.

You cannot.

But you can improve where the next person begins.

Document what you learned.

Remove the unnecessary dependency.

Automate the repetitive task.

Fix the misleading name.

Explain the strange configuration.

Preserve the reason behind the decision.

Create the rollback procedure.

Teach someone else.

Clean up after yourself.

Fill the gas tank.

The next person should not have to rediscover everything you already paid to learn.

This Is Why Documentation Matters

Documentation appears repeatedly throughout these Principles because it is one of the simplest ways to communicate with the future.

You are saying:

I was here.

This is what I found.

This is what I changed.

This is why.

This is what you should know before touching it again.

Good documentation is an act of consideration for someone who is not in the room yet.

Sometimes that person is you six months later.

Sometimes it is someone you will never know.

Either way, leave the note.

This Is Why Teaching Matters

Knowledge that ends with you has limited reach.

Teach someone.

Now the knowledge travels.

They use it somewhere you never will.

They improve it.

They teach someone else.

Eventually an idea you shared may influence work you never see.

That is extraordinary.

You do not have to personally touch every system to improve it.

Sometimes you improve the person who will.

This Is Why Enablement Matters

Principle XL asked us to enable others to succeed.

Now we can see why it belongs so close to the end.

Your reach is finite.

You can solve only so many problems.

Build only so many systems.

Attend only so many meetings.

Help only so many customers directly.

But capable people multiply.

If you help someone become better…

And they help someone else…

Your contribution travels farther than your own hands ever could.

This Is Why Institutions Matter

Principle XXXIX asked us to build institutions, not merely projects.

Because projects end.

Capability can remain.

A good process remains.

A standard remains.

A culture remains.

Knowledge remains.

People remain.

An institution carries useful ideas beyond the people who originally created them.

That is how temporary work produces durable value.

This Is Why Integrity Matters

You will make decisions nobody sees.

Shortcuts nobody would discover.

Documentation nobody forces you to write.

Risks you could quietly ignore.

Problems you could leave for someone else.

Integrity determines what you do in those moments.

Leaving something better behind often depends on work for which nobody will ever applaud you.

Do it anyway.

The person who inherits the result may never know your name.

They will still experience your decisions.

This Is Why Humility Matters

You will not finish the work.

None of us will.

There will always be another improvement.

Another problem.

Another generation.

Another idea.

Humility allows us to contribute without believing the story ends with us.

We build on what others left.

Others will build on what we leave.

That is how progress works.

Inherit With Gratitude

Leaving something better behind also requires recognizing what was left for you.

Someone wrote the language.

Someone designed the protocol.

Someone built the operating system.

Someone documented the standard.

Someone discovered the algorithm.

Someone installed the cable.

Someone answered the question.

Someone taught you.

Someone gave you the opportunity.

Nobody builds alone.

Every expert stands on an enormous foundation of work performed by people they will never meet.

Remember that before becoming too impressed with yourself.

Improve Without Contempt

You will inherit bad systems.

Confusing systems.

Undocumented systems.

Fragile systems.

Systems built with decisions you would never make today.

Improve them.

But be careful about judging the people who came before you.

You rarely know all the constraints they faced.

The deadline.

The budget.

The technology available at the time.

The requirements.

The emergency.

The knowledge they had.

The organization around them.

You can improve the past without insulting it.

Respect what you inherited enough to understand it, and respect what comes next enough to improve it.

Progress Is a Relay

Very little meaningful progress is completed by one person.

Someone begins.

Someone improves.

Someone discovers a problem.

Someone solves part of it.

Someone teaches.

Someone challenges.

Someone builds the next version.

Then someone else continues.

We like stories about individual genius because they are easy to tell.

Reality is usually more collaborative.

Progress is a relay.

You carry something for a while.

Then you hand it forward.

The important question is:

What condition is it in when you pass it?

Your Name Does Not Need to Remain

There is a temptation to connect legacy with recognition.

Buildings with names.

Awards.

Titles.

Products.

Books.

Maybe those things matter.

But some of the most meaningful contributions will never carry the contributor’s name.

A process that quietly prevents mistakes.

A lesson someone still remembers.

A script that saves hours every week.

A person whose career changed because someone believed in them.

A decision that prevented a failure nobody knows almost happened.

Invisible contributions still count.

Legacy is not whether people remember your name. It is whether something remained better because you were here.

Better Does Not Mean Perfect

This book has never asked for perfection.

Perfection is usually unavailable.

Sometimes impossible.

You will leave unfinished work.

Unanswered questions.

Technical debt.

Mistakes.

Things you wish you had done differently.

So will I.

The standard is not:

Did you perfect everything you touched?

The better question is:

Did you move it in the right direction?

Did you leave useful knowledge?

Did you reduce unnecessary harm?

Did you make the next step easier?

Did you care?

Small Improvements Count

Not every contribution needs to change the world.

Fix the documentation.

Teach the new employee.

Clean up the script.

Call the customer back.

Correct the misleading instruction.

Automate the annoying task.

Listen to someone.

Share the credit.

Ask the question.

Keep the promise.

Do the extra fifteen minutes.

Small acts compound.

A career is made from them.

So is a reputation.

So is a culture.

So, eventually, is a legacy.

The World Does Not Need Your Perfection

It needs your contribution.

Something useful.

Something honest.

Something thoughtful.

Something that helps.

You do not need to know everything.

You do not need to solve everything.

You do not need to be the smartest person in every room.

You need to take what you have learned and use it responsibly while it is yours to use.

Then pass something worthwhile forward.

The Answer Was Never 42

Douglas Adams gave us a wonderful joke.

The answer to the ultimate question of life, the universe, and everything:

But the joke contains another lesson.

An answer without understanding the question is not particularly useful.

That is why this book was never really about finding one universal answer.

It was about learning how to approach the questions.

With curiosity.

Humility.

Integrity.

Discipline.

Responsibility.

And care.

There is no single command that solves everything.

No architecture.

No methodology.

No career lesson.

No Principle.

Not even this one.

Solve for 42

To me, solving for 42 does not mean discovering the final answer.

It means accepting that we may never have one.

And working responsibly anyway.

Ask better questions.

Solve the problem in front of you.

Tell the truth about what you know.

Admit what you don’t.

Protect what matters.

Learn from failure.

Share what you discover.

Help other people become capable.

Build things worth inheriting.

Then leave the next person a better starting point than the one you received.

That is enough.

More than enough.

One Life, Limited Time

Eventually the number of projects remaining becomes smaller than the number behind us.

The number of problems we will personally solve becomes finite.

The number of people we can directly teach becomes finite.

Time makes that decision for everyone.

That is why what we pass forward matters.

Knowledge extends beyond our time.

People extend beyond our reach.

Institutions extend beyond our tenure.

Ideas extend beyond our presence.

We cannot stay.

But something we contributed can.

Closing Thought

You will not solve every problem.

You will not answer every question.

You will not finish everything worth building.

Neither will I.

That was never the assignment.

Take responsibility for what reaches your hands.

Learn everything you reasonably can from it.

Do the work well.

Tell the truth.

Help people.

Teach what you know.

Remain curious.

And when it is time to hand the work to someone else…

Leave them something better than you received.

You do not need to leave the world knowing your name. Leave it with something worth having because you were here.

The Principles Are a System

Forty-two Principles can look like forty-two separate ideas.

They are not.

They depend on one another.

Sometimes they reinforce each other.

Sometimes one prevents another from being taken too far.

Together they describe something larger than any individual lesson.

A way of approaching work.

A way of approaching responsibility.

And, increasingly, a way of approaching life.

Principles become useful when they stop being things you remember and become ways you naturally make decisions.

Curiosity Needs Humility

Curiosity asks:

Why?

Humility admits:

I may not already know.

Without humility, curiosity becomes performance.

We ask questions only to demonstrate what we know.

Real curiosity requires the possibility that the answer may surprise us.

Or contradict us.

Or prove us wrong.

That is why these Principles connect.

Curiosity keeps us searching.

Humility keeps us teachable.

Humility Needs Confidence

Humility does not mean believing you have nothing valuable to contribute.

You need enough confidence to make decisions.

To challenge assumptions.

To propose a better design.

To speak when something is wrong.

To lead.

The balance matters.

Confidence says:

“I believe this is the right direction.”

Humility adds:

“Show me what I may have missed.”

Together they create something stronger than either alone.

Truth Needs Courage

Truth Over Comfort sounds simple until the truth is expensive.

The project is late.

The design has a flaw.

The backup cannot be restored.

The metric is misleading.

The customer expectation cannot be met.

The mistake was yours.

Now truth requires courage.

It is easy to value honesty when honesty costs nothing.

Character appears when the truthful answer creates consequences.

Ownership Needs Truth

Ownership without truth becomes defensiveness.

If the outcome belongs to you, then you must be willing to understand the outcome as it actually exists.

Not as you intended it.

Not as the dashboard makes it appear.

Not as you hoped it would be.

Reality first.

Then responsibility.

Then improvement.

You cannot own an outcome you are unwilling to see clearly.

Ownership Needs Humility Too

Taking ownership does not mean claiming you can solve everything yourself.

Sometimes ownership means asking for help.

Escalating.

Calling the expert.

Admitting the problem exceeds your current knowledge.

Ownership is responsibility for the outcome.

Not ownership of every answer.

That distinction matters.

Curiosity Needs Judgment

Curiosity can take you anywhere.

Judgment decides whether you should go there now.

The rabbit hole will always be available.

There will always be another dependency.

Another optimization.

Another experiment.

Another interesting question.

Solve the real problem first.

Then decide which mysteries deserve more time.

Curiosity creates possibilities.

Judgment creates priorities.

Complexity Needs Purpose

Complexity is not automatically bad.

Some problems are genuinely complicated.

Some requirements demand sophisticated solutions.

The mistake is adding complexity without sufficient value.

Every dependency has a price.

Every abstraction has a cost.

Every component becomes something someone may eventually need to understand, operate, secure, recover, upgrade, or replace.

Build what the problem requires.

No more than necessary.

No less than responsible.

Automation Needs Understanding

Automation is powerful.

It removes toil.

Creates consistency.

Reduces repetitive mistakes.

Scales expertise.

It also scales whatever assumptions you put inside it.

A bad manual process performed once creates one problem.

A bad automated process can create thousands very efficiently.

Understand first.

Then automate.

Automation multiplies behavior. Make sure the behavior deserves multiplication.

Automation Needs Ownership

Automated does not mean ownerless.

Someone still needs to understand:

What it does.

Why it exists.

What happens when it fails.

How to stop it.

How to recover.

Who receives the alert.

Automation should remove unnecessary human effort.

It should not remove human responsibility.

Security Needs Design

Security added at the end is usually expensive.

Sometimes ineffective.

Protect what matters from the beginning.

Understand the data.

The access.

The trust boundaries.

The dependencies.

The recovery path.

The human behavior.

Security is not one component.

It is a property of the system.

Security Needs Usability

A control nobody can reasonably follow will eventually be bypassed.

People write down impossible passwords.

Create unofficial workflows.

Share accounts.

Move data somewhere easier.

Disable protections that constantly interrupt legitimate work.

That does not mean lowering security standards.

It means designing controls human beings can actually use correctly.

Good security protects people without requiring them to fight the system constantly.

Reliability Needs Failure

That sounds contradictory.

It isn’t.

Reliable systems are designed by people willing to think seriously about failure.

What breaks?

What happens next?

What is redundant?

What is backed up?

What is monitored?

How do we recover?

How long will recovery take?

Has anyone tested it?

Design for failure because pretending failure will never happen does not make a system reliable.

It makes the failure surprising.

Backups Need Restore Tests

A backup is a promise.

A restore test verifies the promise.

Until then, you have hope.

This pattern appears everywhere.

A plan needs validation.

A design needs testing.

A theory needs evidence.

A procedure needs practice.

Confidence should be earned.

Metrics Need Context

Measure what matters.

But remember that measurement is representation.

The number is not the system.

Averages can hide spikes.

Percentages can hide populations.

Green dashboards can hide unhappy customers.

Performance metrics can reward behavior that damages the larger outcome.

Measure.

Then ask what the measurement actually means.

Standards Need Judgment

Standards create consistency.

They prevent teams from solving the same basic decisions repeatedly.

They encode experience.

But standards should not eliminate thought.

There will be exceptions.

New technologies.

Different risks.

Changed assumptions.

Use the standard.

Understand why it exists.

Then challenge it responsibly when reality no longer fits.

Documentation Needs Truth

Bad documentation can be worse than none.

Outdated instructions create confidence in the wrong answer.

Document what actually exists.

Update it when reality changes.

Include the strange parts.

Explain why.

Record limitations.

A document should reduce uncertainty.

Not preserve an old version of reality indefinitely.

Documentation Needs Curiosity

The best documentation often comes from remembering the questions you had before you understood.

Why is this here?

What does this connect to?

Which account does it use?

What happens if it fails?

Where are the logs?

How do I restore it?

What should normal look like?

Write for the person who will ask those questions next.

Teaching Needs Knowledge

You cannot teach what you do not understand.

Repeating instructions is not the same as transferring understanding.

Know the reason.

Know the tradeoff.

Know the failure mode.

Know where your knowledge ends.

Then teach honestly.

Teaching Needs Humility

The teacher does not always remain the expert.

Students grow.

Technologies change.

Someone you taught may discover a better method.

Good.

Let them teach you.

Teaching should create knowledge flow in both directions.

Teaching Needs Enablement

If you explain everything but never let someone act, you have created education without capability.

Eventually they need the keyboard.

The project.

The decision.

The presentation.

The responsibility.

Knowledge becomes capability through use.

Give people enough support to succeed and enough ownership for the success to belong to them.

Enablement Needs Standards

Helping someone succeed does not mean lowering expectations.

Give them the ladder.

Keep the height.

Training.

Tools.

Feedback.

Opportunity.

Context.

Guardrails.

Then let them climb.

Do not confuse making success possible with making success meaningless.

Trust Needs Consistency

Trust is not created by one impressive moment.

It accumulates.

You said you would do something.

Then you did it.

Again.

And again.

Your estimates were honest.

Your mistakes were acknowledged.

Your commitments meant something.

Eventually people stop wondering whether your word can be trusted.

That is a powerful form of infrastructure.

Trust Needs Truth

A comfortable lie can preserve trust for a moment.

Then destroy it completely.

Bad news delivered honestly may create a difficult conversation.

Hidden bad news creates a different question:

“What else aren’t you telling me?”

Trust survives difficult truths far better than discovered deception.

Reputation Needs Quiet

If you constantly have to tell people how excellent you are, something is missing.

Let the work accumulate.

Let the customer speak.

Let the people you taught speak.

Let the systems you left behind speak.

A strong reputation is evidence gathered over time.

You do not need to narrate it constantly.

Excellence Needs Restraint

Good engineers can build many things.

Wise engineers know which ones should exist.

Every interesting idea does not belong in the current project.

Every possible feature does not belong in the product.

Every improvement does not justify the complexity.

Capability gives you options.

Judgment tells you which options to decline.

The Long View Needs Action Today

Thinking long-term does not mean postponing everything for some imagined future.

The future is built from today’s decisions.

Document now.

Patch now.

Train now.

Test recovery now.

Remove the temporary workaround when it is no longer needed.

The long view changes what today’s fifteen minutes are worth.

The Small Things Need the Big Picture

Sometimes the work is tiny.

Rename the variable.

Update the diagram.

Clean the equipment.

Write the note.

Return the call.

Fill the tank.

Those actions can look insignificant.

The big picture tells you why they matter.

Someone comes next.

Small acts of stewardship accumulate into reliable systems, trustworthy people, and healthy organizations.

The Big Picture Needs Small Things

Vision without execution is decoration.

You can talk about reliability forever.

Someone still needs to test the restore.

You can value documentation.

Someone still needs to write it.

You can value mentorship.

Someone still needs to sit beside the new engineer.

You can value integrity.

Someone still needs to tell the uncomfortable truth.

Principles become real through behavior.

Usually small behavior.

Repeated consistently.

Every Principle Has a Failure Mode

Almost any good idea can become harmful when separated from judgment.

Ownership can become control.

Curiosity can become distraction.

Standards can become bureaucracy.

Security can become obstruction.

Automation can scale mistakes.

Confidence can become arrogance.

Humility can become passivity.

Long-term thinking can become indecision.

Teaching can become dependence if ownership never transfers.

Simplicity can become inadequacy if the problem truly requires complexity.

That is why there are forty-two Principles instead of one slogan.

They balance one another.

No Principle Removes the Need to Think

This may be the most important warning in the entire collection.

Do not use Principles as substitutes for judgment.

There will be situations where two good principles appear to conflict.

Move quickly.

Be careful.

Simplify.

Add redundancy.

Trust people.

Verify.

Automate.

Slow down and understand.

Which one applies?

It depends.

Context matters.

Risk matters.

People matter.

Consequences matter.

Principles guide judgment.

They do not eliminate it.

A principle should improve your thinking, not replace it.

They Are Meant to Be Used Together

When facing a difficult decision, you may find several Principles standing in the room.

Tell the truth.

Own the outcome.

Protect what matters.

Measure what matters.

Understand the dependency.

Consider failure.

Keep the long view.

Ask what you are missing.

Solve the real problem.

Leave it better than you found it.

None alone gives you the complete answer.

Together they improve the question.

And better questions tend to produce better decisions.

This Is What Experience Becomes

Experience is not merely remembering more answers.

It is accumulating patterns.

Knowing which questions matter.

Recognizing risk.

Understanding consequences.

Seeing connections.

Knowing when the standard applies.

Knowing when the exception deserves consideration.

Knowing when to act.

Knowing when to stop.

Knowing when to ask for help.

Knowing how much you still do not know.

Principles are compressed experience.

They allow lessons to travel.

But They Are Not Laws

These forty-two Principles are not commandments.

They are not complete.

They are not immune from challenge.

They came from experience.

Mine.

The people who taught me.

The systems I worked on.

The mistakes I made.

The failures I witnessed.

The people I led.

The people who led me.

The customers who trusted me.

The questions I kept asking.

Another person’s experience will add different lessons.

It should.

Improve Them

Challenge these Principles.

Test them.

Find the exceptions.

Refine the language.

Discover something I missed.

Add Principle XLIII if you need one.

I will not be offended.

In fact, that would prove several of the Principles worked.

Knowledge is meant to be shared.

Truth matters more than comfort.

Humility leaves room for better answers.

Curiosity never ends.

And everything worth inheriting should be improved when possible.

The System Is Alive

A philosophy that cannot tolerate new evidence eventually becomes dogma.

That is not what I want this to be.

Use these Principles.

Keep what works.

Understand why.

Challenge what doesn’t.

Improve what you can.

Then pass the lessons forward.

The Principles themselves should be treated the same way we have treated every other system in this book.

Inherit them.

Understand them.

Test them.

Improve them.

Leave them better.

Closing Thought

Forty-two Principles are not forty-two answers.

They are forty-two reminders that good work requires more than technical ability.

It requires judgment.

Integrity.

Humility.

Curiosity.

Responsibility.

Care.

And the willingness to keep learning when experience would make it easier to stop.

Taken together, they ask something simple:

Do the work in a way that makes what comes after you stronger.

The Principles are not the answer. They are tools for becoming the kind of person who can keep searching for better ones.

Now It’s Yours

If you have made it this far, I have spent a lot of time telling you what I think.

What experience taught me.

What mistakes taught me.

What good engineers taught me.

What bad systems taught me.

What leadership taught me.

What failure taught me.

What customers taught me.

What people taught me.

Now comes the important part.

What are you going to do with it?

Because the book cannot answer that for you.

Neither can I.

Eventually every lesson has to leave the page and become a decision.

Do Not Memorize This Book

That is not the point.

I do not expect you to remember forty-two Principles by number.

I don’t expect you to quote them.

I don’t expect you to agree with every sentence.

What I hope happens is much simpler.

Someday you are standing in front of a difficult decision and something in these pages comes back to you.

Maybe you ask:

What am I missing?

Maybe you stop before adding another dependency.

Maybe you test the restore.

Maybe you tell someone the uncomfortable truth.

Maybe you write the documentation before closing the ticket.

Maybe you let someone else keep the keyboard.

Maybe you ask one more question.

Maybe you spend the extra fifteen minutes.

That is enough.

Use What Helps

Some Principles will matter to you more than others.

That is natural.

Your work is different from mine.

Your career will be different.

Your mistakes will be different.

Your opportunities will be different.

Take what is useful.

Apply it.

Test it against reality.

If it makes you better, keep it.

If experience teaches you something more complete, improve it.

The goal is not loyalty to the book.

The goal is better judgment.

Challenge What You Disagree With

Please do.

If you read something here and think:

“That’s wrong.”

Good.

Ask why.

What experience led you somewhere different?

What assumption do you reject?

What exception have you encountered?

Can you explain the disagreement?

Can you support it?

Can you improve the idea?

That is exactly what curiosity should produce.

Agreement is not the price of admission.

Thinking is.

I would rather you challenge a Principle thoughtfully than follow it without understanding why.

Find Your Own Principles

These forty-two came from my experience.

You will collect your own.

Maybe you already have.

Things a parent taught you.

A teacher.

A manager.

A coworker.

A customer.

A failure.

A success.

A terrible project.

A great team.

A mistake you promised yourself you would never make again.

Write them down.

You may be surprised how many decisions in your life are already guided by lessons you have never formally named.

Give them names.

Think about them.

Test them.

Refine them.

Know Where Your Principles Came From

A principle without context can become a superstition.

Understand why you believe what you believe.

Maybe you value documentation because you once inherited a system with none.

Maybe you value testing because a failed deployment taught you the cost of assumptions.

Maybe you value honesty because someone once lied to you.

Maybe you value mentorship because someone took the time to teach you.

Maybe you value preparation because you once needed a recovery plan that did not exist.

The story matters.

It reminds you what problem the Principle was trying to solve.

Some Lessons Are Expensive

I would love to tell you that reading about someone else’s mistakes allows you to avoid all of your own.

It doesn’t.

You will make mistakes.

Some will be embarrassing.

Some expensive.

Some painful.

Some will become stories you tell years later.

Learn from them.

The price has already been paid.

Do not waste the purchase.

A mistake becomes more expensive when you pay for the lesson and refuse to learn it.

Borrow Experience Whenever You Can

You do not have enough time to make every mistake personally.

That is one reason we teach.

Listen to people who have been there.

Read the incident report.

Study the failure.

Ask the experienced engineer what they would do differently.

Ask the customer what actually hurt.

Ask the person leaving what nobody documented.

Ask the new person what makes no sense.

Borrow experience.

Then add your own.

Do Not Confuse Age With Wisdom

Time produces experience.

It does not guarantee reflection.

Someone can repeat the same year twenty times.

Another person can learn enormously from five.

The value is not simply how long you have been doing something.

It is whether you remained awake while doing it.

Did you ask why?

Did you examine the result?

Did you change?

Did you teach?

Did experience modify your judgment?

Years are counted automatically.

Wisdom is not.

Your Career Is Not a Straight Line

Mine wasn’t.

Yours probably won’t be either.

Skills transfer in strange ways.

A lesson from one job appears ten years later in another.

A communication skill becomes a leadership skill.

A support problem becomes an engineering principle.

A failed project becomes an architecture standard.

A call center becomes a lesson about multiplying people.

You cannot always see which experiences will matter while you are living them.

Pay attention anyway.

Take the Strange Opportunity

Some of the most valuable experiences begin with something outside the expected path.

A project nobody else wants.

A technology you have never used.

A customer problem outside your specialty.

A chance to teach.

A chance to lead.

A chance to build.

A chance to start over.

Not every opportunity deserves yes.

But do not become so protective of the career you planned that you miss the career experience is trying to give you.

Become Useful

There are many ways to measure a career.

Titles.

Salary.

Certifications.

Promotions.

Projects.

Awards.

Those things can matter.

But there is another measure I value greatly.

Are you useful?

When something difficult happens, do people trust you?

Can you help?

Can you find the answer?

Can you make the situation clearer?

Can you calm the chaos?

Can you teach someone?

Can you improve the system?

Can you leave the problem smaller than you found it?

Useful people create value wherever they go.

Become Trustworthy

Competence matters.

Character matters longer.

People will eventually forget many technical details about projects you worked on together.

They will remember whether they trusted you.

Did you tell the truth?

Did you keep your word?

Did you admit mistakes?

Did you give credit?

Did you show up when things were difficult?

Did you protect what they trusted you with?

Did you treat people well when you did not need anything from them?

Your technical reputation and your human reputation eventually become the same reputation.

Learn to Say “I Don’t Know”

You will need this sentence.

Use it.

Then add:

“But I’ll find out.”

Or:

“Let’s find out.”

Those words can carry you through an entire career.

They protect you from pretending.

They invite collaboration.

They preserve curiosity.

They make room for learning.

You do not need to possess every answer.

You need to remain capable of finding better ones.

Learn to Say “I Was Wrong”

You will need this sentence too.

Use it quickly.

Do not spend three meetings defending something you already know is incorrect.

Do not make other people fight through your ego to reach the truth.

“I was wrong.”

Then:

“Here is what I learned.”

That is not weakness.

That is maintenance.

You are correcting your own model of reality.

Good engineers do that constantly.

Good people should too.

Learn to Say “You Were Right”

This one matters more than people realize.

Someone challenged you.

You disagreed.

The evidence arrived.

They were right.

Tell them.

Not reluctantly.

Not:

“Well, technically…”

Just say it.

“You were right.”

People remember leaders who can do that.

It tells them that truth actually matters more than hierarchy.

Learn to Say “Thank You”

Nobody builds alone.

Someone gave you time.

Someone answered your question.

Someone reviewed the code.

Someone opened the door.

Someone took a chance on you.

Someone covered the outage.

Someone taught you something.

Someone told you the truth when it would have been easier not to.

Notice.

Say thank you.

Competence without gratitude becomes entitlement.

Teach Before You Leave

At some point, you will know something other people need.

Do not wait until your final week to transfer it.

Teach while you are still there.

Document while the details are fresh.

Bring someone into the meeting.

Explain the strange configuration.

Let someone else run the procedure.

Create another expert.

You should not need a frantic knowledge-transfer meeting before every transition.

Knowledge transfer should have been happening all along.

Make Yourself Replaceable

This sounds dangerous to some people.

It isn’t.

If you are the only person who can perform your current responsibilities, you may feel secure.

You may also be trapped.

You cannot move.

The organization cannot move.

Every vacation becomes an escalation path.

Every promotion creates a coverage problem.

Teach people.

Automate.

Document.

Build capability.

Make yourself replaceable at yesterday’s work.

That creates room for tomorrow’s.

Help Someone Pass You

At some point, someone you helped may become better than you.

Faster.

More knowledgeable.

More accomplished.

More senior.

Good.

Do not move the finish line because they are getting close.

Do not withhold the final lesson.

Do not suddenly become protective of status.

Help them.

Their success does not erase yours.

It may be part of it.

Build Something You Will Never See Finished

Some work is larger than one career.

A culture.

An institution.

A body of knowledge.

A person.

A family.

A profession.

You may contribute without seeing the final result.

Do it anyway.

Plant things whose shade belongs to someone else.

Not every return needs to arrive while you are still standing there.

Leave Evidence That You Cared

The person who comes after you may never know you.

But they will encounter your decisions.

They will see whether the documentation exists.

Whether the names make sense.

Whether the temporary workaround was cleaned up.

Whether the recovery procedure works.

Whether someone thought about failure.

Whether knowledge was preserved.

Whether the system feels cared for.

You leave fingerprints on work even when your name is removed.

Make them good ones.

Write Things Down

Memory is temporary.

Write.

Document the system.

Document the decision.

Document the failure.

Document the lesson.

Write the story.

Write your Principles.

Someone may need them later.

You may need them later.

This entire book exists because experiences that lived in my head were eventually written down.

Until then, they could travel only as far as I could personally carry them.

Now they can go somewhere without me.

That is the point.

Your Version Will Be Different

If you eventually write your own forty-two Principles, I hope they are not these.

Some may overlap.

Others should not.

Your experience should add something.

Your generation should encounter problems mine did not.

Your technology will be different.

Your world will be different.

Your answers should evolve.

If every generation merely repeats the previous one, nobody is learning.

Inheritance is the starting point.

Not the finish line.

Add the Forty-Third

I called this book Solve for 42.

Forty-two is where this collection ends.

It does not need to be where yours does.

Maybe experience gives you forty-three.

Maybe seventy.

Maybe seven principles are enough.

The number is not important.

The reflection is.

Know what you believe.

Know why.

Remain willing to change it when reality teaches you something better.

Then Give Yours Away

Do not keep the lessons only for yourself.

Tell the story.

Teach the engineer.

Mentor the new employee.

Write the runbook.

Share the failure.

Explain the mistake.

Publish the idea.

Help someone avoid paying the same price for knowledge you already purchased.

Knowledge becomes more valuable when it moves.

You Are the Next Person

Throughout this book I have repeatedly talked about the next person.

Leave documentation for the next person.

Build recovery for the next person.

Remove mystery for the next person.

Teach the next person.

Prepare the system for the next person.

There is something I should make explicit now.

Sometimes…

You are the next person.

You inherited this book.

You inherited these stories.

You inherited these mistakes.

You inherited these lessons.

For a little while, they are yours.

What happens next is no longer up to me.

The Handoff

That is what this section really is.

A handoff.

I have carried these lessons as far as I can inside these pages.

Now you decide whether they travel farther.

Use them.

Challenge them.

Improve them.

Teach them.

Replace them when you discover something better.

Add your own.

And when someone eventually inherits what you know…

Give them a better starting point than you had.

You inherited someone else’s lessons. Add your experience to them, then leave the next person more capable than you were when they reached you.

Founder’s Commentary

What I Hope I Leave Behind

I started writing these Principles because I had accumulated lessons I did not want to lose.

Some came from success.

Many came from mistakes.

A few were expensive.

Some were taught to me by people whose names I still remember.

Others came from people who probably never realized they were teaching me anything at all.

Over time, they became part of how I work.

How I make decisions.

How I lead.

How I solve problems.

How I try to treat people.

Writing them down forced me to ask something I had not really asked before.

What do all of these lessons add up to?

I think I know now.

It Was Never Really About Technology

Technology is where much of my experience happened.

It gave me the problems.

The failures.

The puzzles.

The customers.

The teams.

The late nights.

The recoveries.

The opportunities to build things that had not existed before.

I love technology.

I still find it fascinating.

I hope I always will.

But somewhere while writing this book, I realized that most of the lessons I cared about were not really technical.

Tell the truth.

Keep your word.

Admit what you don’t know.

Own the outcome.

Be humble.

Teach people.

Protect what matters.

Help others succeed.

Stay curious.

Leave things better than you found them.

You don’t need a computer to do any of those things.

The Technology Was the Classroom

That may be the simplest way I can explain it.

Technology was the classroom.

It gave me immediate feedback.

Bad assumptions eventually failed.

Poor preparation eventually mattered.

Missing documentation eventually hurt someone.

Complexity eventually sent its bill.

Trust eventually compounded.

Teaching eventually multiplied.

Curiosity eventually found something.

The systems were teaching me about more than systems.

I just didn’t always realize it at the time.

I Have Been Lucky

I have had opportunities to work with extraordinarily intelligent people.

I have worked on difficult problems.

Large systems.

Important systems.

Systems where failure mattered.

I have been trusted with responsibility.

I have been given opportunities to lead.

To teach.

To build.

To fail.

To recover.

And to try again.

Not everyone receives the same opportunities.

I know that.

So I believe there is a responsibility attached to having them.

Learn something.

Then give something back.

I Am Still Learning

Nothing about reaching Principle XLII means I am finished.

I will make another mistake.

Probably more than one.

I will encounter something I do not understand.

Someone will challenge something I believe.

Technology will change.

Experience will add another lesson.

Maybe something in this book will eventually need refinement.

Good.

That means I am still paying attention.

I would be much more concerned if I reached a point where nothing could change my mind anymore.

These Are My Forty-Two

They are not the forty-two.

They are mine.

The lessons that survived long enough to become important to me.

If I wrote this book again twenty years ago, it would be different.

If I am fortunate enough to revisit it twenty years from now, I hope it would be different again.

Because I hope I will have learned something.

That is the bargain.

We preserve what experience has taught us without pretending experience is finished teaching.

I Don’t Need You to Agree With Me

You may disagree with some of this book.

You probably should.

Your life is not mine.

Your career is not mine.

Your failures will not be mine.

Your conclusions do not have to be mine.

What I hope is that something here makes you think.

Maybe one story changes a decision.

Maybe one Principle prevents a mistake.

Maybe one question follows you into a meeting.

Maybe you teach something instead of keeping it to yourself.

Maybe you stop and ask what you are missing.

Maybe you leave one system, one team, or one person better than you otherwise would have.

Then writing this was worth it.

The People Matter Most

Systems are replaced.

Code is rewritten.

Servers are retired.

Companies change.

Products disappear.

Technologies that once seemed permanent become historical footnotes.

People carry things forward.

A lesson.

A standard.

A habit.

A story.

A way of thinking.

Confidence someone helped them discover.

An opportunity someone gave them.

Knowledge someone took the time to share.

That is why, looking back, the people matter more to me than the technology.

The technology gave us something to build together.

The people made the work worth remembering.

I Hope Someone Had an Easier Day

Maybe that is too small a measure for a life’s work.

I don’t think so.

I hope someone inherited a system and found the documentation.

I hope someone avoided an outage because we planned for failure.

I hope someone went home on time because we automated the repetitive work.

I hope someone felt confident because I took the time to teach them.

I hope a customer received something better than they expected.

I hope someone got an opportunity because I opened a door.

I hope an engineer solved a problem without calling me because I taught them enough that they didn’t need to.

Those things count.

They count a lot.

I Hope I Filled the Gas Tank

My grandmother’s lesson stayed with me.

A job worth doing is a job worth doing right the first time.

Finish the job.

Clean up.

Put things away.

Prepare for the next person.

Fill the gas tank.

That lesson turned out to be much larger than a lawn mower.

It became documentation.

Preparation.

Stewardship.

Responsibility.

Consideration for whoever comes next.

Maybe this book is another version of filling the gas tank.

I learned these lessons.

I used them.

Now I am leaving them here for the next person.

There Is No Final Answer

The joke behind 42 works because the answer is useless without understanding the question.

Life is considerably more complicated than one question anyway.

There will always be another variable.

Another perspective.

Another unknown.

Another person.

Another consequence.

Another question.

I am comfortable with that.

I don’t need a final answer.

I would rather remain curious.

What Was It All For?

At the end of Principle XLI, I asked that question.

After everything we have built…

Everything we have learned…

Everything we have taught…

Everything we have protected…

Everything we have left behind…

What was it all for?

I don’t think the answer is a title.

Or a salary.

Or a system.

Or a company.

Or a product.

Or even a book.

Those are things we do along the way.

The answer, for me, is what changed because we were here.

Did we help?

Did we teach?

Did we protect?

Did we build?

Did we make someone’s path easier?

Did we leave knowledge behind?

Did we create something another person could build upon?

Did we make the small part of the world entrusted to us a little better?

If the answer is yes…

That is enough for me.

Thank You

If you made it all the way here, thank you.

You gave me something valuable.

Your time.

I hope I respected it.

I hope somewhere in these pages you found something useful.

Something worth arguing with.

Something worth remembering.

Something worth teaching.

Something worth improving.

And someday, perhaps, something worth passing forward.

I have carried these Principles as far as I can inside this book.

They belong to you now.

Solve for 42

Ask the question.

Follow the evidence.

Tell the truth.

Own your work.

Keep your word.

Protect what matters.

Prepare for failure.

Stay humble.

Teach what you learn.

Help people succeed.

Remain curious.

And remember that someone comes after you.

You will not solve everything.

You were never supposed to.

Just take your turn.

Carry the work for a while.

Care for it while it is yours.

Add what you can.

Then hand it forward.

A little stronger.

A little clearer.

A little easier to understand.

A little better prepared for whoever comes next.

That is my answer.

It may not be yours.

I hope you find yours.

And when you do…

Share it.

Now go leave something better behind.