When a new director took over our group a few years ago, she assembled us for a getting-to-know-you session where she described her management style (open door, flexible, trusting), her expectations of us, and her long-term goals.
When she opened it up for Q & A, someone asked, “What is your pet peeve?”
The answer came without hesitation: “Endless e-mail chains.”
She decribed the all-too-familar scenario: Employees. who sit in the same building or even the same floor, arguing a question via e-mail, escalating the debate along the way by cc’ing more and more people, higher and higher up the org chart. Tension mounts as everyone copied on the exchange hovers over their Inbox awaiting the next salvo. Newcomers to the debate are forced to read the lengthy chain from the bottom up. Accusations and denials are made. The original thread gets muddled, nothing gets resolved. and little real work is done along the way.
“If you cannot resolve a problem in two rounds of e-mails. Get out of your chair, walk over to your coworker’s cube or office, and settle the dispute. At the very least pick up the phone and call them.”
With all the hype about wikis and virtual teams, are we losing sight of the benefits of face-to-face discussions with our fellow team members? I don’t know the statistics, but I would guess that many of us still primarily interact with coworkers located in the same physical plant. Yet how often do we take advantage of the opportunity to get together in the same room and talk things through.
This is what went through my mind last month when Mike Hughes described how his team at IBM Internet Security Systems talks through the architecture of their online help with the aid of an old-fashioned white board. They pull everyone into a room and examine the product, looking for the rough edges where users might turn to the online help for assistance. They scrutinize the content of the help file to determine what is useful and what is not.
Mike’s presentation was not about collaboration — his primary goal was to demonstrate the value of using “task clusters” in a help file as opposed to a TOC-driven structure. But his description of their collaborative efforts was an eye-opener for me.
My team has always worked on a wide variety of training and documentation deliverables. With rare exceptions, each writer works alone on a document or help file. We collaborate to solve problems, but not to validate our decisions on how to structure a document or approach a topic. As manager and editor, I review the final draft, but I can see the advantage of an earlier discussion. I’d like to experiment with this.
This kind of collaboration can be threatening if it isn’t handled well or if the presenter isn’t adequately prepared. But the benefits could be enormous. Every individual—even the most talented among us—has limitations and blind-spots. Another set of eyes or several sets, can make what seemed impossible, possible. As a team works through problems, they become more cohesive and build trust. Standards are set, innovation happens. The document or help file no longer “belongs” to the individual. It is a joint product.
I believe Mark Wallis (also from ISS) is going to be discussing this more at next month’s meeting. The information isn’t posted on the chapter site yet, but it will be soon.