For an in dustry that prides itself on it s analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.
“So you've stopped coding, then?”
Several times over the last few weeks I've been on the receiving end of this question. It usually comes from somebody who's known me (or known of me) and they find out that my current role is as Director of Developer Relations for a hockey-stick-scaling startup called Smartsheet (http://www.smartsheet.com –check ‘em out, get a developer license, and make my CEO happy!). I got the same question several times in the prior two years too, when I was the CTO of the consulting company startup. There's this unwritten rule, somehow, that if “manager” or “director” or “VP” appears anywhere in your title, you've clearly stepped over that “not a coder” line.
And, strangely, I find myself growing a touch defensive about the question, like somehow it's an admission of failure or something, instead of the natural progression of the developer to senior developer to architect or team lead to…
Management.
It's a subject that's on my mind, too, because Smartsheet is conducting its annual employee review process, and one of the questions asked is, “Is your manager technically skilled enough to support you in your position?” At Smartsheet, almost anyone in any management capacity is expected to be hands-on coding at least some non-trivial percentage of the time, and, not surprisingly, almost all of them do.
And yet...should they? Should they have to? Should they want to?
What Managers Do
It's not an uncommon question: What, exactly, do managers do for us? Certainly, recent industry experiments would seem to suggest that a manager-free lifestyle is not a terrible thing to live. After all, with no managers, there's no status reports, and no meetings to go to, and no “Yeahhhhhh...if you could have those TPS reports by Friday, that'd be great” that developers need to deal with.
But, like the myth of the open office plan, the myth of the manager-free lifestyle is slowly eroding. Google, in particular, is discovering that a workplace where developers simply roam where they will can yield some impressive experiments and projects, but doesn't always yield what the customer (or the project manager, or upper management, or…) asked for. Part of that is because the developer doesn't have easy access to the people asking for the project in the first place - the customers are on a different floor, different building, different company, or different continent, and as a result, the developer ends up building what the developer thinks the customer asked for, rather than what the customer actually asked for.
And, worse, sometimes the developers know that they don't know what the customer wants, but without a manager, they have limited-to-no ability to navigate across the org chart to find out. This leaves them with the only real option left to them at that point: guessing.
This, in part, is what managers are supposed to do: When an issue or obstacle arises that keeps people from getting their jobs done, it's the manager's responsibility to make that obstacle or issue go away. Sometimes those obstacles are internal in nature, such as a logjam among the developers around what language to use or framework to adopt or methodology to use or some other technical decision needs to be made and the team is stuck. Sometimes those obstacles are external in nature, such as getting those-who-are-asking-for-the-software to sit in a room with those-who-are-building-the-software so they can build the software to do what it actually needs to do. And sometimes the obstacles are physical in nature, such as when a developer needs a 34" monitor to...er… um...well, I'm sure there's some kind of good reason that a developer needs a monitor that big. Or to manage the physical grow-out of the company so that developers aren't crammed four-to-an-office. Or any of a thousand other things that, when not properly handled, send developers' productivity plummeting.
This isn't to argue that all managers are good managers. Every developer knows, through our collective unconscious, of managers who put up more obstacles than they eliminate. But to paint all managers with that brush is to commit the same sin that managers do when they paint all developers with the “prima donna” brush. Or the “they're all bespectacled nerds” brush. Or the "400-pound hacker sleeping in his parents' basement," as a particular political candidate put it.
Famed ScrumMaster Trainer, and Planning Poker aficionado Mike Cohn was, to my great delight, one of my first managers when I began programming. (Ask him sometime if you see him at a conference - he's got some stories). He once described his job as “being the umbrella over the development team, to keep all the management off of them so they could actually get work done.” And, largely, that's what he did, and we were able to get some stuff done.
What Managers Don't Need to Do
Code.
Seriously. They don't need to be coding. It's nice that they can, of course, because certain situations call for a degree of technical expertise as part of the decision-making process. And some choose to do so because they came from these same roots that you and I do, and see coding as an enjoyable activity to which they can return at times, like salmon returning to their spawning pool periodically to perpetuate the species (or, in this case, to recharge their batteries so they can go out and fight the managerial battles).
As a matter of fact, I'll never forget one day when Mike came into our team room and asked a buddy of mine if he was the one to fix bug #453. My buddy and I looked at each other, then both dived into the bug-tracking system to figure out which bug #453 was. Turned out, it was a bug in the About box (this was back in the mid-90s and we were working on a desktop system. Don't judge), and Ron had, in fact, fixed it. In a very soft voice, Mike said, “I need you to back that fix out.” Now thoroughly confused, Ron and I just looked at each other until Mike explained further. “I spend close to forty hours a week slogging through management meetings and reports so you guys don't have to, and every Friday, after lunch, I close the door to my office and work on the code. The About box is the only thing I'll let myself work on, and I'll be damned if I let you guys take that away from me!”
(For the record, it was the most gold-plated About box you've ever seen. Scrolling text, a video Easter egg - you name it, our About box had it. It was a virtual monument to one man's ability to put every possible C++/Windows thing into a single, solitary dialog box of no real importance. It was, by far, the single most impressive thing in our application that nobody ever looked at.)
It's nice that Mike could code, but we didn't need him to be the technical expert on the team. We had a Technical Lead, and he made pretty good decisions. Mike was, to be sure, thoroughly proficient in C++ and Windows, but the truth is that the rest of the team was (probably) leaving him behind in raw technical knowledge, particularly as time went by and we learned more on a day-to-day basis that he didn't get the chance to. The truth was that we didn't need him to be the technical lead. We needed him to be our manager, making sure our desktops were working, the team room was ours (which it wasn't when I first started), and so on.
The more hours that a manager is spending heads-down in the IDE, the less that manager is available to resolve conflicts, make decisions, or erase obstacles that only somebody higher up the food chain can. Like the time the VP of Operations thought an internal outage was due to something somebody on our team had done - Mike went to bat for us, insisting that nothing we were doing would've caused the outage (which was true). Eventually it was “discovered” that the fault had originated from within the Operations group. (And the VP's voice, screaming at the top of his lungs at his Operations team for their mistake, could be heard throughout almost the entire building - which reminds me, never ever be that kind of manager.)
Look at it this way: if a manager is working an hour on code, it's one man-hour of code contributed to the project. But if the manager can unblock the team from an obstacle, it's a half-dozen or more man-hours of (perhaps more productive) development time that's now added. The manager becomes, as the military calls it, a force multiplier; their actions essentially multiply the effectiveness of the rest of the group, carrying far greater weight than their actions alone ever could.
And hey, if the net effect is to make the team better, does it really matter all that much if you're the one writing the code?
Summary
It's helpful, certainly, for managers to know how to code - having the ability to understand the issues that your team faces, and being able to weigh in with suggestions or ideas, even if they are more vague or abstract than concrete and specific, is a valuable thing. But a manager has to recognize that this is not their principal contribution to the team; they have a different title for a reason. Despite how the manager may feel, theirs is the role of facilitator and, sometimes, coach.
Which means it's maybe OK for managers to code the About box, even if it's one of those gold-plated Cadillac Escalade versions of an About box. But I wouldn't feel comfortable with them doing much more than that; they've got much better things to do.
