Breaking engineering silos: A guide to cross-exposure training

Sport, history and geography geek helping the tech geeks of Mews be seen and heard around the world.

Long gone are the days when everyone in the engineering team sat in one room and knew the whole domain and could (and had to) work on every task that came to them. 

This scenario is a typical image of a small startup where everyone needs to be a generalist (or, as they call it, “full stack”). However, when I think about that, this was never truly the case for Mews. As far as I remember (back when we only had four engineers in the team), there was a clear line between frontend and backend. Why was that? I think it had a lot to do with the two stacks not being too popular in the “full stack” world: JavaScript (TypeScript)/React on frontend and .NET/C# on backend. Still, everyone knew what was happening in each domain and, more importantly, who to go to when stuck. 

Fast forward to the present day, where we have 20+ product teams with 350+ engineers, product managers and designers working on a hell of a complex solution. We are past the point of every engineer knowing every aspect of engineering, and as a remote-first company, our teams are not sitting in the same room anymore, except for virtual ones of course. Naturally, velocity on this scale is different. How did we address this? How do we enable people to touch domains beyond the one they work in daily? And how do we empower engineers to jump into domains outside their core competency or area of expertise? 

Rather than telling you a wordy story of how we did it, this post serves as a guide for setting up such an intitiative, along with our feedback and ideas for improvement.  

Important note: As mentioned, we work in product teams consisting of frontend engineers, backend engineers, QA engineers, product managers, designers and many other roles depending on the size of the team. At the same time, the teams are often rather small, with around eight people each. This means your code will be reviewed by someone from another team but the same domain. 

Let’s not just talk, let’s do it (theory & preparation) 

For this type of exercise, you need buy-in not only from leadership but also from the teams and engineers themselves. Communication is key, so make sure you have the right story to illustrate the importance and benefits of the initiative.  

In our case, it was quite easy because the original idea of being more “T-shaped” came from our engineering leadership. However, the initial discussion caused a bit of chaos because the message wasn’t clear from the start, and some people understood that everyone was expected to become a full-stack engineer.  

Once you have the message sorted out, look for teams with members who are already interested in the other stack and may have some prior experience in the area. These teams are more likely to understand the benefits of such training.  

For the pilot, we identified two teams from the same tribe whose engineers already knew each other a little bit, although maybe not in person, because Mews has distributed teams across different countries. For this reason, we decided to conduct it remotely online (which was not the case in the end, as you’ll read later). 

Make sure to meet with team managers to define the cross-exposure as much as possible in advance. We’ve identified the following areas to be defined and documented:

Roles & responsibilities 

  • Sponsor 
    • Manager(s) of the team that participate(s). 
  • Participants 
    • Have an interest in other technologies. 
    • Make sure to have the respective environment up and running. 
    • One day of pair-programming with someone from a different guild. 
    • Follow up on the experience via a small survey. 
  • Community team 
    • Owners of the program. 
    • Block time in calendars. 
    • Follow up with a survey. 

Basic organizational information 

  • Ideally, the program should occur every six months per team/tribe. 
  • People can request to participate in the program, or the manager can suggest it. 
  • The optimal setup involves having two frontend engineers and two backend engineers participate. 
  • Once the team is assembled, the Community Team blocks out a day in their respective calendars for the event.

Prerequisites 

  • The sponsor ensures all parties have functioning environments on their devices to prevent delays. 
  • The sponsor selects the exercise topics.

What to expect 

  • Pair-programming-like exercise. 
  • ½ day of frontend-to-backend knowledge sharing, and ½ day of backend-to-frontend. 

Outcomes 

  • The work is pushed into production. 
  • Participants will fill out a short post-event survey to ensure continuous improvement of the program. 

Tasks and projects to work on during the cross-exposure 

  • The teams selected several reports to be migrated to frontend.

We’re doing it (reality & feedback) 

The original plan was to include two frontend and two backend engineers for a remote event. However, due to greater interest, we were fortunate enough to host the event in person at our Prague office. In the end, we had three engineers from both stacks. And, honestly, the in-person element helped create a sense of community and a true hackathon feel. In addition to the six engineers, sponsors/managers were present to manage the timing and answer any questions from the team. 

The managers prepared two projects, let’s call them “Big” (four people working on it) and “Small” (two people working on it), dividing participants with an online sorting tool. The plan for the day was the following: 

9:00-9:15 Intro & team allocation 

9:15-9:45 Setting up 

9:45-12:00 Backend Engineers guide Frontend Engineers  

12:00-13:00 Lunch 

13:00-15:15 Frontend Engineers guide Backend Engineers

