Designing open collaboration in Red Hat Global Support Services

No readers like this yet.
bees in a hive with words intelligent swarming over them

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.

Picture of Sam in his home office smiling at the camera. Sam is a white man. He has long curly brown hair and is wearing a dark green zip up fleece hoody.
I lead a team in Red Hat focused on providing context, knowledge, connection and alignment to our Product and Technologies employees, as well as working to ensure they have an inclusive, equitable, and safe environment to work and grow in. I am a late-diagnosed autistic person and I co-chair Red Hat's neurodiversity employee resource group.


Sam, this is a great writeup. Can you describe the mechanics of the "swarming" in more detail? How does it work in practice?


Sure I'd be happy to. I'm actually thinking of doing another story on those details. In the meantime, would happy to send you some more info directly.



Hats off to the team for this. Many companies have talked about the change, but very few are so far down this path. While it works for smaller companies, the scale and scope of what you all have accomplished so far is superb.

The 'doers as designers' really was a breakthrough, and something I've incorporated into many other situations.

Nice write up, and nice work.



hats off to RedHat indeed! Great overview of the management and change process, but like Gunnar I too am now itching to know the finer detail about the swarming process itself!

Nicely done Sam. As other's have mentioned, a bit on the logistics & mechanics behind the "swarm" would be a great follow-up to this write-up - one I look forward to reading.

That said, I'd also be interested in the risks/reward motivators for the adoption of this plan by individuals in the organization. Were they put in place by management prior to implementation, or did they develop organically through the design team (peer pressure to participate for example).


Hi David,

Great question.

Indeed one important factor when implementing this was to articulate the "what's in it for me?" factor for associates. This part was actually pretty easy.

We clearly articulated a few main benefits during communication and training building up to the launch: the program will enable you to get help faster when you need it, it will make it easier to learn and develop your skills, and it will allow you to focus on areas of expertise that are of the most interest to you. For senior engineers, who had less to learn and more to share, there is an implicit benefit of bolstering reputation by sharing knowledge, but also a more tangible benefit of enabling more people to work on complex issues, reducing the overall demand on senior engineers with very specific skill sets.


Interesting read! When you write "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", what do you mean by that? What was the basis and grounds for this kind of anticipation?

Also how did the empowering of associates look like in practice?

Hi Ann,

Whenever you have a major change rolling out I think it's normal to expect complications. So, in this case we were rolling out the new collaborative workflow, and we were also rolling out a new IT system to support that workflow (something I haven't written about here). The combination of those two things led to the desire to create contingency plans. Especially when we're talking about a behavior change, the actual transition can be very difficult.

In terms of the empowering of associates, are you familiar with design thinking? Design thinking is what inspired the idea. Essentially the associates went through the process, which includes understanding the problem, brainstorming ideas, prototyping solutions and testing them out, finally then choosing a solution. The associates did all of this themselves, I facilitated, and I also kept management informed.


For those looking for more detail on the swarming workflow, I've added those to an expanded version of this article on the MIX management exchange: this is the correct link...

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.