Always Small, Always Better, Always Wrong.
This is the mantra for anyone who seeks change in virtually any genuinely complex environment. I’ve written a lot about small and better, but not so much about wrong, which is what I want to take up today, but first, a little refresher.
The complex systems I deal with professionally all fall under the simple problem statement: "make software for money".
Those systems include lots of different aspects and layers. Two of these, at first blush vastly different, are "changing code" and "changing organizations". My contention is that they actually require the same approach: always small, always better, always wrong.
Always Small
Always Small is the discipline of focusing nearly all of our attention on the smallest possible change whose outcome we think we can detect.
In changing code, this manifests in a bunch of ways associated with the modern synthesis. TDD tests, for instance, work by asserting very small missing behaviors in our code followed by the changes that make those small assertions become true. Continuous integration works by taking such small steps and continuously "stuttering" them into the larger code base. Story slicing works by taking each story and splitting its intended value into tiny 1- and 2-day chunks.
The deep basis for "always small" is the recognition that mental scope — the number of things we have to think about at one time — is the biggest generic indicator we have for whether that thinking will be successful.
Always Better
Always Better is the discipline of pathfinding locally, taking those small steps and making judgments about them based absolutely on whether they represent actual improvement over what we had before we took them. It is at its heart the attitude that every change we make must justify itself immediately after the fact to earn any real trust from us.
In changing organizations, for instance, the skilled leader’s basic obsession is on creating sticky change. The easiest way to think of this: "Will they keep doing this when I look the other way?" The not tremendously shocking truth: they will keep doing this if they think it is helping them right now.
Am I saying that short-term gratification is the way forward?
well. yes.
The actual variation in human ability to hold on to a negative or even neutral behavior is of course a bell curve with a modal. Different people live on different locations, to be sure. But the modal of that curve? "Does this feel better when i do it?"
Don’t get all bitter and cynical. After all, it’s just a tall bump on a curve. And more importantly, "feel better" is itself a highly variable notion. But always better has its basis in both that tall bump on the bell curve and that huge variation in the meaning of "feel better". It is not a moral or ethical valuation, it’s a pretty straightforward observable fact of aggregate human behavior.
Always Wrong
Always Wrong is the discipline of making mistakes, keeping your energy and your spirits up as you discover every day that you’re not done making changes. I often tell geeks, don’t worry so much about whether you’re about to make a mistake, because I can pretty much guarantee you that you’re about to make a mistake.
A lot of folks will seek to convince us that they have a system of laws that will prevent mistakes. That is the stock in trade of the huckster and the naif alike.
It would be nice if we had such a system of laws.
we don’t.
Making software for money is not remotely a closed problem with an algorithmic answer. This holds exactly as true when we are talking about making changes to code — a complex enterprise — and when we are talking about making changes to organizations — a complex enterprise.
It is near the heart of what complexity theory means by "complex enterprise". The reason we focus so much on always small and always better is precisely because we know we will be always wrong.
Tnd the knack of always wrong is in the simple acceptance of that fact. It is making decisions knowing with confidence that you will make them differently again later. It’s why our most fundamental statement or our ideas is "embrace change". We don’t embrace change because we love change so much, we embrace it because it is the entire point of the enterprise.
We stand at this cusp, where the movement has taken us from exclusively focusing on the made to extending our focus to the making and extending it again to the makers themselves.
And making changes that work — in code, in orgs, in processes, in teams, in our selves and other individuals, it’s just this mantra: