Retired Quarterback

Over the last several months, I've implicitly adopted a change in my management style that's been (I'm informed) quite a relief to the folks around me.

Several years ago, a candidate I was interviewing asked me an interesting question: "Would you describe your relationship to your employees as more like a manager, or more like a coach?" My answer was that I saw myself as more like a quarterback: directing the game, but playing on the same field as everyone else, taking the same hits, and working to develop more-or-less the same skills. In other words, I saw myself as engaging in the same debates as everyone else, letting my ideas compete with everyone else's ideas on an even playing field, and expecting and hoping everyone would throw themselves into the argument with the same vigor.

In retrospect, about the time she asked me that question is when my answer stopped being the right one. It sounded good at the time, and up until that point, I think it had worked well. When we were a smaller team, when I understood the details of most decisions that needed to be made, it was all right for me to jump feet-first into every conversation, throw my idea down first, and then let everyone argue with it.

But Zango has grown and changed an awful lot over the last several years (and especially in the last year). Among other things, the size of our technology team has grown. When there were only a dozen of us, sitting within a few yards of each other, we knew each other well, we understood each other, and most everyone was comfortable with the rough and tumble of our chosen rapid development strategy. But our technology team now consists of almost 90 people, spread across the US, Canada and Israel. Sometimes I have a hard time remembering everyone's name, and I simply can't have a close, personal relationship with everyone. (I hate that realities, for what it's worth, and I'm working hard to keep up to speed.) It's not that people won't argue or debate with me, but they're not as comfortable with it – and to be honest, neither am I. It's easier for one or the other of us to get defensive, and once that happens, it's hard for me not to win the argument: and that's obviously problematic.

In addition, I'm a lot dumber now than I was then. When we had two or three projects going at once, I could go deep enough into the details to contribute meaningfully to each. But last I checked, our portfolio consisted of some 30 active projects. There are too many details to manage, and I just don't understand the nuances of most of the debates well enough to put my opinion out first and have it be meaningful. When I have to skim as quickly as I do, my first take on an issue is generally going to be wrong.

Finally, and perhaps more controversially, it's more problematic when I lose a debate these days. This is something that I didn't understand for a long time, and even now, I'm still not sure I accept it: but I can see its effects. As a leader, it's critical to admit when I'm wrong – but the further I get from being able to have a personal relationship with everyone, the more important it becomes that I not be badly wrong in my stated opinions very often. There is such a thing as managerial/leadership capital, I think, and it's not unlimited.

So I've reluctantly dropped my "quarterback" metaphor. I still don't know whether I would more describe myself as a "manager" or a "coach," but the practical effect is that I try to sit back and listen to the whole debate before I weigh in; I ask a lot of questions; and if I finally speak up, it's if I have something meaningful to say. Generally, if I do have something meaningful to contribute, it won't be specifically technical: those sorts of things can and should get solved before I weigh in. My opinions need to be about higher level issues: the overall architecture that we're choosing, the relative priority of a given business issue, what level of resources to throw at a given problem.

Ding of the Month

Four years ago, we were in the process of moving our primary database server – a large, enterprise class box – from one rack at our data center to another. Given our architecture back then, we didn't have any way to accomplish this without at least an hour of downtime, so we planned the move carefully, with checklists galore. The time came for the move, we shut everything down, rolled the server down the hall and into the new cage, racked it – and then tried to plug it in. That's when we discovered that our hosting company had provisioned the cage with the wrong 220 plug.

A week later, after our second attempt at the move had proven successful, we took the original plug, mounted it on a small wood pedestal, and turned it into a trophy, awarded monthly. The recipient of this trophy is the person who makes the most boneheaded mistake over the course of the previous month. Like you would expect at any fast-moving, dynamic company, there's no shortage of nominees. J

The point of the award, of course, is not to kick people while they're down – it's intended to be an (admittedly perverse) way to communicate trust. It's a way to let people know that it's OK to make mistakes – indeed, encouraged – and it's fully in the spirit of the award that I've been one of the recipients (for deleting an active employee's AD account and Exchange mailbox in one fell swoop – while the employee was looking over my shoulder, no less). We would never give the award to somebody who was on a performance plan or whose performance we were otherwise seriously questioning – we'd handle that privately.

The interesting thing is that it's usually the very best employees who are the most frequent recipients. It's smart folks who are working their asses off, putting in the hours, trying to get their next project out the door on time, who are most likely to make a mistake. Nobody likes these mistakes, of course, but we want to encourage the conditions (hard work, moving fast) that make them possible, even inevitable; if we're not moving fast enough to make mistakes, we've ignored the reality of our space and the advantage of being relatively small and nimble. So giving people the chance to nominate each other over the course of the month, publicly reciting the nominees at our monthly All Tech meeting, and waiting for the applause and cat calls to die down between each name and description, is a way to "draw the poison from the wound" and balance both sides.

One note: we also have a "Save of the Month," awarded to the person whose spectacular efforts or intelligence have helped the company out the most. And trust me: those efforts are appreciated. But awarding a Save isn't nearly as much fun as a Ding.

A second note: managers aren't eligible for "Saves," but they most definitely are eligible for "Dings."

A third note: pictured below is our most recent "Ding" recipient, Jeff Malek, our VP of Product Development, who won for a bug in our decompression code that he managed to hide for three years.