#6 The Elephant Vanishes
Hi there, good people!
I was on a short, unannounced hiatus due to a sudden, very necessary summer vacation. Now I’m back on the weekly schedule! Subscribe if you haven’t already 😉.
Originally this started out as one long essay, but it turned out so long that I’m splitting it up into several parts. Today we start with part one: The Elephant Vanishes.
Day in, day out we build software: design new features, code it up, build automated deployment pipelines, manage infrastructure (hopefully as code), operate the whole thing (hopefully without too many spikes in blood pressure), troubleshoot bugs, handle customer inquiries… then there’s the whole meta-game of “doing agile right” (what a horrible phrase), creating a work culture that we want to work in, communicating effectively in large teams… then there’s the meta-meta-game of navigating strategy and big company politics… There’s a lot of stuff going in a large organization of a technology or technology-enabled company.
Today I will talk about none of the above.
Instead let’s return to the root of it all, the reason why we build software.
Some people call it “The Elephant in the Architecture”.
Gregor Hohpe calls it “Business Drives IT”.
It’s obvious, really. Anything we do as software professionals is rooted in our business.
It’s so obvious that we, large company folks, tend to forget all about it.
The Elephant Vanishes.
Why is that even a problem?
In small companies it is not. Small, independent product teams understand the value of their product and as a consequence they are highly aligned. They know why they build software.
In contrast to that, at large companies teams are often not small and the value of a product or service is not always clear - sometimes theres’s not even a customer. It is really hard to align a team without an idea of value creation. Sure, we can motivate teams to build shiny new things for a bit. But soon enough somebody will ask “Why are we building this feature?” or exclaim “This is stupid!”. At that point you have to know the reason, the business reason and communicate it effectively. Otherwise your team is setup for colossal failure. Eventually reality catches up with everyone: even a large company will not fund a team without customers, without a value proposition for very long.
So how did we get here?
Let’s start with Marx. He coined the term of “entfremdete Arbeit” which loosely translates to “alienation from work” (the German expression hits harder, is more piercing). This alienation starts with the alienation of the worker from her work product - mainly because it doesn’t belong to her and she’s making the mean capitalist rich. In consequence the worker doesn’t really care about the work that much, she’s alienated from the activity of work itself. Now call me marxist, but I believe that’s what we’re seeing in large companies: randomly assorted teams, who are tasked with building a service that they have no relationship to. Every individual is smart and takes pride in their craft - developers, product managers, project managers, people managers, designers, testers, operations, support, … but nobody really owns the product, many don’t even see the product, they only see tasks assigned to them. That’s the price we pay for this high degree of specialization and separation of responsibility into infinitesimally small units, which shall never be found again. Alienation from work.
If you don’t like Marx or just don’t care for Germans, bearded or otherwise, (come as you are) let me say the same thing again with a different framing: Skin in the Game. The central thesis of Nassim Taleb’s book (as far as I understand it) is that incentives need to be aligned with goals, otherwise actors will “misbehave”. A politician that can start a war without any personal downside will do so more willingly than one that has to go lead the charge. A financial trader who gets a share of profits, but doesn’t share in losses will bankrupt the firm. A developer who gets paid regardless of product success or failure will do the minimum that’s required of her - and then do what she enjoys. If we as teams and individuals don’t have “skin in the game”… or maybe “skin in the product” then we can’t really expect the result to be the highest quality & highest value product, can we?
Still not convinced? Let’s forget about those lofty intellectuals, old or new, and look at what constitutes our team - or rather: who. For most positions in tech teams we (= large companies) require a college degree related to the role. By and large we don’t really teach computer science student to understand the business value of software - instead we force-feed them UML or and sorting algorithms. These days there are many entrepreneurship classes, but they are optional and separate from the software - I doubt students are taught to ask themselves “what business value does this database table create?”. My impression is that understanding the business behind the software is secondary, optional from the college and university perspective. Tech media and social media is even worse, the most popular story is that of the college dropout running a VC funded startup, burning money and with no path to profitability. So we can’t really expect developers be curious about business models, can we?
Let’s take a short breather and summarize: In large companies teams often don’t understand why they build software, they don’t understand the underlying business value. This has several reasons: Marx, Skin in the game, education & media and probably others. The outcome is that teams build an excess of software, features, bloat that don’t create any value. Because they lack that understanding of the business model.
Compare that to our starting point, Gregor Hohpe’s prime directive:
Business Drives IT!
That’s doesn’t seem to be the case. It’s more like "We don’t know what drives IT, but at least we’re driving…“.
So it’s your job to make it reality. You’re a leader after all, right? How do you ensure that all technical decisions can be reduced to a business reason?
🤔
We’ll pick up right here, next time.
Hyperlinks
Life is Short
Having kids showed me how to convert a continuous quantity, time, into discrete quantities. You only get 52 weekends with your 2 year old. If Christmas-as-magic lasts from say ages 3 to 10, you only get to watch your child experience it 8 times. And while it's impossible to say what is a lot or a little of a continuous quantity like time, 8 is not a lot of something. If you had a handful of 8 peanuts, or a shelf of 8 books to choose from, the quantity would definitely seem limited, no matter what your lifespan was.
A great reminder of (1) how much clutter we face while working in large organization (interruptions, pointless meetings, process for the sake of process etc.) and (2) how little time we have to allocate. It feels like you should be able to get a lot done in one week, right? But if you chop it up into discreet quantities, say 10 x 2h blocks of deep work (rest of the time is taken up by clutter) then you really can only on 10 small, meaningful things in a week. Chose wisely.
The Elephant Vanishes / 象の消滅
Besides the title of this post it’s also the title of a shot story collection by Haruki Murakami. Great (non-technical) read, here’s a reading of “Barn Burning” to give you a taste.
That’s it for this week. If you enjoyed this ☝️leave comment or share it with a friend.