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.

---