The Need for Community
Wayfair’s engineering team has gone through immense growth over the past few years sometimes hiring and onboarding over 40 engineers per month. In such extreme conditions it can be difficult to hold onto culture and teams begin to sub-divide making it difficult to keep in touch with what everyone is doing. Additionally, most engineers are on small cross-functional teams making it difficult to get a sense community across any single function (e.g. frontend engineers).
Each league has a lead who is responsible for tracking member sign-up and event attendance. Each league breaks down into chapters of ~10 members each who meet regularly to take part in a planned activity. Each chapter has a lead who is responsible for scheduling the meeting and having some activity planned.
At the start we had high hopes for activities including book clubs, live code review sessions, code spelunking (deep dive into codebase), formal presentations, and live coding. But we quickly found that engineers were most comfortable and successful with one specific format: presentation followed by discussion. This allows one engineer to practice presenting and diving into a specific topic, and discussion let all members participate.
Additionally we schedule a quarterly all-hands meeting to get all chapters together for presentations and discussion.
The initial success spawned new leagues for QA, managers, and cross-platform engineers. We also send quarterly newsletters with recordings and notes from the meetings to keep all engineers in the loop and to solicit membership.
Covid Hit Hard
After going full remote in March activity significantly died down. Remote community building is difficult. Additionally, it was becoming difficult to consistently find people ready with content to present due to busy times of the year and topics we’ve already covered. One silver lining was that our previously remote engineers were now on a level playing field and happy to participate.
The league leads grouped to try different things. The iOS league shifted chapters to be more topic focused and made membership fluid. This way engineers can pick topics they’re most interested in, have consistent topic, and choose a chapter that best fits their schedule. The JS league introduced a remote panel format all hands meeting where a smaller set of people talk and we field questions from the audience.
Finally, we introduced “clubs” as targeted learning groups that meet weekly to tackle specific course material. All credit goes to Kent C. Dodds for this idea. The difference between what we’ve tried before and clubs is the emphasis on measuring value and getting buy-in and commitment. Club dates and times are chosen before sign-up so that engineers can speak with their manager and confirm they have the time to commit. We’re tracking value in a few ways: feedback from club lead during the course, feedback via NPS (Net Promoter Score) at the end of the course, and a followup survey one month after the course to see how the information was used in day-to-day projects.
Where we’re heading
We’re going to continue to evolve to optimize for career growth, learning, and a sense of community while keeping what works. Something we’re going to try soon is weekly coffee chats. So far our sense of community is very tightly tied to technical skill and learning but there’s so much more to engineer career development and life and we want a forum to bring this community to life.
We’re also trialing a private instance of Forem, the platform that powers this site (dev.to). Having a place for open long-form async communication is a key missing piece of communication in the company.
To sum up my key take aways: community building is hard and requires dedicated owners, there is no one size fits all strategy so keep trying new things, and to keep an eye on moving the needle on the problem you’re trying to solve.