Don’t stop believing: The fall and rise of a tech forum

Working in a rapidly growing RnD organization can bring both lots of new opportunities and challenges. New hires do not necessarily come from the same tech background or are accustomed to the same development standards. On the other hand, some senior developers may feel they have fewer ways to influence the tech decision-making, which becomes more hierarchical.

One of the solutions for these challenges are tech forums, which are aimed at setting the dev standards for RnD and communicating them. Such forums can provide their members with more opportunities for growth and influence. They can also fail and become irrelevant if they aren’t active and engaging.

At Yotpo, we’ve established a few such forums. One of them is our User Generated Content Group tech forum that I’ve been leading for the last 3 years, and which now plays a crucial role in our tech decision making. If you want to know how it was born, where we struggled and how we eventually managed to make it work — keep on reading…

The forum’s first version

Our forum was initiated a few years ago when we were growing from one small dev group to multiple groups, each working on a separate product — we were hiring and acquiring.
Our codebase was a few years old back then and starting to show signs of age, becoming less suited to our growing scale. RnD’s tech leadership initiated a transition to a different tech stack and microservices architecture — concepts, not all our engineers were familiar with at the time.

One of the ways to help with that transition in my group was a new tech forum, including one senior engineer from each team, and working in the following format:

• Bi-weekly meetings — mainly to discuss our new tech vision and decisions, to make them understandable and pass them down to the teams
• Quarterly meetings — to set our tech road map, based on our new stack
• Ad-hoc on-demand meetings — to design-review new complicated services and processes

While this helped with knowledge sharing, it was not engaging and did not leave much room for an active role for the members. The vibe around the forum was becoming like it was a place to listen to someone else’s decisions, rather than take part in them. It was getting much harder to keep the members engaged, and we started to skip meetings.

Revision

A year ago, we started to question if this was the right way. Together with the group management, we decided to revisit the forum and redefine its vision. Each member got the chance to provide their input and suggest the stuff they’d want to do in the forum. Together we outlined the following principles:

Hands-on forum

We decided to spend more time on writing code together around initiatives we considered important, to help make the developers active members of the forum. Moreover, hands-on experience was supposed to help them better understand and later explain our new stack and tools to their teams. This was backed by management, which guaranteed we’d be getting dedicated time for that — a crucial requirement for success.

Forum for problem-solving, and not just theoretical discussions

Closely connected to the previous bullet, the idea here was to make sure we were not only talking about theories none of us met in practice. It was the members’ responsibility to make sure such problems were introduced to the forum.

A place for education and knowledge sharing

Other than keeping the developers engaged, we still had to help the group with the transition to the new architecture and standards.

Combining all of the above, the forum would now guarantee the members a more active role, based on the cooperation and agenda they were willing to provide. Soon we started working in the new format.

Signs of success

Hands-on work and problem solving

First, we initiated a PoC for a new observability tool required by the teams. The PoC was successful and led to a revision of our observability stack, in which our forum played an active role as well.
This was also the first chance for the forum to work together, to understand each other’s approaches to code and problem solving, learning and sharing — efficiently creating a more consolidated forum.

Education and knowledge sharing

We initiated a series of group education meetings, based on a plan we’d outlined. Each member conducted at least one of them. This in turn provided the forum with an opportunity to deep dive into topics they were passionate about, and supported the members’ growth and positioning as tech authorities.

We also continued working on our roadmap, including an offsite and a series of meetings with the management, aimed at defining our tech vision for the next few years. In between, we still had our standard meetings around code and design reviews, to make sure we were aligned on those aspects.

Eventually, these initiatives turned the forum into a living one and provided every member with dedicated time for professional growth and innovation. In turn, it helped us build standardized processes, as we were becoming a forum that was speaking the same language and could more easily promote the same language within the teams.

The future

Our group is continuously growing, and we are expected to double our headcount in the next 2 years. Our next challenges will be related to the growth, rapid development and easier adoption of our latest tech vision. Our tech forum will continue to play a crucial role in these processes, making sure we support both the growth of the company, and the personal growth of the forum’s members.

We already have a long-term plan for the hands-on work, helping solve problems that currently slow us down during onboarding and then development. Of course, we will also continue working on the group’s education and introduction to our tech tools.

As we grow, members from new teams are expected to join the forum. Ergo, they will have the same place to share their team’s problems, learn, influence and keep us working as a group towards having the same standards across all teams.

Wrapping up

Quite often tech forums tend to fail, as they lose context and agenda. This can happen when they become too theoretical or irrelevant to real day-to-day problems, and make the participants feel like they are wasting time they don’t have.

Sometimes, the path that’s chosen around such problems is ignoring them, until the forum ceases to exist. When we realized this was happening to our forum, we decided to discuss it openly with the forum’s members, and see what they had to say. Based on their input and cooperation, and the commitment from them and the management, we revisited our forum’s guiding principles and eventually made it work.

While there may be no bulletproof recipe here, my personal lesson is that it’s always better to have an open discussion with members of any such forum. Let them have a say and own it, instead of just letting it fade away and lose an important tool en route.