Merriam-Webster defines ‘polyglot’ as a mixture or confusion of languages or nomenclatures.

Sounds like a promise and a warning, right?

It is.

Done right, a good mixture provides strength, depth and variety. Those are good things. Confusion... not so much—especially when it comes to managing developers. Hiring and maintaining a mixture of programmers with a working knowledge of several languages, storage options and platforms enhances your development team and gives you more options when problems arise. In fact, here are four reasons why you should let your devs choose their programming language. However, you can’t tell your developers, “Choose any language you like and start building.” That approach might excite your developers, but it almost guarantees you’ll end up with technology you can’t use long-term.

Fortunately, building and maintaining a polyglot dev team isn’t too difficult, but it does require a very strategic approach to selecting and deploying new technologies. So, how do we harness the strength, depth and variety of a polyglot culture without dipping into the confusion side of the definition?

Polyglot dev teams: How to keep the strength and dump the confusion

When new business needs come up, have your development team respond with potential solutions. Sometimes those solutions involve adopting a new language or platform. At Pluralsight – as a developer-led company – we love to see this kind of problem-solving and inventiveness. But it has to balance with our resources and strategy. We can’t afford to adopt new technologies without a compelling business reason, and neither can you.

Rather than simply running with the proposed solution, a representative of the dev team should present the idea to a group of work peers who are also well-versed in architecture, platforms, storage and the variety of languages that are currently part of the technology stack. At Pluralsight, we go with an Architecture Guild approach.

In this presentation, the dev team should lay out the problem. (Consider using the RAPID framework, a tool developed by Bain & Company that clarifies decision-making and accountability.)

Have your team present the issue they are trying to solve and the technology they’ve identified to do it. It might sound something like this: “We’re trying to implement a technology that allows us to share X feature (for us it was our notes feature) across a client’s organization within a subscription. We think the Firebase database technology would work great for that.” Have your team explain the use cases and why this solution will work.

Then, the different members of the group discuss the proposal. Someone might argue that this might be a great solution because his or her team used it for another feature of the product and it worked well. Another Guild member might share his or her experience where the solution didn’t work so well. Someone from the security team might raise an issue with where the data is stored, creating a security issue. Ask yourself: Are our developers asking for this because they are excited to try something new, or is there a real business case for adopting the new technology?

Polyglot dev teams: Outcomes and how new technology decisions are made

All of this discussion creates an opportunity for feedback on the idea and whether the team should move forward. There are three potential outcomes:

• First, yes, build it.
• Second, no, this isn’t a good solution right now.
• Or third, and most common, let’s run an experiment and have the team come back and report on the results. This helps us identify issues that come up in production that the team may not have anticipated in planning.

The RAPID process, which I mentioned above, allows our employees to discover and surface new ideas that might be overlooked by the teams that oversee our technology stack. Additionally, we use a second tool to help ensure the technologies we use are relevant to our employees and our customers. It’s our own version of the technology radar, a framework developed by Thoughtworks, (here’s a post on how  to use the radar) helps us visualize which new technologies we should adopt, which we should keep an eye on and which are candidates for retirement. Our radar helps us identify new languages, storage options and platforms our employees should be exploring.

Ultimately the final decision should comes from your peer group (AKA our Architecture Guild). And typically, it’s best to iterate into new solutions, rather than jump in with both feet. Build and launch to an internal team, then roll it out to a small subset of customers—as we do with our integrated approach to product development. Finally, it’s time to deploy to the entire customer base, permitting the solution proves to work as well as predicted.

Polyglot dev teams: Not for everyone or every project

Before you give your teams the polyglot push, consider the tradeoffs. While polyglot teams can introduce new solutions and ideas to explore, it also creates complexity in managing people and technology. (Remember that confusion part of the definition we mentioned?) The more technologies in a production environment, the harder it is to support and maintain. There’s a good argument that smaller development teams should be wary about adopting a range of new technologies that they may not be staffed to deal with.

When you deploy a new experience to production, you need consistent ways to know if the experience is performing as expected and the ability to alert the right people when things go wrong. Additionally, there are dozens of tasks that every team needs to correctly figure out in order for the new technology to even work. That takes manpower, time and oversight that a lot of smaller teams or companies simply don’t have.

Even larger companies with a simple technology stack might not find solid business reasons to adopt a polyglot team. But that shouldn’t stop them from encouraging employees to learn a variety of languages and platforms. The actual technology they learn may not be applicable to current needs, but they will pick up tools, techniques and new ideas to help them approach problems from new and different directions.

And that, more than anything else, is the reason your organization should at the very least think about building a polyglot development team.

Make sure your devs are keeping up with important tech trends.

Get the guide: Finding your way in today's rapidly changing tech environment