Thread by @GeePawHill

Change Pro-Tip: We can't (purposefully) change what we don't sense, what we don't talk about, or what we assume can't be changed.

I remind myself of this one a lot, because it's easy to forget in the middle of the circus that passes for professional software development.

Changing things means going from A to B in, idunno, operational space. For me to do that well, I need awareness of A. I have to be able to *sense* what I or we are doing right now.

This is, given my approach to coaching, mostly about noticing pain in various forms: operational friction, individual discomfort, wasted time, misdirected effort.

I use three methods for this by and large. I use retrospectives, instant bitching, and quiet reflection & observation.

Retrospectives can be powerful, and there's a lot of great material out there about them, so I'm gonna trust you to look into that on your own.

Sadly, because of our proceduralist bent, in the trade, they are often either misused or overvalued. For misuse, the three biggest weaknesses are: they get stale, they emphasize proceduralism themselves, and they inevitably prioritize big things.

There are patches for these holes. Use a huge variety and random selection of technique and leadership. Re-focus around humans. Purposefully invert priority. All doable, with practice.

Next, there's instant bitching. The IBM[tm], or Instant Bitching Method, involves all of us adopting a strategy of saying what is making us unhappy right when it's making us unhappy.

Blurt it out. Blurt it out every time. If it makes me unhappy, I say it, right then, and with very little constraint. Believe me, no team I am on doesn't know what is making me unhappy this week, pretty much not ever.

I model this for others, and I reward them every time they do it through, check this subtle manipulative technique: paying attention. I ask them what it is. I ask them why they don't like it. I ask them not for an answer but for a rich description of a problem.

I may or may not get around to asking them for an idea of a fix, but I never rush to that. It tends to come out anyway, which is fine.

Finally, to heighten our senses, I just go to the team room and I watch. In fact, I ask individuals sometimes to do it for me. "Go hang out. Do the minimal amount of interaction. Just watch and listen. Notice everything you can. Make notes right after. Then let's talk."

Rotate that observer role around your team for a while. Just do it a couple of times a week, an hour or so each time, a different person each time. If you have highly structured activities at work, you might want to vary the timing so you get observers in place for each activity.

This emphasis on sensing things came to me from real-world repeated experience of people working on internet-stack problems. I'd watch some gal with 9 different apps running. Bounce app-to-app. Make a change. Bounce server. Bounce client. Tab around a bunch.

A one-line formatting change could result in 10 *minutes* of time-to-proof. I was startled, so I asked. And here's the thing: she never even noticed she was doing it. I have seen whole teams of people doing this kind of thing, whole orgs, even.

It's like when you drive to work and you don't remember having done so, because all the activity you did was subconscious.

We can't purposefully change what we haven't noticed.

We also can't purposefully change what we can't talk about. Look, we can take a swing at anything, but not if no one is allowed or encouraged to throw the pitch.

I'm already running long here, so I'm not going to go deep on this today. We have all seen the un-mentioned elephant in the room, the emperor's nudity, the forbidden topic.

To be able to talk about things we need a whole range of things, but the first thing we need is a sense that it is good to talk about them. Good as in "valued", "protected", "expected", and "safe".

It's a complicated problem, and approaching it requires delicacy, tact, and above all a rich sense that the most important part of our software development circus is the clowns: the humans.

We can't change what we can't talk about, so we need to work around whatever barriers exist to just talking about things.

Finally, we can't change anything we assume we can't change. This blocker is endemic to VBCA's. Even if we've tackled sensing and talking, we very often are left with a variety of assumptions of inability to change.

Stock reasons we assume we can't change some operational X usually boil down to just two abstractions: 1) someone large is making us do it, or 2) we have always done it this way.

"Someone large" is generally a Suit, an Internal Auditor, or an External Auditor.

BOO!!

Scaredja, dint I?

There's normally just two ways to deal with the Large Person. 1) Find out if they really say that. 2) Find out what they are afraid will happen if we don't do that.

For the first, a *staggering* number of "that is the rule" statements are simply not true. Rules are written down, or handed down, and they're often interpreted by the hearer in ways the rule-maker never intended.

So before you deal with blocker, be very damned sure there even *is* one. I can't tell you how many times I've girded my loins, gathered my briefcase, prepared my powerpoint, stormed passionately into a Lage Person's office for one of these big showdown....

...I get there, and I start by saying "the rule is that we do X", and they just look at me blankly. They say, "why is the rule X?" I say, "Cuz you said so." They say, "No, no, that's not the rule. The rule is Y."

This kind of thing is a complete waste of loin-girding!

But if the rule really is X, then we enter step 2: find out the fear that is driving that rule. Because if I know what the fear is, I can very often come up *not* *with* *counter-argument* but with alternative implementation that will do just as well at addressing the fear.

(REPEAT: Not the counter-argument. The goal is to find an alternative implementation that assuages the fear.)

Nine times out of ten, if you can bring a Y that actually addresses the fear of X, the Large Person will respond favorably. I have seen this over and over again.

"Oh. Okay, cool. Sounds good. Try that."

I am running on way too long, but I can deal with "we have always lived this way" in a one-liner. who cares? before 1950 we always lived without computers altogether, for tens of thousands of years.

So there it is. We can't (purposefully) change what we can't sense, what we can't say, or what we assume we can't change.

In large shops, it's particularly important to build an atmosphere in which these three issues fade in to the background.