Humans and Technology Technical Report TR 2003.01, Jan 1, 2003
A person managing a portfolio has the job assignment to keep an alert eye open to oncoming trouble and an educated eye open for opportunity, acting in time for both, prioritizing choices along the way.
Managing a project consists of exactly this. Whether the entire team shares the assignment, it is part of the team leader’s assignment or it is given to a dedicated role, whoever holds the assignment is supposed to detect and act on future hazards and opportunities. Only through some odd misunderstanding of project life has project manager come to mean “the person who orders the others around.” It should mean “the most alert and most proactive,” the person that responds effectively to signals. Perception and creativity are intrinsically linked to the job assignment.
As I searched out experienced project managers, especially those labeled “good” by their peers, their perceptiveness and creativity stood out clearly. I began cataloging some of the more interesting strategies that I had been using over the years, and discovered that I was not alone ; almost every team lead and manager has had to invent similar strategies in their “normal” project life.
This article is about one such strategy, invented during my third visit to a troubled project. The problem was completely standard — you will recognize it. If you have ever been a team lead, you have been there. I’ve been in this situation many times and never found a solution for it. The fact that we found a solution that worked this time is why I am writing this article. Of course, in retrospect, we found that many of us had naturally been using this strategy for years; but not having a name for it, we didn’t even notice it in our bag of tricks. The purpose of this article is to give a name and a setting, so you can apply variations of it yourself.
Before telling you the problem and its incredibly simple solution, I have to warn you: To pull off the solution, you need a supportive manager. Remember, a manager is supposed to act to avoid trouble and grab opportunity, balancing priorities? This is a story of how we got ourselves out of a tight situation, with the help of a manager who understood how to support her people. Please don’t write to me to say that you can’t apply this strategy because your manager won’t support this solution – a manager who supports her people in their assignments is the key ingredient to this strategy.
The Problem Setting
Jim is lead programmer and domain expert on a project of eight people (Jim, six other programmers, and Aaron, the project manager). Jim has worked on previous versions of the system. Mark has also worked on the previous system and has domain knowledge. However, he gets diverted daily from this project’s activity by a second boss he has. There is nothing we can find that will reduce the level of interruption he has from the other boss, so he pretty much gets washed out of the project in terms of effectiveness. The other five programmers, of varying abilities, have been added to the project to help Jim get the work done, mostly on the many little programming assignments that don’t need deep domain knowledge. Aaron was recently introduced to help offload Jim from bureaucratic work. Their manager is Lisa.
The six programmers work in partitioned cubicles in an area accessed by a short hallway. Jim sits in a private office coming off this short hallway. Aaron sits around the corner and farther down the main hallway.
Jim has this private office so he can close the door to get privacy, but otherwise be available to answer questions from the other programmers. At least, that was the big idea.
The idea backfires. Jim’s office is tiny, so he keeps it open a crack. Consequently, he sees everyone walking up and down the hall, and he gets asked questions multiple times an hour by the other programmers. He also gets visited or called out every time there is a question about either the schedule or the system architecture.
Oh, and of course, upper management decided to outsource future versions of the product, so Jim has to interface to and transfer knowledge to the outsource company. In short, like so many team leads around the world, he gets nothing done during the day, and is reduced to working nights and weekends. He has no spare capacity left, and is burning out, all without the project making headway.
In my first visit, we go over the project schedule, create a simplified project plan and determine three things. First, the team can’t get done in time. Second, the only person who can do most of the actual programming is Jim. Third, Jim is calamitously overworked. Note that it took most of Jim’s day to participate in this session, so he ended up one day behind for getting this information (all of which was obvious to start with, except for the simplified project plan). So far, this should like like very many software projects.
Attempted Solution #1
It is clear that Jim needs more design time and fewer distractions. So we make the usual promises.
We promise that Jim will not get disturbed for trivial issues. Aaron will take all non-technical interrupts, the new programmers will work together to train themselves on the domain, Mark will track and reduce his disturbances from his other boss (whom we cannot get rid of), and Jim will focus on his programming. He will only be interrupted for major questions.
Of course, this doesn’t work.
Jim’s office is small enough to be claustrophobic when the door is closed. Besides, he case hear people walking up and down outside his closed door, and he frets that something is going wrong that he should be attending to. He keeps the door open a crack.
The other programmers on the project just need to get their questions answered, so they ask Jim anyway.
Mark can’t do anything about his other boss, who, for reasons we needn’t get into, has the right to create high-priority interrupts multiple times a day, and does. In other words, he never gets sufficient time to offload Jim.
No matter how Aaron tries, there are still meetings that need Jim’s technical expertise on the project and scheduling matters. Jim still gets called out of his office, or the meeting comes to him.
The “obvious” solution isn’t working.
Attempted Solutions #2, #3
How about having Jim work at home? We try that, but it turns out that he doesn’t work well at home. Besides the set of distractions around his house, he can’t get the high-speed line he needs to link to the development environment. He has to work in the office.
There is one would-be strategy that usually doesn’t work but we have to try. It is Bundled Distractions (written with a line drawn through it, to show that it is a generally unsuccessful strategy). The idea is to create office open-hours for Jim, and have all questions and interruptions come in during those open hours. We decide that he will handle questions for half a day a couple of days a week.
As is usually the case, Bundled Distractions didn’t work. The team simply couldn’t hold themselves back from questions, Jim couldn’t hold himself back from being helpful.
Why do I bother to mention this strategy if it doesn’t work? I do so because it sounds so good, and so rarely works. In 30 years of project life including 10 years as a consultant, I have never seen it work on a project (although it seems to work with university professors). Nonetheless, it is a possible strategy, and we were desperate enough to try it.
Cone of Silence
Before giving up, we revisit the problem one more time:
Jim needs quiet time to focus, real freedom from distractions, and a high-speed connection to reach the development environment. He can’t work in his home or his office. In a reversal of the usual project priorities, it seems he can’t be close and available to his teammates, he needs to be invisible to them.
I ask one last time (I’m sure this suggestion got made and rejected at least once before in our deliberations) whether Jim couldn’t get a second office somewhere else in the building, far enough away that people won’t be bothered to walk that far to ask him a question, but where he still can connect to the office LAN and have the feeling of being at work. This would provide him with a “cone of silence” in which to get his work done.
Much to my surprise, Aaron, Lisa and Jim all say, “Yes, we could do that – that might work.” To this day, I don’t know why this suggestion didn’t get picked up the previous times it came up (I don’t know that it didn’t come up, I only suspect that it must have been suggested). I think that every strategy is appropriate for a particular level of desperation, and we were not desperate enough before to pay it any attention.
In any case, they get enthusiastic about trying the Cone of Silence, as the name sticks. I remain skeptical, because it seemed to me that Jim will get drawn into meetings just as much as before, but don’t say anything, because we really are desperate by this point.
I didn’t see or hear from the team for several months. In a casual phone call one day, Lisa mentions, “Oh, that Cone of Silence is working really well.” Apparently, Jim really does go to that office, and other people don’t bother him. For the first time in over a year, he has enough quiet time to focus on his list of work. He concentrates, he is happy, he makes progress.
What about all the other people on the project, and all the distractions?
The others still have questions, and they entire team moves more slowly than before because their expert is gone, but they make adequate progress without Jim. Aaron and Lisa keep people away from Jim. Aaron steps in and makes project decisions mostly without Jim. Lisa reminds people of the project’s true priorities, which include Jim getting his work done as top priority, and almost everything else second to that.
More months went by, and I receive a call from Lisa again. Almost off-hand, she mentions that Jim is almost finished with his work, well ahead of the project plan we created on my first visit. I confess to be astonished by this news. My view was that that schedule was unduly optimistic. It seems, however, that Jim, a combination of domain expert and senior programmer, was able to move faster when left alone with his code than he predicted.
Why Did it Work?
What worked, and why did it work?
What worked was that Lisa, the manager above the project manager, correctly saw Jim’s progress as the single top priority to the project. Everything else was secondary. Unlike many managers, she was willing to bend rules to attend to satisfying this priority. She was able to find another office, and she kept everyone appraised of the importance of working on the other assignments without Jim.
I highlight Lisa’s role, because I have encountered many managers who insist on keeping everyone within their sight, who won’t go out of their way to get additional resources such as a second office for Jim, or who yield to pressure to bring Jim back to attend meetings and answer questions.
Lisa accepted that the rest of the team would have to “muddle through” without Jim; she correctly assessed that they would, in fact, be able to muddle through, though at a slower pace. Many managers would chicken out at the last instant and recall Jim.
What also worked was that Aaron, the project manager, supported Lisa in the strategy. He had to make himself conversant enough on the topics to make decisions along the way. Note that Lisa had to trust and support Aaron in getting to this level, and Aaron had to support the strategy in not running to Aaron with his questions. Aaron also had to keep the rest of the team from running to Jim.
Besides the level of support, there had to be a barrier, the Cone of Silence itself.
Normally, I recommend putting a project team close together, because research shows that generally, people won’t walk up a flight of stairs to get questions answered, or, as it turns out, even a couple of bends in the hallway [Allen98]. Normally, we want people to get their questions answered, and so we ensure there is no flight of stairs between them.
In this case, we needed that very barrier.
Strategies are Interlinked
Project management strategies do not sit in isolation. I wrote down a dozen strategies, lightly interlinked, in the appendix to Surviving OO Projects. I now find them heavily, not lightly, interlinked.
Osmotic Communication is a strategy is described at length in Agile Software Development. The idea is that teammates sit in the same room or adjacent cubicles, so that they overhear each other during their normal working day, picking up information in their background hearing. Even while not particularly conscious of it, they learn who knows the answers to which sorts of questions and what is happening on the project. They can ask questions without particularly raising their voice, and often can answer a question without particularly getting distracted from their current work. In the normal course of events, Osmotic Communication is the ideal. In our particular project, the Osmotic Communication was good for everyone except Jim. Cone of Silence__sets up the opposite dynamic to Osmotic Communication, sufficiently so that I will come back to these two in a moment.
Expert in Earshot is described in CockburnEiE]. The idea is that novice workers should work within earshot of an expert, in order to pick up good work habits. Like Osmotic Communication, the Expert in Earshot backfired in our situation, actively causing problems because the expert couldn’t get his work done. This backfiring is mentioned in the description of Expert in Earshot as the “overdose effect,” an apt description of what happened on this project.
Progress Team / Training Team is detailed in Surviving OO Projects, where it is given the cute primary name Day Care and the more descriptive name Progress Team / Training Team. I now think that the longer name is the better one. Cone of Silence implements Progress Team / Training Team, since the project needed Jim to make maximum progress, and the rest of the team was allowed to work at a slower pace as they learned their material.
Cone of Silence, then, permits Progress Team to be implemented, at the cost of Osmotic Communication with the expert. It is a deliberate move away from Expert in Earshot.
In general, I find that Osmotic Communication and Cone of Silence are two strategies that need to be balanced, usually with more of the former and only a little of the latter.
Variations on a Theme
A good strategy gets rediscovered many times. After we applied the Cone of Silence successfully, I searched for other situations and some varied ways in which it was done.
A similar implementation of the strategy. I was once in charge of a research project that ran with half a dozen people over a few years. Partway through, it became clear that we were a bit lost in terms of our project structure and plan. I made a deal with a sister organization to get use of a quiet office at their location for two days to rebuild the project plan — I had found our normal office environment too distracting to get two days of quiet time there. I sent an email to my boss, Elizabeth, on the Sunday night before I went, saying what I was doing. When I called in to the office to check for emergencies on the first day, my boss scolded me severely for setting up off-site work without her permission, and for disturbing the sister organization. What a difference between Lisa and Elizabeth! As you can guess, that destroyed any peace of mind I might have within my little Cone of Silence, and the two days were not as productive as I had hoped, although still better than staying at the lab.
A larger implementation of the strategy. I met a manager at a company that was having trouble adopting Extreme Programming. The company had a tradition of “off-sites,” which in their language meant that they moved an entire project team out of the office to a special off-site location for a short period of time — a weekend to two weeks — in order to make maximum progress on a targeted section of software. In the “off site,” they would set up Osmotic Communication and a Cone of Silence for the team. The odd part was that the resistance he ran into was that the people there considered XP as nothing more than extended off-sites, and they therefore wouldn’t try it! (The logic of that I leave as an exercise to the reader.) If their off-sites are so effective, I would think they would legitimize this setup as standard practice for all their projects. Can your organization manage to?
Two very large implementations of the Osmotic Communication with Cone of Silence combination were IBM’s development of the IBM PC in the early 1980s and Lockheeds Skunkworks facility following the second world war (nicely described in the book Skunk Works [Rich94]). In IBM’s case, the executives decided that they couldn’t develop the PC with the existing IBM bureaucracy and working style, so they shipped the team off to a warehouse to get some privacy, speed and informality in their work. Lockheed’s Skunkworks facility designed their most difficult, top secret military airplanes. They sat, deliberately crowded together, with different specialties within easy earshot of each other, in a facility cut off from outside distractions.
A small implementation of the strategy. I usually wear airport-style ear-muffs when I need to concentrate while working in a large room (18 – 20 db hearing protectors . . . I buy them at any local gun shop). I find that this cuts down the noise just enough that I can concentrate, but lets me hear if someone calls my name. I’ll take them on and off depending on how much concentration I need, thus balancing Osmotic Communication and Cone of Silence. Other people use music headphones to get the same effect. Sometimes they never hear their colleagues speaking, though, so they get too silence and not enough communication.
Why did it take so long for us to recognize and apply the Cone of Silence idea to Jim’s situation?
Partly, we hadn’t reached the appropriate level of desperation earlier. We worked through the easier alternatives first, because those would cause less disruption to the project. If one were to categorize the level of desperation as the levels of a fire alarm (one-alarm, two-alarm, three-alarm fires send calls to that many fire stations), then we might say that BundledDistractions and the other strategies we started with are applied at the one-alarm level. Isolating the team lead in a Cone of Silence is disadvantageous to a project under normal circumstances. Only when we reached the two-alarm stage was it a worthwhile tradeoff.
Also, these project management strategies don’t yet have an accepted set of names and study literature. Jim Coplien and I have been deliberately collecting these strategies for a number of years. Jim collects mostly organization patterns CoplienOP, I collect mostly risk reduction Project risk reduction patterns], but these are not yet at the stage where people look through them as standard problem-solving procedure. When I am in an optimistic mood, I think that this might change in another 10 or 20 years.
After we did apply it, why did it work?
It worked in part because people really do find a flight of stairs to be a considerable barrier to asking questions. It worked in part because Jim really could do his work in isolation.
The final, and in my opinion, most important reason it worked, is that his managers, Lisa and Aaron, were perceptive, creative and supportive.
Allen98: Allen, T.J., Managing the Flow of Technology, MIT Press, Boston, MA, 1984.
Cockburn98: Cockburn, A., Surviving OO Projects, Addison-Wesley, 1998.
Cockburn03: Cockburn, A., Agile Software Development, Addison-Wesley, 2002.
Rich94: Rich, B, Janos, L., Skunk Works: A Personal Memoir of My Years at Lockheed, Little, Brown and Company, Boston, MA, 1994.