Collaboration—A Necessity and a Challenge for Information Developers

Home/Publications/Best Practices Newsletter/2015 – Best Practices Newsletter/Collaboration—A Necessity and a Challenge for Information Developers


June 2015

From the Director

CIDMIconNewsletter JoAnn Hackos, CIDM Director

Collaboration—A Necessity and a Challenge for Information Developers

Information developers have always been collaborators, especially with the engineers and programmers who develop the products we support. We have also collaborated in some organizations with the user-experience team. Unfortunately, it’s often a one-way collaboration, writers using user-experience data to gain some insight into what customers need to know.

Nonetheless, collaboration remains a challenge and, increasingly, a necessity. Information developers are reaching out to instructional designers and trainers, offering a opportunity to share content in more productive ways than cut and paste. You reach out to service and support personnel, suggesting that they reuse content from technical manuals to support customer cases rather than creating duplicate information on their own. You suggest that sales and marketing professionals use excerpts from existing content to build product catalogs or new-business proposals. And, you’re being asked to help curate customer-developed content.

Unfortunately, despite all the good reasons to collaborate, many information-development managers find that their organizations create barriers that make collaboration challenging.

I’ve been reading about collaboration from experts in the field, and I have been especially impressed by Morten Hansen’s book, Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results.1 Hansen studied what he calls “collaboration disease” at Hewlett-Packard in the 1990s as he was working on his PhD at Stanford University. He discovered that innovative teams at HP were collaborating but finding it very difficult. Over two years, he collected data across the company and looked at 120 projects. Some teams were really good at collaborating. As a result, their projects went faster and were better. Other teams failed. They spent their time fighting and were sometimes worse because of the time wasted than if they hadn’t collaborated at all.

In the 1990s, I had a similar experience on an HP project. I worked with a senior engineering manager who was about to retire. He was distressed that so much knowledge and ability at HP was being wasted because engineering teams failed to collaborate. He knew of teams that spent months or even years working out a technology that had already been perfected by another team in the company. They just didn’t know about it because of a complete lack of communication.

This manager asked me to help him put together a business case to present to senior management and engineering management to increase communication and collaboration. We worked hard for a few months on the business case and his presentation. To me, the idea was a “no-brainer.” It was so obvious that increased communication about the work being done by the various teams on their projects would benefit everyone and cost very little to implement. This was, by the way, well before the Internet was ubiquitous. My friend was proposing a technology that would make sharing project information straightforward.

The engineering manager made his presentation. We were both excited that it would be easily accepted. To his surprise and consternation, it was rejected outright. The engineering project managers, in particular, were afraid that the secrets of their new technologies would be comprised if others in the company learned about them. Even though my friend had carefully outlined the use of encryption to keep the data secret, they were unconvinced.

It was actually a very sad ending. My friend retired sadly without having achieved what he hoped would be his parting gift to the company.

Hansen asks a key question based on his HP study (probably about the same time). He wants to know what the difference is between good and bad collaboration. He’s worked now with many companies since HP, putting together a set of rules that managers can use when they decide whether to collaborate or not.

Hansen developed a set of principles he calls “disciplined collaboration.” With this set of principles, he poses what he calls a simple question: “How do we cultivate collaboration in the right way so that we achieve the great things that are not possible when we are divided.”

This is one of the key questions that we hope to address at the fall 2015 Best Practices conference. I hope that you’ll get a copy of Hansen’s book and consider his ideas. I’ll write more about collaboration and Hansen in the CIDM e-newsletter, Information Management News, between this issue and the September conference.

With the changes occurring in the information-development profession, with the introduction of customer-generated content, with the need to ensure a single source of truth among all the content produced by disparate teams, collaboration should be at the top of your list of challenges. In fact, if we don’t learn how to collaborate, we may not be in business for long. CIDMIconNewsletter

1 Harvard Business School Publishing, Boston, 2009.