Team Collab Header

One of Dialpad’s most unique features is our machine learning powered Voice Intelligence (Vi) technology, which is the product of collaboration across a variety of teams.

👉 Dialpad tip: Voice Intelligence (Vi) is a technology we built from the ground up! With built-in machine learning, it uses natural language processing and voice recognition to provide recommendations in real-time and create comprehensive post-call transcripts and summaries. (Because not everyone can make every meeting—or type fast enough to take notes...)

In this blog post, we’ll reveal how we maintain high-performance, cross-team collaboration remotely—even across multiple locations and time zones—as part of our collaboration on Vi:

  • An overview of our cross-functional Vi teams
  • Different forms of cross-team collaboration
  • Areas of friction in multi-team collaboration
  • 6 tips for cross-team project communication

An overview of our cross-functional Vi teams: ASR, NLP, and DE

As I mentioned earlier, our in-house Vi is capable of handling the entire pipeline from transcribing your speech to providing insights about what you said—all in real-time. It’s a big task, with a big team behind it.

These processes are owned by three teams:

  • Our Automatic Speech Recognition (ASR) team, which mainly works on transcribing speech into readable text

  • Our Natural Language Processing (NLP) team, which uses models to provide insights from these transcriptions

  • Our Data Engineering (DE) team, which supports us in maintaining stable, real-time service for all our customers

As a team, we understand that the true currency in business is not money—but time. That’s why we’re committed to providing accurate data to our customers as quickly as possible. The ultimate goal is always speed and accuracy!

Different forms of cross-team collaboration

Various forms of collaboration are continuously happening across these three teams to make our Vi a better product.

One area we work together in is to establish metrics across all our teams to make sure the quality and accuracy of Vi keeps on improving. For example, ASR and NLP joined forces to identify the impact of ASR’s transcription work on the NLP team's efforts to glean insights from those transcriptions.

To achieve this, we do two main things:

  • Track the changes in ASR models when they are built, and

  • Re-evaluate the NLP models’ performance during our quality assurance process

If the ASR changes result in a degradation in performance for NLP accuracy (which would look like a lower accuracy in how Dialpad identifies action items), we’re able to delay our release, investigate, and make changes before any effects would even make it to our customers.

This is important because text-based insights that are useful for our customers, like Dialpad’s automatic identification of action items, would be affected by the ASR systems’ transcript accuracy!

action items in dialpad's platform

By having our teams join forces, we’re able to carefully assess how changes in transcription impact downstream tasks, and make sure issues are caught and quickly fixed.

Another example of successful collaboration between our teams: To make our Vi as amazing as it can be, we run a fair amount of model experiments. And the time and resources it takes to run these experiments isn't cheap. So, how can we do that while still maintaining high cost-effectiveness?

👉 Dialpad tip: "Experiment setups" basically refer to setting up lots of virtual machines (computers) to run experiments for testing out the best hyperparameters, which would normally take our NLP engineers a very long time to prepare.

To solve this, the NLP and DE teams worked together in constructing an in-house infrastructure for hyperparameter optimization.

👉 Dialpad tip: “Hyperparameter optimization” is essentially a process required by some of our machine learning models that involves searching through vast (the “hyper” part) of parameters in order to get maximum accuracy, with minimum computation time. This process is very expensive, but an essential step before deploying new models into the product.

The most costly part for these experiments would be the computation cost (the cost of having to use a lot of high-computing-power virtual machines).

In order to address this, the DE team developed a platform to support the NLP team’s research needs, which resulted in easier experiment setup while also helping us save on costs. It allowed us to achieve the same results, but way less expensively.

There are many other examples of our teams working together to improve the quality of our products too.

For example, the ASR team and DE team worked together on a keyphrase accuracy improvement project, which aims to provide more accurate transcriptions of phrases our customers submit through their company dictionary.

Let's look at this project as a case study to see how we manage to balance constraints between distributed teams.

Key learning: Collaboration is balancing constraints between teams

There were actually several key difficulties we had with the keyphrase accuracy improvement project because it involved developing new ways of improving our transcription of targeted words that are important to our customers' work.

Solving this problem would improve the accuracy—but one issue is that it would take more time to do the transcription. The key was figuring out the sweet spot where we could achieve accuracy gains—without sacrificing speed.

These areas of friction required a concerted effort and effective cross-team communication to resolve.

