Against Config as a Lifestyle

Fight the Trap of Config-Heavy Human Middleware Jobs

Against Config as a Lifestyle

Many moons ago when I was about 11 or 12 years old, my family’s house became overrun with ants. We woke up one day to ants in the kitchen, ants in the laundry room, ants in the bedrooms, ants in the cookie jar, ants in my sock drawer, ants everywhere.

Later that morning, while my mother ran to the bank back in those days of physically depositing checks, I was dropped off across the parking lot at Wal-Mart with $40 in cash. I had been tasked with assembling an arsenal of ant spray, ant traps, borax to kill ants, and any other weaponry I could get my hands on.

We were going to war with the ants.

As a useless and clueless sixth grader, I was not an expert in ants, rodents, vermin, varmints, or any other type of pest. I asked the first Wal-Mart associate I saw for help in sourcing munitions.

“Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.” — Sun Tzu

“Excuse me, sir, do you know where the ant traps are located?” I asked the Wal-Mart associate.

“I don’t know, I just work here,” replied the associate.

The battle was lost already, even though I didn’t know it yet.

The guy just worked at Wal-Mart, and he didn’t know anything. He didn’t know where I could procure ant spray, ant traps, borax to kill ants, and anything else I could get my hands on. He had a ten-year anniversary plastic plate around his name badge and he didn’t know where the ant traps were located, he just worked there, and had worked there for ten years or more.

I pressed him further, as I was not yet used to negotiating with human middleware.

He took me across the Wal-Mart to the home goods section, stopping to pick up various cans in the aisles we came across, stopping to chat with a coworker for a minute, stopping to reshelve the cans he had collected along the journey.

We finally got to the Tupperware aisle. He handed me some Tupperware. He informed me that I could put my ants in Tupperware and use it as ant traps.

My family was doomed.

I didn’t get any ant spray or ant traps or any other type of physical or chemical weaponry that day and our house became overrun with ants. They overtook the kitchen. They overtook the basement. They ate the family dog.

The red ants and the black ants got into some kind of ant war. My younger sister was held hostage as a bargaining chip.

We eventually had to soak our entire house in gasoline, my father lit a match, and then we all hopped in the mini van and moved to the Yukon Territory in Northern Canada, where presumably there would be fewer ants.

“I don’t know, I just work here.”

That phrase still haunts my dreams.

How Deep is the Human Middleware Problem?

For several years now I’ve witnessed and developed a discomfort with what I call Config as a Lifestyle that is pervasive across not only tech companies but in the broader economy. The caricature is “Sip cold brew coffee, wear a beanie, and go entrench yourself in some process that forces your employer to become locked into you. Become a lifestyle engineer. Or a lifestyle operations person. Or whatever vibes feel right.” It’s the caricature on which Elon Musk has declared war in his takeover of Twitter.

Config as a Lifestyle breaks down to the deliberate decision to remove oneself from the outcomes of an organization and lock oneself into increasingly nuanced systems integration that is further and further from a positive P&L outcome or net profitability or a revenue center or reality itself.

On paper, Config as a Lifestyle makes some economic sense for someone taking up the cloth as human middleware. If you’re the only person who knows how to move data from System A to System B and then to System C, you may gain power from the configuration in place that you and only you understand. That $200k a year salary you are paid to do this is moated if it is allegedly very important that data moves from System A to B to C in this way. As long as you have the tribal knowledge, you have some semblance of protection, even as you start to disproportionately capture surplus value from your employer.

Certainly that Wal-Mart associate was doing Config as a Lifestyle. He wanted to mosey around, waste time, and if he were ever called out on it by his boss he’d claim he was reconfiguring cans on shelves.

However, as an attitude and as an operating paradigm, Config as a Lifestyle is terrible at both a personal and organizational level. It only works when markets are good and everyone is popping champagne. Knowing how to config something in a language or through a specific software is only as valuable as long as there is demand for it. Working in a config-heavy job over time and planting a flag in the ground that removes you from a department P&L strategy or the organization’s direction is a guaranteed way to ensure you are going to be doing more config.

