Thread by @GeePawHill

If your change works, and if it's small enough to take at one gulp, Then you might consider de-emphasizing the argument for adoption, and focusing your powers on gaining an experiment.

(If you change doesn't work, or it's too big to take at one gulp, then you might want to go back to the drawing board.)

Experiments are significantly easier to get than pre-argued pre-justified pre-determined change. Even very conservative teams can be convinced to try a small thing in a small corner for a small amount of time.

When you get such an experiment opportunity, there are several tricky parts to getting the experiment you want.

1) You want the right small corner. That is, you want a place in the environment where your idea for change is most likely to produce the benefit experience.

A simple example: I can refactor and TDD anywhere, cuz I've spent 20 years learning how to. Noobs can't, so their first experience of TDD wants to be one where TDD delivers its operational value when you're still new at using it.

2) You want the right set of experimenters. This is hard, and involves a lot of guesswork and judgment call. Make the victim-set as small as possible to being with. Then, accept that you want a balanced mix of noobs and olbs, and a balanced mix of gung-ho and nay-sayer.

3) You want the right grasp of the small change. Go as small as you can and still get operational benefit, even if it's just a little. Be especially careful of expressing "what we're gonna do" as a set of rules to be applied without using human judgment.

An example: a lot of folks grasp TDD as a set of rather rigid rules. But TDD involves a great deal of human judgment. If you make a rule like "we will not write any code without a test", we'll be inviting people to run headlong into how hard the steering premise really is.

4) You want to be there. When trying your idea for change, the victims are almost certain to have myriad questions, thoughts, experiences, enhancements. If you're not there, the experiment will spin and spin and never do what it was you wanted in the first place.

(I continue to marvel at the extraordinary number of people who think they can get change by using language-at-a-distance as their primary tool. It is to laugh.)

5) (This one's gonna sting some folks.) Doing experiments like this is a trick. It's not proof. It's not an alternative form of reasoning. It's not what they taught you in the fourth grade about science (which isn't science, either, but that's another argument). It's a trick.

What you're doing is using the language of experimentation to open people to trying something you want them to try. You're doing this because you think they're closed to trying that. You're doing it because you think they will like it if they try it.

I *have* to bring this up. If you're going to be a successful change agent, you're going to have to take personal responsibility for your actions.

I can't decide for you whether's it's okay for you to use language like this, or whether it's okay for you to do your best to guarantee the outcome of an experiment.

That's on you.

If you're going to change things, you'll face these questions about, whatever you want to call it, morality, ethics, responsibility, justification, and so on. There is no avoiding that.

And whatever answers you give to them, you have to accept those are the ones you give.

For me, well, I make those decisions more or less ad hoc more or less routinely. For me, the most important ethical rule is this: "don't kid yourself about what you're doing".

Anyway. If your small-enough change can be tried in a small-enough corner for a small-enough period, you don't *have* to argue your way into adoption. You can argue your way into an experiment. If you do, the win is a handful more supporters when you rejoin the larger org.

Have a lovely Thursday evening.

I'mo go to a local brewery with Va and some of our guest-workers.