Story:
Designing open collaboration in Red Hat Global Support Services

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 several different functional roles, across 16 countries, through nine languages, and dozens of areas of domain knowledge, who had traditionally used separate, disconnected knowledge and case management systems.

Finding the right design process

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? This would, after all, be consistent with open source principles – enable people to work together to develop a solution that makes their lives easier.

The existing project team became what we called the “core team”. This team consisted only of 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 AM, 2:00 AM, 11:00 PM or other odd hours in their local timezone. 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. Doesn't increasing collaboration and knowledge sharing mean that you give up that power?

The Solution: A new collaborative workflow

The design process taught us that breaking down silos and improving collaboration would be a major culture change and require a comprehensive change management effort that could potentially 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 for all our technical associates worldwide, along with new unified knowledge and case management systems, based on what I now refer to as “intelligent swarming”. Along the way the design team worked through dozens of questions, tough conversations, heated debates and disagreements.

For example, one key realization that we came to was that not everybody had the same understanding of what it meant to “collaborate”. Does it mean that you work on a problem until you reach the end of your ability, and then ask somebody else to work on the problem? Or, does it mean you work on the problem and ask for help as you need it, but maintain ownership of the case until it closes? Or, should we strive for people to proactively contribute to cases where they can help, based on monitoring cases appropriate to their skills, regardless of of whether they are asked to help? The answer would entail very different workflow guidelines.

During one design session early on, I asked everyone on the team to each draw a picture of how they thought the workflow should look in an effort to move the conversation forward. Many different diagrams were shared, several of which kept the principles from the existing escalation model, but renamed the terms. That is, people still envisioned putting a case through some kind of process by which a more senior person was tapped to help, but instead of calling it “escalation” they called it “collaboration”. This was revealing, and became a theme. Understanding the concept of collaboration at an intellectual level is one thing, but actually internalizing it quite another.

Then one diagram came in from a frontline support associate in Beijing that looked truly original:

Rather than envisioning a traditional phased workflow, this associate wanted to visualize the different states a solution could be in during its life cycle based on the concepts we had been discussing. This workflow diagram has been updated and tweaked several times since it was first created, but it largely resembles the original and has served as a simple but effective guidepost for the project. Some elements of the workflow are similar to the old one – for example a frontline (junior) associate is the “first touch” on a new case and the first thing they do is search the knowledge base to see if they are dealing with a known problem or a truly “new” problem. If the case owner can solve the case on their own, they do so. There is no reason to collaborate for the sake of collaboration. Any issue that has been solved previously should be found in the knowledgebase, leaving only previously unsolved problems to the collaborative workflow.

If, however, the case owner needs help, they do not hand the issue off to someone else. Instead, they signify they need help by changing the status of the case to “waiting on collaboration”. This is where the new model really kicks in. All associates belong to different technical “domains” that focus on different topic areas. Associates of all skill levels view all the cases in the system through a filter for their domains. They review cases relevant to their skills, and can help guide each other toward resolution. More junior associates take more cases up front, while more senior associates spend more time contributing to cases owned by other people through the new collaboration model. Thus senior associates see more issues than they did before, which means their expertise is accessed more quickly, junior associates are sticking with cases longer, learning directly from the senior associates rather than simply handing issues off. Customers, ultimately, are getting the answers to their questions faster.