You Don’t Inherit a System. You Slowly Agree to It.

[The Systems You Inherit Part 5] The maturity path runs from “someone else’s mess” to “my system now,” and the handover happens whether you notice it or not.

This is a member-only story. If you’re not a Medium member, you can read it for free through the friend link.

You notice it in a meeting, usually. Someone asks who owns the billing service, and before you have decided how to answer, you have already said: “We.” Not “the team that built it.” Not “whoever set this up originally.” We.

Nobody handed you this system. You agreed to it, one room at a time.

Nobody appointed you. There was no document, no handover, no moment where the system was formally signed over to your care. And yet some part of you has already filed it under things that are yours, and the rest of you is only now catching up to a decision it apparently made without consulting you.

That slip is the whole subject of this article, and the whole subject of this series, compressed into a single pronoun. Because you did not inherit that system in the way the word “inherit” suggests, all at once, on a particular day, like a house left in a will.

You agreed to it. Slowly. In a hundred small moments where you could have drawn a line and chose, instead, to let it pass.

The bug you decided to live with. The function you routed around instead of fixing. The “I’ll deal with that later” that quietly became “I have decided not to deal with that.”

Each of those was a tiny act of consent. Stack enough of them, and you wake up one day saying “we” about a system you never agreed to own, except that you did, repeatedly, in increments too small to notice.

This is the last piece in a series about the systems you inherit. The earlier parts were about understanding them. This one is about the stranger thing that happens after you understand them: the way they stop being someone else’s and become yours, not through any act of acquisition, but through the slow accumulation of all the times you said yes by not saying no.

Saying Nothing Is Saying Yes

Back in Part 2, I argued that the first honest move with an inherited system is to read it as a fossil record, not a crime scene.

The structure that looks insane usually isn’t. It is the rational residue of constraints nobody witnessed: a deadline, a headcount, a dependency that mattered in 2019 and doesn’t now, a person who knew something the code can no longer tell you. You inherited the route. You didn’t inherit the reasons.

[embed]The Senior Skill I've Been Trying to Name for a Decade: Reading Other People's Decisions Most inherited code that looks wrong was right once. On reading the decisions hidden in a codebase, and the senior…saeedhbi.medium.com

I still believe that. But there is a consequence to understanding a system that I undersold, and it is the hinge this whole piece turns on.

The moment you understand why a system is the way it is, you lose the right to treat it as someone else’s problem. Before you understood it, your inaction was innocent. You couldn’t fix what you didn’t comprehend, and nobody could fault you for leaving the mysterious part alone.

But understanding changes the moral status of doing nothing. Once you know why the sharp edge is there, and you know roughly what it would take to file it down, leaving it sharp is no longer neglect. It is a decision. A quiet one, unspoken, possibly even unconscious, but a decision all the same.

This is the uncomfortable arithmetic of inherited systems. Every line of code you understand and don’t change is a line you have chosen to keep. The understanding is what converts your silence from absence into agreement. And since understanding only deepens the longer you stay, the share of the system you have tacitly agreed to grows every single week, whether or not you ever touch the keyboard.

Three Stages, and You Can’t Skip Any

There is a path most engineers walk with an inherited system, and the stages map almost exactly onto degrees of agreement. You can move through them fast or slow, but you cannot jump to the end.

The first stage is someone else’s mess, and it is defined by refusal. You will not agree to this. The code is wrong, the abstractions are wrong, the person who wrote it clearly didn’t care, and if they had just done it properly, you wouldn’t be here at 11pm tracing a null through six layers.

This stage feels like clarity. It is mostly distance. You are still standing at the edge of the excavation, as Part 1 described it, certain you would have dug a cleaner hole, and your certainty depends entirely on not yet having to commit to anything.

[embed]The First 48 Hours With Someone Else's Codebase What you actually do when you inherit a system you didn't build. Not the idealized version with architecture docs and…saeedhbi.medium.com

The second stage is my responsibility, and it is an agreement under duress. Something breaks. You are the one who has been near it longest, and the escalation path ends at you because there is no one left to escalate to. So you fix it.

You did not volunteer; the incident volunteered you. But in fixing it you have crossed a line, because now a part of the system exists because of you, and you can no longer claim it is purely inherited. (I suspect a great deal of senior growth is just this line being crossed, over and over, in smaller and smaller increments, until you stop noticing it is a line at all.)

