Designing open collaboration in Red Hat Global Support Services |

Designing open collaboration in Red Hat Global Support Services

Image by :

Red Hat's Global Support Services (GSS) organization is accountable for customer loyalty. In that capacity, we're in the business of solving complex technical problems experienced by our customers. In February of 2009, the GSS management team began a journey to determine if we could serve our customers better, and ultimately increase customer loyalty, by improving the ability of our highly trained technical support associates to collaborate with each other. The fundamental idea was that if we could take away certain structural, cultural, and procedural barriers that separated different groups of associates, we could increase the flow of knowledge, reduce the duplication of efforts, and ultimately provide customers with more accurate, more consistent, and faster results.

Embarking on this journey ultimately taught us lessons that we didn't expect—not just in how to manage collaboration for our associates' day-to-day jobs, but in how to use open collaboration as a management team to innovate on process design in our organization.

Deciding to increase collaboration is one thing, but actually enabling increased collaboration and then fostering its use by associates is no easy task. While our associates have always freely collaborated within small groups (people who sit near each other, for example, or people who work on a similar technology), our vision was to take advantage of our organization's collective knowledge by fostering collaboration on a global scale. That meant connecting people from three different functional roles, across a dozen countries, through eight languages, and dozens of areas of domain knowledge.

Figuring out how to design a workflow that could accommodate this ambitious goal proved quite difficult. We assembled a project team and went through several iterations without feeling like we had something solid enough to fully implement. We started with a few pilot groups collaborating on a small scale, but found logistical as well as fundamental attitudinal problems stymied the open collaboration we envisioned. While we had successfully articulated the goals of our efforts, we were not making progress on a solution.

Then, after several months of false starts, we finally had a breakthrough. What if we got rid of the project team, which consisted mostly of managers from different areas of the organization, and instead asked the associates themselves to get together and figure out the best way to achieve the goals?

The existing project team became what we called the 'core team.' This team consisted of only managers, and their role would change from actually designing the solution to being more of an advisory board for the project. We then solicited volunteers for a new team, which we called the 'design team.' This team was composed of about 15 technical associates: a representative from every region, every team, and every skill level. These associates were all enthusiastic and energized by the project—but that didn't mean they all thought it was a good idea or agreed on how to implement it.

My role was to facilitate the design team meetings using design thinking techniques, make sure the conversation remained productive and on-track, and to make sure all voices were heard.

The design process wasn’t easy. We alternated meetings between early morning and late evening to accommodate various time zones. Some associates were joining our calls at 5:00 a.m., 2:00 a.m., 11:00 p.m., or other odd hours. Emotions ran strong; some of the discussions questioned the validity of certain roles and opened the door of possibility to major change. People feared of losing their relevance, of sacrificing their exclusive status as experts of a particular topic, of having to take on more work than they previously had, of having to spend more time discussing problems with team members instead of just doing the work themselves. The implicit understanding that many people in technical fields have is that knowledge is power. Does increasing collaboration and knowledge-sharing mean that you give up that power?

Breaking down silos and improving collaboration would be a major culture change and require a full change-management effort that would likely take years to be fully realized. Far beyond the scope of the original vision, we spent the next twelve months designing and revising what would become the new workflow, based on what I refer to as 'intelligent swarming,' for all our technical associates worldwide. Along the way the design team worked through dozens of questions, tough conversations, heated debates, and disagreements.

As we counted down the days to launching the new process, which also involved a new set of tools, management began to brace for the worst. Risks and mitigation strategies were identified, contingency plans drafted, round-the-clock management monitoring schedules put in place. There were bugs, to be sure, and plenty of glitches and rough spots. But all things considered, the change ended up going remarkably smoothly.

Ultimately, we came out with a concept that enabled collaboration by allowing associates from different offices, different skill levels, and different functional groups to 'swarm' around customer cases, ultimately getting the right people on the right case sooner and solving customer problems faster. At the same time, associates who didn't previously collaborate are sharing knowledge and learning from each other.

Early results indicate that the combination of knowledge-centered support (a methodology for incorporating knowledge creation and reuse into the workflow of solving customer problems) and our new intelligent swarming model allow us to handle greater call volumes without increasing staff. These efficiency gains are early indicators of a positive ROI and are a direct result of empowering our associates to take the lead in designing their own processes and procedures.

Our new collaborative workflow is far from perfect. There are still tough questions, problems we encounter, and improvements we recognize we need to make. Over the coming months, we will focus on measuring the effectiveness of our new intelligent swarming model and increasing its efficiency. To do this, we'll keep building on the lessons we've learned in developing the program: resist the temptation to apply changes or improvements from the top-down, and let the people who do the work design and improve the process, transparently.


About the author

Sam Knuth - I have the privilege to lead the Customer Content Services team at Red Hat, which produces all of the documentation we provide for our customers. Our goal is to provide customers with the insights they need to be successful with Open Source technology in the enterprise. Connect with me on Twitter: @samfw