Ellen Isaacs: Managing collaboratively

Throughout my career as a researcher and a user interface designer, I have both studied the way people collaborate and built software to help support collaboration. Perhaps it is not surprising, then, that when I moved into software engineering management, I did it as part of a collaborative team. I am currently one of "The Gang of Four" that is running the engineering department at Electric Communities, a software startup company in Cupertino, California. Trying to explain our structure is difficult, in part because it is unfamiliar. It also raises suspicions from people who are uncomfortable with the notion of sharing power or of distributing responsibility across a team.

Having shared a leadership role, I believe that it can be far more effective for two or more people to take on the multi-faceted responsibilities of a leader rather than concentrating it within a single person. Certainly, co-leaders will not work for all people in all situations, but I believe it is a viable organizational model that should be considered where appropriate. This article is an attempt to characterize the advantages and pitfalls of collaborative leadership based on our experience.

First, let me explain the structure of engineering management at EC. From November, 1997 to April, 1998, engineering was run by "the Gang of Four," which consisted of Gordie Freedman, Trevor Morris, Rob Jellinghaus, and me. Gordie, Trev, and Rob are all supremely talented engineers, each of whom has different areas of technical expertise and different organizational strengths. I had joined the company as its user interface designer, but had moved into engineering to help with scheduling and organizing the department. When The Gang started, Gordie was director), I was an engineering manager, and Trev and Rob were senior technical leads. Three months into it, Gordie went on leave of absence and I became director. In practice, we ran the department as a completely collaborative team.

Although everyone had a say in any important decision, we divided up the management activities and gave each other the power and responsibility to make the small decisions in our areas. When one of us encountered a larger issue, we discussed it with the others and reached a solution together. We usually wanted to get each others' input on most decisions of any import, but occasionally one of us made a call on our own, and the rest of us knew we must honor it. Over time, we learned more about which decisions the others want to discuss.

The following are the advantages and disadvantages we experienced by sharing leadership.

Advantages

We were good at more things.

Being a good leader requires a wide range of skills and few people are good at them all. By pooling our efforts, we use all our strengths to better advantage. Here are some examples of our responsibilities. My strengths are more organizational than technical, so I spearheaded our effort to set our goals and procedures, managed our schedule, tried to remove obstacles, and handled people and resource issues. Gordie is very articulate and has a diplomatic style, so he tended to talk to management about technical issues and translates management's views to engineering, while also guiding the technical projects in his area of expertise. Trev excels at integrating big systems, so he focused on reviewing technical designs, making sure the pieces fit together, and generally helping people with technical problems. Rob is blindingly quick at handling technical issues as they arise, so, in addition to leading the development of his part of the system, he tended to respond to the technical email mailing lists, frequently shooting off responses before the rest of us could double click.

We made better decisions.

I have found decision making much like user interface design: You collect input from different people with different interests, develop alternative approaches, discuss them with others, choose the better aspects of each design to narrow down to one approach, and iterate on that approach until you feel it handles most of the objectives with the fewest drawbacks.

We used the same process to make major decisions: We gathered information from those involved and then discussed potential approaches. Usually, one of us suggested a course of action, and another one pointed out a problem and offered either an alternative or a refinement. We continued to refine until we agreed we were balancing the tradeoffs as best as possible. In many cases, none of us would have thought of that approach on our own. But by pooling our opinions and concerns, we usually arrived at decisions that anticipated most of the potential problems and handled the concerns of a larger portion of the people affected by the decision.

We moderated each other.

Occasionally, one of us was especially upset about an issue and wanted to take relatively dramatic action. Sometimes dramatic approaches make sense, but to reach this conclusion, we had to convince three other people whose opinions we respect. If we did, then the dramatic course was likely a good approach. But usually, we wound up convincing the person that they were overreacting, saving ourselves from actions that I believe would have worsened the problem. Had there been only one of us, it is more likely we would have acted on our emotional impulses, only to regret it later.

This happened once when we were having problems with engineers breaking the daily build. As schedule keeper, I was painfully aware of how much time we were losing to recover from the aftermath of broken builds. I wanted to give people disincentives for breaking the build, perhaps by charging $5 to the guilty engineer, using the money to pay for a celebration when we shipped. My reasonable colleagues reminded me that only rarely did the build break because an engineer wasn't careful. Most often it was due to the complexity of our build environment. Instead, it was better to figure out the different reasons the build broke so we could better decide how to improve the system. The result was a mailing list called "ec_ibrokethebuild" that included all of engineering. Every time an engineer broke the build they had to send a note to ec_ibrokethebuild explaining what caused the build break. This had the primary function of collecting information that allowed us to improve the build environment, but it also created a disincentive to breaking the build without treating the engineers like children. This was a much better solution than my original plan, and I'm very grateful I had colleagues who could stop me from following my first instincts.