This is all that was achieved in the production code in one day.

The schedule was almost 100% followed, largely due to having all the environments set up beforehand. One issue we discovered early on was that attendees didn’t know the tasks they would be working on in advance. That would have improved efficiency by allowing discussions before the meeting. We could see that during pair programming, much of the conversation was around the product domain, and it was difficult for people to start “fixing” a report they didn’t know much about. Not knowing the product domain, even though the teams were from the same tribe, proved to be an even bigger challenge than not knowing the tasks themselves.  

Everyone involved agreed that working on production code was the right approach because it allowed people to see the impact instantly. We had an ongoing Slack channel discussion throughout the day, and celebrating the first merge was truly rewarding. 

The team soon realized that the “Big” project was too ambitious to complete, which was a bit discouraging. So try to prepare tasks manageable within a half-day timeframe. It’s impossible to estimate it 100% perfectly, but keep this in mind.

Would you like to try out other stacks once in a while?

Or you are really confident in one and would like to join us?

What feedback did the engineers provide? 

  • “Everything was great. I just wish we had a bit more time. Maybe next time, we could make it a full day by default (or even more days) and have a quick lunch in the office for a real hackathon vibe.” 
  • “The part I loved most was working on a real project that’s quite feasible and could be in production the same day. I also loved getting to work in another domain.” 
  • “It was fantastic, I felt great, and it was fun. We managed to get stuff done, and I met new people. It should happen more often since it is a great routine breaker.” 
  • “It was really insightful to see how both stacks operate and the difficulties we face. It triggered my interest in learning more about our FE, but it also made clear that having real full stack engineers in Mews would be very hard as they would need to learn to navigate huge codebases.” 
  • “I’d give people a better high-level idea of what happens in the cross-exposure, e.g., you will be paired up and working on small initiatives from our codebase. People could spend some time playing around with the unknown IDE for a while before the cross-exposure.” 
  • “The migration of pages from BE to FE seems like the perfect exercise for cross-exposure.” 
  • “The managers created a safe, friendly and fun atmosphere in the room, which was crucial for people to relax.” 
  • “Having little “hackathony” initiatives such as these make – at least in my eyes – Mews more fun and could be leveraged to advertise Mews as a good place to work.” 

What benefits did we observe? 

  • It offers an excellent growth opportunity for our engineers, allowing them to learn a different stack and enhance their hard technical skills. 
  • It fosters growth in software skills, while also emphasizing the importance of strong collaboration, trust, coaching and mentoring. 
  • It improves autonomy and velocity. When delivering incremental values relying on both backend and frontend work, sequencing the right people at the right time can be challenging. This creates mini-dependencies within teams that have the potential to slow us down exponentially over time. 
  • It deepens our understanding of the broader product and architecture. Knowing practical examples of how exactly the product fits together allows us to make more informed and efficient technical decisions.
Since the meeting was held in Prague, chlebíčky and zákusky were a must.

Tips and lessons for the future

We’re seeing more and more that the disconnect between domains is blocking smoother operations between engineers and teams. Hopefully, this exercise will gain momentum with other teams and encourage every engineer to participate. Here are some tips from our experience if you want to try it for yourself:

  1. Don’t underestimate preparation. Prior catchups with management, documentation with basic information, and ensuring everyone has their respective environments ready are crucial steps. Share the tasks and teams in advance to allow communication before the pair programming session. 
  1. Don’t take this post as the only source of truth but as an inspiration. It could be a great team-building activity for the whole team (maybe you have product managers or designers who like to code or engineers who like to design) and even for longer than just a day. 
  1. We were lucky the situation allowed us to do this in person, but don’t get discouraged if you have to do it online. While nothing beats the in-person hackathon feeling, which is valuable for team morale and bonding, remote work is increasingly a part of our culture. Let’s embrace it. 
  1. Ensure the purpose and vision of the exercise are communicated clearly from the outset to avoid misunderstandings. 
  1. Pair engineers in advance and encourage them to spend some time together discussing the domain and familiarizing themselves with the tasks. 
  1. Consider incorporating tasks for QA and potentially Data Engineers. But that may be the next level once we get this one right. 

Are you next?

Lastly, I’d love to thank everyone involved in this pilot. Namely the managers David Müller and Jakub Tkadleček, along with the engineers Taia Makhmutova, Václav Kučera, Matúš König, Samuel Ketels, Jiří Pohanka, and Senem Unal. Who is going to be next in the Mews team? And will you try it out in your company, too? 

Sport, history and geography geek helping the tech geeks of Mews be seen and heard around the world.
Share:

More About