At xMatters, our group of 100 or so talented engineers is subdivided into teams tackling everything from front-end work to release automation to user interface (UI) and user experience (UX). As is common in an agile-minded organization, our engineering team members are cross-functional, with knowledge and expertise that carries over into areas outside their main focus. The advantages of this cross-functionality are an enhanced, self-organized form of collaboration and a more contextual understanding of project needs and goals—all of which ultimately lead to faster innovation.

When I joined the company seven years ago, we had three engineering teams. We were already utilizing agile methodologies to eliminate as many inefficiencies as possible and streamline the continuous delivery process. However, as we grew to six, seven and upwards of eight teams, we realized that agile principles weren’t enough to scale the benefits. There was still a tipping point at which critical information started to silo and communication hurdles began to creep up between teams.

Despite the stellar performance and incredible strides we had achieved with our platform, there still was room for us to grow and become smarter, faster and more productive. We needed a solution for this problem at the team-level, and for this we found that another cultural transformation was necessary.

Here’s how it started: We observed that many of our engineers had keen interests in areas outside their usual scope, and that we could harness their interests as a valuable resource. There was the possibility of another kind of team—less official and more fluid—that would allow us to capture new ideas and solutions to problems as well as give our engineers the opportunity to engage in their interests.

Thus, we adopted the concept of “guilds,” originally pioneered by Spotify’s development team. While Spotify’s structure is more complex to account for its nearly 2,000 engineers (it utilizes squads, tribes, chapters and guilds), the premise is the same: Allow people from different teams to come together fluidly and collaborate on a shared purpose. Our teams already utilized Slack for internal communications, and so we also created relevant channels for guilds.

For instance, the UX guild exists separately from our dedicated UX team to include members from the front-end and other teams. We also have a test guild, comprised mostly of QA team members, who meet in person or over videoconference on a monthly basis. Our architecture guild features people from across nearly every engineering team who are interested in discussing the way we build our platform and structure our code base. Whenever people have an architecture-related problem, they post it to the architecture guild, and its members devise, record and vet a solution.

In one case, we needed a way to configure all our customer’s environments and also replicate those configurations globally across our data centers around the world. The conversation about this issue arose in the architecture guild channel, and through it we gathered all of the necessary information and expertise to work on a spike and write a complete architecture document.

If you’re at an agile-minded organization and are thinking of implementing guilds, the most important thing is to create an open, welcoming environment. Don’t try to structure them or make them overly formal; in principle, they should be self-governing entities that are virtually hierarchy-less. One of the coolest things about guilds is that they will be self-vetted by your community of engineers, so as soon as one no longer serves a function or becomes redundant, it naturally will fizzle out. We saw this happen with an auto-testing guild (for automation testing vs. manual testing)—it was essentially absorbed into the testing guild.

Remember, in addition to bringing together experts in different areas, you’re inviting newbies who are interested in learning. There are so many advantages to this approach: You not only benefit from free user testing—in the case of the UX guild—but you also can harness a diversity of skill sets and creative minds to solve problems. As Einstein once said, “We cannot solve our problems with the same thinking we used when we created them.” NASA has taken this idea to heart, and has long used public crowdsourcing to solve problems for humanity in space and create new, innovative projects.

The people who ultimately create the solutions often don’t have any traditional experience or expertise in the same area as the problem itself. Sometimes, it takes the collaboration of those both near and far from an issue to overcome it.

About the Author / Nick Fletcher

Nick Fletcher, Engineering Manager at xMatters, started designing and developing websites back in 1998, when the World Wide Web was the Next Big Thing. In the time since that first website, he’s mastered all the aspects involved in creating great products: design, development and strong leadership. Connect with him on LinkedIn.