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.

Mt. Adams

I'm off to Mt. Adams for a couple of days, to try to drag my sorry carcass up the south climbing route. I'll take pictures, and see if any are interesting enough to post when I get back. See y'all soon.

MSR Whisperlite International

Yikes. OK, for what it's worth, I don't recommend this stove. I've had an MSR DragonFly for years, and all things considered, it's been fine: no complaints, except maybe it's a bit heavy. But when I finally lost some key pieces to it (it's a long story, involving an airport, a full fuel bottle, and a dunderhead trying to combine the two), I thought I'd try something a bit lighter, and replaced it with a Whisperlite.

I'm reasonably confident I'll be returning it to REI this afternoon.

To start with, the directions have this encouraging quote: "A soccer-ball sized ball of flame is normal." Certainly my testing (in my garage just now) seemed to bear that out. The directions didn't indicate whether it was also normal for the stove to start spilling liquid burning fuel everywhere, but I'm guessing even MSR would consider that problematic. I managed to avoid burning the house down only by grabbing the still-burning, still-dripping-burning-fuel stove in my hand and running with it outside onto my driveway, where it could sputter and drip and burn in relative peace.

I'm not sure what went wrong, and quite possibly it was something I did: but I can say this, that in the last eight or so years I've been using my DragonFly, I've never actually felt like I was in danger of blowing myself up. A friend of mine once said, in reference to rock climbing, "I'm a father: I'm not going to participate in a sport where the penalty for a mistake is death." I'm not sure I agree with his sentiments about rock climbing, but I'm fully in sympathy when it comes to backpacking stoves.

And even after I got the WhisperLite working, i.e., not actually spilling burning fuel, I wasn't impressed. It seemed to put out barely any flame, and what flame did come out wasn't the sturdy blue flame I've come to expect from my DragonFly, but a weak, wobbly yellow thing that seemed unlikely to heat anything interesting. Maybe that's how it's supposed to be – but I'm thinking it's not what I want.

Two Holy Men

A couple months ago, when my cousin Brian was on his way to climb Mt. Everest (see pictures here, here and here), he ran across the Indian holy man below:

I've never been to India, but I understand that they're a common site.

I had occasion to think of this tonight, when I was with my friend Doug at a Devereaux concert, during the Bite of Seattle. I noticed a very similar gentleman, presumably homeless, dressed largely in what looked like women's scarves, twirling and swaying, sort of in time to the music. A group of hip looking teenagers were not-so-subtly laughing at him.

My suspicion is that the two men are alike in more than appearance, i.e., I suspect that by traditional medical standards they both suffer from some form of psychosis. But they differ in one key way. In India, there's a place for people like that. They know how to fit them into their culture, and in their own way, they are respected. I doubt that you want your son to grow up to be like that: but if he does, you know that he's not going to begging for change down on skid row. There's a way for that person to be understood, to fit, in a way, into society. And of course, in America, we don't. They're a problem to be solved, not a holy man to be revered. They carry the whiff only of spirits, and never of the Spirit. Think on that for a while, and ponder what we're missing.

Best Practices for Remote Dev Offices

As I mentioned in my last post, there's no doubt that managing developers in remote offices is tough. Here are some things that I try to do, which have helped:

1. Build trust. It's astonishing how much more gets done when teams trust each other. Two tactical recommendations along these lines:
   
   1. Travel. There's no substitute for butts on airplane seats. Debating database architecture long distance has an entirely different tone if the person at the far end of the call took twenty bucks off you at poker two weeks ago.
      
   2. Use video-conferencing. A person's face takes up more room in your brain than their voice. Plus, you're less tempted to check email while they're talking. We use the Polycom VSX system for our conference rooms and Polycom PVX for our desktops; the UI is annoying and buggy on both, and I have ongoing problems with the desktop audio, so I can't really recommend it, but it works better than just a phone call.
      
2. Communicate. Schedule regular 1:1 meetings with as many people at the remote office as possible. If folks at our Tel Aviv office stay late, and folks at our Bellevue office come in early, we can get maybe 8 hours of overlap a week. I try to have all 8 of those hours filled with meetings; usually, I'm about half successful.
   
