The Guild Leader—From Facilitator to Strategic Influencer
Part 3 of How to Make Your Engineering Guild Successful
In Part 1 and Part 2, we explored why guilds fail and how to sustain engagement. But no matter how solid your structure or how vibrant your meetings, strong leadership ultimately determines whether your guild flourishes or fades out.
Most of the guilds I led started similarly. I set the meeting agenda and spent most of the time talking to the audience. I usually gave company updates relevant to guild members. Then, I presented weekly dashboards, e.g., with crash metrics, quality insights, and progress in specific initiatives. Then came the knowledge-sharing part, where I, or the most senior engineer, covered an interesting subject. Finally, there was a feedback session to check if everyone liked it.
After such a meeting, you feel like you are doing your job well. So you invite people to share their propositions for the next meeting’s agenda to repeat this success, and... nothing is coming from them.
Many believe an Engineering Guild Leader just takes meeting notes, sends invites, and occasionally presents slides, while engineers will passionately share their stories and ideas.
It’s not true. Running a guild is an ongoing effort, even if it’s just a bi-weekly meeting. The leader is the central driving force, proactively curating content, advocating for the guild with upper management, shaping its strategy, and eventually transitioning it into something bigger if needed.
Below, we’ll break down the five core responsibilities of a guild leader and show you how to handle each with confidence and vision.
1 - Facilitation Is the Heartbeat of the Guild, But It’s Not Enough
The guild’s early days, as described in the previous paragraph, are nothing more than top-down leadership. As I wrote in the past:
If you are a classic, top-down manager, your main focus goes to coordinating data, decisions, and people. (…) Top-down managers act as rulers, but in fast-paced environments, they also face cognitive overload, constant urgency, and the need for a highly detailed understanding of their landscape.
You prepare the agenda, talk to people, collect their feedback, and repeat it at the next meeting. It’s a very one-directional approach. But to make the guild truly successful, you must transform your style into center-out leadership (for inspiration, read more: Top-down Leadership vs Center-out Leadership).
The first step is facilitation:
Seek Out Silent Voices: Identify shy or imposter-syndrome-prone engineers who hesitate to share. Let everyone speak. For example, organize a 10-minute Post-it session, after which everyone is expected to read their ideas aloud (this is the way to fight the halo effect). Or, during the feedback session, ask directly: “Why did you give 5 out of 5? Does it mean this session cannot be any better?”
Provoke Conversation: Spark debate by posing questions that challenge assumptions—“What stops us from releasing on demand? Why do we need code freezes?”—and invite different points of view. Be the devil’s advocate. Even if you support specific ideas, challenge them and let engineers teach you.
Cheer Loudly: Publicly celebrate wins (as discussed in Part 2) and the people behind those wins.
However, reactive facilitation is not enough. First, you must have good content to facilitate. Effective guild leaders don’t assume the group will magically surface the right topics:
Scout for Ideas: Regularly discuss emerging issues with engineers, team leads, architects, or product managers. Bring those hot topics into your guild sessions.
Divide & Conquer: Observe current projects and challenges being solved and ask the authors for a short presentation. Let people learn from each other. You can also ask certain people to summarize a conference talk or a whitepaper close to their heart. By distributing the load, you avoid the dreaded “one-man show.”
Here’s the thing—“Feel free to add your points to the agenda” never works. You must collect people’s thoughts proactively. Some people avoid extra effort. Others think their challenge or idea isn’t even worth sharing publicly.
Your job is to remind them that a guild isn’t a big IT conference. It’s a place to freely exchange even the smallest ideas and experiences so people can learn from each other continuously.
In my work, I’m the one who repeats ad nauseam, “Can you present it at the next guild meeting, please?"
2 - Bridging the Gap Between Individuals and Management
We emphasized in Part 1 that guilds should focus on engineers’ needs rather than pleasing management. But it doesn’t mean avoiding your CTO. It’s the opposite: