Coaching: What I Actually Do

i spoze today is as good a day as any for me to start talking about what coaching is, about what i do and how and why.

tho i have these conversations in private, i have put off doing it here. i think it’s a mix of factors. two amusing ones: i’m not very sure i have words for it. and i’m not sure i want to argue about it. 🙂

i am a software development coach. what i do is travel around and hang out with software teams as they work to create and ship programs. companies pay me to do this. i have been doing it for nearly 20 years.

my clients pay me, and they value my practice and results, but they don’t often really understand what i do or how i do it. some do, for sure, but by no means all or even most. this bothered me for a long time, though it doesn’t anymore, and that’s worth looking at more closely, i think.

the disconnect happens in lots of little ways and a few pretty big ones.

the first big disconnect is just the mission. ostensibly, i’m usually hired by folks who want to “make my team agile”. they usually mean something like “make my team abide by this particular agile-umbrella system”.

i don’t really do that. on the one hand, i can’t: orgs make themselves, i don’t make them. on the other hand, i would not do that even if i could: i know of no such system, in agile or outside of it, that produces consistently high results. (aside: i think of myself as a pretty corrupt person, but i surprise me at times, when i draw little lines like these and abide by them. i think “system installation” in the agile world is at a pretty fundamental level, not good for the world.)

what i can and often do accomplish for these clients is to incite changes that make their teams demonstrably more valuable to the client.

the second big confusion is of course in “how i do it”. the ordinary expectation is that i will do this by, in essence, walking in and telling people what to do. and again, i don’t really do that. again, i can’t do that, because that is not an effective way to incite change for the better. again, i won’t do that, because that’s perilously close to exactly the opposite of how i think we should live and work together.

now, at first blush, it’s hardly surprising that people pay me for work when they don’t understand what that work is.

i don’t know what my doctor, my plumber, my mechanic, my arborist, my … well, we don’t have time to list all that. i don’t know what *they* do, either, i just pay them cuz things are better when they’re done.

and we could just stop there: “that’s just how it is”. it did bother me tho, and for a long time. i wanted my customers to *understand* the what and how and why.

coaches uniformly come from a place of ferocious energy about the insights they gathered in their pre-coaching existence. you just don’t get into coaching at all if you think you have no insights or you think that what you’ve learned shouldn’t be shared.

newer coaches, especially, are *consumed* with this notion. they are certain that if everyone just *understood* their ideas, everything would get better. so they focus their energy heavily on a sort of information-transfer-centric set of skills and behaviors.

we old fuckers are rather more sanguine about this. 🙂

there’s lots of room here for us to talk about what i sell and how i sell it. and that’s certainly a tremendously important conversation. i just don’t want to have it right now, because reasons.

i want to talk instead about what i actually *do*. to approach that, i’ve in mind telling you my local mission/goal/vision/focus, and telling you the many different styles of activity that go with that.

this is my local focus at work: i create or exploit small openings through which individuals, including sometimes myself, can take small steps towards becoming more like who they wish they were.

eh? wait, what? yeah. that’s what i do. it’s how i think about what i do, it’s how i post-mortem it. it is the framing of the puzzle i set out to solve when i’m working as a coach.

if that statement leaves you a little jarred, well, join the club. i’ve made it from time to time in a variety of forums public and private, and met with a nearly complete lack of response. 🙂 the thing is, i can’t let it go.

i’ve tried on dozens of coaching clothes over the years. i started with the one true religion of XP, me a leading acolyte and evangelist. i absorbed each of the new twists in the agile saga, investing in some, rejecting others.

all those suits failed me, one way or another. the only answer i’ve ever been able to hold to the entire time is the one i just gave. maybe it’ll last me for the rest of my life, idunno. but it includes in it every good thing i’ve ever done for a client. so i’m sticking to it.

you may think it strange that it doesn’t mention agile or geekery or even computers.

but don’t be silly. i am a geek. i work with geeks. i work in the geek trade. i work with teams and companies that are geek centric. of *course* agile and computers and geekery are all mixed in all the time.

it is precisely my point that geekery is inherently sociotechnical. it is neither entirely social nor entirely technical. it’s both. and it’s not sometimes the one and sometimes the other, not for the most part. they nearly always co-present.

