Why you could never pool an engineer

Why did compute get to be pooled and engineering never did? In an earlier article, Nearly thirty geek years in this industry, and the way we build teams quietly became the wrong shape, I argued that we still buy engineering the way we bought servers before the cloud; here I'll explain why, and it turns out to matter more than the observation.

Cloud runs on one trick. When you provision sixteen gigabytes of memory, nobody sets sixteen gigabytes aside for you. Your workload shares hardware with strangers, and the vendor owns far less capacity than the sum of what its customers believe they have. It gets away with this because workloads are bursty and, more importantly, uncorrelated. Your peak and my peak don't land in the same minute. Put thousands of us together and the aggregate is smooth. The vendor provisions for the smooth line and charges for the spiky one, and the gap between those two lines is the entire business of cloud computing. Everything else, the elasticity, the pricing, the marketing, follows from it.

Here's what I find hard to let go of. Specialist engineering demand has exactly those properties. The database expert one company needs for a week a quarter is spiky, intermittent, and uncorrelated with the week any other company needs them. Put enough companies together and that expert is busy full time, doing for all of them what most of them couldn't keep them busy doing alone. The arithmetic that made EC2 possible was sitting right there for engineering, the whole time.

So why did nobody do it?

The easy answer is that people aren't servers. True, and useless, because it doesn't say what the difference is. The actual difference is one word, and it's the same word that decided what cloud could and couldn't pool: state.

Compute could be pooled because it was made stateless on purpose. The instance holds nothing that matters; everything that matters lives in storage, which is a separate layer. That separation is the architecture. It's why a VM can be moved to another host mid-request and you never notice, and it's why nobody could pool a database server in 2004: the data was on it.

Now think about what an engineer with four years on a codebase actually carries. Why the ugly module in billing exists and why nobody has dared touch it. Which refactor was tried in 2023 and abandoned, and why. What the regulator asked for, in the words they used. Which stakeholder will veto the sensible option. And the one I think about most, from years of walking into other people's code: which three unrelated things break when you touch the function that looks safe to touch. None of that is in the repository. All of it took years to accumulate. It lives in a person, and it's the reason the person is valuable.

That's state. And you can't pool a stateful resource, because every time you move it the state has to come along, and the state was never written down. Where it was, it was written by someone on their way out, under time pressure, recording what was decided and rarely what was rejected or why, and it stopped being true the month after they left.

So the industry did the only thing it could. It divided time instead of capability. You can buy a day of a security consultant; what you've never been able to buy is their accumulated knowledge of your system, because that only gets into their head by being there. It's why fractional work stays senior and expensive: being useful in a few hours on a system you've never seen is a skill, and the market prices it.

Which means the thing that stopped engineering from being pooled was never the people. It was that the thing that made each person valuable couldn't leave them.

If that constraint ever broke, the arithmetic above would simply start working. I think it has broken, quietly, in the last couple of years, and not because anyone set out to break it.