Back in the Before Times, I went to a Haskell-flavored FP conference, where one of the speakers said something that blew my mind. Sadly, it seems that I didn’t write this up at the time (although I swear I wrote it somewhere… maybe in an internal company memo) and I’ve lost the details of who said it. If by some quirk of odds, it was you, dear reader, please let me know!

The “rule of eights” is a handy way to think about feedback cycle time and the effect it has on human attention spans. This is something I heard–and am probably misremembering to some extent–at an agile conference back in the day. I can’t take credit for this but I also can’t remember who I heard it from. If you know who came up with this, please contact me so I can properly attribute this.

About ten years ago, I was introduced to something called “The Bad Idea Game” by Danvers Fleury. We were doing a company strategy retreat. Fortunately we did not spend it all on wordcrafting mission and values statements, and we actually engaged in some good strategy. The bad idea game was a fun exercise that didn’t seem to produce any directly useful results. At first I thought it had been a waste of a precious hour from our limited supply.

Suppose we build a road. If we build it road and walk away, it will decay into a hazard before long. It will be scoured by wind, rain, and sand. Ultraviolet rays from the sun will break down its molecular structure. The shifting earth beneath will crack and buckle it. We must maintain what we build, and that requires expense. Suppose we decide that the road is no longer needed or that it costs more to maintain than it is worth.

When trying to communicate, we sometimes use the same word thinking that it means the same thing to everyone. But words are slippery, multivalent things. I can speak a word with one meaning and you might hear it with another. The result is the illusion of communication. As a leader you must be aware that your words can be taken in different ways. In one kind of culture, people might look for the most sinister possible interpretation and assume that’s what you must have meant.

When building an application, we tend to select a database technology based on its transactional characteristics. We consider raw performance, API style, consistency model, data model, and deployment architecture. That’s about as much as your service cares about: can it meet the functional and non-functional requirements for the production behavior of the service? Even in a microservice architecture where no other application is allowed to access the service’s database, that database probably has a bunch of other clients.

Suppose we’ve had a recent error with a Kubernetes cluster. As often happens with a problem in our systems, we noticed it first in terms of the visible error, which we could state as “Builds did not complete.” Now we want to trace backwards to figure out what happened. A common technique is the “Five Whys” popularized by Lean thinking. So we ask “Why did builds not complete” and we find “Kubernetes could not start the pod, and the operation timed out after 1 hour.

Driving down a shady road, windows down, listening to the frogs and crickets, my family was in the car talking about various stuff and things. This summer evening we happened to talk about the invention and emergence of the word “yeet.” I observed that it was kind of cool to have a word with a known origin and etymology, even if that was only because it was a made-up word. My daughter instantly responded that “all words were made up by someone.

In discussions about change in a complex system I commonly hear people object, “We can’t do that because X.” (That statement often follows a passive-aggressive prelude such as “That’s all well and good” or “being tactical for a moment.” Depending on your organizational culture you may also hear “That’s great in theory…” Or if your company is more aggressive-aggressive, “Get real!") My advice is to reformulate that statement. Treat the blocker as a missing prerequisite: “In order to do that, X must be true.

I’ve seen a repeated pattern that plays out in many companies. Delay, or more accurately, the perception of delay induces the creation of “extra” layers in the architecture. The pattern goes like this: A component or subsystem needs to add a capability to serve some end-user need. It will take “too long” to implement that capability in the component. (This is where the perception part really steps in.) Maybe the team is stretched too thinly.