We create artifacts to remove the need for skill. Too often we fail to account for the atrophy that naturally occurs from not exercising a skill often. What do?

I read a snippet of conversation about automation this morning that resonated mightily. As I had just hopped off of a pairing session to understand how in the hell some automation worked, it started me thinking about the flip side of the coin:

If automation is the serialization of understanding, what happens when we can’t deserialize understanding from it?

Having had the pleasure of being near Jabe and Mark, my mind leapt to Social Practice Theory. Let’s frame “automation is the serialization of understanding” through that lens.

When we say automation we’re talking about “stuff”. We’re defining “stuff”, material in the theory proper, as the manifestation of someone’s “skill”. In engineering land, that’s often the skill of the automater, but it need not be so. The computer I’m using is a piece of stuff that let’s me not need to know about how to make rocks think by trapping lightning inside. Barring intense reverse engineering by someone who kinda already knows what’s up, we’re not figuring out how to recreate said rock by studying it. This is all well and good; we’re happy to outsource that knowledge. But what about when we make that trade-off accidentally? What about when we want, and desperately need, to be able to recover “skill” from “stuff”?

Back to my pairing session: This script was about what you’d expect from someone jamming out a solution to the problem at hand with the belief that they’d come back to it to refine later when later never came. Compeletly inscrutable. Grown, not designed. Undocumented. No breadcrumbs for anyone to follow. As a result, the skill of the creator has been lost to time. This is the crux of legacy code. Stuff from which we can’t recover skill.

Stuff causes skill to atrophy. Maybe not our skill. Maybe the skill of the people the people using the stuff we cast off. We should care about documentation in its very many forms for its ability to provide a trail for others to (re)build skill. Too often we learn that the other is future us, so be selfish; you’ll come to the same place. We need to help those who come after recover the skill we used to craft our stuff.

Alan Cooper’s thoughts on pairing apply to leaving breadcrumbs:

When you program in pairs, you have to communicate your ideas, you have to explain your thinking, you have to agree on intent, and your work gets checked and checked again. If this bothers you, you can’t sustain it at a high enough level to be professionally competent.

This is what it means to be a professional in modern software development. We’re tending to our living system of code and services, but more importantly we’re tending to the understanding of the people around us. We have to put that understanding into stuff, but we don’t have to lock it away. Leave some breadcrumbs. Maybe someone comes to visit.

In this COVID’y world, I find I lack feedback I’m accustomed to while facilitating. A small example of this is the natural reinforcement that occurs as folks see others inspect and vote on cards during LeanCoffees.

As a result, I’ve been doing something I call Derby voting.

Folks create cards as usual, then they put them into a vertical line.

We cover a synopsis of each topic then open up for voting.

Voting is simple.

Everyone votes concurrently. You drag a card across the course one tick/column for each vote you want to cast.

On tools like Miro, Mural, etc. the visual indication of an individual’ pointer provides enough of a clue to prevent tugs of war around cards.

The result is an interesting “race” of topics to the fore.

Added bonus for the facilitator: the cards are naturally stack ranked once you compress the columns vertically.

To give it a little flair, you can create a finish line with some black boxes!

More often than any other factor, headcount growth kills companies.

The assumption of the status quo: Groups of people have advantage over individuals because they can do more work with better insights and fewer failures.

There are a ton of assumptions baked into this supposition.

• Everyone is working to a common goal.
• All individuals have input.
• Disagreements are raised and resolved to the benefit of the goal.
• Folks aren’t blocking each other’s work.

These assumptions ring less-and-less true as a group grows. We’re not wired to have the trust needed to fulfill them at scale. We can subscribe to a rule of law which forces them to be true, but we balk at those strictures—critique of Holacracy and Bridgewater’s Radical Transparency makes that abundantly clear.

Rather than trying to solve the problem, let’s dissolve it instead. Let’s not try to tightly align massive groups of people.

Option 1: Stay small.

If we can’t get the scaling we want out of a large group of people, what do we gain by having it? I’d argue, a headache.

Take a cold, hard think about what your needs are. Are you covering up problems with more bodies? Why are you doing the work you’re doing today? Can you drop some, most, or all of it?

Option 2: Allow a huge degree of autonomy around a vision.

Ok, you’ve got a big, nasty problem. It’s completely inconceivable that you’re get traction with a small group, cool.

Are you treating loosely coupled problems as a tightly coupled one? Could you design interfaces between your problems and let their insides be black boxes labled Magic ? There are certainly problems that can’t be solved this way, but I find that those are usually the ones which are sociological in nature. IE) Caused by overly large groups of people.

Option n: <Insert Option Here>

Obviously this isn’t an exhaustative list or a true dichotomy. I write down these two because they’re the path I rarely see travelled. Companies like Basecamp and Haier are showing how much can be done pursuing alternate strategies. I hope that we take their lessons to heart. Just because something is normal doesn’t mean it’s right. Solutions need to be fitted to their context. Design can dissolve problems or completely prevent their formation.

Everything is a trade-off because nothing stands in isolation. We need to acknowledge the rich, unpredictable ecosystems that are our socio-technical workplaces. Often that means giving up the illusion of control.

I spend a lot of time talking about systems for someone who doesn’t treat himself like he’s part of one. Maybe it’s my upbringing with its lack of acknowledgement of emotions. Maybe it’s straight pride. Hard to say. Whatever it is, I haven’t been acknowledging where I’m at and where I have and don’t have agency to improve that. This creates a whole bunch of stress, irrationality, and wasted energy. Time to stop that, eh?

I co-facilitated a workshop using Ecocycle Planning from Liberating Structures last week. One of the things we spent a lot of time talking about are the traps on either side. In the Poverty Trap live things which you’ve given lipservice to, but are failing to thrive. In the Rigidity Trap live things which are past their use-by dates—things which no longer meet their contextual needs. My habits are in both traps. They do not been the contextual needs and the ones that would are dying on the vine. Mindfulness works. Shipping junk works. Reading works. I know this, but I’ve been trying to live like an animal driving solely by intuition. It’s the very thing I coach against.

So, this isn’t good, but it’s shipped. Gotta start somewhere.

Measure and grind beans.
Let bloom, then steep for seven.
Press, savor, and smile.

This won’t be literary gold, but I’m writing it down. Something about morning makes it easier to do so. Maybe it’s that I haven’t had time to spend too much time inside my head since returning from the clouds of dream.

Early morning and late night share so much. The ones I’m speaking to are quiet, solitary things—free from the myriad stimulae of life—when you are left alone to ponder. These brief periods are good for the soul in a way that simply taking time during the day can’t match. Maybe it’s simple biology, and circadian rythms can explain it all away. The cause doesn’t matter much. What does is the differences between these dawning, dusky stretches.

Morning seems so pregnant with hope, possibilities, and promise. To continue the cliches, it’s a time for new beginnings. A time when nothing in our daily lives has been given the opportunity to chain us and limit posibility.

Nights. Nights are more bracing. They are times for reflection on the existent&emdash;on the bounded possibility that is our knowledge and resources and environment. They are times of wanton productivity, but it’s less a function of hope and more of desperation. There is so little time to achieve what we’re capable of building.

Ultimately it’s abundance contrasted with scarcity. Both are motivators, but the qualities of the products differ wildly. I’ve been thinking about these states of mind pretty much constantly as I’ve been trying to find a new job. More to come on that.

So what’s the point? I’m not sure there is one, to be honest. Does there need to be? Sometimes all we need is to start.