Numerous paths that can be taken from that first step. Many more pressing in this moment in history. I'll speak to a piece I'm most familiar with, the MBA'ification of business and be eternally thankful for those covering the rest.

MBA'ification. Boeing'ification, if you will. The practice of promoting men (almost always) who have never been close to the actual work of the business to the top of the org chart until planes start literally falling out of the sky.

Now this has been covered.
But this is in no way isolated to Boeing. Every PE-backed org in existence is dealing with this in some capacity. A hollowing out of the ecosystem that creates real value for customers in order to make paper value for potential buyers. In many ways, this is not new human behavior. James C. Scott does an incredible job of impressing that in Seeing Like a State; showing the consequences of governmental practices that seek to simplify complex systems down to stats. What may be new'ish is it happening in business at this scale.

ZIRP, Citizen's United, and the complete failure of our regulatory bodies have resulted in a concentration of wealth and power in Capitalists the world has never seen. I'll punt on the morality of this--it deserves its own piece--and solely focus on its efficacy. This state of affairs is destroying RealValue:tm: as it extracts profits from it.

What's RealValue:tm:?

I mean the utility provided by the company that customers donate to, lease, or buy.
I mean a stable software product that saves folks time or solves a previously unsolved problem without toppling over under the injection of AI slop and hallucination. I mean a plane that goes from Point A to Point B without cutting short the lives and experiences of hundreds of individuals.

The crux of the problem is that the folks making decisions are too far away from the actual work. They don't have time or inclination to grok the nuance of their domain. As a result, nonsensical edicts are the norm. Couple this with the constant squeezing of Labor to optimize P&Ls and you have a completely disenfranchised workforce doing what they must to survive.

Who needs people...

It turns out that those stupid motivational posters aren't wrong. People are our greatest asset. All resilience to date has come from people. Robustness is the domain of machines. As we erode the agency and willingness of folks doing the work to help shape direction, we lose the ability to nudge outputs towards RealValue:tm:. Some argue that LLMs change this. I'd argue that Ashby's Law holds and hallucination is going to bite far before a model of the world will fit in memory. In fact, I'd argue that AI fervor is a case in point.

There is real utility in LLMs; I'm not a Luddite. However, no one in the Capitalist class seems to be serious about considering total costs. Not really a change, I suppose. What's different is that the total cost in this case will come due well before the subprime asset can be dumped. It only takes one security incident or long-term outage to cripple valuation. I can tell you from lived experience that there is no nuanced conversation about this. You're for the Capitalist fantasy of disempowered Labor or you're out.

"Now, I'm not saying they don't want you to go out there and inspect a job. You know, they do," Dean told NPR. "But if you make too much trouble, you will get the Josh treatment. You will get what happened to me."
Dean was fired in April of last year — in retaliation, he said, for flagging improperly drilled holes in fuselages.
"I think they were sending out a message to anybody else," Dean said. "If you are too loud, we will silence you."
NPR

Ultimately,

This damn-the-consequences AI rollout is effecively the same as what's come before; it's just happening at a dramatically accelerated pace. The lust for wealth and power coupled with supreme naïveté is driving decisions that the folks at the bottom are nearly uniformly concerned about to one degree or another. My hope is that we suffer isolated crashes that clearly tell the story of risk before we crash it all. With the Magnificent Seven's percentage of the S&P 500 sitting at 32.6% as of writing, and our industrial base in shambles due to MBA'ification, that ship may have sailed.

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, but the skill of 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.

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!

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 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.

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.