Feet on the ground

Here's your free management tip for the day: get out of your chair and go see what's happening on the floor.

Every summer, I go to Boy Scout summer camp with my son.  Although this passes for vacation, it invariably ends up being a management clinic.  You might think you see where I'm going with this: chasing 30 Scouts around is just like chasing developers, right?

But that's not actually what I had in mind.  My real job at summer camp is to remove obstacles for the kids.  They're at camp to earn badges, and it's amazing how many trivial problems pop up and totally confound either the kids or the camp counselors, who are also kids.  Left to their own, both the Scouts and the counselors can be expected to churn on these problems, waiting for them to fix themselves.

I've seen counselors, for instance, find themselves without some tool or supply they need to teach a class, and they'll just wait for the tool fairy to drop by and bestow upon them a brand-new left-handed clipboard, or box of triple-gussetted ziplock bags, or whatever they're missing.  In the mean time, Scouts sit idle because they can't get their work done, and badges are not earned.

Other problems occur as well: sometimes there are disruptive students; sometimes the counselors don't know the material they're supposed to teach; sometimes kids aren't paying attention to work they're supposed to do outside of "class" time.  In all these cases, though, if you're sitting back at camp asking kids how they're doing, they'll all tell you things are great -- right up to the end of the week when they don't get their badges.

Now, it's true that some of these problems would eventually sort themselves out, but probably not in time for most of these kids to catch back up again.  I consistently find that if I spend time checking out classes myself, I can spot problems and take them to someone who can help, and we can get small issues turned around before they become large issues.

What's the lesson here for a software manager?

First, I'm not suggesting that you hover behind someone's desk so you can swat them when they stop coding.  I'm talking about finding the real obstacles to effective development and addressing them.

You might find that your developers need better equipment.  You might find that the requirements they're working from are woefully inadequete.  You might find that servers they depend on are slow or frequently down.

But don't limit your observations to developers only.  Check out the help desk.  This is one of the best sources for information about how your software is really performing.  It's one thing to read about a problem in a help desk ticket, but it's another thing altogether to observe your customers' emotional reaction to problems with your software.  Similarly, watch your software in use by real customers, or by your operations team, and you'll gain a new appreciation for real-world usability and performance.

When there's something wrong with your software, you'll probably learn about it eventually through your TPS reports, but you can keep an awful lot of small problems from becoming big problems by getting out there and looking around.