coneblog

In recounting my early development experiences, I’ve described a situation where I “went dark”. In the literature, there are many discussions of the project situations and individual developer pathologies that give rise to this situation. But for the Project Manager who is managing risk, a “Guy in a Room” can turn into a real problem.

The classic “Guy in a Room” is a situation in which a project team member, usually a specialist in some technical aspect of the solution, goes off and does his thing and creates a critical piece of the solution. Often, this is the piece that will 1) connect everything together or 2) solve a difficult technical problem or 3) provide the generalized toolkit for everyone to use for everything or 4) handle the interface to other systems or to the real world.

This usually seems like a good idea to the Project Manager. There may be one piece of the solution that is less defined, or less conventional, or more difficult or complex. You may have a team member that is more technical, skilled in writing complex code, or just prefers to work by himself.

The combination of these two factors can produce the “Guy in a Room” syndrome. In this situation, the guy goes into the room, and sometimes nothing comes out. Not code, not demos, not specifications, not even progress reports. This is also known as going dark.

As a project manager, this situation should be a risk red flag. The danger, of course, is that no usable components ever come out of the room.

How can you avoid this situation? What can you do if you have a team member who has gone into a room, and gone dark?