Thread by @GeePawHill

a little coaching theory today, eh?

coaches seek to change how things go. they see what is here and they think it could be better. in fact, they usually think it could be rather dramatically better -- not worth the trouble of being a coach if not.

and our clients want us to make things better, too. tho it must be said, they usually don't understand what that better is or how it will work or the rather kind of wild cuckoo egg they're planting when they bring us in.

i am a relentless quester after small incremental improvements. my policy is expressly this: find the nearest easiest simplest team-felt owwie and fix it. lather, rinse, repeat, ad infinitum.

there's a tension here. on the one hand, like most coaches, i want great big change. on the other hand, i insist on tiny stepwise changes to get there.

this policy has brought me into conflict with a whole lot of people over the years. :)

growing coaches want big change now.
marketeers promise big change now.
product sold big change now.
managers are desperate for big change now.
executives order big change now.

how, then, do i rationalize this strange insistence that we *don't* try big change now?

well. in one sentence: i use small changes because big changes don't work or don't work very well.

i spoze i could stop there. but, you know. it's me. i'm not gonna. :)

an always-small always-improvement (ASAI) approach has lots in favor of it, and a couple of things opposing it. let's chase it down.

always-small-always-improvement (ASAI) has a lot to recommend it, vs one-big-change (OBC) .

first. when i make a small change, i don't have to be right, just right-ish, just "not immediately wrong".

small changes are easy to do, and they're easy to undo -- pretty much by definition. so if we're off-target, whether a little or a lot, we're still okay. we invest a little, we lose a little or win, we still have lots of room.

next, with ASAI i can avoid or mitigate the need for two of the most pernicious forces for corruption of intent: marketing and forcing.

always-improvement means i just don't have to go further. people like "better". they don't need to be sold on it or ordered to do it, they just have to experience it.

a third point: ASAI sidesteps cargo cults. this is again a combination of perceived-size and perceived-improvement over perceived owwie.

cargo culting comes from received but not integrated knowledge.because one doesn't grasp how a thing works, one simply goes through the motion of how one was told to do it.

the size of what is to be learned increases the risk of cargo culting, and the distance-to-gratification does to. ASAI seeks to minimize both of these.

a fourth advantage: acclimation to change. this one is grossly undersung, but it's actually critically important in building orgs that wrestle with complexity day in and day out.

the more routinely we change and deal with change, the better we get at it. the less often we change our *org*, the less skilled we are at handling the change in our *problem*.

(conway's law, or a loose corrolary to it, fits in here somewhere.)

and a fifth advantage: sticky results. small changes are easier to get right, which means they pay back sooner. that payback is what makes the change stick.

so there are plenty of arguments favoring ASAI approaches. let's turn our attention to the counter-arguments.

the commonplace case against ASAI is the efficiency argument. "making 97 small changes is less efficient than making 1 big one".

BOO!

(made you jump, yeah?)

this is idols of the schema at work. by ignoring inconvenient realities, we can hold the "1 change is more efficient than 97" canard.

1 change *is* more efficient than 97, provided only that ... it's right, it's sold, it's trained, it sticks. and one or more of those conditions *always* fail.

it's *hard* to be right, to teach people. it's *hard* to convince people to try something they don't believe helps them. it's *hard* to get people to do a thing when they're only doing it because they were told to.

really really hard. hard.

the second argument against is more subtle. it is a variation on what we call the hill-climbing problem.

consider the landscape of possible orgs & processes. it's got hills, some tall, some low, some middle. a change is a movement of some kind across this landscape.

ASAI is a policy that says we always make small moves and we always go up. that means if i'm at the top of a low hill, and there's no taller hill within my movement range, i'm stuck.

so laid out, this counter goes like this: "there is no way to get to our big change by insisting on small AND better, because we will have to either do big OR we have to accept not-better for a while."

this is coherent, and it has a nice logical math-y feel to it, so your smarter than average bear is very likely to go here and settle with it.

but there are a couple of problems with it. first, it holds "small" as a fixed distance, a permanent range limit. second, it implies that the landscape is both known to us and stable.

second one first: our knowledge of and the stability of the org landscape.

it would be nice to have a perfect topo map of possible organizations & processes. we could pick out the tallest height and head straight for it.

there's an implicit idea embedded here: "there is a tallest height." that's neo-platonic sleight of hand in action.

if you truly believe that there is one best organization or process for all possible groups of people, then you are prolly already lost to me. :)

and if you *don't* believe that -- i hope you don't -- then it's trivial to admit that no such map can exist. instead, there are only local viewings. "where i'm at and what i can see".

which moves us to stability. "where i'm at and what i can see" is not a stable arrangement. it can change dramatically with only very slight steps.

so this landscape argument is weak because: there's no tallest mountain, there's no map, and as our location changes so does what we can see.

and now on to the "fixed small" idea. i've been saying small small small. what's small? what's the range of a possible change? here we come to one of my most treasured insights.

the definition of "small" depends on us, on where we are, on what we can see, on how we *feel*.

i learned this lesson from XP: from finally understanding why user stories aren't just requirements written another way, and from seeing the kind of astonishing results i got from refactoring. i'll use the latter for my analogy here.

i'm pretty expert at unraveling legacy code. most of your hardcore geek coaches are, actually, and nearly all of us *love* to do it.

when i first see a 2000 line method or a 20,000 line class, i quake just like everyone else on the planet: how can i ever untangle this unspeakable shite?!?

the answer is of course: find the cheapest safe change you can make. lather, rinse, repeat. stupid shit: rename a variable. extract that four-liner into a method. don't re-use that variable. invert that if's condition.

i just keep focusing on the smallest step, over and over again.

and an astonishing thing happens. arrange all the problems in order of increasing "difficulty-of-fix". after the first thirty, there's thirty more, and thirty more.

let's say the first thirty are at difficulty 1, the second tranche at difficulty 2, and so on. or at least, that's my opinion when i start.

and the astonishing thing: after the first thirty are done, the second thirty just don't seem like 2's anymore. they seem like 1's, or nearly 1's. and after the second thirty, the *third* thirty seems like 1's, or nearly 1's.

before long i am making dramatic changes in the large-scale structure of the code, and they are creating *huge* improvements.

clearing the easy ones doesn't just make the hard ones more visible, it makes them *easier*.

so, too, with org & process change. when we fix the easy problems, the hard problems get markedly easier to fix. *markedly*.

to sum up this incredibly long screed -- even by my debased standards...

always-small-always-improve mitigates or elides entirely a host of difficulties that big-change invariably involves. it produces reliable results in equal or better inefficiency. the arguments against are flawed

always-small-always-improve is the mantra of my coaching practice just as it is the mantra of my coding practice.

every day starter question: what's the smallest nearest owwie we can fix today?

here's "Always-Small-Always-Improve: A Coaching Vision" geepawhill.org/?p=252