Areas of friction in multi-team collaboration

areas of friction in cross team collaboration
Figure 1 - Each team is focused on slightly different targets but multiple steps involve both teams to communicate and work together.

As you can see in Figure 1, there are multiple tasks that are unique to each team. For example, the ASR team mainly focuses on the implementation of improvements, while the DE team would need to make sure that the whole idea could eventually be released into the product and work quickly enough to be used in real-time.

To eliminate potential friction between these two end goals, we worked to eliminate any unfeasible options (which usually means options that could improve transcript accuracy, but aren’t realistic because they’d take up too much computing power or result in too long of an inference time) early on in development.

simplified project workflow for cross function team
Figure 2 - A simplified project workflow of this case study

Next, we made sure each team understood the needs of the others and shared necessary information in the pipeline by creating what we call a “contract.”

👉 Dialpad tip: Setting up this contract was important because it meant each team could work independently knowing the other team clearly understood the goals and limitations on each end.


Finally, we came together to do testing.

The ASR team tests if the resulting model is actually giving more accurate transcripts, while the DE team performs systematic tests on checking speed and scalability.

Everyone has an important, complementary role to play.

6 tips for cross-team project communication

1. Have a small, focused team

It was important that we had dedicated people from each team as the primary person in charge of the project. This was so that we didn’t bloat the project with too many cooks in the kitchen. In this case, four or five people was the magic number.

2. Scope feasibility as early as possible

Establish a contract at the beginning about exactly what each team needs from the others. This not only helps both teams make sure they get the necessary information to work on their tasks independently, but it also encourages thinking about long-term support.

3. Identify and mitigate risks as early as possible

Planning ahead of time and assessing risk early on has helped make our workflow smoother. The ability to relentlessly identify and mitigate risk is the key to high-performance project teams.

We used the “Risk Up Front” principle when designing and scheduling tasks, namely confronting risk head-on and providing possible alternatives before everything starts. When performing these activities with a cross-functional team, you’re more likely to catch issues long before they even arise—including those that may have been invisible to some team members!

4. Provide external visibility in the team

Given such a focused development team, the project's visibility outside these few individuals is likely to be low.

So, make sure there are backup folks on each team—for example, having multiple people across the team be familiar with the codebase and concepts.

5. Make room for non-work discussions

We have a social channel that is honestly, booming, and allows cross-functional team members to see a different side of their colleagues and have the chance to engage in fun, social interactions.

Along with that, team members are encouraged to book one-on-one time to have a mixture of work and non-work related discussions which help foster personal connections. With the move to full time WFH, the loss of quick, fun discussions while getting coffee or on your lunch break can lead to a burnt out feeling, as your entire day is a solid wall of work.

These two methods have helped us foster these lost types of interactions for the team.

6. Hold a project retrospective

We hold retrospective meetings using Easy Retro when a project is complete, which allows each team member to provide their ideas for what "Went Well," "Needs Improvement," and any resulting action items from the previous two categories.

Important note: This only works if team members already feel comfortable being open and honest in this setting and do not take it as an opportunity to place blame. Luckily, we’ve worked hard to foster that type of culture and subsequently Retros have become one of our most valuable tools as a team!

Retros help make sure that lessons learned from a project will not be lost and can be applied to new projects moving forward.

Using our tools for remote collaboration

map of cross functional team members
Figure 3 - We used UberConference for remote collaboration in different offices (Kitchener, Vancouver, Montreal, San Francisco)

Remote collaboration has now become standard in many industries, and our Voice Intelligence engineering teams are no exception.

While we were developing the keyphrase accuracy improvement project last year, we experienced switching to 100% remote work at the same time.

We were in a unique position because we already worked with people in other offices on a daily basis. Our DE and ASR teams have offices in different locations and different time zones. In order to make remote collaboration easier, we used Dialpad to host regular meetings and continuously update our weekly progress with teams.

We even regularly shared our screens for virtual pair programming as if we were all in one office using Dialpad...

screen sharing in dialpad

... And used other remote collaboration tools like shared messaging channels to keep our records!

Hope you enjoyed this case study on cross-functional collaboration!

I hope this blog post gives you a clear overview of how cross-team collaboration works across our VI teams, and that the tips we shared are useful for your next cross-team collaboration project.

Looking for a cross-functional collaboration platform that lets you have video meetings, phone calls, messaging, and more?

Try Dialpad for Free