Further, the idea that moating oneself into a purposefully complex system of one’s own design somehow affords long-term job protection or at the very least, the ability to stave off an initial layoff or two, is equally incorrect.

All across the market middleware is getting cut, the people and the technology along with it.

Almost every week now I get emails or texts from people who either got hosed or had their whole middleware tech stack hosed. Typically they work at a perpetually unprofitable tech company and/or they managed a stack that costs way more than the value it provides in terms of products, cloud spend, and human capital.

These jobs become too config heavy, too nuanced around details of the config, and become further and further distanced from actual business value and outcomes up until the point these jobs and products and infrastructure get dropped altogether.

Every week now I get many of these types of messages. Data engineering, data science, analytics, database management — that’s all dominated by human middleware buried deep in managing actual middleware.

I will see all sorts of things on social media or in emails or in talks with people about how cutting human middleware jobs is bad for the business.

“Those execs will soon learn they can’t do without Segment and Looker and Snowflake and a bunch of dashboards!” say the data middleware people. “How will they manage?!”

Well, I think they can manage in most cases. They’ll just take data dumps out of a system, use VLOOKUPs in Excel instead of joins in SQL on the cloud, and they’ll save lots of money and still produce many directionally correct insights. It’s happening everywhere. It’s the hip, new thing.

Human Middleware as a Zeitgeist

Go ahead and Google ‘human middleware’ and poke around at articles and blog pieces that pop up.

You’ll see a few posts from about 2012, when quantitative easing was in full swing, cloud adoption was taking off, and software-defined networking was getting further adoption. That’s really when the term starts to get thrown around.

In this Gartner piece from 2012, Mark P. McDonald argues against the proliferation of human middleware headcount as it is a “sign of distortion” within the organization.

In this blog from 2012, Alan Cohen, formerly of Nicira, lays out a way for human middleware to self-diagnose, and argues that self-diagnosed human middleware should find a new job, even noting the rise of developers and decline of operators.

What I don’t believe Cohen planned for in 2012, however, was almost another full decade of quantitative easing and cheap money.

Here is how the game works.

Sustained quantitative easing = more money to VC and cheaper debt = more businesses started or able to access more capital all across the market = more businesses hiring more people = more people who desire incrementally nuanced tooling be they ops or developers or marketers or anyone = more businesses started to make this tooling to sell bottoms-up to these individuals, etc.

Steve Ballmer knows what’s up. The fast eat the slow, and by putting unfinished products into market and relying on outside developers to ‘complete’ the solution, companies can get products into market faster so long as there are developers in market willing to take on the extra config work.

But the Consumerization of IT and bottoms-up selling do not go far enough to explain the full story. Even a lot of the literature on bottoms-up sales doesn’t get into this in depth, primarily because most of the bottoms-up literature is written by people with equity stakes in the proliferation of bottoms-up software.

What is actually going on here deserves its own new term altogether.

I call this the Bird Scooterization of IT.

Marginal employees are hired to solve increasingly marginal problems with an increasing set of point solutions that solve marginal problems.

The last decade or so of last mile transportation solves for increasingly marginal Point A to Point B with higher capital outlay required and more competition as the distance from Point A to B decreases.

First we had Uber. You could charter a black car in San Francisco right from your phone. Then Lyft came along and offered any car, not just a black car. Point A to Point B here is miles. Then, bikes took off, both with city sponsorship and as private companies. The cost of a ride for a customer was lower than a carshare, it was more unsafe for a lot of people as many people not used to city biking began using city bikes, and the average trip distance is on average less than that of a carshare. These also tended to be more capital intensive than carshare. The fleet needs to be purchased or leased, whereas the carshares did not (in most cases) own their fleet.

Then, scooters came along. These were even more unsafe, more capital intensive per unit, and covered an even shorter average trip, but consumers benefitted from generally even easier to find rides than carshares or bikes afforded.

Plus, you didn’t have to leave scooters at a designated docking area. You could ride the scooter right up to your house and toss it on the sidewalk.

What is the scooter market really solving for at the end of the day? Do most consumers actually want to leave a scooter at their door instead of leaving a bike two blocks away at the docking station and then walking the last two blocks? Plus, lots of people got ticked off at the scooters and refused to even ride them, for various safety concerns or simply because they hated their presence.

