Bloatonomics - How Many Hands Make Much Work

18 Jan 2024

18 Jan 2024 by Luke Puplett - Founder

The inside story of how hiring the wrong people can tip into a self-sustaining economy of busywork

The lift door opens and I step out into a large open-plan floor of an office building. It's divided by a metal wall of filing cabinets which serves to discriminate the people on the project I'll be working on from the people of "the business". It's deliberate, emblematic, and all too familiar.

On the project side I see perhaps 50 people arranged in clusters of desks, and I discover there are more project people on other floors. This thing I'm going to be working on is the entire future of the company and touches almost everyone in some way, including the guy with the big keychain, restocking the vending machine.

To put this in perspective, Basecamp, the private company formerly known as 37signals, known for its email and calendar apps, and project management software that competes with the likes of Trello, Asana and monday.com, has around 60-70 employees.

At that moment, I'm the newest hire and I'm a software engineer. It's my job to build a small and tricky part of the login system and then leave. They've booked me for a few months. I end up working there for years.

Over the course of my first week I learn that there are up to 70 people working on this and they've been toiling away for months. I get introduced to the software development team, who will actually code Project Hail Mary and I discover that, of the team of five technical people, none have experience of building something so big, which figures, it's a smallish firm. What's unusual is that only one guy has been actually coding it, half of his time, the other half allocated to all the other technical demands they have. He's been there decades.

So we have a software project that's consuming half a floor of a two-story office building for half a year, and yet they've only half a developer actually building the thing. This was the most bizarre situation of my career. Later, as we tried to hire more engineers, one guy started, took a look around and then immediately resigned. As the months went by, I admired his perception and decisiveness.

It gets weirder

In the middle of the floor was a cluster of desks in an island with their leader at the end: the test team. There were a similar number around another island of use-to-be-technical-years-ago "analysts" who were tending to diagrams on their screens. I can remember the awkwardness of being introduced to these people because I already knew they didn't have the skill to build the app, else they'd have code on the screen, and that whatever they were doing was probably a waste of time. Somehow, soon I'd have to tackle this inconvenient truth, and there were lots of them beavering away and they seemed nice.

I thought of leaving, but the problem in the UK, and Europe, is that there are no well-paying software companies and no tech start-up scene of fearless coders who band together and tear into a problem organically. This is what life as a software developer looks like in the UK. It's why the Agile Manifesto was written, and why it failed.

When I tell this story, people can't understand what all these people could possibly have been doing for all this time. It's a question that I still wonder about now, even though I lived it, and it's why I'm writing this today.

I realized the company had no real idea what it was doing, and they had no idea they had no idea. And worse, they had no idea that people like me do have a very good idea. To them, people like me just type in the gobbledegook that makes it work, right? We're like gamer children who've grown up to look almost like proper adults.

They lacked software for planning what the engineers would work on, not even the most basic task manager. They had no access to their email or calendar from outside the office. The code wasn't in source control. There weren't even whiteboards in the meeting rooms.

There was nothing. Nada. But there were all these busy people.

I'd go to meetings and meet many lovely happy folks working on many important documents, and then I'd come back to my desk and wonder where to start. My boss, the Chief Technical Architect, who very proudly had his own island of devoted workers with fantastic diagrams, was not technical at all.

For weeks I tried to get to the bottom of where things were at and what actually was needed of me, and where to even start to design and code. But all my boss wanted from me was a big document with an intimidating name detailing what I would code, exactly.

He was obsessed with the production of, and signing-off of, stacks of officially named documents and diagrams. The whole company was all-consumed with making documents and spreadsheets and diagrams and meetings and no code, no software, no product, no progress. But of course they were; what else are you going to do when your job is to build an app and you can't code?

I remember one person was tasked with cataloguing and managing every English sentence that would appear in the app, each with a part number. To stay on top of this, they'd book many meetings will people from "the business" to pour over every word. In this ol' town the business decided these things, not usability experts.

It was as if these words would all be chiselled into granite in a public place for eternity. I suspect they'd learned this behaviour and that it was self-reinforcing. I imagine everything they'd ever done before had set with the permanency of concrete because of the way they all worked and had always worked, and that they could not imagine a different way, much as a tribe on a remote island cannot begin to imagine why the planes come.

Then there was the day I discovered that an outside agency was supposed to be building the front-end, the interactive web part of the application. Another company was involved!

I'd never seen these people. They had no desks with us and we had no communications software with them, or with ourselves for that matter. They didn't know they needed it, and when pressed, they refused to set it up. They wouldn't give them a desk. It was ludicrous. One day I strode off to visit them in their offices to try and sort something out. I ended up "illegally" setting up Slack and inviting everyone.

Come around these part making trouble

But still I kept getting heat for not writing my architectural documentation proposal, doc, thing. All the while, I was coding and campaigning for the things we needed. My boss didn't care. To him, I was a trouble maker who didn't respect his authoritay, and I knew he hated me. For a starts, I have zero TOGAF certifications.

They hired a couple more seasoned developers and finally I had some buddies on my side who understood the bizarre situation. We contractors were outsiders, it was palpable, we were to be weary of and gossiped about, but everything would be okay again once we left. We were city slickers drinking in a local's bar.

Fast forward a few months and our development team had colluded to ignore everyone else on the project and we just began building something, anything, that could be deployed. You see, software is built iteratively; you throw something up and then critique it, see where it's wrong and then rework it. It's more like sculpture than a skyscraper.

But during this time, all the people around us carried on just as they had been for months.

The test team continued to write test scripts for software that didn't exist. They were hectic busy doing this and their team had to grow to cope. The meetings all continued. The project managers walked around and some caused a nuisance, though one or two did kind of get it, were in on it and even helped cover for us.

I recall the day I discovered the test scripts weren't actually scripts of code but written instructions in Excel about where to click on the screens such that any screen change invalidated what they'd written.

Each day my inbox filled up with things that I didn't know what to do with. Endless noise. Once, my tech lead spotted an email come in with a giant Word document of pre-planned nonsense and he hurried around to my desk, "Luke! See that email from Jane that's just come in. Just ignore it. Get your head down and crack on."

And that's how we progressed.

We simply got on with our jobs as developers and largely guessed at what was needed. We knew that as soon as we delivered some version of something, that as soon as they saw it, they'd ask for changes by opening their mouths and saying words, and we'd quickly make those changes and problem solved. And this simple feedback cycle would negate all the planning and all the noise, and the "truth" of how software is soft and easy to change would become apparent. Though its actual end users were never really invited until the big reveal.

We eventually delivered their new product, the company was saved (divided and sold off by private equity, actually) and the little login thing I was hired for never made it into the product. Of course, it turned out that the customers didn't actually care for that feature as much as imagined.

"Everyone's got a plan until they get a punch in the mouth." – Mike Tyson

This tale isn't about the crime of not knowing any better, for that's resolved with the good type of hiring: getting the expertise you lack! And it's not really about the crime of not listening to the experts once you've hired them. No, it's mostly a tale of how so many well-meaning people can keep each other busy with fake work.

I'll never forget sitting on that floor, surrounded by so many nice folks, all mad busy like the parts in a human perpetual motion machine. Nor will I forget how so much of what they had been doing for months was paperwork that kept each other's plate full, including the guy that restocked the vending machine.

Every change to a plan in one team had a knock on effect on the plans of another. On an individual level, everyone wanted to feel like they're doing something important. Other people make work for idle hands. Sure, it kept the till ringing in the coffeeshop around the corner, and even the man at the petrol station miles up the road saw an additional few cars a week, but looking after the locals was not the goal.

This was the most stark and absurd self-sustaining economy of busywork I'd ever seen. It taught me how systems of people who don't build or create the final product, collude to make work for each other. And that to those people in the system, their hectic fake work is indistinguishable from the real stuff.

I think around seven people in total could have written that system in half the time, using feedback from actual users after a couple of months.

I believe there are three types of people: those who place greater demands on the people around them than they contribute to the bottom line, those who place less demand, and those who place less demand and actively optimize their own job.

It's as if we each have an R-value, like pandemic math, for the number of people around us that we'll infect with things to do.

Bicycle for the mind

I think this is why software companies, engineers run by engineers, are the most profitable companies in the world, or at least should be, for they too are now often bloated. Software development is the art of most effectively peddling what Steve Jobs called the "bicycle for the mind"–the personal computer.

More than replacing someone's job with a few lines of code, software developers are obsessed with efficiency and automation and are always trying to replace themselves with a few lines of code (as is evidenced by the potentially giant foot-gun that is AI-that-can-code).

However, we engineers tend to sow the seeds of our own demise by being seduced by complexity. They say the road to Hell is paved with good intentions and, in the pursuit of efficiency, we have a habit of over complicating our work.

Complexity is also a way to solve the problem of too many engineers. When the dish you're working on is smaller than the number of cooks, you end up having to needlessly break it into smaller pieces that can be worked on simultaneously, so every has something to do, and the complexity of a componentised system helps soak up the excess skill while setting up a permanent need for them.

This is why Basecamp is what engineers call a monolith: just a single giant app. It's also why Elon Musk poked fun at the convoluted microservices architecture of Twitter. Uber famously has 4,500 microservices, individual tiny programs that work together to make what is really a map and a payment system. They have 4,000 engineers and burned through 23 billion US dollars from 2009 to 2021.

Complicating things is also driven by the dopamine hit we get from solving stimulating problems, and when smart people are abstracted from the stimulating game of continually delighting the end user, we fill the void with complex code. Though it's also possible that teams that remain very close to their customers are destined to complicate their products with features.

But in general, people who hands-on produce the finished article, the thing that is traded, are better able to justify their existence. The other group who can easily justify their existence are salespeople. Not only is it easy to measure their impact on revenues, but their pay is so often directly proportional to their financial impact.

"A players hire A players, while B players hire C players"–Steve Jobs

In between the builders of a product and the salesfolk–leaving out many other important areas–is the adminisphere. It's where planning, discussing and reporting on other people's work happens. It's also where it's most difficult to measure the value of a job description, and it's exactly where aimless expansion most easily occurs, should financial resources permit. It's hard to hire people when the company is skint and it's hard to deny new hires when your record profits are plastered across the headlines.

We tend to hire people that look like ourselves and we tend to "hire down". In large corporate structures where Game Theory dynamics have emerged, we hire people who we think are good enough, won't get us into trouble but who will also not threaten our position or our ego.

And it seems we humans would also prefer to manage a larger team than a smaller one, and there are intrinsic and extrinsic incentives in building a small empire.

To counter this, Amazon adopted a "bar raiser" hiring approach. By ensuring high standards even as teams grew, they aimed to prevent the inevitable slide towards mediocrity, though, it's hard to imagine they've avoided recruiting a representative cross-section of society when they have well over a million employees.

Moreover, bean counters tend to work with the opposite effect by cutting back or outsourcing the skilled people who actually do the thing the company does, and quality suffers. Or they cut perks that are important for the retention of the most talented people. In short, they tend to cut corners and not their friends.

Elon Musk is both a widely disliked bean-counter and a wide-admired engineer. His companies run with industry-leading operating leverage which partly explains why he fired so many people at Twitter, turned off unnecessary servers and joked about its complicated architecture.

You need to be maniacal to resist the bloat and creep at scale, and even more erm, enthusiastic (?) to take an axe to 3/4 of it, retroactively.

Parkinson’s law

In 1955, Cyril Northcote Parkinson wrote a satirical essay for The Economist that became a seminal management concept. Parkinson’s Law states that work expands to fill the time available for its completion.

The core insight is that time acts as a gas to fill a container. If you give someone 4 hours to complete a 1-hour task, the task will subconsciously expand to fully fill the 4 hours. People will find ways to occupy the time allotted.

This phenomenon has been borne out across contexts:

• Government bureaucracy balloons over time rather than increasing efficiency

• Office meetings expand to fill the calendar space allocated

• Projects continue right up to deadlines rather than finishing early

Parkinson’s Law shows our natural tendency is to let work expand to occupy time available. The implication is that constraining time can thus boost productivity by forcing focus, as we’ll see next.

Just as Parkinson noted how work acts as a gas, work also acts like the economy of a country. I propose "Puplett's Law" to describe this phenomenon - work expands to consume the budget available for its completion.

When an unfocused organisation achieves financial success, surplus funds provide latitude for unnecessary expansion. Examples of Puplett's Law you may recognise, include:

• Startups hiring recklessly when flush with venture capital funding.

• Revenues grow, the product stagnates yet hiring increases.

• Governments spending billions on mediocre (or failed) software projects.

• Growing the employee cost base stated proudly as a goal or an achievement.

In an environment of abundance, people optimize for activity over results. The key insight I gained is that more people often reduce overall productivity by creating excess interdependencies, distractions which are then reinforced by the safety of the herd.

When disconnected from the aim to maximise profits or, when rewards are abstract, diffuse, remote, or uncontrollable and far-off as might be with a stock price, humans conspire to make work for each other without economic justification. The abundance of resources permits the invention of activities to sustain the livelihoods of those present and that activity creates demands which can be resolved with further hiring and, left unchecked, the mass expands to fill the availability of resources.

The statement that betrays a mindset

I am an investor in a small company with a big idea. They recently did a round of fundraising and one of the uses for this fresh money was, "to grow our headcount".

What an odd statement. As if hiring people is an end in itself.

I don't know why it needed to be said; you wouldn't say a goal is to "grow our electricity bill"! That's just an unfortunate byproduct of success. The goal would surely be to achieve your business and sales objectives and NOT grow headcount.

"the only real conspiracies are aligned incentives"

I like to say that the only real conspiracies are aligned incentives. It's funny that we talk about misaligned incentives all the time, but it's when incentives line up that we get an irresistible force. Once a company reaches a certain size and the money's flowing in, and it has succumbed to hiring less obsessive people, (or is run by the wrong personality from the outset), then the bloat sets in.

Here's the conspiracy:

• Incentives of the rat race supplant incentives of organizational success

• Inertia and Status Quo Bias, resistance to change, conformity, learned helplessness

• Fear, safety in numbers and blending into the herd

• Empire building, egos and job titles, vanity, polishing your resumé

• The tendency to hire non-threatening people

• The tendency for administrators who control budgets to hire more administrators

• Cutting or outsourcing misunderstood or distant people, lacking technical expertise

But this is good, because jobs, right?

The bloat puts people in jobs, bums on seats. I say seats because I've yet to see or hear of aimless hiring of people doing manual work, though perhaps that could happen: I can see how managers might throw manual workers at a task when rethinking the design of the product and how its made could be an alternative. But generally, we're talking about job creation for desk jobs.

For many people, possibly the majority of people, who don't live for work and are simply trying to live a quiet life, pay the mortgage, have a couple of holidays and sit alongside some friendly people in a comfortable office, this is a great thing. This is rarely the case, however.

In my experience, and we're talking about medium to large corporate enterprises, deadlines are still the way to exercise restraint, and that comforts senior management the use of human resources is sensible. So, most people are still rushing around or staying late, even if it's just meetings, emails and fake work activity. In fact, I suspect they're working more as a result of the bloat.

Remember, it's the activities of people that place demands upon others. This is how economies work and why immigration leads to more jobs and not fewer. America has such a large economy because of its population. It's why China's one-child policy was an economic mistake.

What's more, people tend to only add processes and rules and rarely remove them. Like tax law, it ratchets one way. Optimization-focused software teams recognize this and often have a recurring meeting in the calendar in which they expressly discuss what to start doing, but also what to stop doing.

Sat in traffic

I suspect such jobs of busywork in the middle fatty layers, sat in traffic, where daily interactions are just with other systems of people are the least rewarding and contribute to burnout and disillusionment. And I suspect that it's the diffusion of responsibility, the abstraction of the work from its positive impact on other people, customers, that starts the bloat which compounds in a feedback loop.

If companies were small and lean, its employees would each feel a greater sense of involvement in the value that's delivered to their customers, i.e. to other people in society. With reduced bureaucracy, meetings, and busywork, employees would experience increased intrinsic motivation and enjoy heightened levels of deep-focused productivity.

It's not a coincidence that lean, profitable businesses like Basecamp, founded and run by people such as Jason Fried and David Heinemeier-Hansson who vocally believe in staying lean and small, are able to offer high pay, shorter working days and globally remote working. They had this all figured out years ago.

I believe that if companies ran small and lean, there'd be more small, lean companies to work for, with happier people working less and earning more money. So no, bloat is not a good thing for business nor humanity.

---

Learn more