There is a particular kind of loneliness that comes with being the only person on a team who owns a skill.

You know the situation. You’re the frontend developer embedded on a product team. Everyone else is full-stack, backend, or otherwise unconcerned with whether the component library is being used consistently. You care deeply about this. You have opinions. Strong ones. And yet, every sprint, the same patterns creep in. The same shortcuts get taken. The same “we’ll clean it up later” decisions get made, and later never comes.

The problem is not that your teammates are careless. They’re not. The problem is that frontend (or design, or security, or data, or whatever your specialty happens to be) is not their primary lens. It’s yours. And no amount of pull request comments or Slack messages is going to change the culture of a team by yourself. You cannot hold the line alone. And honestly, you shouldn’t have to.

A few years into leading an engineering team at a startup, I watched this play out in slow motion. We were growing fast. Each product team had a frontend developer or two embedded in it, which sounds great on paper. In practice it meant that every frontend concern, every standards question, every “wait, should we really be doing it this way” moment landed on one person per team.

They were capable. They were passionate. They were also exhausted and a little demoralized, because the math simply does not work when you are the sole keeper of the flame. It’s a lonely gig!

We needed a different approach. Not a new process, not another meeting on the calendar, not a standards document that everyone would agree to and nobody would read. Something lighter than that. Something that felt less like compliance and more like community.

So, you guessed it – we started a frontend guild.

The concept was simple. Once a month, anyone who cared about frontend development, or was curious about it, or just wanted to see what was going on, got together. We shared what we were working on. We talked about best practices. We did workshops. Sometimes we had presentations. Sometimes it was just a good conversation. I got a little budget for food and drink and made sure we had a solid agenda.

Crucially, I did not run it. Not for long, anyway. From the start, I framed the leadership role as an opportunity, not a chore. I asked some of my more senior developers to take point. They got to build their presentation skills, shape the agenda, and have real influence across an engineering organization that they didn’t formally manage. That last part mattered more than I expected. There is something genuinely motivating about being the person who sets the tone for a room full of your peers.

We put a six month rotation on the leadership role. This turned out to be one of the better decisions we made. Fresh leadership meant fresh energy and fresh ideas. It also meant that everyone who had led it felt a particular empathy for whoever was leading it next. You’d been in that seat. You knew what it took.

Attendance grew over time. That is usually not something you can say about a recurring meeting. Then something happened that I did not see coming.

A developer who was not a frontend specialist volunteered to give a talk.

I want to be clear about what this meant. This was not someone doing a favor, or fulfilling an obligation, or being voluntold. This was a full-stack developer who had been attending the guild, had developed opinions, and wanted to share them with the group. That was the moment I knew it was working.

Because the goal was never really “make the frontend developers feel less lonely,” although that was a nice side effect. The real goal was to shift the org’s culture so that frontend was everybody’s concern, not just the specialists’. And you cannot mandate that shift. You cannot put it in a ticket or write it into a job description. What you can do is create a space where the interest develops naturally, where full-stack developers start to build context and confidence, and where one day someone raises their hand and says: I have something to share.

Around the same time, we were in the middle of a framework migration. This is the kind of project that has a way of making everyone quietly miserable if it isn’t framed well. Migrations are long. Progress is invisible for stretches. It is very easy to feel like you are hiking and the summit is not getting any closer.

A developer led a guild session on it. Not a status update, not a mandate from above. Just a peer standing up and explaining their approach. The framing they chose was simple: incremental progress is good progress. You don’t have to get there all at once. Small wins count.

That reframe did more for team morale on that migration than any project plan I could have written. It came from the right person, in the right room, with the right level of credibility. Nobody was being managed. Everyone was just figuring it out together.

Underneath all the the pomp and circumstance of a guild meeting, they really just create a permission structure. Permission for the full-stack developer to care about frontend. Permission for the junior developer to have an opinion on the migration strategy. Permission for the person without a management title to lead a room. The format does not create any of this directly. It just makes it easier for it to exist.

Andy Grove writes about how values and behavioral norms are not transmitted by talk or memo, but by doing, and doing visibly. A guild is a place where doing happens visibly, repeatedly, in front of your peers. That is how “we’re ALL frontend developers now” stops being a slogan and starts being true.

If you want to start one, here is what actually matters:

Keep it light. The moment it feels like a compliance exercise, you’ve lost. It should feel like the best kind of optional that people actually show up for.

Give the leadership away early. Run the first one or two yourself to set the tone, then hand it off. Frame it as a leadership opportunity because it is one. Put a rotation on it from day one. Stick around and coach those who do the leading.

Make room for the non-specialists. The whole point is to blur the lines. If your guild only attracts the people who already care deeply about the domain, it will be a good meeting but it will not change your culture.

Let the topics get weird. AI, a new language, a part of the product nobody on the team fully understands. These are exactly the right things to bring into a guild. The low-stakes format makes scary things approachable. Use that.

Track attendance. Don’t be creepy – it’s to understand the value of the whole thing. If it’s growing, you’re doing something right. If it’s shrinking, that’s worth digging into as well.

The lonely specialist problem does not go away entirely. But when the whole team starts to share the language, the context, and a bit of curiosity, it gets a lot less lonely. That is the point.