I have been putting together some interesting correlations that I have observed throughout my career. It is giving me a realization about why I care about what I care about. I'm still figuring it all out, and this post is one attempt to vocalize a part of it.
I have noticed a gap in outcomes between software engineers who have had to be operators, and those that have never been operators. When I mean operators—I mean responsible for more than just producing code that goes into production, and if it breaks in the first 48hrs fixing it.
"DevOps" is a convenient label for this, but it's not the whole part. Of course a culture of DevOps (note: this is not a team whose name is DevOps) is a good thing. But that doesn't necessarily make someone an operator that has an interest other than software qua software.
One reason that engineers making products for other engineers works so well is because the ones who are most interested in this are the ones that need tools that don't yet exist. Because they are operating something. This is the best version of dog-fooding, or drinking your own champagne, whichever metaphor you prefer.
I've been an operator when I was a software consultant. My job was building software for my clients to operate. I felt the pain of operators, and it was tied directly to my paycheck. I had immediate access to my users. And if I couldn't solve their pain, they would stop paying me.
I've been an operator of a gym, with some friends. We started a powerlifting and olympic weightlifting gym in a warehouse. Paid rent, got equipment, and tried to get people in the door. It was, and remains very successful.
Growing up our family friends were operators. Construction, plumbers, electricians, roofers, you name it. One of them had a particularly strong influence on my I will never forget. I worked construction renovation with them for a summer.
In my career I have observed that software engineers who don't take on an operators perspective when building tend to have some commonalities. Maintaining their software is difficult. Operating their software is difficult. The concerns of those who are operating it are less important than some technical merits. This often holds back improvements. A perpetual list of things to do is seen a "a good thing" and predictable output is the highest possible good, regardless of whether there is any value in that list. Whenever the mood or task at hand feels Sisyphusean, that is when I know in my gut that the folks building do not have the perspective of an operator.
On the other hand. When the folks building have the perspective of an operator, you see creativity, and a varied approach to solving problems. These folks have more than a hammer, and there are more than just nails in the world. You see defensive designs because they expect the unknown. Problems rarely have a large blast radius. And best of all, the folks who work this way are able to move on from what they've built. They're not tied to it like an anchor. Because the maintenance is low, and its easy to operate. It might still have flaws and lack specific things. But they are able to go off and build the next new thing.
Because they are focused on value there is not an endless list of tings to do. Many things & directions have been ruled out. They don't react to incoming feedback by jumping and saying "How high?" They don't react until there is something with large value enough to return and work on it.
Why is the determining factor "acting like an operator"? Because operators have Important Things To Do. Operating the software is something that has to get done in service of the true task. Operating is never itself the goal. The less time and energy spent operating, the more time and energy you have for value creation.
As the line from Halt and Catch Fire goes "Computers aren't the thing. They're the thing that gets you to the thing."