Human Change – What and Why

Today, let’s talk about the change-harvesters use of the concept-cluster we describe with the adjective "human". We advocate that both the what and the how are best centered around the humans in our systems.

The change-harvester looks at changes — in code, in individuals, in teams, in process & flows, in organizations — and sees that ,successfully applied change is human, local, oriented, taken, and iterative, often enough to adopt it as a general approach.

So let’s do “human”.

The idea here is that not only the changes we want to apply, but also the manner in which we adopt them, need to "lean in" to the remarkable strengths of humans, and "lean away" from their equally remarkable weaknesses.

The factors we’re leaning towards or away from include aspects of a given individual, the group, the culture, and the species. (I don’t draw the usual mind/body line, but if you do, add in that both "physical" and "mental" domains are relevant.)

I want to share some ideas for what those strengths include, but before we do that, let’s make sure we understand how important that bit about "individual, group, culture, species" really is.

The issue at hand: be careful when we speak of "the average human", regardless of the size and range of our sample. The overwhelming majority of measured human attributes plot out as some form of bell curve. That curve, by definition, has a central hump and two tails.

If we’re to speak generically about human strength & weakness, we want to be really clear how schmooshy, vague, and gross our generalizations are, and especially how incredibly imporant, valuable, and useful are people who are outliers in one or more of the "average human" areas.

So with that approach, tentative, cheerful, grossly generalizing, and in no way intended to be definitive, let’s talk about some very common human strengths & weaknesses, and how they play into our ideas about harvesting the value of change.

The most obvious attribute of a human is the incredible richness of their social interaction, and their equally remarkable sensitivity to it.

We are really good at navigating the complexities of real-time interactive discourse with each other. Every person you’re likely to encounter at work will have already navigated hundreds of thousands of complex human interactions by the time you wander by.

You may think of yourself as an introvert — I do — or a misfit weirdo — I do — or just barely passing as normal — I do — so it may be hard to think of yourself as a social creature. But you are, believe me.

What’s happening is that we zoom in on a part of the range of possibilities, see ourselves to the left or right away from that hump, and neglect the fact that it is an extremely tall hump, with remarkably little variance.

Approaches to change, or changes themselves, that involve plenty of ongoing peer-to-peer social interaction are much more likely to be successful. (Note that "peer-to-peer" aspect, I’ll get there in a second.)

Approaches or changes that minimize or attempt to replace direct peer-to-peer social interaction are correspondingly much less likely to be winners.

"Direct peer-to-peer" here is meant to suggest something like you and two or three friends in conversation, all participating as they see fit, no one in charge, no one forced to silence or forced to speech, and all happening in person.

What might be another such human attribute, something simpler than social interaction, something more readily measured and understood? Here’s one: humans have profound and rigid limits on mental bandwidth, the number of mental "balls" they can juggle at a time.

We have some extremely clever tricks for outwitting that limit, most notably "chunking", "stacking". and "bookending". If our change or approach supports those tricks, we’re good to go. If it doesn’t, we’re likely to lose our way.

This is why names matter: they are our representation of chunks. This is why step-size matters, because it lets us open and close problems (bookending). These are incredibly powerful capabilities of humans, but only if our change or our approach leans into them.

Another? Rapid visual survey, which I usually call "scanning". We don’t see code the way computers do, reading one character, then token, then line or statement at a time. We scan at amazingly high speed, and do significant "feature detection" w/o even thinking of it.

It is a trivial matter to write perfectly legal perfectly functional perfectly incomprehensible C code precisely because of this: by suppressing the feature detection of the code in various ways, we can dramatically undermine our human ability to work with it. And, vice versa. 🙂

Still another: humans are highly sensitive to rhythm, alternating periods of tension and release. We need variety of both level and distribution to work at our best. We can take advantage of that in our changes.

Consider TDD with its rapid cycling of red-green-refactor-push. One of the under-featured aspects of this style of development is exactly the alternating tension & release it provides. (There are others, including the open-close aspect.)

And we could go on and on, listing various attributes of humans, both finding ways to lean in to the strengths, and finding ways to lean away from the weaknesses.

Now, the other adjectives — "local", "oriented", "taken", and "iterative" — are all going to both reinforce and extend this first one, "human". Why? What is our explanation for why this first attribute, the extent to which our changes lean in to the human, so important?

Is it because we love our fellow humans so much, or ourselves as individuals?

That’s not it, tho let me hasten to say that I do, and I hope you do, too. But it’s not a question of love. This stance doesn’t depend on philanthropy for its case, nor is it undermined by misanthropy.

We focus first on the human aspect of the approach to and the substance of our change for the simple reason that, in mixed systems involving humans, machines, & procedures, it is the humans that most powerfully determine success or failure.

Human beings eat machines and procedures for lunch. We can break any system that relies on us. We can also save any system that relies on us. We routinely do this, every day in myriad ways.

Machines are powerful. Procedures are powerful. We humans ought to know, after all: we’re the ones who made them. We are super-powerful compared to them. If we ignore the human or actively lean away from the human, our systems are doomed to failure.

Human, local, oriented, taken, and iterative change. And the first is human. This lies at the base of harvesting the value of change. In coming days, we’ll take a closer look at the other four, so stay tuned.

Thanks for reading!

The GeePaw Podcast

If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here. You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.

GeePaw Hill

GeePaw’s Camerata is a community of software developers leading in changing the industry. Becoming a member also gives you exclusive access and discounts on the site.
Want new posts straight to your inbox once-a-week?
Scroll to Top