linkedin Skip to Main Content
Just announced: We now support interviewing in spreadsheets!
Back to blog

How We Merged a Global, Hybrid Engineering Team

Engineering Management

Ahhh, how quickly things can change.

Six months ago, I was working as the COO at CodinGame, overseeing a team of 16 engineers on a tightly-knit, in-person team in France. Today, after joining forces with CoderPad and becoming Global Head of Engineering, I’m in a very different situation: our engineering team is 40+ strong, distributed across 11 timezones, and features both in-person and fully-remote engs. 

Needless to say, this transition has kept me and the entire organization on our toes. Changing workflows, cross-cultural communication, and team disruptions can be difficult to handle—but through it all, we’ve learned to be better communicators and sharper engineers.

I spoke with CTO Connection about merging teams to form a global engineering organization and how we evolved our practices along the way. Here are a few of the most important takeaways.

We didn’t immediately merge teams — we stayed focused on moving our products forward 🧐

It can be tempting to try to put everything together at once and “force” cohesion immediately. But if all your focus goes toward the activity of merging teams, it’s impossible to push innovation forward and advance the products themselves. 

That’s why we intentionally operate CoderPad and CodinGame separately in many ways (for now, at least). What does that look like in practice? Maintaining velocity in the early days of our merger meant things were essentially business as usual — and that was by design. Our company is evolving in an incredibly competitive sector, and we can’t risk slowing down. 

At the same time, we understood that merging doesn’t just occur naturally. While teams were working on their respective projects, CoderPad assembled a dedicated team to figure out how we could get our products to come together. 

After taking the time to find common ground and understand where the products converged, we shifted our efforts to merging actual teams of engineers.

We started cross-pollinating project teams based on skillsets 🐝

Although it might sound counterintuitive at first, we avoided setting cross-team collaboration as our “default mode.” Our approach from the start was to identify opportunities for cross-team collaboration that made sense (like when we needed to leverage specific skillsets). But we also avoided pushing engineers together when they were moving full speed ahead in product development. 

As I described to CTO Connection, 

We wanted to avoid having a big tunnel effect directly following the acquisition, meaning we merge but don’t make progress on anything… So instead, we looked for complementary skills or topics between teams to serve as our starting point.

Over time, we took small steps to consolidate our processes — but it certainly didn’t happen overnight. This type of slow merge might seem unusual in the hyper-fast world of growing tech orgs. But for us, it turned out to be the key to minimizing confusion and creating a functional, globally-minded engineering culture. 

Here’s what we focused on to ensure our merge stayed on the right track:

  • Sharing knowledge
  • Documenting what works well, then spreading these practices across teams (and continents)
  • Emphasizing transparency and explaining all processes and tools — even if they seem obvious.

This way, when the time comes to merge for bigger projects and new products, anyone can jump onto a team without an insurmountable learning curve.

We moved most meetings and communication into Notion ✍️  

How do you ensure clear communication and productivity when one group of engineers is diving into their workday while another is still in bed?

With disparate time zones and differing cultural norms to overcome, we needed a tool to centralize things. That’s why the CoderPad engineering teams have moved more and more meetings to Notion, a workflow collaboration software that serves as our space for documentation and helps our teams ideate asynchronously. 

Using this platform helps individual engs achieve more autonomy and significantly reduces the back-and-forths that can hold back a company working in several timezones.

For instance, we kick off technical meetings with a well-documented summary of every feature in Notion. Our categories include: Technical description, API details, Storage details, Additional critical tests, monitoring and alerting, security by design, CCPA, scaling projections, refactor/cleanup, UI components, and documentation. You’d be surprised just how much time and confusion are avoided by naming things accurately and making sure everyone knows where to find resources.

Notion has also been critical for running efficient meetings. We typically set up a Notion page for a topic and then serve as the common space to brainstorm and share ideas openly. These pages have become crucial in product ideation, design, and specifications.

I told CTO Connection,

Very often, [Notion] is even better than having a real-life conversation because there is no one that can speak louder than the other. Everyone has a place to gather and share ideas.

Finally, we create templates called “pitch documents.” For instance, when specifying features, several parties can all remain in sync simultaneously within the interface. Responsibilities of different parties in the template might look like this: 

  • A Product Manager owns specifications and design while ensuring brainstorming is going in the right direction.
  • Someone else from Product makes sure the specifications cover all edge cases.
  • The main engineer reviews all specifications and will be responsible for the delivery stage.
  • PR reviewers (identified at the project kick-off) make sure the review happens on schedule.
  • We set dates and deadlines to get a calendar view of what’s going on right now and what’s next without having a meeting.
  • A design team member produces required designs.
  • We have the flexibility to add in other members, such as infra/FE/BE Tech Leads, if needed.

We held offsites to bring everyone together 🤗

No matter how efficient a collaboration software may be, there’s truly no replacement for in-person communication. Our teams have faced both a time zone barrier and a language barrier. Tiny differences — like how we send a quick affirmative response on Slack or the types of informal language we use — got in the way of forging real connections.  

We had all sorts of mishaps when our communications took place exclusively online. Even tiny quirks in a quick Slack message could leave some parties scratching their heads. For instance, in French, we often say “pas mal” / “not bad” when something is actually very good. We noticed that American team members might say “awesome!” when something was, well, pretty normal. Another time, our French Head of Product misheard a Zoom microphone hand-off asking him to introduce himself as, “We don’t have time for an introduction,” then abruptly ended the meeting.

But I found that meeting face to face instantly improved how our teams functioned — even when we returned to online-first correspondence. I recounted this major change in the webinar:

After meeting everyone during an offsite, people were long afraid to speak to others outside of their team. They assume the best, based on the experience they had with the person. It’s basically unlocking the ability to read a person’s words like they were talking in front of you.

Based on our experience, I recommend at least one offsite per year with your immediate team and one company-wide offsite. These should be held out of the office/home for everyone in the organization to ensure that there are no distractions and the time is used to its full potential.

Check out the entire webinar to learn even more about how we merged teams at CoderPad.