3. Adopt the same processes, and fairly quickly. Two keys to doing this:
   
   1. Pick one set of processes and have the other office/company adopt it. Normally the dev process that will be chosen is, naturally enough, the acquiring company's. But don't just have an argument about processes in the abstract, or try to merge the two. Pick one, and move on it. If you're the acquiring company, be open to adjusting your own processes based on the other company's best practices – but everyone should expect that one set of processes will provide the framework for the discussion.
      
   2. Structure the organization at the remote office to support the process changes. You need to have people on the ground who have bought into the new processes wholeheartedly, and are willing to fight for them. Sometimes the only way this can happen is to bring in new people (e.g., product or project managers), who aren't wedded to the old way of doing things.
      
4. Choose the right managers. Managing remote team members is a difficult skill, and it needs to be learned. Just because a manager has been a success with local team members doesn't mean they'll be successful with remote employees. (I'm a great example of this.) If someone hasn't managed remote employees successfully before, keep a close eye out for problems, and step in quickly. This is a good opportunity for mentoring.
   
5. Be very patient. To a much greater extent than you can know, you don't understand the context for decisions made in remote offices. Always give them the benefit of the doubt. Sometimes that benefit isn't deserved, but in the end you'll get further (and be right more often) if your assumption is, "There must be something I don't understand," and not, "That was stupid."

Merging Dev Teams

One of the hardest things I do as a manager is to oversee remote offices and employees. In addition to our headquarters in Bellevue, Washington, Zango has development offices in Montreal and Tel Aviv. We hadn't intended to open offices there, but took them on (and are glad we did) as a result of various acquisitions and mergers.

When we first acquired CDT in Montreal, I'll confess, I don't think I did a very good job managing the office. The only people I had been managing for the previous five years had been sitting outside my door, and I had developed some bad habits. I took for granted the trust we had built up over years of working together, and I was used to communicating in a sort of short-hand. Most of the developers here could complete my sentences, and we thought about (or at least argued about) architecture in very similar ways. We had the same philosophy about where to invest extra architectural efforts, and where to take short-cuts, and if we had different perspectives on a given issue, we trusted each other enough to not take the debate personally.

But those same techniques didn't transfer well to a newly acquired company in a remote office. Because they weren't right outside my door, I didn't talk to the folks in Montreal regularly, and it took longer to develop a sense of trust than it should have. I didn't pay close attention to what they were doing. I didn't make much of an effort to visit the office or establish strong relationships. Not surprisingly, we have had more turnover there than I wanted. Even so, the team there has worked very hard, they've done a great job, and have accomplished a great deal – but at least originally, it was probably more in spite of my management than because of it.

The good news is that I've got very good managers working for me. As it turns out, some of them are very experienced with remote management, and I've learned a lot by watching them. So when the time came for our merger with Hotbar a little over a year ago, I managed to avoid most of the same mistakes I made after the CDT acquisition. There's still been turnover: you can't avoid it in any sort of M&A situation. But we did things differently this time, and our Tel Aviv office got off to a smoother start than our Montreal office.

Still, there's no getting around it: managing remote teams takes a great deal of effort, and an abundance of patience. In my next post, I'll try to cover some of the specific things I've been doing lately to help our remote offices be a success.

What would you do?

A little over an hour ago, I was finishing up a hike up and down the cable line trail up Tiger Mountain, near work. I had been mostly running down the trail, so I came around the last bend of the trail, and onto the pavement, pretty quickly.

The first thing I saw was a thin, sallow-looking man pulling a woman's purse out of the broken driver's side window of a black Lexus, two cars down from mine. There was glass lying all around the car. He was about 10 feet away from me. He looked startled, to say the least.

What would you do?

1. Swear at him. Loudly.
2. Whack him with your hiking pole. Hard.
3. Chase him down the street.
4. Call 911.

The correct answer, of course, is (e) All of the above.