We stayed in better touch with our staff, our peers, and our boss.

Good managers stay in touch with as many people as possible, both within and across organizations. Still, the bulk of office communication happens in spontaneous and opportunistic ways: You chat with someone as you both pick up a print job, walking back to your office you see someone you've been meaning to speak with, you overhear two people chatting in the break room so you join in (Kraut et al.). With four of us, we simply had more of these informal conversations, so we were better informed about what was going on.

We noticed more.

A manager's day is filled with many short-term issues that demand immediate attention. It takes effort to simultaneously keep track of the group's longer-term direction and think about such ongoing issues as morale and employee growth. With four of us, we were more likely to notice ourselves drifting on one of these basic issues, not only because we have more time but because we each have our personal areas of concern. I care deeply about morale, so I'm more likely to notice when motivation seems low. Trev worries about potential system breakdowns, so he's most likely to notice a technical aspect of the system that is not fully designed.

We were better at working with different personalities.

Everyone tends to work better with some personalities than others. You can train yourself to work with people whose styles don't match your own, but most people find it difficult to work well with everyone. With four of us, each with our own style, we were better at working with a broader range of people. This works two ways. Not only did we carefully choose who should talk to someone about an issue, but our colleagues also chose which of us to approach. The result was that we handled issues better and we found out about problems earlier because most people could find someone they were willing to tell.

We were less biased.

One of the hardest management problems I have encountered is dealing with biases. It is impossible to rid yourself of biases, and yet you must make decisions that affect others' ability to excel in their careers. Many managers rely on a handful of people who they believe do the best work or have the soundest judgement. This is understandable but also dangerous. Humans have a consistent proclivity to overly weight early impressions of people and then either not notice or discount the many counterexamples that occur afterward (Kahnneman & Tversky). Once a manager gets in the habit of giving the most interesting and challenging jobs to the same set of people, they not only impair the rest of their staff's ability to grow but they lose credibility.

This is one area where I'm most grateful for having peers I respect. When discussing whom to give an assignment, a limited resource, or a reward, a wider range of names got mentioned and more considerations relating to the each person's need and merit were raised. In fact, when giving out rewards, we typically each made our own lists independently. Then we merged the lists and discuss any discrepancies. Of course we still have biases, but I do believe we made fairer decisions than one person could make on their own.

We reinforced each other.

I confess that we have used our numbers to give the appearance of general agreement. At senior management meetings, one of us might raise an issue and another one would reinforce it (from the opposite side of the room), making it feel like there was general support. We tried not to abuse this (and I suspect people would see right through us if we tried), but it does help to have more than one voice promoting a point of view.

We vented our frustrations with each other, not at others in the company

Sometimes when we're especially frustrated, we went into each other's offices and rant. We complained that someone wasn't communicating when she's in trouble or someone else wasn't producing the results we needed. We heard each other out, knowing all the while that we mostly needed to get our frustrations out. Sometimes we even ranted together. Then after we felt better for sharing our predicament, we got on with our jobs. Usually, one of us pointed out all the considerations the other was conveniently leaving out of their analysis. The real value was that we were able to reveal our irrational reactions to someone who understood our position and who wasn't seeing us in our role as Gang of Four Member. It is unprofessional and damaging to convey these frustrations to others, since it simply fosters the problem by making it The Official View of that person. A single leader has to either refrain from talking to anyone or talk to someone outside the company who wouldn't fully understand. I suspect that for most people, the frustration tends to leak out in unintended ways. Having partners greatly eased the burdens of managing.

We covered for each other when one is away.

Everyone gets sick and (we hope) takes vacations. By sharing the job, we could cover for each other. In December, Gordie re-injured a chronic back injury and needed two weeks to recover, and even then could only slowly return to using a computer. This happened right in the middle of a crunch that affected the viability of the company. This could have been a crisis, but the three of us simply adjusted, which gave Gordie piece of mind that undoubtedly assisted his recovery. Sure, Trev and Rob didn't write much code during that crunch, but this outcome was far better than the loss of a single leader would have been for that period.