Additionally, bike shares and scooters can really only exist in urban areas with dense populations, where carshares can spread out to suburbs and eventually made their way to rural areas.

What enables Bird and over a dozen other competitors to exist? What enables smaller and smaller marginal problems to be solved with higher capital outlay? Cheap money. Cheap money is the enemy of automation.

More and more very cheap money means smaller and smaller problems get solved with more and more cash. More dollars go into venture capital. More stuff gets built, and the stuff that gets built solves smaller and smaller problems. New specialists appear with new job titles. In the case of scooters, there were even companies that formed and essentially consisted of people riding around in vans collecting scooters and bringing them to docking stations. For a two year period or so, some people took up the full-time job of collecting scooters, throwing them into vans, and corralling them back to docking stations, like cowboys herding cattle.

The same thing happens with IT and Ops job titles and responsibilities of all sorts.

MLOps exists because ML engineers need to properly productionize their models and outputs. So a new job was made.

There is RevOps, analytics engineering, a solid chunk of DevOps, and all kinds of jobs that have come into existence the past few years, all focused around moving data around a certain way, verticalizing data, creating more data, and storing the data in various places.

It’s all middleware. It’s human middleware using technical middleware to create some kind of back office or middle office process to appease middle management in many cases. Middleware begets more middleware begets more middleware.

And the human middleware is one of the most lucrative audiences, for both vendors and venture capital firms, especially seed-focused firms and investors looking to catch the newest project with X Github Stars or Y users subscribed to its newsletter so they can get money in early before these companies get marked up later with subsequent rounds of financing.

The human middleware has been king, and venture knows it. At least one-third of the Forbes Cloud 100 has a bottoms-up motion.

One wonders how much of this social graph of human middleware audience and its graph clusters is actively plotted out across Github projects, Twitter, and Slack groups and how many individuals are scored on propensity to contribute to growth metrics.

The playbook has been: win the early eyeball war with install numbers or Github Star counts to get to a Seed Round, win the eyeball war from Seed to Series A and get your treasury together, keep playing the eyeball war from Series A to B as you hire more people and build something that can sell for high five-figure and six-figure enterprise deals.

It’s also become very obvious to many how prevalent strategic social graph selling has become in some cases. Probably the most obvious example of this around the general data/analytics/ML world is Hex.

Hosted notebook tool Hex plays the social graph game to generate bottoms-up growth. There is a tight cluster centered around SQL-first developers and the ‘analytics engineering’ term that comprises an audience full of human middleware who will install or Github Star or trial anything that influencers tell them.
Then, more FOMO is generated. Strategically selling into this social graph cluster generates enough signal to get from a Seed to A financing, then an A to a B. But is this real growth or is it simply flooding a limited market with FOMO-based shiny object syndrome? Time will tell.

The Fallacy of ‘Above the API’ vs. ‘Below the API’ Jobs

In 2015, Segment co-founder Peter Reinhart posted a widely-circulated piece in which he argued that jobs were becoming ‘Above the API’ or ‘Below the API’ and that APIs would potentially replace middle management.

‘Above’ jobs are manned by humans who create software and ‘Below’ jobs are manned by humans who are told what to do by the software. The example used is Uber, which has human engineers building applications to tell human drivers where to go and what to do, essentially automating away the middle management job of a taxi dispatcher.

It’s a good framework and it’s certainly something to chew over. However, I’d argue that seven years later, most of these ‘Above’ jobs are not actually above the application at all. In fact, many of these software and data jobs are within the APIs or among the APIs or around the APIs because the software layer has gotten so thick with so many moving parts.

As a great example of this, Charles Chretien of Prequel posted this piece this past week about common problems and pitfalls with writing code against various database and data warehouse drivers, with many examples of common patterns and bugs to watch out for.

Aside from being a good reference document, I love this piece because it gets at the state of the market — all kinds of applications are produced that are rushed to market with bugs, and the vendors of these softwares have to rely on outside developers to fix and address them. These outside developers do not sit on the balance sheets of these vendors. Rather, they sit on the balance sheets of their employers. The vendors get all kinds of free work from the market.

