Every new system has its boundaries. Draw them or discover them later.

You can’t reinvent the universe.

If you wish to make an apple pie from scratch, you must first invent the universe.

Carl Sagan, Cosmos

All of us live and work within systems, and each of those systems operates within further systems, and those within systems further yet, and so on until stardust, spirituality, and semantics. Even just a few hierarchical steps represents fractal complexity.

Any time you aim to replace or reinvent “the whole system”, there will be boundaries around the system space for which you can even attempt this, and tighter boundaries on the space where you could possibly succeed. This is true whether you’re shattering the patriarchal-capitalist system, rebuilding your organization’s core offering, refactoring a software feature, or changing a personal habit.

Every system change space has boundaries.

Reinventing the universe is too much. You have to depend on most existing systems remaining outside your influence as you work to effect change within a boundaried space.

What’s far outside these boundaries can be (but isn’t always!) intuitive. Your apple pie from scratch will most likely have milled flour you bought at a store, butter churned in a factory, apples from trees you did not grow. But as you get closer to the boundary edge (do you sift your own flour?), the line becomes less clearly obvious.

Boundaries can be drawn and defined, or discovered…or can slip by unnoticed.

When you draw a boundary between the system you want to change and the ones it interacts with and depends upon, you clarify how your new system has to interface with the rest of existence. Once you decide you’re not changing your reporting structure or the teams outside your division, so you’ll have to find appropriate ways for the new system within your division to communicate and interface with what’s still in place. Or if you’re changing your daily schedule to accommodate exercise, you may decide that appropriate systems to continue using are the 7-day week and your existing workplace, and only work within those boundaries.

If you don’t decide on your system-under-change boundaries, limitations on your ability to make that change still exist–though their expression when you discover them can vary. If you’re “lucky”, you’ll run headlong into a system boundary in a definitive fashion: a hard “no, you can’t change that system”. This can be disappointing, but has the upside of clarity. More common is to miss entirely where you system boundary should be, and end up floundering trying to have a meaningful effect on too large of a system space, like a conceptual mud trap. Software folks will recognize “scope creep” as an expression of this failure pattern.

If you want to succeed in changing, replacing, or rebuilding a system, you need to know what you won’t (or can’t) change. Draw the boundaries early on. Keep them tight. You can always make another apple pie when you’ve finished the first one.