Disadvantages

Of course, all is not perfect with a collaborative leadership approach. There are pitfalls, and here are the main ones we've noticed.

We had to spend a lot of time communicating.

For the four of us to work effectively, we had to communicate constantly. This was not really a drawback, especially for someone like me who loves talking to people all day, but it did take a lot of diligence. We all tracked a large number of issues, and it was easy to forget whom we've told about what. Shortly after we started working together, an engineer complained that he was asked the same question four times by each of us, so we realized we had to coordinate better. To do this, we focus our areas of responsibility. But more so, we stayed in touch. We had two Gang of Four meetings a week, many short pair-wise or three-way conversations throughout the week, and, most of all, we used email constantly. All of us read our email regularly throughout the day, and when any of us sent mail, we responded as quickly as possible. Since we each had areas of focus, we usually suggested a course of action and request feedback rather than asking for a discussion. Usually one or two of the others sent a quick okay or suggested some revisions, and the decision was made without ever having to confirm it in person. Gordie and Rob worked at home once a week, and it rarely caused a problem because they checked email so often. Often the person at home was the most accessible because they didn't have other interruptions.

People sometimes had to go to more than one of us to get what they wanted.

Although we had announced our areas of responsibility, it was not that uncommon for someone to ask me a question that was in another partner's domain. In some cases, I could make a quick decision, but usually I asked them to talk to the person who knew the most about that area. Or I offered to discuss it with that partner and get back to them. I suspect some people found it frustrating to have to keep track of who covers what and sometimes repeat their request.

Decisions could be slower in coming

In some cases, someone would ask me to make a decision that was within my domain, and I would still tell them I want to consult with one of my partners before making the call. Since our knowledge is distributed, I was sometimes wary of making a commitment that the others will have to respect without consulting them first. Again, this might have bothered some people who expect a quick decision. We hoped that this was offset by better decisions, but it might not have always worked out that way.

The company had to pay two (or more) people for "the same" job

From the company's point of view, it took four people to do the job of one. In our case, that was probably not so much a problem since we had no other managers for a group of 35 engineers, and we were paid at the same rate as other senior engineers. In any case, the crux of my argument is that they got what they paid for: better management.

We could exaggerate our collective biases

Although we each had our own views, part of the reason we worked so well together is that we shared similar beliefs, values, and interests. Yes, we did get input from a wider range of engineers than a single person could, but we didn't cover everyone, and that could make us falsely confident that we adequately represented the entire group. We were rightly accused of fostering a certain view of our process that not everyone shared, and I believe it hurt us that we felt we had agreement of the staff when in fact an important group disagreed. After that, we made a more concerted effort to foster communication with the people none of us naturally spoke with to make sure we fairly considered everyone's views.

We sometimes had to honor decisions we didn't agree with.

There were cases when one of us made a commitment to an engineer that the others wouldn't have agreed to if we had participated in the decision. One time, one of us told an engineer that we would offset the cost of a rescheduling a plane ticket when he agreed to push back his vacation to get a job done. Others of us felt that he shouldn't have gotten himself in the position of needing to postpone the vacation and would have preferred not to reward him for poor planning. It's possible we would have agreed to cover the cost anyway, but since he had made the decision already, we all felt bound to honor it. Over time, this happened less, probably because we were better at either anticipating the group's position or knowing when to consult the group before making a commitment.

I don't believe collaborative management works for everyone. In many respects, sharing leadership can be like a marriage. Pulling it off successfully requires deep mutual respect among the partners, a complementary skill set, complementary personality styles, and, most of all, massive communication. The partners have to like each other and be committed to working on their shared process as much as they are to doing their job. It won't work to put together people who don't work well together simply because they both want a similar job. They have to want to do it together.

Our situation is especially unusual in that we share the position among four people, rather than just two. Still, most of the feedback we've gotten is that our foursome has been very successful. In fact, the engineer who had complained about being asked a question four times later said about the Gang of Four, "Everything you read in all the management books tell you this is wrong, but it works!" Perhaps the management books are wrong.

NOTE: In the spring of 1998, Electric Communities merged with two other startups, The Palace and OnLive Technologies, and then reformed as two separate companies focusing on different aspects of collaborative technology. The Gang of Three was split up and put into more traditional roles in the new companies. Ellen and Trevor went to OnLive an Rob remained with Electric Communities. In the future, Ellen will be looking for new opportunities for the appropriate use of collaborative management.