Thread by @GeePawHill

Change Pro-Tip: It's common, but mistaken, to believe that some change I want to make will be procedural, given, sweeping, and final.

Let's imagine someone, we'll call her Alice. Alice is a mid-level manager, a department head let's say, neither quite at the top nor quite at the bottom. She's got some power, but not all the power, and she has a very strong desire to change how her organization works.

You see, Alice has a vision. In her vision -- inspired perhaps by a talk, or a conference, or a video, or a book, or just her own idea -- and that vision has her all fired up.

Alice imagines a future, and sees what we call A City On The Hill. It is perfect there, in the City. A perfect team working on the perfect problem for the perfect customer all in the perfect way.

It's gonna be great in the City, and she wants us there as soon as we can be.

But when she's not thinking of the City, she looks around her, and she sees that where we are just now isn't the City On The Hill, it's South Craptown. I mean, it's not even *central* Craptown here.

It's just one long strip mall full of off-brand fastfood, check-cashing places, and liquor stores. On the upside it's quite lit up at night, by the neon from the strip clubs, and the noisy flashing red lights from the cops.

So she's pretty motivated to get us outta there, and she wants to go *now*. So she makes a plan for the change.

(Careful, now, we're not making fun of Alice. That fire in her is real, and it's *good*, we're glad she wants to change.)

So she's got a plan for the change, an approach, and if she's like most folks who aren't experienced changers, her plan is Procedural, Given, Sweeping, and Final.

Let's talk about these adjectives, flesh them out a little so you get a sense of what they mean to me.

By "procedural", I mean that her plan focuses most heavily on a kind of org-as-machine view. She will change processes, rules, artifacts, metrics. She'll reorder some steps, lose some, add others. We'll have new meetings, maybe new teams. We'll divide the work a certain way.

Very likely, her procedural model will make great powerpoint diagrams, with cool names in boxes and uni-directional arrows that show the flow through the system.

Procedural, here, means algorithmic, in the sense of formal recipe, the sense computer geeks mean. Only instead of computers running code, this will be humans running procedures.

By "given", I mean that her approach involves her giving us the system she has in mind. She's gives it, we take it and do it, and Bang!, City On The Hill here we come.

The change will be external to the folks on the ground floor. They may be given it using orders, or classes, or homework. They may get it in chunks, one week or month or quarter at a time.

Alice will be directing the change, she'll be monitoring it, and yes -- she'll be measuring and scoring the folks who are implementing it.

Alice's approach is "given".

"Sweeping" is pretty obvious in intent. South Craptown isn't the City On The Hill by a long ways. The changes will touch on every aspect of the org. We'll change the code, the meetings, the source control, the auditing, the documents, the language, we'll change *everything*.

We'll also change it across all the teams at once. It's no good getting Team A to the City if we aren't also getting Team B there, and so on.

Alice sees how far away the City is, and she knows it will take a lot to get there, and her approach is necessarily "sweeping".

Finally -- see what I did there -- her change is "final". It will be the last change, because remember, this is gonna get us to the City On The Hill, and it's perfect there. When it's perfect there's no *need* to change.

The City On The Hill solves all, so it's a kind of final place we'll stay. After we're done with these changes, we just sit around being perfect and, idunno, living life to the fullest while savoring the sweet taste of success.

Alice's approach to change is final.

So there we go. Alice has a vision, and a plan to achieve it, and her plan is -- if she's like most of us getting started in change -- Procedural, Given, Sweeping, and Final.

Unfortunately, it's also practically guaranteed to be a failure on a scale approaching intergalactic.

Alice. Friend. We need to talk.

The approach to change I want to talk about takes those four adjectives and turns them on their head. I want to urge Alice -- you, me -- I want to urge people to approach change differently. In one phrase, then:

Human, Taken, Local, Iterative.

Instead of a procedural focus, I propose a human one. Instead of giving the change, let's try taking it. Instead of sweeping change, let's try local change, and instead of final change, let's iterate.

Human, taken, local, iterative.

Now I know my audience isn't really composed of middle managers. I know most of you are, like me, geeks. Programmers, designers, analysts, *makers*.

Alice is kind of an easy target, cuz I know of very few folks who understand how hard it is to be a middle manager and how hard middle managers work.

But tell the truth. Haven't you done the same thing, the Alice approach, only in code, or architecture, or look and feel? Can you see how changing orgs and changing code are closely related?

(I feel a littlle like Mr. Rogers here: "I know you can.")

Here endeth part 1. Soon, we will take up the four alternative adectives, one at a time, with specific advice for your change plan.

If you want homework, though, do this: sit with it. Just soak in what we've said so far.

What could we mean by human, taken, local, and iterative?

I hope your Saturday weather is as magnificent as mine, and I hope you find yourself pleasantly surprised.

Catcha later.