Starting a Frontend Guild: Making Enjoyable Meetings

Last year I started a frontend guild at my current employer. Not because I wanted to teach everyone what I knew, but because I wanted to hear what everyone else was dealing with. The structure was simple: one hour a month, three parts.

The Pitch

I started with my manager, then my manager's manager. The pitch was straightforward: frontend engineers across teams were solving the same problems in different ways, and we had no forum for sharing knowledge.

After getting approval, I wrote an RFC (see my previous post about RFCs) that outlined the problem, the proposal, the structure, and the commitment - just one hour per month. I sent it to the wider organization and invited anyone interested in frontend development to join.

The Problem

Frontend knowledge was siloed across teams. Engineers were duplicating patterns, unaware of changes happening elsewhere, and missing opportunities to learn from each other.

It wasn't that people didn't want to share. There just wasn't a regular forum for it. Slack was mostly emergencies. Confluence and READMEs went stale. One-off conversations didn't scale. We needed something consistent and focused.

The Three-Part Meeting Structure

"We have two ears and one mouth so that we can listen twice as much as we speak." - Epictetus

Every frontend guild meeting followed the same structure - one part for updates from the frontend foundations team I'm on, two parts for others. That two-to-one ratio was deliberate.

Part 1: Intros & Frontend Team Updates (20 minutes)

Start with intros of any people joining for the first time - things they like about frontend, what they've worked on in the past, what they're working on now.

I'm a part of the frontend core team, and I'd share relevant work being done by the entire team. This wasn't a status report - it was curated context-sharing.

New patterns we were introducing: Like Ember single file components that would change how we structured code.

Dependency Maintenance: Design system updates and component migrations, Ember.js and ecosystem updates.

Upcoming changes: Things that would impact developers across teams.

This section set the stage, but it wasn't the point of the meeting. It was the opening act.

Part 2: Show & Tell (20 minutes)

A rotating open spot where a team member showcased in-progress or recently completed work.

The format was intentionally low-friction:

• Not a formal presentation, no slides required
• As casual as needed, just a conversation
• Walking through the app on screenshare, environment didn't matter

Topics ranged from an agents index page refactor to new unified client-side login to scroll behavior after pagination.

I was active in finding volunteers, so there was usually someone ready to share. This improved discoverability of work, which helped with knowing how to test new parts of the app, and gave everyone a platform to share.

Part 3: Open Floor (20 minutes)

The last part was open discussion. I'd often ask newcomers to the guild meeting to tell us about their frontend experience - what they were working on, what tools they were using, what challenges they were facing.

This led to sharing useful links, demoing tools people had discovered, and surfacing problems that weren't big enough for a full presentation but were still worth discussing. It created a conversational space that complemented the more structured showcase.

The Real Goal: Listening

The guild wasn't about teaching others. It was about hearing problems, understanding pain points I couldn't see, making people feel heard, and building community.

Creating space for others to speak surfaced insights I would never have discovered on my own. When someone casually mentioned "yeah, I just copied this polling logic from another file and tweaked it a bit," that was signal. When multiple people mentioned similar pain points, that was a pattern worth addressing.

What Changed

Easy Wins

Better test output:

Our codebase is Ruby and Javascript. Ruby tests printed a nice summary of failures. JavaScript tests didn't.

Someone mentioned that debugging JavaScript test failures was tedious - you had to scroll through the entire output. It was such a minor complaint it might not have warranted a ticket, but it was trivial to fix.

We updated JavaScript test output to match. Easy for us to get prioritized in our backlog, valuable for others.

Local development against staging:

Our local development environment required spinning up 20+ docker containers. To stay up to date for security reasons, these are constantly changing and requiring manual intervention. Changing git branches often means stopping and starting the whole system.

We created a way to develop the frontend locally against our staging environment. This skipped spinning up the local container mess and utilized our shared, continuously deployed staging environment.

Engineers could make frontend changes quickly without fighting their environment first.

Bigger Structural Changes

The problem:

Various polling strategies were propagated through the app. Some had error handling. Some had exponential backoff. Some had page visibility checking. Some had no bells or whistles.

Engineers felt uncomfortable copy/pasting duplicated code with multiple variations. But no shared polling service existed.

How the guild surfaced it:

People voiced frustration about inconsistent polling patterns during presentations. The pain was consistent across teams. Multiple people mentioned it over several months - clearly a systemic issue.

The solution:

We implemented a unified polling service:

• Exponential backoff to be kind to the servers
• Error handling that didn't crash the application
• Page visibility checking to pause when users weren't looking
• Consistent API across the application

Impact:

One endpoint saw a 10x reduction in traffic - it had been hammering our servers unnecessarily because the polling implementation didn't check page visibility.

We got consistent, reliable polling behavior across the entire application. No more "why is this polling implementation different from that one?"

Making It Sustainable

Cadence:

Once a month, Thursdays at 4pm ET. My "it's the weekend" meeting - a good wind-down. Same day, same time, same cadence. People could plan around it.

Keeping attendance up:

Announced at the beginning of the week in Slack with who was presenting. Reminder the morning of with the meeting link. Simple, consistent communication.

Preventing "just another meeting" syndrome:

Gave people who showed up a chance to speak. An open floor is uncommon - most meetings are about disseminating information or making decisions. This one was about listening.

Always tried to let out early. Respecting people's time built goodwill.

Measuring success:

Success meant continued attendance throughout the year - even late December before the holidays. It meant representation by at least one person from all teams that contribute to the project. People returning month after month. When people voluntarily come back, you know it's providing value.

What I Learned

What surprised me:

The guild was a great way to meet new, friendly people throughout the org. Having people engage for most of the hour and want to return was incredibly rewarding.

The human connections mattered as much as the technical outcomes. We built relationships that made future collaboration easier - when you need to coordinate a breaking change, it helps to already know and trust the people affected. Slack was nice, but this was humanizing. A time to enjoy each other's company and shared struggles.

What I'd do differently:

Occasionally include design or product perspectives. The focus on developers allowed for technical depth, but bridging the gap between disciplines would have created even more value.

Most valuable outcome:

The relationships and trust built through the guild.

When someone presented a gnarly bug they'd spent days tracking down, others would share similar experiences. That validation - "yeah, that's a hard problem" - mattered.

When you've seen someone present their work, asked them questions, heard them think - working with them later is different. You already have context and trust.

The Pattern: Create Space for Others

Leadership isn't about having all the answers or being the smartest person in the room. It's about creating space for others to be heard and contribute.

The frontend guild worked because:

Structure enabled participation. The three-part format made it safe and clear. The consistency removed uncertainty.

Listening was the strategy. Two-thirds of the meeting belonged to others. That wasn't an accident - it was the entire point. I learned more from listening than I could have taught.

Low barrier to entry. No slides, no formality, just conversation. You could show up and walk through your work without hours of preparation.

Servant mindset. The goal was to serve the community, not showcase my expertise.

The best meetings aren't about what you say. They're about what you learn by listening.

When you create space for others to speak - really speak, not just rubber-stamp your ideas - you discover problems you didn't know existed and solutions you wouldn't have thought of. The polling service that reduced traffic by 10x? I didn't invent that. I just listened when people complained, recognized the pattern, and created space for my team to solve it.

That's the unlock. Create the forum. Ask the questions. Listen to the answers. Act on what you hear. Repeat monthly.