My Morlock Guide To Management, Very Quickly

As some of you no doubt know, and one correspondent has already told me, Scott Locklin has a new blog entry on what he calls "complification", illustrated by this amusing-to-nerds example:

Yale for example: more administrators than undergraduates. This is ridiculous; Yale students would be better off if they hired each undergraduate a PhD educated personal tutor and a maid/servant, and it would be cheaper. There is a Yale administrator event horizon at which the mass of administrators at Yale within the confines of the Yale campus will form a black hole from which light cannot escape. If current trends continue, this will happen by the year 3622.

Being Locklin, of course, he goes on to do the math and show his work on it. The remainder of the blogpost consists of a terrifying journey through the shared library crisis, in which I once again find myself accidentally aligned with a brilliant man; for most of my life in tech I busted my hump to make sure I compiled stuff with static binaries, even if it cost more time and resources. I didn't have a genuine philosophy behind it, as Scott does. Rather, I was just trying to make more money. Shared libraries always resulted in me doing more work after the fact, and since I generally charged flat fees for programming gigs, I didn't have any interest in doing more work.

That notion of productive laziness, as exemplified in the greatest book ever written, has defined my life for the better part of twenty-two years. I'd like to briefly explain how my "Morlock Philosophy" works, just for fun and as a response/amplification of the points made in Locklin's post.

I'm currently a people manager at $INSURANCE_COMPANY, which is a rare situation for me. Most of my life I've hired and managed subcontractors on a temporary basis to get things done. Most of the people I hired were fearsomely intelligent and absolutely focused on making money, so we got along well. I can only think of two people with whom I had to cut ties, and in both cases it was because I couldn't get them to return calls within 48 hours, much less within the one-hour timeframe I usually had to capitalize on an opportunity.

Anyway, here are my basic guidelines for managing people and projects.

#0: There's never any reason for a meeting, except an emotional one. Someone once wrote that "Corporations have meetings because they are physically unable to masturbate." If you enjoy meetings -- if you really look forward to sitting down with people and talking in circles about something -- I have no use for you. Meetings are where ideas go to die and work goes to be postponed. Send me an email if you need a decision. Slack me if you must. Call me if it's critical. Otherwise, sit your ass down and do your work.

A meeting is the single most expensive and wasteful thing a company can do. You take a lot of expensive resources, sit them down in a room, and watch nothing happen. Why do "leaders" like meetings? Because they have no self-confidence, or because they need the serotonin boost of looking at all the people whom they control, or because they can't stand to be alone. I personally get no enjoyment from having minions. I don't need to mark my territory. If you work for me, it's because I trust you to do what you do best. If you have questions, send an email. And if you don't hear from me, as Van Morrison once said, it just means I didn't call.

That being said, there are occasionally emotional reasons to have a meeting. You have a bunch of people at remote locations who could use a little human companionship. You have things that you need to say to the group that should be said in person, like bad news or good news that sounds like bad news initially. Or you want to foster friendship and fellowship among your team. Those are emotional reasons, and I accept them. I'm exceptionally fond of all my people and I'd like nothing better than to hang out with them. The problem is that doing so isn't productive.

#1: Don't be vague. Most managers forget what it's like to be managed badly, the same way most parents develop a strange amnesia of their own youth. When you are vague or hesitant with your people, they will fill in the blanks for you, and you won't like what they fill in. I was in a meeting a long time ago where a director wanted to call someone out for being worthless, but because he didn't have the guts to name the person, he just rambled vaguely about "if you have a problem like..." Afterwards, the text messages flew fast and furious. "Was he talking about ME?" The net effect was fifty hugely demotivated people, instead of one properly chastised person.

#2: When in doubt, be kind. Nothing more to say on that.

#3: Don't emasculate your sub-leaders or project owners. Nobody likes to be micro-managed. I can't think of a single instance in history where I was glad to have someone "checking up" on a task they'd assigned to me. The best-case scenario is that you waste half an hour telling someone what you haven't finished, and now you are half an hour behind. The worst-case scenario is that you get sick of it and quit.

In God Emperor Of Dune, the Bene Gesserit explain how they deal with Emperor Leto:

Our address to him will continue to be: “Tell us if we threaten you that we may desist.” And: “Tell us of your grand plan that we may help.”

This is a useful way to deal with both your managers and your people. If they're screwing you up, or if you think you're screwing them up, it's worth discussing. And if you can be helpful up or down the chain, you'd like to know that as well. Nowhere in there is there room for "checkpoints" or "status meetings". Those behaviors are born from insecurity.

#4: Never act in arbitrary fashion -- but if you must, then be forthright about it. Ninety-nine times out of a hundred there is no harm in sharing your reasons for a decision with the people affected by it. This is true in parenting as well, I think. "Because I said so" should be reserved for emergency situations. And if you do, in fact, reserve your arbitrary commands for emergencies, they stand a greater chance of being followed.

#5: No cargo culture, not ever. The mindless adoption of management techniques and practices, simply because they are successful elsewhere, is the behavior of an idiot. Every single recurring practice you inflict on your department is a massive cost to productivity, so if you don't truly understand how and why such a practice should exist, do the safe thing and strangle it in the proverbial crib. Here's an example: I worked for a company once that brought in a ping-pong table, presumably because they'd heard that Google had ping-pong tables. People started playing ping-pong. The managers got very upset at this waste of time. After six months, they had the table put in a storage room. This was hugely demoralizing, far more so than never having the ping-pong table in the first place. And our workaround as employees -- to hold hour-long "focus meetings" that were, in fact, daily ping-pong tournaments in the storage room -- probably cost the company a hundred grand or more in lost productivity.

#MostImportant: When in doubt, be lazy. Mike Gancarz says that great programmers are lazy. By which he means: they don't bother with unproductive activity. They only do what's necessary. If your presence in a meeting isn't life or death to you or your project, don't go. Don't return unimportant calls, don't read unimportant emails, don't allow unimportant people to waste your time. Once, as an experiment, I deleted 200 unread emails from my inbox to see what would happen. Three of the emails turned out be fairly important, and in all cases the people involved eventually contacted me again. So I saved myself 197 emails' worth of time.

The purpose of being lazy isn't to waste time, but rather to save it. It is a point of pride for me that I not only manage more than a dozen people, I also produce more written output than ninety percent of them. I do this by being lazy about things that don't matter. The rather insane German fellow for whom I worked at TTAC said many insane things but he also said one sane thing: "Instead of writing me a long email, why don't you write a story and make money instead?" Any time I'm tempted to join a two-hour meeting with absolutely zero nutritional value, I sit down and write two thousand words instead -- or I read the classics.

* * *

I'm moving out of my house this week, and I'm unearthing memories with the rapidity of the first people to investigate the La Brea tar pit. The IBM xServer pictured at the top of this column used to run this website and several others. It's going to be thrown away, because it's no longer useful. I paid six or seven grand for it, as a refurb, and I probably earned thirty times that much from what it hosted. We should all serve our causes so well, and so faithfully.

A commenter on one of my articles from last week claimed that I was afraid of change. In this one respect at least, he's right. I don't like what has happened to computing over the past decade. We have assembled a Rube Goldberg architecture of idiocy where we once had straightforward operating systems running on bare metal. The trend is ever towards complification. More layers, more APIs, more virtual environments. More managers, more executives, more people who thrive by doing email and meetings instead of doing creative work and proper leadership. I console myself like so: maybe it's the low point of a long cycle. If you are reading this in the year 2050, after some inevitable Victorian-esque abandonment of what I like to call the promiscuity of unproductivity, then I salute you. Go be lazy. You've earned it.