Why Your “Engineering Guild” Is Quietly Failing And How to Make It Successful
How to Build Your Engineering Guild From Scratch
Around a decade ago, I attended a conference where Spotify representatives discussed their famous engineering culture. One concept they presented was “engineering guilds”—communities of interest with no formal leader where people discuss, evangelize, and learn frontend, backend, machine learning, DevOps, mobile, and more.
Wow - I thought! I was so impressed by the concept. That day, I decided to build my own one.
Ten years later, after building and leading dozens of them (some successful, others miserably failed), I want to help you avoid my mistakes and misconceptions about engineering guilds.
What’s an Engineering Guild and Why It’s Not Enough to Succeed
Leaders often assume that once they call a meeting or group of people a “guild,” engineers will naturally jump in with unstoppable enthusiasm. But here’s the reality: most guilds remain ghost towns, and their valuable topics go unnoticed.
Okay, so you add some "core values" statements as a remedy. Today, AI can quickly generate one (here’s from Gemini 2.0):
Our guild’s values:
Focus on Community: To build a thriving community of engineers dedicated to professional growth and mutual support.
Focus on Excellence: To empower engineers to achieve excellence through collaboration, knowledge sharing, and continuous improvement.
Focus on Growth: To cultivate the next generation of engineering leaders through mentorship, development, and networking.
You put that in the company’s wiki, share it with people, and... nothing.
Engineers—famously autonomous and curious—don’t show up, don’t collaborate, and don’t solve cross-team challenges.
Merely naming something a guild doesn’t make it compelling. Devs crave autonomy but also need clear objectives, an engaging agenda, and quick wins.
Without explicit structure and leadership, most guilds become “optional” gatherings that engineers skip whenever sprint deadlines loom. Lack of clarity about goals, roles, or meeting outcomes erodes engagement even further.
You Build a Guild for Engineers in the First Place, Not for the Company
Imagine you work for an organization with cross-functional teams (e.g., Spotify’s Squads). There’s no central Frontend or Mobile Engineering team. Instead, developers are spread across different divisions, building their features independently. The problem is that they still contribute to a single codebase (whether it’s a monolith or a distributed architecture, at some level, those independent features are combined into a bigger picture anyway).
How could engineering guilds help here? It’s simple—engineers sync across teams, share common standards, and help each other with code review, among other things.
That’s how you sell the concept to management.
No surprise—you’ll likely get buy-in almost immediately. But here’s the trap: inadvertently, you sell a promise of solving tech issues outside regular “product development.” Now, feature teams will have their own backlog, and the guild will have its own—to address all things tech. (Two backlogs are among the most common issues I described in “Optimizing Your ‘20% Time’ for Technical Debt”).
The problem is that an engineering guild is not a platform team—fully focused on developing infrastructure, with a prioritized backlog and regular project management processes. No—after a guild meeting ends, everyone returns to their regular teams to deliver their “product commitment.”
This leads to another tension. Engineers are frustrated they have no time for “guild stuff,” while management thinks no more tech issues will slip into product development. The result? Your guild slowly becomes a quiet corner of Slack, with only one or two folks posting tips while everyone else lurks or forgets it exists.
Here’s the surprising fix: change the narrative from helping the company to helping engineers.
Instead of selling the idea to management, sell it to the group of devs first. With a guild, all Frontend devs will have a “body”—the Frontend Engineering Guild—that can influence management decisions and backlog prioritization.
You, talking with management on behalf of 10 developers from all teams, will have more influence than each engineer individually trying to convince their PM to add just one more “tech-related” ticket to the sprint.
Don’t stop there.
(The rest of this content, where I cover the checklist of running the engineering guild and core components of this concept, is available for premium subscribers of Practical Engineering Management)