The Dead Simple Guide To Being a Good Manager

I've been fortunate in my career to have had a couple of great managers.  The rare combination of vision and execution found in my managers at Microsoft Research and DuClaw Brewing Company have established a kind of gold standard in my mind.  I've been thinking about management a lot lately.  I'll probably be head down doing technical work for the next few months, but after that I hope to build and run a new technical team.  Even though I aspire to be like the outstanding managers I've worked for, I don't think you have to be great to be successful.  As a matter of fact, I think that being a good manager can be distilled into 2 simple steps.

Step 1: Make It Terrible to be Bad

There are plenty of good people who are bad employees, especially in the technical world.  Since I've worked mostly in software, I'll focus there for a moment but the same principle is applicable to any industry.  My definition of a good developer is one who develops good software.  It's no surprise then that I think a bad developer is someone who doesn't develop good software.  As a manager, it's your job to make the environment unpleasant for bad employees.  Yes, you get extra points for offering up solutions to their crapitude like training and whatnot but even if you don't you can still be good manager simply by making bad employees not want to be there.  Why am I harping on this so much?  Because bad employees are a cancer to a team and they kill the team from the inside.  First we have displacement – a bad employee is sitting in the seat that could be occupied by a good one.  Next we have infection – bad employees have a very strong potential to turn others bad either by active instruction ("Here, junior dev, let me show you the wrong way") or through passive observance ("Why should I be any better if that guy sucks and he's still here?").  And finally we have repulsion – good employees don't enjoy working with bad ones so they leave.

Step 2: Make it Easy to be Good

The step is all about clearing the path for your direct reports.  Most technical people really enjoy what they do, it's all the other stupid stuff that turns what they enjoy into "work".  This is one of the reasons so many good and great developers work for start-ups, small software companies, or the few "big name" companies that you read about all the time like Google.  It's about the purity of the work as much as it is about the work itself.  This is where most companies inflict Death By 1000 Cuts – poorly managed web filtering that blocks technical blogs? Cut.  Stupid HR rules that require filling out a paper form once a month? Cut.  17" screen instead of a 24"? Cut.  Slow network, unstable email server, not enough hard drive space? Cut, cut, cut.  Sure, any given one of these isn't enough for someone to leave but put enough of them together and you've got one seriously unpleasant and ineffective environment to work in.

The steps are listed in order of importance.  Sure, you can start knocking off some of the low hanging fruit to make it easy to be good while you're putting the heat on the bad folks but you can't ignore step 1 and make it up by doing lots of step 2.  When a patient is diagnosed with cancer, the immediate focus is on eradicating the cancer not on adding lean muscle or lowering cholesterol.  Yes, the latter two can contribute to improved overall health by they simply don't matter if you don't take care of the most pressing need first.


  1. Hal Diggs says:

    wow I can’t believe this blog piece is over a year old and I just found it. I like the points but I wish you had proposed a couple of solutions to step 1.