In most organizations, communication between different professionals is a source of frustration and delays: developers are frustrated by QA's requirements, graphic designers feel their vision gets lost, and DevOps teams feel they receive requests that ignore infrastructure requirements... Sound familiar?
And the most frustrating part: beyond the frustration, these problems directly hurt timelines and delivery quality.
One of the main ways to tackle these challenges is to create a unified professional language. A language like this bridges gaps, prevents duplicate work, and reduces frustration. Among other things, guilds work on finding that shared language, both among guild members and with the other professional teams they work with.
Here's how it happens in practice:
Before we start, why does this matter?
Picture a single spec document that gets interpreted into several different versions, and every time, the developers have to decode the things that matter most to them. Sometimes information is missing, sometimes the way it's presented makes it harder to decode the needs, and so on.
A unified professional language is a critical tool for bridging gaps between professional teams. It prevents misunderstandings, makes it easier to divide responsibilities, and ensures everyone knows exactly what's expected of them. The goal is to prevent duplicate work, align expectations, and save time and energy for everyone involved in the process.
The catch is that the shared language starts among the professionals themselves: among all the UX people in the organization, among all the analysts, and so on... And that's where the guild comes in.
Where does a guild come in?
One of a guild's main missions is to create standardization and to model the work processes across the different product units.
The most critical stage in a guild is understanding which processes are relevant to all the professionals (regardless of the product unit they belong to), how to support those processes so they're easier to carry out in practice, and what can be done so that all (or most) guild members speak the same language.
This mission creates a significant challenge. In one of the processes we ran at Glue, we saw clearly how proud the different teams are of the processes and materials they work on, and how hard it is for them to imagine having to adopt a new way of working. That's how it is when you're used to working a certain way and someone asks you to change...
Once you crack this challenge, you can see how unified processes and cross-team work methods bring calm both to the professionals' own workflow (starting from a new employee's onboarding) and to their work with the teams they interface with.
How do you do it in practice?
To create a shared language, we start with the internal processes and then move on to processes that involve other teams in the organization. Here's what it looks like in practice when we do it together:
Step 1: Map the current state and all the basic processes the professionals work on day to day. Everything that repeats again and again in their workflows and that we'd like to model in one way or another.
Step 2: Catalog the processes into internal processes (known only to the professionals themselves) and processes that involve other teams in the organization. Then prioritize them by importance and impact on delivery.
Step 3: The guild starts working on them and building knowledge bases and new processes together with the guild members, who bring their personal knowledge and create outputs they're happy with. The kind they'll look at and say: "We'll use this."
Step 4: Rollout and measuring success. First with the guild members themselves, and later with the different teams they work with. We start with specific projects, learn what needs to change and how to improve a bit more, and then expand the rollout to more projects.
For example, a guild can write shared guides for all the teams, like spec documents or checklists that make it easier for QA to verify that new features are ready. It can also create shared component libraries for designers and developers, and more.
What have we learned from similar processes in different organizations?
Creating a unified language takes a structured process that combines planning, communication, and collaboration.
- Start small: choose one project where you put the outputs to work. Choose early adopters who are willing to try and curious to see the change. See how it works, what succeeds and what doesn't, and improve. It's important to define clear success metrics for the rollout.
- Share the success with the whole guild: turn the pilot into a case study that shows the benefits, the value, and the improvement since the changes were introduced. This is where we talk in terms of money saved, shorter processes, real-world ease of use, and more.
- Expand the impact and measure results with the teams you interface with.
To sum up
A unified professional language is the key to stronger collaboration, deeper trust, and greater organizational efficiency. Professional guilds go beyond a technical solution: they're an engine for building an organizational culture that reduces frustration and leads to shared success.
If your organization is looking for a shared language, guilds are probably the right solution for you. And if you're still deciding, we're here to help!