SolveFor42

The 42 Principles · Principle XXXIX

Build Institutions, Not Projects

Standards, succession, institutional memory, repeatability, guardrails, and systems that outlive individual contributors.

LeadershipMentoringSystems ThinkingPurpose & Legacy

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.

Related Principles

Continue the idea.

These Principles share themes with Principle XXXIX.