The database drivers article is the perfect example of how config heavy certain jobs have become. When a data engineer has to spend a disproportionate amount of time configuring connectivity among an increasing number of SaaS applications and infrastructure, that person becomes increasingly distant from a P&L outcome at her organization. Instead, she either has to start patching workarounds or she has to open tickets or issues with these vendors or open source projects, and then spend extra time in config land.

She may like this. The vendors may allow her to speak at their conferences. They may call her a thought leader and write up all kinds of things about how important and smart she is.

As Steve Ballmer would say, “Developers, developers, developers, developers!” He loves developers in the market, off his balance sheet, who will configure his products and finish them in production in the market.

Meanwhile, these developers have to spend extra time, money, and resources fixing these problems and gluing things together, becoming human middleware and bearing risk. The developers are the ones who have backed up project delivery times at their employers because of these bugs. They risk losing face and credibility. They risk losing their jobs when times get bad because they spend too much time gluing and patching up fast-to-market, hyped-up products.

Of course, there are always going to be bugs or misses. However, when there are gigantic misses on ODBC and JDBC drivers from household name vendors with wide adoption, it really shows how much power the vendors and open source projects hold over their customers and users.

In fact, bottoms-up connectivity data companies like Airbyte and Meltano rely on this paradigm. As ‘community-driven’ integrations collections they take the valuation, they get the VC money, they get the most benefits, but who does a solid chunk of the work and who bears the most risk for bugs and issues? Developers in the market, off their balance sheet.

The only reason this has been so tolerated the past few years is because the organizations that employ these developers have had so much free money that they haven’t been scrutinizing their human middleware.

Many CFOs would pull their hair out if they knew how much they were subsidizing these external vendors by employing human middleware that spends more time among the APIs than above them. Some have already figured out the game here. Plenty of CTOs and CIOs know the game and they’re getting scrutinized too.

Take Stock of Config as a Lifestyle

The whole idea of taking on Config as a Lifestyle has been lucrative. For the human middleware on the cloud, it has provided social capital and modest increases in compensation, plus an increased ability to move more freely around the market.

The thought process of hitching yourself to a specific config-heavy profession or job title goes something like this:

  1. I am comfortable and safe in my job as a DevOps Analytics Operations Engineer. I know there are others out there who are also DevOps Analytics Operations Engineers because I am in a Slack group that the guy who made up that term manages and there are 2,000 people in this Slack group.
  2. As a DevOps Analytics Operations Engineer I must stay up on all of the current trends in DevOps Analytics Operations Engineering so I can be a thought leader in the space or find another DevOps Analytics Operations Engineer job in case I don’t want to work at my current employer anymore. I want to be able to move to any company as a DevOps Analytics Operations Engineer and I am more attached to this job title and profession than I am to my current employer.
  3. Therefore, I will take trainings, go to webinars that various vendors throw, and join all of the dozen industry Slack groups that have popped up around DevOps Analytics Operations Engineering. I will participate on social media with DevOps Analytics Operations Engineering influencers who have popped up and are affiliated with various venture capital firms or vendors, because I wish to show off my expertise and perhaps tap into their networks as well.
  4. I see a lot of growth. Last month there were 2,000 DevOps Analytics Operations Engineers in the Slack group and now there are 2,500. That means this is popular and growing. I have made a good choice. There are also more blogs about DevOps Analytics Operations Engineering.
  5. I see more growth in vendors as well. The problems I have with tools 1, 2, and 3 are getting solved by tool 4. Wow, I just need to buy tool 4 and look, a lot of people on Twitter and in Slack groups are hyping this up so it must be good. Some of these tools are even getting new funding and on a Series B, C, or further.
  6. Now that I am a year in, I am going to recruit other people I know into DevOps Analytics Operations Engineering. It’s an easy job. I work remotely. I have several other companies that have reached out to me about DevOps Analytics Operations Engineering jobs. I must be pretty smart. Maybe I will even make some online classes about DevOps Analytics Operations Engineering and charge people to take them. Maybe I can be an influencer too, I should start a blog and a Twitter account to start talking more and more about DevOps Analytics Operations Engineering.

