The Front-end Guild: Alignment, growth (and fun)

Early in my front-end engineering career, I worked as a consultant in the professional service team for Backbase, which was then an ambitious startup working for many clients internationally (they now have over 1000 employees). This was a very exciting time for me, working as part of a diverse group of people with the same goals, working for different companies located in many different places in the world.

Within the professional services group, we had a weekly meeting on Friday — initially at the end of the day with beers, later we decided a breakfast with coffee was more productive 🤭. In this meeting we shared ideas, best practices and challenges we faced working on projects for our clients.

Here I saw first-hand the value of cultivating knowledge sharing within a tightly-knit group of people working to solve similar problems, especially when those problems are to be solved across different projects (and continents).

Taking this experience with me throughout my career, since I joined FindHotel to bootstrap the front-end discipline, I have been advocating for the “Front-end Guild”. At first as the sole member but our Slack channel is now an impressive 17 members strong! Since we are scaling and expanding all areas of engineering at FindHotel, the need to share knowledge and make decisions efficiently is becoming even more important than it was when the company was smaller.

In this post, I will share how we use the guild to share knowledge, and make decisions that span multiple squads and tribes.

What is the Front-end Guild?

At FindHotel we roughly follow the “Spotify model” terminology to organize ourselves in Chapters, Tribes, Squads and Guilds. The Front-end Guild is a group of people within the company who share a passion for front-end engineering. This obviously includes all our front-end engineers, but also colleagues from other disciplines that are interested in sharing knowledge related to anything “front-end”.
Since the engineers in the guild work across different squads and tribes, the guild is a space in the company where we connect and make decisions together — for the latter aspect I’ve seen the term “council” being used, which arguably might be a better name, but it sounds too official for the knowledge sharing and fun parts 😃

What Does the Guild Do?

We have engineers working across different squads on the same product in a monorepo. We share code and concepts via core “packages”, and components via a shared design system that is maintained in collaboration with our UX discipline. Sharing a repository means any change you make in the shared code can affect your colleagues, and in order to contribute to the different systems effectively, it’s obviously beneficial to have a common way of working. Since we don’t hire people for the short term or a specific project, this alignment will also allow people to move across squads and projects with less friction.

On top of the practical alignment on how we work together, it is also a place where we can help each other grow and inspire each other.

Some of the things we do as a guild:

• Showcase and discuss interesting engineering patterns we’ve come across
• Share interesting tools we can consider adopting
• Share best practices
• Decide on architecture
• Decide on code conventions
• Document and implement process improvements to our collective way of working
• Have fun 🤪

Making Decisions

We use several platforms and rituals to make decisions as a group.

As we are growing, certain synchronous ways of making decisions that used to work when we were smaller, such as only during in-person meetings, are no longer efficient. Recently we started experimenting by adding more formalized asynchronous ways to prepare and make our decisions.

We use the following communication channels at the moment:

• Asynchronous discussions in Slack for urgent help and emergencies 🔥
• Asynchronous discussions and sharing of inspirational content via the GitHub Discussions platform 🧠
• Bi-weekly Front-end Sync: Synchronous (remote) meeting, since we’re people (nice ones too, may I add?) 👨‍👩‍👧‍👦

Best practices, incremental or reversible decisions

For decisions only related to front-end code, or for decisions that are easily reversed, we are experimenting with Github Discussions. We use it to prepare and collect feedback on a proposed decision before sharing it in the synchronous Front-end Sync meeting.

We collect feedback asynchronously for a certain period, for instance for two weeks, or more depending on the contentiousness or complexity of the topic, to lock in a decision that is again presented during the Front-end Sync meeting.

Non-incremental / architecture changes

We maintain an engineering roadmap in Clubhouse / Shortcut that we use to map out bigger topics that span multiple squads, such as our migration from Flow to TypeScript, migrating to a new major version of React, or significant changes to the Design System that the team implements together.

We are still tweaking the process on dealing with topics on the engineering roadmap. For now we assign one owner that is pushing the initiative — usually this is connected to that person’s individual growth plan — where others can join in on the effort in solving these cross-squad initiatives. We prioritize the initiatives by potential impact / value, and effort to try and ensure we’re attacking them in the right order.

Cross-discipline or hard-to-reverse decisions

For bigger topics that span multiple disciplines across the company we utilize Request for Comments (RFC) documents to collect ideas before jumping on implementation. This process resides outside of the Guild itself because it touches other disciples than front-end engineering, but they can be initiated by Guild members.

Documenting Decisions

After a decision has been made they are recorded in the tool where the discussion originated, and as part of our documentation in the monorepo for future reference.

In terms of documenting the decisions, we adopted the Redux Best Practices Documentation style of categorizing them in three levels to signify the importance of a rule or advice, though we adapted their meaning a little for our internal use:

Priority A Essential:

These rules are for determining the usage of certain critical dependencies or help prevent errors, so learn and abide by them at all costs. Exceptions may exist, but should be very rare.

If you encounter violations during code review, you should block the PR from being merged until the issue is adequately addressed.

The only exceptions to this rule are urgent hotfixes when the website is on fire 🔥 and our users are hurting, or during a POC phase (but please fix the violation soon after).

Priority B Strongly Recommended:

These rules have been found to improve readability and/or developer experience in our collective experience. Your code will still run if you violate them, but violations should be rare and well-justified.

Follow these rules whenever it is reasonably possible.

Priority C Recommended:

If there are multiple options with similar value and effort estimates are available, pick the recommendation for consistency and the avoidance of bike-shedding. In these rules, we describe each acceptable option and suggest a default choice. That means you can feel free to make a different choice, as long as you’re consistent and have a good reason.

Please do have a good reason though!

Documented decisions

As mentioned, once we decide on a best practice or decision, it gets added to our official set of documentation that resides next to the code in the monorepo, like this documentation of best practices around type checking:

This is the current TOC of our documentation:

Other ways of growing together

In this post I focussed specifically on the Front-end Guild, but there are many more initiatives in the company that focus on knowledge sharing and growing together. We have for instance an Elixir Guild, while the Offer Squad holds bi-weekly architecture jams to improve their architecture together. Within the Engineering Chapter level we have bi-weekly slots for “tech-talks” where colleagues can present engineering challenges they are facing and receive feedback on them.

Every week on Friday we reserve so called demo-time for the whole company where everybody can present and discuss completed work they are proud of in short 5 minute presentations. This is also the time where colleagues can ask clarifying questions on how / what is being shipped to our customers and give suggestion on how to improve features, what A/B test to run next as follow up, etc.

Finally, as Andreea already pointed out, we keep a library and in another post, Fernando explained we have a yearly budget that our colleagues can spend on growth on an individual level.

Help us scale

We are still fine-tuning our processes, trying to balance democratizing important decisions, making local ones quickly to move fast, and planning larger cross-squad changes to help our organization scale to help our customer better.

We will need to utilize and optimize the Front-end Guild and other knowledge sharing vehicles much more as we’re planning to grow the team greatly over the next period; we’re happy to hear your story on knowledge sharing and decision making, and if you are considering joining us to help with this, have a look at our career page!

Written by Jop de Klein

Originally published at https://blog.findhotel.net on August 16, 2021.