The third stage is my system now, and it is agreement so total it has gone silent. There is no ceremony here, no moment of acceptance, because by the time you reach this stage, the accepting is already done. It announces itself only in the vocabulary.

You stop saying “whoever built this” and start saying “we.” That pronoun is the receipt for a thousand small agreements you never read closely. The system you inherited has become the system you maintain, which is to say the system you have decided, through all those undecided choices, to have.

And here is the part that is easy to get wrong: you cannot skip from the first stage to the third by force of will. You cannot decide, on day one, to feel ownership over a system you do not understand, because the agreement that constitutes ownership has not been earned yet. It has to be accumulated through the second stage, through the unglamorous pile-up of fixes and near-misses and 2 am context.

The engineers who try to short-circuit this, who arrive announcing they “own this now” before they have understood anything, are not in the third stage. They are in the first stage, wearing the vocabulary of the third. They have learned to say “we” without having agreed to anything, and the system can always tell.

The Handover That Never Happens

We talk about inheritance as if there is a moment of transfer. A handover meeting. A document. A walkthrough where the person who knows everything tells you everything before they go.

That meeting is either fictional or useless. Either it did not happen because the original team was already gone, or it happened and you nodded along to forty-five minutes of context you had no hooks to hang anything on, and you retained roughly none of it, because you cannot receive knowledge about a system you have not yet struggled with.

Context only sticks to scar tissue. The walkthrough teaches you what the original author thought was important. It cannot teach you what you will discover is important, which is a different and longer list.

So the real handover does not happen in a room. It happens slowly, in production, at the worst possible times. You learn the system the way you learn a city: not from the tour, but from getting lost in it, repeatedly, until the streets stop being someone else’s directions and start being a place you simply know.

This is why “the knowledge left when the team left” is both true and slightly beside the point. Yes, the original context is gone. But it was never going to be absorbed by transfer anyway. It always had to be rebuilt the hard way, and the rebuilt version, the one earned through incidents, is the one that actually lives in your head.

The departed team’s knowledge was a map of their journey. You needed a map of yours, and the only way to draw it was to walk the ground yourself, agreeing as you went.

The Responsibility You Take by Accident

There is a version of “take ownership” that is just a poster in a stairwell. That is not what this means. The agreements that actually transfer a system are smaller and quieter than a slogan, and they are often made before you realize a contract is on the table.

Consider the most common shape it takes. A service sits between two teams, owned by neither. Both treat it the way you treat a shared kitchen in an office: technically everyone’s, actually no one’s. When it breaks, the incident channel fills with people explaining, politely and at length, why it is not theirs.

This is exactly the kind of ownership gap Part 3 was about: operational pain with no named victim, the work that does not get done because the cost is diffuse and the responsibility is unassigned.

[embed]The Moment You Realize Nobody Owns This Part of the System This is about finding those zones, understanding how they form, and the counterintuitive case for owning what nobody…saeedhbi.medium.com

Now, suppose you fix it once. Just once. You find the bug, ship the patch, and close the incident. It feels good. It feels like being a senior engineer.

What you have actually done is sign something, and the signature is binding even though you never read the terms. The next time it breaks, the most recent change is yours, so the page comes to you. The time after that, someone adds you to the owners file without asking.

By the time you look up, you have agreed to a service you were never assigned, built on assumptions you never reviewed, and the cost is rarely dramatic, but it is real: a quarter spent tending a system you backed into owning is a quarter not spent on the work you were actually there to do.

This is not an argument to leave the unowned thing alone. The unowned thing is often the highest-leverage work in the building, and many of the best engineers became senior precisely by adopting orphans nobody else would touch.

The argument is narrower: agreement transfers a system, whether or not you meant to agree, so agree on purpose. Know that the first fix is a first yes, and that yeses compound. The accidental version of this is how good engineers end up buried under systems they never chose and cannot put down, resentful in a way that looks, from the outside, exactly like the resentment they once aimed at the people before them.

So adopt the orphan deliberately, with your eyes open, having decided it is worth it. Just don’t let it adopt you while you weren’t paying attention.

A Note on Tourists

Side note, because it is a distinction worth holding onto.

The worst thing you can be in an inherited system is a tourist, and a tourist is simply someone who refuses, on principle, to agree to anything.

