Or: How to fight the hierarchy of disappointment
Chances are that in your company, once it hits a certain size, the hierarchy of disappointment makes an appearance — and, not to be hyperbolic about it, it is slowly killing your company.
“What the hell is the hierarchy of disappointment!?”
At the top of this hierarchy is the Business.
In the Business we identify opportunities in the market that are going to be huge (some would say yuge). And all we need to grab them is a tiny bit of product.
Sadly, Product in this company is a disappointment. Product says “no” to practically everything we ask, and the few things they do agree too, even though they’re pretty basic, are delivered at a turtle’s pace, and an unpredictable turtle at that. Not sure what Product is doing most of the time, except deliver some stripped-down-to-the-bone version of whatever we told them we needed, after the opportunity has already passed. Clearly they have somehow abstracted from the idea that money needs to be earned to keep this business running.
In Product we listen to the voice of the customer, and based on their feedback, behavior and other sources of data, figure out how to make our product even more awesome. Sometimes people from the Business descend from the stairs, and attempt to disrupt our roadmap with short term revenue boosting ideas to hit some arbitrary revenue target they set based on who-knows-what. These ideas are generally not particularly coherent from a product perspective, but hey — when it generates some cash, who cares, right? Luckily, we are good at saying “no” most of the time, and manage to pursue our own roadmap.
Sadly, our roadmap is progressing slowly, because Engineering cannot keep up. We’re not very convinced our Engineering guys know what they’re doing, because they keep complaining about all the technical debt that’s there, and that we need to stop everything to pay it. “Who generated all that technical debt?” we are wondering in Product. Apparently, the Engineering guys cannot write code without having to fix it later, and as a result we cannot build the features that our users are clamoring for and tested so well in our UX lab. On top of that, Engineering generates bugs all over, generates technical debt, and then proceed to complain about how we’re not prioritizing them cleaning up their mess. Engineering in this company is a big disappointment.
In Engineering, we do the real work. We’re writing the code that keeps this company afloat. No code, no product; no product, no business. Simple as that. But we do not get the space to do our job properly. There’s always product people chasing our ass, asking us to move faster, to cut corners, and asking what customer value unit tests really provide. We tried to explain technical debt, but we’re not really sure they understand the cost of all the gymnastics and duck tape we apply to hit their arbitrary deadlines.
Part of the challenge in Engineering is that our users cannot use the cool features we build some of the time, because our Infrastructure guys cannot seem to keep a simple server running. We deliver them a nice package — and all they have to do is use off the shelf tools — tools that every other company in the universe is also using — and run our software. Yet somehow, this proves too difficult. One day the database goes down, another it turns out they seem to be too slow to provision new servers to handle all the users that want to use awesome new feature. Infrastructure in this company is a big disappointment.
We in Infrastructure are the real warriors in this company. While engineering checks out at 5pm, and is having a fun family time, we’re on call trying to somehow keep this monstrous piece of “art” that they produced running. It’s as inefficient as f***, executes like 200 database queries per request, and then people are surprised we incur so much infrastructure cost because we need the largest machines in the universe to even keep this application running for a few hours before it collapses under its enormous memory leaks. Then, they asks us to reduce infrastructure cost, even though 80% of that cost comes debug logs saturating the network, and all the petabytes of storage it requires to keep them even for a week. Are these people completely blind? This company is a dead end. Exit now.
Sounds familiar at any level? Chances are that at least some of this may be going on in your company as we speak, unless you are structured to address it.
So, what to do?
Invest in tables. Big tables.
The problem largely originates from the distance trap. As I wrote in that article:
Distance simplifies things.
On the abstract, everything is easy; when you get down to the detail, hardly anything is.
So, what to do?
Well, how do you reduce distance?
When you think about it, this is what DevOps is about to a large extent. The old model was to have separate engineering and operations teams. This naturally lead to distance, leading to lack of empathy, lack of mutual understanding and lack of productive collaboration. In DevOps, you bring both together in one team, sitting at the same table. _Engineering _becomes painfully aware of how their code operates in production, and the whole team owns the development and operational aspects of the software together.
Agile teams in turn, pull Product and Engineering together. Through mutual challenging of each other’s ideas, and sitting at the same table, Engineering becomes more aware of the rationale behind the features to be built and what may possibly happen in the future. Product becomes more aware of bottlenecks, and gets visibility in trade-offs and their short and long term impact.
AWS takes the next natural step with BusProdDevOps, putting Business, Product, Engineering and Infrastructure together in one team, sitting at the same table. Business sees an opportunity, all functions analyze together what the options and the trade-offs between the options are at all levels, and well-considered decisions are made.
It’s so obvious, yet so rare.
Big tables, and the right people sitting at them. People that want to understand the other perspectives. Business who wants to understand the complexity of Product, Engineering and Infrastructure. Product who wants to understand the urgency with which the Business operates and the financial state of the company. And wants to understand all other functions, and gives feedback on what things are technically easy, what things are hard, and what the consequences are of decisions long and short term. And Infrastructure who can estimate potential scaling issues that may come out of all of this.
They all sit at that table. Perhaps more than seems necessary, until the gap closes. And all appreciate the full extent of the complexity of this company.