You can tell a lot about a group based on how they choose to self organize. What they decide is important—what values they decide to teach their new members, whether they even choose values at all or let things form naturally—these things reveal what the group holds dear. At Squarespace, few things exemplify our Engineering culture like the Frontend Forum.
Every other Wednesday, the Frontend Engineers at Squarespace convene in a large room to hash out these issues. For the last year and a half, this meeting has served as the primary way that Frontend Engineers (or persons vaguely interested in front-end technology) stay aligned across teams. Developers present new learnings and best practices. We discuss and shop around new technologies and patterns. We decide which haircuts to give our yaks, and what shade of gray looks best on our bike shed.
Beginnings
Like many things, the Frontend Forum started organically. It grew from an irritant planted by the deprecation of our core UI library, YUI 3. At the time, our teams were rapidly expanding, and we had to face a big architectural decision that spanned multiple teams and affected every part of the front end. The team leads did the sensible thing: they solicited engineers to help fix the problem until someone was foolish enough to say yes (me). A coworker and I started prototyping and evaluating technologies but soon realized that pieces were missing.
How would we get the other engineers to learn this stuff? When would they have the time? Everyone was busy working on their own projects, trying to get their features and fixes out the door. Had Yahoo somehow failed to see our product roadmap? How would we get people to agree on the best way to write these things? And generally, how would we get everyone to buy in considering that we highly value individualism and the ability for one engineer to Make a Difference™? Never mind that we still smarted from the deprecation (“Oh, how will I ever learn to love again?” they lamented). And finally, how could we ensure we were leveraging the strong engineers around us to better inform our decision-making?
We started small, bringing in people who were interested in contributing to the new decisions. In those days, we met weekly to go over prototypes and other technologies. Should we transpile? Do we just leave it ES5? What’s this webpack we’re hearing so much about? Week by week, the meeting grew as people became interested, and I continued to invite more to contribute. Soon, we had made the decisions we’d set out to make, but by then the grain of sand had been lacquered into a pearl that was too pretty to throw away. We decided to keep it.
Remaining Relevant
The Frontend Forum is now one of the largest regular gatherings at Squarespace. A few factors played critical roles in ensuring its usefulness.
Some people might have inferred “recurrent meeting with lots of attendees arguing about our pseudo-religious programming practices,” and rightly suppressed an involuntary shudder. Recurrent meetings are dangerous things—they must meet a higher standard, because they’re a permanent decrease in each attendee’s schedule. We’ve been able to avoid many of the traps by approaching it like any problem at Squarespace: get something working, throw away what doesn’t work, keep what does, iterate, polish.
We’ve worked hard to ensure the Forum continues to meet the needs of the team. We’ve experimented with meeting frequency. We’ve surveyed attendees to ensure we’re addressing relevant problems and finding unaddressed green field. This helped us identify early on that the education aspect would be critical, and changed the trajectory away from pure decision-making. Now, we encourage engineers to give talks on the technologies they feel are important or useful. This not only helps us improve technically, but gives engineers a chance to speak publicly in (what we hope to be) a friendlier environment.
Good meeting discipline helps too; agendas and meeting notes sandwich every Forum. If the agenda is too light, we cancel it. Being surrounded by engaged, thoughtful engineers willing to get together and roll up their sleeves also helps. When we notice a lily becoming gilded, or veering into minutiae, we form a small group to discuss the merits, and then present the findings at the next forum.
Being open, inclusive, and optional plays a critical role in guaranteeing that the right people are in the room for the meeting. The energy of the passionate can get harnessed in productive ways instead of dissipated as waste heat around the water cooler. Those less interested in helping guide conventions and practices find themselves free to read the meeting summaries and our components handbooks. The presentations and proposals we make persist as living documents that codify the practices and patterns required to let a large codebase cohere. Having a long-running log of our meetings, designated Wikis, and demo applications makes it so we can avoid repeating past mistakes, and also ensures that future engineers can come up to speed as quickly as possible.
Also, since the Frontend Forum is discipline oriented, rather than team oriented, our Frontenders can stay aligned despite any team shuffling, product-related reorganizations, or quirks of team composition. (I mean, sometimes you find yourself as the lone Frontend person on a team.) This also makes it one of the stronger acculturating factors, and helps ensure that we impart our teams’ values to new engineers.
Adapting
It didn’t (and doesn’t!) always go perfectly, I’ll admit. I have bored a crowd or two waxing poetically about the virtues of alphabetizing lists. Occasionally, a topic will arise so narrowly scoped that they’d have been better handled by the small subset that cares about it. But every important lesson we have learned with the Forum started as a mistake.
No organization is perfect, and I think it’s important to understand that perfection is the aim, not the goal. Even though sometimes it feels like this,
I feel lucky to work somewhere that allows us to experiment, tweak, and try to find something that fits our needs, and that can adapt when circumstances change.
So that’s just a process that works for us. What I’d love is to hear what has worked for you, and how you and your team have tried to address the less crunchy needs of your team. Or better yet, join ours!