Human Infrastructure

One of the last things I can see myself doing with my life, below "astronaut" on the list of unlikely careers, is managing a software company. Yet for some reason I've been reading the archive of Joel on Software recently. I find myself nodding in agreement with his descriptions of managment techniques that don't work, including musings from his days in the Israeli army about military-style management and why it's necessary and why it doesn't work if your people can quit. (What does he say works? Trusting the people who take pride in what they do.) Mostly the guy is just a good writer, funny and insightful, one good point per entertaining essay.

Anyway, one essay in particular got me thinking. It's called The Development Abstraction Layer.

He starts off with the story of a talented programmer who saves up enough money to live for a year and then quits his job to write a piece of software better than anything else on the market: "Flawless, artistic, elegant, bug free." Then he sets up to take orders from customers.

Of course, no orders come. Why?

"He's pretty sure he knows. 'Marketing,' he says. Like many young technicians, he is apt to say things like, "Microsoft has worse products but better marketing."

When uttered by a software developer, the term "marketing" simply stands in for all that business stuff: everything they don't actually understand about creating software and selling it.

This, actually, is not really what "marketing" means. Actually Microsoft has pretty terrible marketing. Can you imagine those dinosaur ads actually making someone want to buy Microsoft Office?

The real reason, he says, is the lack of infrastructure to support the product. Not just marketing to make people want it, but sales, to make sure they can get it, and customer service, to make sure they can use it, and billing, to make sure they pay for it, "and public relations, and an office, and a network, and infrastructure, and air conditioning in the office," and "accounting, and a bunch of other support tasks."

But this isn't limited to software development:

The level a programmer works at (say, Emacs) is too abstract to support a business. Developers working at the developer abstraction layer need an implementation layer -- an organization that takes their code and turns it into products. Dolly Parton, working at the "singing a nice song" layer, needs a huge implementation layer too, to make the records and book the concert halls and take the tickets and set up the audio gear and promote the records and collect the royalties.

.

While I was thinking about that, I read Teresa Nielsen Hayden's latest post on book publishing. Teresa works for Tor, putting out mainly science fiction novels. She sometimes uses her blog to explain how book publishing works, and why nobody ever reads books that have been "self-published" by their authors. Why, in fact, self-publishing is a scam, even if the people who print your book offer to help you "market" it.

Huh, I thought, a publishing company is like a software company without any programmers! The whole company is "infrastructure." The product comes from somewhere else. And no matter how great that product is, "self publishing" almost never works.

Then I thought about reality shows like "American Idol" and "American Inventor." The prize on those shows is, basically, an infrastructure.

Even the military works this way. Joel Spolsky says "It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1"

All of this has opened my eyes a little. First of all, I am not going to think of "efficiency" in the same way anymore. When I hear that big charities spend 80% of their donation income on administration, I am not going to be appalled. Every effective organization spends 80% of its income on administration, according to Joel. An efficient organization is one in which the infrastructure works invisibly.

Secondly, I am going to try to be more respectful of the people who actually do all of this infrastructure work. I'm guilty of complaining bitterly about "bureaucracy." Of losing my cool with customer service people. Of noticing only when the secretaries and payroll people at my university do things wrong, and not all of the times they do things right. Of not appreciating that their job is both hard and vital. The lesson here is that the infrastructure is in some ways more important than the product. A bad product with a good infrastructure may succeed, but a good product with a bad infrastructure will not.

I know I have a tendency to forget this. Which is one of several reasons why, though I notice bad managment all the time, I wouldn't make a good manager either.