Tourists keep their distance. They photograph the problems, complain about the food, and leave the place exactly as they found it, because they are always, secretly, about to depart. A tourist in a codebase writes the patch that routes around the design instead of the patch that fixes it, because fixing it would be an admission that they live here now.

You can spot tourist commits a mile off. They are the ones who add a flag instead of removing a branch. They are reversible by design, not out of caution, but out of refusal to commit. Every tourist change is engineered to be deniable, so that no accumulated yes ever forms.

There is nothing wrong with caution. Part 1 was an entire argument for it. But caution and tourism look identical for the first few months, and only one of them ever turns into ownership. The cautious engineer is withholding agreement until they understand. The tourist is withholding it forever.

What “Better” Means When You Can’t Rewrite

Here is the claim the series has been building toward, and the one I am least certain how to defend cleanly: the mark of a senior engineer with an inherited system is not that they eventually rewrite it. It is that they make it better without rewriting it, and they make it look like nothing happened.

The rewrite is the seductive option, and Part 4 spent a whole piece on why it usually loses. I will not relitigate the mechanics. But it is worth naming what the rewrite is really offering, because it is not what it claims.

[embed]What to Change, What to Keep, and What to Leave Alone. Rewrite is loud. Refactor is principled. The third option, the one nobody champions, is usually the right answer. A…saeedhbi.medium.com

The rewrite promises a system you can agree to freely, all at once, on your own terms. That is the actual appeal. Not correctness, not performance, not maintainability, though those are the words that go in the planning doc. The appeal is clean consent: a system you said an enthusiastic yes to, instead of one you backed into agreeing with through a hundred reluctant shrugs. A rewrite lets you stop living with choices you never made and make a fresh set that are finally, cleanly, yours.

And the trap is that you already have a way to make the system reflect your judgment. You just have it the slow way, the same way you came to own it: one agreement at a time, except now the agreements are active instead of passive.

Because that is all “better” is, inside an inherited system. It is the moment you stop silently agreeing to keep the sharp edge and start deliberately agreeing to file it down. The act is identical in kind, a choice about the existing system, but the direction reverses.

You straighten one joint. You delete one dead branch instead of adding a flag to route around it. You rename the thing that has been lying about what it does since before you arrived. You add the test that pins down the behavior everyone has been afraid to touch, so the next person, possibly you, can finally touch it. You spend your structural-change budget, the one Part 4 described, on the two or three things that genuinely move the system, and you go on consenting to the rest, but now it is a considered consent rather than an accidental one.

None of these show up in a launch announcement. There is no demo for “the billing module is now slightly less frightening.” But the cumulative effect is a system that, six months later, is unmistakably shaped by your hands. The people who come after you will look at the parts that don’t hurt and assume you designed them that way from the start. That is the closest thing to a monument this work offers: being mistaken, by your successors, for the original architect of everything that works.

What “better” means here is narrower than what you would build from scratch, and that narrowness is the entire discipline. Better is not the system you would have designed. It is this system, with fewer sharp edges, fewer lies, and fewer places where a new engineer falls through the floor. That is a much smaller target than a rewrite. It is also one you can actually hit, this quarter, without a six-month migration and a risk register and a prayer.

The uncomfortable part, stated plainly: most of the time an engineer wants to rewrite a system, what they actually want is to not have to keep agreeing to it line by line. The rewrite promises to settle the whole question in one signature. It is sometimes an engineering judgment. More often, it is impatience with the slow, unglamorous consent that real ownership is actually made of.

The Decisions Become Yours Whether You Make Them or Not

The hardest idea in the title is the word “slowly,” because slowness is what lets you believe, for a while, that you haven’t agreed to anything yet.

For the first few months, the belief is even accurate. Nobody can hold you responsible for a billing module you have barely read. “I didn’t write that” is a complete and honest defense, and you are entitled to it. But the defense has a half-life, and it is shorter than you think.

After enough time, “I didn’t write that” quietly decays into “I chose not to fix that,” and from the outside, the two are indistinguishable, and eventually, if you are honest, from the inside too. The transition is so gradual that there is no day on which you could say the defense expired. It simply stops being true at some point you cannot locate, which is exactly how slow agreement works.

This connects to an idea from a different series of mine, decision debt: the way a good decision quietly curdles as the context around it changes, until a choice that was once correct is now just a liability nobody has revisited.

