– G. K. Chesterton

Stumbling upon[1] the concept of Chesterton's fence has provided a useful label for the approach to change management that I’d adopted in the weeks immediately following my return from parental leave to resume managing my team. According to Wikipedia,

Essentially, don’t try to remove a fence without first understanding what it is meant to protect (or restrain). As I’ve been reintegrating, I’ve worked to identify the changes in the team and discern between the healthy adaptations to keep, temporary stop-gaps to revert, and regressions to repair that have emerged in my absence. In other words, I’ve been looking for the fences.

To that end, here are a few of the types of questions that I’ve asked my direct reports and colleagues to gauge the changes and their impact:

Although I shared some of these questions as thought prompts beforehand, the emphasis was on delving deeper in one-on-one conversations and team health forums.

An example of how this played out was in recognizing that the meeting load on Thursdays had become unsustainable. There were several meetings that had expanded to have overlapping scope and unclear attendance policies. This caused high fatigue and a general reduction in the effectiveness of each forum as the value of each was unclear. It was tempting to come in and start canceling meetings because who doesn’t want fewer meetings! However, using team health processes such as retros and one-on-ones to gather input, I was able to first validate my observations, get a sense of what folks were hoping to get out of the forums, and understand where that wasn’t happening.

An engineering practice that is useful for identifying the fences in legacy software systems is that of writing characterization tests. Legacy systems are usually many years old, most of their original architects have already moved on, and they risk breaking every time someone makes a change. Such systems tend to also be lacking in automated tests. How does one go about updating such a system with any degree of confidence that they aren’t introducing regressions?

Characterization tests are meant to address that concern by helping the authoring engineer to elucidate the system’s actual behavior. By writing tests to guide exploration of a system, an engineer also builds up the capabilities to detect unintended changes when they shift from exploring to augmenting. Essentially, the act of writing tests helps to find the existing fences and the resulting test suite itself serves as a fence going forward.

Another engineering practice that helps to build fences is test-driven development (TDD). A practice that TDD encourages is that rather than driving straight into fixing a bug and then writing or updating tests for it after the fact, you first write a test that reflects the desired state (with the bug fixed). That test should fail by virtue of the bug fix not having been written yet. You then write the code to fix the bug and get the test to pass.

When I first learned about this approach, I thought it was overly dogmatic to spend time writing a test that I knew would fail. That was until I experienced one of the modes of failure that the practice is designed to prevent – false positive tests. False positives - tests that pass under conditions that should produce failures - can be caused by poor test isolation. For instance, if application state is reused between tests and not correctly reset on setup/teardown, the order in which they run will affect if they pass. False positive tests are particularly pernicious because they may lend false confidence that can slow down debugging efforts by misdirecting engineers.

By writing (failing) tests first, an engineer not only affirms that they understand the system under test well enough to reliably reproduce the bug in question, they also increase the odds that when the test does eventually pass, it is because of their fix as opposed to a false positive.

In addition to the fence formed by building out a test suite, TDD also forms a fence around that fence by using engineering practices to ensure that the tests are actually doing what they are expected to.

Inertia and entropy are both forces to reckon with in life. You may need to overcome inertia when you wish to change the way you do things as the way you've always done them no longer serves the intended purposes. At the same time, leaders (including you), are tasked with protecting the foundations that are core to success in their environments, guarding against entropy’s deleterious effects. The principle of fences is one way to think about the polarity between resisting entropy and overcoming inertia in order to navigate change and unlock opportunity.

Mental frameworks become useful when you are able to match them to patterns that emerge throughout your days, especially when those frameworks can be summoned under duress. Chesterton's fence is language that can be recalled when when you recognize that change is imminent or when the mode of change is being considered.