the hidden trick? it’s in that phrase “more like who they wish they were”. for shorthand, let’s call that “better”.

people want to be “better”. their “better” includes technique, for sure, and it includes a whole lot more besides. people want to be smarter, stronger, wiser, kinder. they want to code better, to talk better, to listen better. they want to produce better.

and as a coach, what i do is help them take the next tiny step towards their “better”, (almost) regardless of which of the infinite number of dimensions they want to step along.

so. that’s it for the moment. i want very much to talk about roles and styles and activities, and i promise i will do that soon. but i had to start here, with that local mission, because it frames the problems i spend my professional life solving.

i am a professional software development coach. i create or exploit openings through which individuals in the geek trades, including myself, can take tiny steps to become closer to who and how they wish they were.

ASAI: What If That Takes A Long Time?

We spoke of always-small-always-improve (ASAI), arguing for it as strategy against big-bang-change (BBC). In another part of the forest, someone has asked the question, “what if the cost of delay for starting small instead of going big is extreme?”

A situation where a BBC is better because the cost of delay implementing ASAI is extreme is an “on paper” situation, not an “in practice” one, and it only works on paper because we’ve embedded it in a nest of un-true-to-life assumptions.

One assumption is inertia-lessness: that orgs can change course and speed in quantum fashion — literal jumps in state with no in-between states. This is trivially false. While orgs are not in fact entirely newtonian in nature, they are certainly possessed of mass and momentum. If you doubt mass, then you hold a two-person org to be the same thing as a two-thousand-person org. If you doubt momentum, well, I’m not sure what to say except to point out that Amazon also sells books. It’s not possible to hold sanely the idea that all potential changes to an org are possible in an instant. The ordinary way to understand this is to use the metaphor of a ship on the water. Making a turn of more than a few degrees at a time is simply not possible. In fact, it’s even less possible if the ship is traveling at speed.

Related to the first, but not entirely fitting in it, is the second assumption: the on-paper case assumes a passivity of the org-under-change that is never ever present. I’m reminded of Bruce Lee in Enter the Dragon: He watches a guy break a huge stack of planks with a strike. He never flinches, just says, “Boards don’t hit back.” An organization is not a piece on a playing board, to be moved from one location in org-space to another by an act of the mover’s will. Orgs are not remotely passive. They’re made of people and processes and techniques and attitudes and history. It would be a surprise if they were passive, to be honest. This means that they are preternaturally hard to control. Orgs are complex systems, far closer in nature to an animal, and ecology, a meta-person, than to a playing piece on a board. Org charts don’t hit back, but organizations do, believe me.

The third assumption is about the knowability and correctness of the big change. It’s a doozy. In this on-paper situation, the would-be changer exhibits a startling certainty that her big-bang-change is the correct change to make. Is that a reasonable assumption? Well. given what we’ve just implied about the staggering complexity of organizations, not to mention the even larger complexity of the environments in which we hope for them to thrive, it’s certainly quite a claim. I’m an arrogant person, I assume that’s by now dreadfully clear to all of you. I daresay I play up there in the big leagues of smug conceit, and it’s especially marked in matters of intellect, of my confidence in how much shit I know. But the idea that I could know with certainty that a big-bang-change was the right change, given the reality of the complexities we’re dealing with, that idea seems outside the reach of even my overweening pride. And of course, the larger the change, the greater the risk that I’m wrong, and the greater the cost if I am.

So? So I’ve got three baked-in assumptions in this on-paper situation, where the cost of delay caused by ASAI might make one prefer BBC. And all three of them seem highly suspect to me.

I’ll close with a story I’ve stolen from Jack Kennedy, who I’m reasonably confident came from a speechwriter, and reasonably confident was apochryphal at best. But it gives me a way to answer an implicit question in that on-paper scenario I’ve just doubted. That scenario posited a situation in which ASAI change was thought to take too long.

Kennedy: The great French Marshall Lyautey once asked his gardener to plant a tree. The gardener objected that the tree was slow growing and would not reach maturity for 100 years. The Marshall replied, ‘In that case, there is no time to lose; plant it this afternoon!’

Always-Small-Always-Improve: A Coaching Vision

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?


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. Always-small-always-improvement (ASAI) has a lot to recommend it, vs one-big-change (OBC). Let’s chase it down.

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?