An inherited system is decision debt you didn’t take on, at first. But the longer you hold it, the more of that debt gets refinanced in your name. The original team made the decisions that created the system. You make the decisions, including the enormous, invisible category of decisions-not-to-decide, that keep it alive in its current shape. And after enough of those, pointing back at the original team starts to feel like what it is: an alibi that has run out.

I find this clarifying rather than depressing, most days. It means the question “is this a good system?” eventually collapses into “what have I agreed to, and what am I going to do about it?” There is nowhere to hide in that question. It is uncomfortable. It is also the thing that turns maintenance from a chore into a craft, because it reframes every act of keeping a system as an authored choice, exactly as authored as the acts of changing it. You are writing the system either way. Doing nothing is a sentence you are choosing to leave in.

But I Really Did Inherit a Disaster

You might be reading all of this thinking: that is fine for a system with good bones, but I inherited a genuine catastrophe, and no amount of patient agreement is going to redeem it. Sometimes, refusing to agree, tearing the whole thing out, is the only sane response.

Sometimes that is correct. Not every inherited system can be lived with, let alone improved. Some should be decommissioned. Some should be strangled slowly behind a new interface until the old one can be quietly retired. And a rare few should, in fact, be rewritten, usually because the business they were built for no longer exists in the shape the system assumes. Senior judgment includes knowing the difference, and it is far better to rewrite the genuinely doomed thing than to nurse it for years out of misplaced patience.

But here is the pattern worth distrusting in yourself. Engineers call far more systems unsalvageable than actually are. The disaster is sometimes real. More often, the disaster is the gap between the system and your understanding of it, and that gap closes with time, not with a rewrite.

The system you are certain has to be torn down in month one is often, by month nine, a system you understand well enough to fix in place. It did not change. You did. What felt like “this is unsalvageable” was frequently “I have not yet agreed to understand this,” and the moment you do, the catastrophe resolves into something merely difficult.

So, before concluding you have inherited the exception, ask how long you have known it. The verdict reached in week three is mostly a verdict on your own ignorance, and ignorance is the one variable in this whole equation guaranteed to improve if you simply stay long enough to keep agreeing.

What Actually Changes

Early in a career, an inherited system is an insult. It is proof that you have been handed someone else’s failure, and the fantasy is always the same: get senior enough, get trusted enough, and someday you will work on something clean, something yours, something you said yes to on purpose rather than by default.

A little further in, you learn the secret that should have been obvious. There is no clean system. The greenfield project becomes someone’s brownfield the moment it ships. Every system anyone has ever loved was, to the next person who touched it, a system they inherited and slowly agreed to. The pristine codebase in the fantasy is just one nobody has started shrugging at yet.

The senior shift is when you stop waiting for a system you can agree to freely and start agreeing, deliberately, to the one you have. You stop treating inheritance as a temporary condition to escape and start treating it as the permanent condition of the work, because it is.

The job was never to build the perfect thing from nothing. The job is to receive something imperfect, understand it before you judge it, keep what is load-bearing, change what is worth the budget, and hand it on a little better than you got it, knowing full well the person you hand it to will, for a while, refuse to agree to it in exactly the way you once refused.

That is not a tragedy. That is the relay.

A system you inherit is someone else’s work. A system you maintain is your responsibility. A system you have quietly agreed to, and then quietly improved, until the parts that work are the parts you chose to keep, is yours. You did not get it by rewriting it. You got it the slow way, one yes at a time, which is the only way that holds.

The refusal never fully goes away. Some new horror surfaces in a corner of the service you thought you knew, and for an afternoon, you are back in the first stage, photographing the problem and resenting the people who left. Then someone asks who owns it, and you hear yourself say “we” before you can stop, and you remember that the question of whether this system is yours was settled a long time ago, in a hundred moments you didn’t notice you were deciding.

Which is to say: there is a sharp edge somewhere in your system that you have been agreeing to for longer than you’d like to admit. You know the one. You could file it down this week. The only thing keeping it sharp is a decision you keep making by not making it.

The contents of external submissions are not necessarily reflective of the opinions or work of Maven Analytics or any of its team members.

We believe in fostering lifelong learning and our intent is to provide a platform for the data community to share their work and seek feedback from the Maven Analytics data fam.

*Submit your own writing here if you’d like to become a contributor.*

Happy learning!

-Team Maven