Globalization Isn’t Dead in Software Engineering

Jamie Dimon, Larry Fink and the many others proclaiming the death of globalization haven’t been in Zus Health’s ‘virtual’ engineering room. And it’s not just us – the age of cross border engineering teams and talent has never been more vibrant. Aside from being cool and smart, engineers from outside the U.S. are often humble and lower key with zero sensationalism. At the same time, they are firm in their beliefs and savvy enough with English and U.S. culture (usually) to argue points. A winning combination.

However, there are indeed tricks of the trade (best practices some would say) in harnessing the collective power of global engineering teams. While these have evolved in the last decade or so, here are some guidelines to dig into when thinking about extending your engineering capacity. And of course, many of these apply for any sort of remote work, today’s new reality:

• The value of ongoing customer-facing interactions cannot be overstated. While cultural, linguistic and geographic obstacles (flights are expensive!) can be challenging, exposing global engineers to customers in a shadowing environment is valuable because all engineers should build direct customer understanding and empathy.
• Exploratory prototypes and new market definition are often best done in-house. Steel threads that fail are often more valuable than those that succeed – initial learnings are foundational to building what is actually useful for customers. If you do not intimately understand how you made it and why you made it, you do not get the benefits of knowing what to learn from the failure. Even with a perfect understanding of what went right and wrong, if offsite you will still miss the smell or the internet pop-up ad or whatever other accident that inevitably leads to inspiration. Total ownership by an external team can possibly play here, but generally the cultural, linguistic and geographic constraints make that more difficult.
• Objectively knowable work is fertile ground for external service partners. For example, here at Zus we are building all our products based on the Fast Healthcare Interoperability Resources (FHIR) standard, a modern standard defining how electronic health information can be exchanged. Within this framework, we find that it is difficult to meaningfully reduce the tax associated with a digital health builder working in a FHIR-native environment by mapping data fields into the FHIR standard or prospecting alternatives that preserve their ability to network-connect their data in the future. FHIR is lovely in so many ways, but it is really immature as a production framework for many use cases. However, the ability to make it invisible and effortless to builders is huge. So, the possibility of an international team standing up the ability to parse wild amounts of incoming data from across the industry and refactor it for FHIR is super valuable.
• Iteration, improvements and extensions are where the team can shine. Once you have workflows and data, if you are in a product-centric ecosystem, anyone should be able to get into the sandbox and offer alternative microservices that are faster or that do more than older ones. The future possibilities here are exciting, but obviously there must first be an ecosystem with results. External teams can build wonderful ecosystems on top of some initial proof of product-market fit, if you open up that door.

Times have changed dramatically both recently and over the last decade. There is the swagger and imagination of veterans of modern, product-centric tech business available everywhere. By adding experienced, diverse minds, companies can build a better product in ways that would otherwise be impossible. Anyone who does not consider this is not only a laggard – but they are completely missing the boat.