Back to resources

Providing a Great User Experience When Expanding Internationally

Managing Expectations
Impact
Users

25 May, 2021

Harrison Hunter
Harrison Hunter

CTO at MaestroQA

Harrison Hunter, CTO at MaestroQA, shares how to provide a great user experience for users distributed worldwide by choosing a hybrid model that beats technical difficulties.

Problem

For most companies, the first couple of customers are their home market ones -- and ours were as well -- but we quickly acquired some other large customers in other geographies, most notably Asia-Pacific, Australia, and Europe. As a result, we started to expand our business internationally sooner than expected for a company at our stage of growth. It included not only launching the product but also providing support.

While we largely managed to deliver on expectations, there was some frustration around the increased latency of connecting to servers based in the US, entirely over the public internet. Those latency concerns would make a poor user experience. In many places of Southeast Asia, it could be up to hundreds of milliseconds slower, especially with round trips and handshakes. If activities that should be performed in fast workflows and feel quite instant are slowed down, it will start to impact the value of software. To no surprise, a customer will feel that our software is holding them back rather than accelerating them. The whole thing only adds up in time and in one’s perception that the tool is not able to follow the speed of their thoughts.

Actions taken

We considered multiple options. They ranged from optimizing the code to make the code itself faster, to running different versions of our entire infrastructure in different regions having one or a few hubs per continent. We also considered having some type of a hybrid system, where some parts of the systems would be located in some geographical areas while others parts would be located elsewhere. We already had a CDN (Content Delivery Network) -- which most companies with a reasonable scale do -- but there were many steps between running your infrastructure everywhere and running it in one place using CDN.

That was a direction we were set to explore and with which we got a lot of mileage. We had since been able to build up the ability to launch in specific regions, which enabled even more flexibility, particularly in regard to data residency laws. However, that didn’t come as the first obvious choice. It wouldn’t be the most feasible option in the earliest days because we were a small team with an ambitious timeframe. Running multiple data cloud centers in different places would be too much of an overhead to start with. Instead, we decided to find an intermediate option by doing some code optimization but also figuring out how to distribute better and provide a decent experience around the world.

In order to accomplish that, we looked at a couple of different tools that would benchmark our impact. We were considering moving web servers but keeping the databases in the same place. We were also looking at local points of presence from a network perspective. Ultimately, we found that it was a sufficient solution to get us started and provide a good experience for our customers.

The first step we took that got us quite far -- before going to fully distributed infrastructure -- was putting in place tools that allowed for local points of presence and networking. It could be anything from Cloudflare to AWS and its global accelerator. We looked at both solutions, and both provided significant performance improvements. Those tools would enable people to connect locally and then go to our backend over private Internet infrastructure. We could keep our backend servers in any region and a customer could connect to a server in their home country over an optimized network instead of a public Internet that could be inconsistent and slow. Though we haven’t moved all of our infrastructure into a customer’s home country, the latency would be greatly improved, especially for long-running connections, anything on Publish/Subscribe, or web socket type of architecture.

Lessons learned

  • We were hesitant at first because we were convinced that the only option was to move our infrastructure all over the world. We were skeptical if that was manageable and were close to saying No to some of the customers. We pushed ourselves to think creatively and come up with a hybrid solution that would provide sufficient user experience and buy us time to develop a long-term, more sustainable solution.

  • When presented with problems like the one we encountered, try to understand the business impact of saying Yes. Once you establish what is the value of being able to get to Yes, start to work backward. That will force you to think creatively and solve the problem.

  • When looking for a clue, look at what the best and biggest companies are doing and compare that with where you are at that moment. We knew that the best players in the industry were running local infrastructure, but we had to adjust that solution to our situation. This is why we came up with a hybrid solution. Knowing the gold standard is always good, but you need to be cognizant of your constraints and find a middle ground where you will feel confident with limited resources.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How I failed at my startup

14 October

There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Mission / Vision / Charter
Scaling Team
Building A Team
Impact
Strategy
Prioritization
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

High Performance Team in Action

13 October

A high performance team refers to “ a group of goal-focused individuals with specialized expertise and complementary skills who collaborate, innovate and produce consistently superior results.”

Managing Expectations
Building A Team
Company Culture
Feedback
Coaching / Training / Mentorship
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign