Productivity Is Not About People

How best to combine “software” with “management”?

First published on NewCo Shift

You’re doing productivity wrong. Actually, it’s worse than that. You have no idea what it is. And no, this isn’t some sort of technical, jargon-y sense where I’m arguing over whether to measure it in terms of lines of code, hours spent typing code, or something else. Your core understanding of productivity is entirely wrong, and it’s making your company worse at everything it does.

Productivity in the software world is discussed in terms of the individual, and usually phrased as getting more of a person’s time on the thing they were hired for. “Hey, I didn’t hire you to talk to users or attend training! I hired you to write code!” Even the developers join in: “Every minute I spend in meetings instead of writing code is wasting company money.”

This is stupid and wrong.

I had a conversation with a CFO recently who asked me why his company should use Puppet. I asked him in turn, what does it cost you to ship software right now, and what’s the value of lowering that cost? He said, not surprisingly, that he could not answer that. This isn’t to pick on him - most software CFOs would say the same things, since their job rarely delves into software operations.

Can you imagine having the equivalent job description with a manufacturing company? Picture the CFO of GM saying their job doesn’t require they understand the financial aspects of building cars. They’d be shipped out in disgrace. Yet somehow the software world tolerates ignorance of the financial implications of their core work product, software.

Sure, you might say, our finance teams can’t help us build more, better software for less money, but we don’t need their help because we intuitively know that more time spent writing code equals more productive development teams. Right?

No, you don’t. Again, you’re wrong. This is exactly, specifically how you’re wrong.

Toyota showed decades ago ensuring everyone is busy all the team is a great way to lower productivity. Yeah, you read that right. Lower. If you can’t shut the factory down (thus making everyone idle), you can’t fix problems at their source, which means every car you make is broken in the same way.

As another example, teams can almost never be perfectly balanced in output. Maybe you make doors much faster than you make engines, so if your door team is always busy, you end up with too many doors. Just like in development: The interface team might work a bit faster than the backend team, so they build an interface on a myth and then you can’t ship their work because there isn’t coverage on the backend. Oops. But hey, at least that interface developer didn’t spend any time in training, testing their prototypes with users, or bringing fancy coffee to the backend team.

The stupid thing is modern industry figured this out with its very first business consultant, Frederick Taylor, who developed a thing he called ‘Scientific Management.’ His ideas sounded good: I’ll hold a stopwatch and find ways to encourage people to get more done in a given amount of time. Seems reasonable, right? Probably more advanced than how most software companies do it today. In fact, he was really successful: He spawned our nation’s first management consultants, and they’ve continued to make tons of money on the fraud that he perpetrated more than a century ago.

Because that’s exactly what he was: A fraud. He was fired from his first gig because it ruined actual productivity, yet managed to convince corporate America that it was such a good idea they should ignore the little problem of it not working. Here we are a century later and the Harvard Business Review is still giving advice using Taylor’s own language.

But, you ask, what do I focus on if I’m not allowed to just track what the developer works on?

Now, Grasshopper, you set foot on the path to wisdom.

These are examples of waste in the form of rework (fixing quality problems later) and inventory (the built but unshipped interface work), but there are many other kinds that pervade modern software development. Lean Manufacturing is our most complete and coherent philosophy of productivity, and its name isn’t just decorative. It reframes the problem of optimizing productivity into the practice of reducing seven (or sometimes eight) kinds of wastes, including those above.

The funny thing, though, is that none of these wastes are visible if you just look at the individuals involved, so measuring what the people do isn’t just worthless, it’s actively counter-productive. See what I mean about all the wrongness?

Transport is a great example. You might have a person at your company specifically tasked with this (the most famous example from this is certainly from Office Space, but there are rational reasons for such roles in modern software teams). Intuitively you’d want this person to be 100% busy, yet optimizing the system to need more transport hurts the system even while it makes your individual stats look better.

Our world of software is fundamentally confused because it can’t move past thinking about the people to seeing the system. The first page of results on software productivity pretty much exclusively focus on the people, and even developers will say they should be spending more time writing code and less time doing other stuff (like in meetings with product managers or customers).

This is the challenge of our industry over the next few decades. It took around two centuries to get from the first industrial mills in the 1700s to the development of lean in the late 1900s. There are times where I think we can do better, learn faster, but then I realize how much more complicated our problem domain is, and I start to wonder. At least in factories you can physically measure inputs and outputs, and you’re consuming and producing discrete, easily measurable work. With software - especially SaaS built on the public cloud - discreteness is impossible, and even measuring the cost of inputs often approaches impossibility. It’s much harder to optimize systems that extend far beyond our own data-centers (if we even have them).

Nonetheless, this is our challenge. The first step is to move away from this focus on people, from this view that the developer’s precious time at keyboard is our main concern. Only then can we start to truly get better at building better software, faster, and for less money.