I love the concept of self-managing teams.  Everyone figures out what needs to be done, and does their best to make the greater organization successful.  Beautiful.  Reminds me of the Shaker Village, the Russian Artel, or the Israeli Kibbutz.  All of which are (largely) extinct today.

There are three structural problems that, like termites behind the wallpaper in a French Quarter house, cause these “worker’s paradises” to fail.  Our job, as managers of the Innovation Engine, are to sniff ‘em out, expose them, and exterminate them.

Problem #2: PURE – Previously Undiagnosed Recruiting Errors

My old boss used to tell me there were three kinds of programmers.  Those smart enough to do the job, those too stupid to do the job, and those that could do the job but don’t care to.  Well, that’s not exactly the words he used, but this is a family blog.

None of us is the perfect recruiter, and every once in a while people get through the screening process that we’d rather have work for Al Qaida.

The incompetent developer (which we managers code name “moron”) is not always the one who takes the longest to do a story.  If some developers generally take longer than average to complete a story, they may be “slow” (as my grandmother would have put it) or the estimates may be dominated by optimists.  Until you’re measuring the amount of rework created by bugs found in QA (and the field), you really won’t know.

That doesn’t mean you don’t have to take action: managers have been acting on intuition since the Donner party decided to try the Sierra Nevadas in the winter of 1846.  Sometimes it’s better to eat the mule than have the whole group starve.

As engineers we tend to focus on technical proficiency, but there are some things which are hard to judge in an interview.  Like whether a developer has good judgment of when to refactor and when to patch.  Or whether a developer can embrace process changes or will struggle for weeks with the changes.  Or whether a developer has that certain combination of personality traits that make their coworkers doodle pictures of poisons, weapons and torture devices.

Now finding the sociopath may be more difficult than you think, because they’ve cleverly chosen to hide out amongst programmers, most of whom act as though still carrying scars from middle-school.  Like a submerged rock in the river, sometimes they can best be detected by the havoc they leave in their wake.

Developers generally treat managers using the same rules the Mafia use with the DA: no matter how much we loath our co-workers, we’re not going to rat them out.  One-on-one meetings with group members can give some indication of problems.  A few tactful questions at retrospectives may give some clues to underlying issues that aren’t being discussed.

Try inviting the group to try a little pair-programming and see what pairs get put together, and who threatens to quit.

Finally, the toughest people management issues are when good performers drop off.  Often this is a temporary fluctuation which just requires some coaching: do they need some customer visits to increase motivation, maybe a chance to learn some new technology they can apply, or sometimes there is a transient personal problem that just needs a little extra time.

Often, establishing expectations with people of what needs to be improved and then giving them a little time to do so is just the right prescription.  They may need mid-course correction and coaching to improve.  They might just need a supportive shoulder, or a swift kick in the pants, but the combination of communicating the issue, establishing higher expectations, and providing support is a good combination for improving performance.

Unfortunately, persistent decreases in performance are usually like that oil leak under your car every morning: they indicate there’s more going wrong than you thought, they’re probably going to get worse, and if untreated the future isn’t going to be pretty.

The most common mistake I see in my conversations with engineering management is the “conflict avoider.”  We’ve all made excuses about how long we need to wait to see if the situation can improve, how hard it is to find new talent, how much training time and ramp-up it is going to take to get a replacement up and productive.  And don’t forget the ‘ole disempowering “I can’t make a change in the middle of the project!”

These are just excuses. We owe it to both the team and the company to accept our mistakes, make the changes, and get on with building a better future.  That’s what we get paid to do.