And so on.

However, the risk borne by the DevOps Analytics Operations Engineer is that she identifies more with the job title than as an employee of the company. Does she know her company’s general strategy? Does she know even the top line revenue that her company did last month or quarter, or if at a larger organization, her region’s revenue or other metrics or financials? It’s unlikely in many cases.

HBR published a piece in 2005 which said that, on average, 95% of a company’s employees are unaware of, or do not understand, the company’s strategy. It’s probably higher now with the proliferation of human middleware.

Human Middleware Going Forward

I have seen the below meme and several variations getting circulated around again and again the past month or so.

This meme gets to the heart of the problem. In many organizations there are too many people involved in the assembly line. There is too much human middleware on the cloud.

The promise of the cloud as a cost saving mechanism has failed.

Yes, it drives quicker time to delivery. Yes, it’s led to an explosion of SaaS applications that do various things ranging from managing customer tickets to tracking emails. Yes, it’s led to the creation of many new professions and job titles of various sorts.

But if the new era of the cloud is so great, why are there so many humans working on it within organizations?

Wasn’t one of the largest promised benefits of the cloud the human labor saving benefits?

AI-powered automation is coming in some form or another, sure. We also already have macros and screen-scraping RPA and all kinds of integrations and connectivity available via SaaS and infra that can be paid, free, open-core, open-source, and every other way you can slice it.

But the biggest threat to human middleware is simply the fact that most organizations can fire large chunks of their human middleware tomorrow and be no worse off. It’s a nice to have, especially when the human middleware is not maintaining a core business-critical service.

There is not some grand technological replacement that is the existential threat to human middleware, not yet anyway. The existential threat is simply rising interest rates.

When looking at the market, there are a number of questions that come up:

  • How does this impact the US visa system, specifically H-1B tech employees? Are too many workers obtaining visas? Too few? How will the powers that be balance this out?
  • If bloated tech companies are contracting in headcount, how many of these laid off employees will simply exit the labor force? How many of them are independently wealthy through family or through years of high wages and savings?
  • How many of these middleware employees will find work in different sectors? Is there demand for these middleware skills outside of tech?

When looking at an individual level, here are some questions that human middleware should be considering:

If you are human middleware you need to sort out where you fit into the giant graph mind in the cloud, and analyze why you are human middleware.

If you are several layers removed from doing anything meaningful for your department P&L or your company’s profitability, ask yourself why this is the case.

Did you embed yourself into the position you are in, or were you shepherded there? Are you building anything meaningful or are you creating more config on top of other config? Why were you hired? Is it because you possess a necessary skill or is it because of bandwidth reasons? Are you the only person who can do something or are you the sixth hire for a specific type of job?

If you are human middleware on the cloud here is some advice:

  1. The best thing you can do is learn basic corporate finance. Low interest rates likely created your job, or at the very least they created the premium on your compensation. Many people who have only ever worked as human middleware on the cloud in their careers have been spoiled by the longest bull market in modern history, and now that times are tight you may want to start understanding how businesses actually operate. It will pay dividends far greater than learning a new language or reading another sea of database documentation.
  2. The next best thing you can do is ignore any influencer trying to sell you some new shiny object to try out and install. Influencers are used for bottoms-up selling, to generate FOMO, and to use you as the product so vendors can pump their Github Stars/install numbers/whatever other growth metric they need in the absence of revenue. They then trade this for valuation increases and in some cases, these founders then trade these valuation markups for cash via secondaries they sell. They can make millions while you struggle to glue their product together along everyone else in whatever “community” you are in. You take the risk, you do this on the balance sheet of your employer, and someone else gets the benefit. Bottoms-up selling to human middleware is going to die down for a bit. Purchasing decisions are going to be going through executives for the near future.
  3. Get to meaningful business value creation ASAP. Do not make excuses about how your boss does this or how you don’t care. This is your career. If you can’t have meaningful conversations about business value with your boss or department leaders or perhaps even with the executive team, then you are in the wrong place or you need to learn how to manage communications better.

When times are tight the ‘I don’t know, I just work here’ guy is the first to go. Don’t be that guy. Know the difference between ant traps and Tupperware.