There’s an anecdote in which Gorbachev (or Yeltsin) visits New York (or London, or Austin) in the waning years of the USSR. He is astonished by a grocery store, with its fully stocked shelves and no lines. He asks, “Who is in charge of the supply of bread to New York?”
because it is ingrained in him that serious work is best done by a single planning mind. Yet the evidence said otherwise: New York has plenty of bread, and Moscow did not.
No one is in charge of the supply of bread to New York. A thousand people are in charge of the supply of bread to one store. A thousand small problems, each solved in their own way, are tractable; one big problem, solved “efficiently,” is not.
In an enterprise, it sometimes feels efficient to put a person in charge of the supply of servers, or testing, or purchasing. Yet by lumping these small problems together by category, you’ve created a big problem that can never be solved well for everyone.
Teams need different servers, at different paces, so gathering guesses and then planning and then allocating is always going to be too slow and never accurate. Letting each team get their own is a small pain for each team, but a big pain for no one. Even better: offer a general solution to solve 80% of the problem (fill out this web form to get a company-standard cloud VM within five minutes), and then let teams handle their special needs themselves.
The stores in New York mostly buy bread from a few distributors, but they can bake their own bread if they choose.
When developing infrastructure and tooling for an enterprise, I don’t want to be the central planner, very efficient at slowing everyone down. I want to be a distributor. The internal market is large enough and specific enough to target. When I do my job well, many teams will use my products. A few will still bake their own, and I’m not in their way.