A new manager takes over a building, or a firm wins a new management contract, and within the first month the cleanup begins. There is an odd clause in the standard lease that nobody uses anymore. A pre-winter inspection step that looks like busywork. A rule that one particular unit type always gets a longer notice period. A vendor everyone insists on even though two others are cheaper. None of it makes obvious sense, so out it goes, in the name of running a tighter operation.

Some of those changes will be improvements. At least one of them will quietly reintroduce a problem that the old rule existed to prevent, and the operation will pay for it a few months later without anyone connecting the two.

The Reformer Who Removes What He Does Not Understand

There is a piece of very old advice for exactly this moment. The writer G.K. Chesterton described a reformer who comes across a fence built across a road and says, in effect, I see no use for this, let us clear it away. The wiser response, Chesterton argued, is that if you cannot see the use of the fence, you are precisely the person who should not remove it yet. Go and find out why it was built. Once you understand the reason, you have earned the right to decide whether it still holds. The idea later became widely known as Chesterton's Fence, and its logic is plain: the fence did not build itself. Somebody put it there to solve a problem, and until you know what that problem was, you cannot judge whether removing it is smart or a mistake waiting to happen.

The point is not that every old rule is worth keeping. Chesterton was not defending clutter. The point is about order of operations. Understand first, then change. The reformer who reverses that order is not being bold. He is guessing, with the operation as the stake.

In Property, The Strange Rules Are Scar Tissue

Property operations accumulate these fences faster than most businesses, because the work is long-cycle and the lessons are expensive. A rule rarely gets written because someone enjoyed writing rules. It gets written the week after something went wrong.

The odd inspection step exists because a roof once failed in exactly the month nobody was checking. The longer notice period on a certain unit type traces back to a turnover that took three months instead of one. The lease clause that reads like boilerplate was added after a specific dispute that the clause would now prevent. The vendor everyone insists on is the one who actually showed up during a burst pipe at two in the morning, when the cheaper options did not answer. Each of these looks arbitrary from the outside. Each is the healed-over mark of a problem the operation already paid, once, to learn about.

The Rule Survives, The Reason Usually Does Not

Here is where property gets caught. The fence stays, because it is written into the process, the lease template, the checklist. But the rationale for the fence lives somewhere far less durable: in the memory of the manager who was there when the roof failed, or the pipe burst, or the dispute went to court. And that person eventually leaves.

When they go, the rule remains but its justification walks out with them. This is the quiet half of the tribal-knowledge problem: it is not only that know-how leaves with people, it is that the reasons behind the rules leave too, so the next person inherits a set of instructions with no explanation attached. They are handed the fence and none of the story. And a fence with no story is almost designed to be torn down by the first person trying to look decisive.

Which Leaves Two Bad Ways To Run an Inherited Operation

Faced with rules they cannot explain, managers tend to fall into one of two failure modes, and both are costly.

The first is the confident cleanup. Remove what looks pointless, move fast, and find out the hard way which fences were load-bearing. This is expensive because property lessons are expensive to relearn, and because the cost usually surfaces months later, disconnected from the change that caused it, so the operation often never even works out which removal did the damage.

The second is the opposite, and it is just as bad in slow motion. Touch nothing. Keep every inherited rule forever, out of a vague fear that some of them matter, and let the process calcify into a pile of steps nobody understands and nobody dares question. This operation never repeats the old mistake, but it never improves either, and it keeps paying the cost of every rule long after the problem that justified it may have vanished. Both failure modes grow from the same root. The rule is present and the reason is missing, so there is no way to tell a load-bearing fence from a useless one.

Make The Reason as Durable As The Rule

The way out is not better judgment from whoever happens to be in the chair. It is to stop letting the rationale live somewhere as fragile as one person's memory, and to record it where the rule itself lives.

A rule captured with its reason attached is a completely different object from a rule captured alone. "Do the pre-winter roof inspection" is an instruction someone will eventually cut. "Do the pre-winter roof inspection, added after the roof failure on the north-facing units" is a decision the next manager can actually evaluate, and then keep or retire on purpose. The rule never changed. The difference is that its reason now travels with it. When the operation's workflows and their reasons live in the system rather than in the head of whoever set them up, a new manager can see why a step exists before deciding whether it still should, which is the exact thing Chesterton asked for, and the exact thing a departing manager usually takes with them.

Once the why sits alongside the what, in a place that does not resign, get promoted, or forget, an inherited operation stops being a minefield of rules you are afraid to touch and becomes something you can actually improve, because for the first time you can see which fences were protecting something and which were merely left standing.

The Takeaway

Every well-run property is carrying a set of rules that are smarter than they look, written in the aftermath of problems the current team may never have seen. The danger is not that these rules exist. It is that the reasons behind them are usually stored in the least reliable place available, a person, and people move on.

An operation whose memory depends on a long-tenured manager is one resignation away from forgetting why it does half of what it does. An operation whose memory is infrastructure keeps its hard-won lessons on the books, lets a newcomer understand them in an afternoon, and can therefore change with confidence instead of fear. That is the whole difference. Institutional memory that lives in a person is borrowed and temporary. Institutional memory that lives in the system is infrastructure, and infrastructure is the only kind you actually own.

FAQ

1. What is Chesterton's Fence, and how does it apply to property management?
It is a principle from the writer G.K. Chesterton: do not remove a fence until you understand why it was put up. In property, the "fences" are inherited rules, lease clauses, inspection steps, and vendor choices that look pointless to a new manager. The principle says to learn why each exists before removing it, because many were put in place to prevent a specific, expensive problem.

2. Why do property operations accumulate so many rules that seem pointless?
Because property lessons are costly and slow, and most rules are written in reaction to something that went wrong: a failed roof, a long vacancy, a dispute, a vendor who did not show. The rule is the operation's way of not repeating the mistake. From the outside it can look like arbitrary bureaucracy, when it is really scar tissue.

3. What is the risk of removing an inherited process I don't understand?
You may be removing a safeguard whose original problem is invisible to you right now. Because property outcomes play out over months, the consequence often appears long after the change and is hard to trace back to it. That delay is what makes reckless cleanup so costly: you rarely even learn which removal caused the damage.

4. How do I capture institutional memory so it doesn't leave with staff?
Record the reason alongside the rule, in the system where the work actually happens, not in someone's head or a personal note. A step documented with the event that prompted it can be evaluated by anyone later. The goal is to make the "why" as durable and as portable as the "what," so it survives turnover.

5. Doesn't this mean I should never change inherited processes?
No. Chesterton's point is about sequence, not stasis. Understand why a rule exists, then decide. Once the reason is visible, you are free to keep it, update it, or remove it with confidence. The problem is only changing things blindly. A rule whose reason you understand and judge obsolete is exactly the kind you should retire.