Discover A New Band. Uncover A Mental Model For Technology Management.
What the title of an obscure "prog metal" album can teach us about technology systems management.
When I first decided to start this Substack, I knew I wanted to keep the aperture of topics pretty open. I also felt it was an interesting opportunity to create connections between many of my interests and hopefully, along the way, bring new insights and discoveries to anyone that happens to read these posts.
Today we’re going to explore two seemingly disconnected topics; Swedish Progressive Metal and a mental model to help you look at technology systems/teams/projects in a new way. Stick with me. At the very least you’ll find a new band to love or hate and maybe a new way to think about your work.
In the far, far away galaxy known as the 90s, I had one of those “you can’t tell me any other music exists” phases that you have in your youth. My drug of choice at the time was very complex, theatrical, narrative progressive metal. For the sake of simplicity - let’s just call it “Prog Metal” like all the cool kids do. Personally, one of the emblematic bands of this phase I went through was the Swedish band Pain of Salvation. I actually first discovered them through their second album (do we still call them albums?). But as you do, I immediately started exploring their other music. Their first album is titled Entropia. Check out the handy in-line player below to give it a listen.
My top track picks are:
Track 4 - People Passing By
Track 5 - Oblivion Ocean
Track 11 - Nightmist
So what does this have to do with anything, much less technology management? Well the word “entropia” stuck with me since I first saw it. Honestly, at first I thought it was a real word until I discovered the lead singer simply combined “entropy” and “utopia” together.
So what exactly is entropy? As one the members of our team at work reminds me, entropy is usually seen as a strict physics concept. Have a look here if you’d like that definition. But if you look a little deeper there is also the interpretation that entropy is a mental model. The team over at FS has an excellent deep dive on this interpretation titled Entropy: The Hidden Force That Complicates Life. Make sure you check it out!
In my career in technology it has always struck me how we seem to be fighting this constant movement from order to disorder. While we’ve wrapped all sorts of fancy techniques around how to combat this effect, what remains is that we’re just trying to keep systems, platforms, teams, strategies from becoming…less ordered.
In a recent piece in CIO.com, I proposed that when deciding on technology solutions, it was important to build a solution with just the right amount of technology, no more, no less. What I called “Goldilocks IT.” To me, the reason is clear; as soon as you bring order to something, the forces of entropy begin to act upon it. Over-engineering or complicating solutions will add increased complexity. And that leads to the management costs of the inherent entropy to be even greater. Now, I don’t have data to back this up per se so your mileage may vary, but I think there are some foundational ideas we can use to guide our approach.
Build only what is required at that moment.
Anticipate entropy and plan for it.
Teams and the solution/product aren’t done on “go-live” day.
Each additional feature to a product is likely to introduce some increased proportional amount of entropy.
Using a simple example of a technology product launch, once we launch we set into motion a lifecycle that shouldn't be seen as a linear decay. Instead it's a cycle of managing entropy until the environment deems the solution to be such a poor fit that the cost of iteration is higher than the cost of extinction. This condition arrives earlier if the teams are not given enough bandwidth to iterate once launch happens. Simply, the cost of late iteration will be so high, that your only choice left is extinction. This is why I like the “Goldilocks IT” concept. As soon as you apply technology to a solution, by default you introduce debt (because of the entropy forces at play). So sometimes the best way to mitigate this is to not use technology in the first place. It's not always the answer.
Now let’s tie this up in a bow. The key insights are that you need to plan for decay, you need to give teams ample room to deal with the decay, it’s going to cost you to do so, and sometimes the only way to arrive at the perfect balance is to not build technology in the first place. And so using these principles, we arrive at…wait for it…
Entropia!