When to Leave a System

📚 Engineering Without a Starting Point - Part 9 System Architecture #Engineering Maturity
Table of Contents

When to Leave a System

There’s an uncomfortable point in the career of experienced engineers. A point where they realize:

I need to leave this system.

The Illusion: “If Only We Invested a Bit More”

It’s very easy to stay with a system because:

  • We’ve already invested years in it
  • We know every corner
  • We know “how it thinks”

That knowledge is valuable. But it’s also a trap.

Because it makes us interpret every difficulty as another challenge - and not ask whether the direction itself is still right.

When You Really Leave a System (an Example)

Imagine an old core system.

Not collapsing. Not on fire. Even “working.”

But every quarter the same thing happens:

  • Every small change requires weeks of coordination
  • Every significant bug gets “solved” with a workaround
  • Every improvement promises “we’ll clean it up later” - and the cleanup never comes
  • There’s no single big decision that moves things forward - just a sequence of survival

And then a critical moment arrives:

A major business change is being planned. Not a refactor. Not an optimization. A change of direction.

The system doesn’t block technically - it blocks conceptually.

Because everyone who knows it deeply knows: for this to really work, you need to rethink it.

But those same people - who built it, fixed it, and kept it alive - also can’t let it go.

This is where the responsible moment of leaving arrives.

Not because the system is broken. But because your presence has become the factor that locks it in place.

A Clear Sign: When You Become an Isolation Layer

Leaving properly gets close when:

  • You’re the only person who really understands how things work
  • Decisions pass through you “so nothing breaks”
  • The system survives because of you - and doesn’t develop

This looks like responsibility. In practice - it’s a blockage.

The Responsibility No One Talks About

There’s responsibility in building. But there’s also responsibility in not staying too long.

Because sometimes:

  • Your staying prevents others from taking ownership
  • Your knowledge prevents expansion
  • And your experience prevents real change

Responsible engineers ask: am I still creating possibilities - or just postponing hard decisions?

How to Leave Without Leaving a Hole

A mature departure isn’t “the last day at work.”

It’s a deliberate process:

  • Turning tacit knowledge into written, simple, and bounded material
  • Reducing points where “only you know”
  • Strengthening critical areas - not a general cleanup
  • And transferring judgment, not just code

The goal isn’t to leave a perfect system. It’s to leave a system that doesn’t depend on one person.

What Happens After You Leave?

Two things happen - almost always:

To the system

  • Some things break (and that’s okay)
  • Decisions get made that you wouldn’t have made
  • Some of the complexity gets exposed - and then handled

Sometimes, for the first time, the system starts to truly change.

To the engineer

  • A gap becomes visible between “how important I am” and “how much the system can live without me”
  • Room opens up for new thinking
  • And, most importantly: an identity that had become too tightly bound to one system is freed

A responsible departure isn’t a failure. It’s a transition from a stage of holding on - to a stage of broader influence.

The Bottom Line

You don’t leave a system when it breaks. You leave when you realize the main effort is just keeping it as it is.

And the ability to recognize that moment - is one of the most mature skills an engineer can have.

Comments