25 Years of Global Operations

My experience with remote and global operations began at my first office job in the mid-90s. I worked at book publisher that leveraged freelancers to complete specific steps of the book production process (writers, editors, indexers, designs) depending on the companies production pipeline. These resources were spread throughout the country (US) and the company’s use of them was steady but sporadic for a given individual – we had a “rolodex” of names we could call when needed etc. Little effort was put in to integrate any one contractor into the company operations since it might be months before they were needed again. Communication was limited to phone and some email – not all of them had email.

This was my first “office” job so I assumed this was the way all companies operated – leveraging outside resources vs hiring full-time onsite etc. I didn’t realize that it was the beginning of a shift in how work would get done but I learned quickly.

In 1999, I co-founded a company (eWork) on the belief that the Internet could enable work to be performed from any location by anyone. It was an impactful idea but the tech infrastructure and economy wasn’t mature enough for us to realize our vision. I like to think we were right but just too early which, unfortunately, is the same as being wrong. We eventually had to pivot – a story for another day.

But before we did, we partnered with an India-based tech team to develop collaboration software to allow remote teams to work and share in a “digital space.” We had just received funding so we knew we needed to move fast. We didn’t have expertise in-house, we didn’t want to wait until we were staffed up and if we wanted to be about global remote work we needed to walk the walk etc. It was ambitious but ultimately very challenging – did I mention that the infrastructure was primitive?

Communication was rough – no effective screen sharing or video solutions, trans-Pacific calls to India were marked with high latency that made them almost useless. None of the tools we use to track and manage development today existed (Jira, Github etc) so we had zero visibility into progress outside of primitive trackers that were emailed back and forth. In the end, the lack of software and communication materially impacted our effectiveness and reduced the upside of the project. Despite the challenges, we could see the potential for the model if we were able to solve the operational pain.

Fast-forwarding a few years later to the mid-aughts while working at IAC, we leveraged an off-shore development team to build a feature-light FB app with some success. Communication was easier (VoIP, instant messaging) and the reduced complexity coupled with better specs allowed the off-shore team to work more autonomously. They were able to iterate faster without having to waste cycles waiting for responses.

Both of these projects (eWork and IAC) were tangential to the “core” business and were treated as such internally. They were siloed off and these teams were never integrated into the company. This approach is fine when executing one-off projects but it won’t generate long-term operational leverage. For that to happen, a broader knowledge transfer has to occur (and be maintained) so off-shore resources can understand strategic goals and the internal teams can understand the skills and talents of the remote teams. When I joined US Auto in 2009, I experienced the operational leverage that can be obtained with a deeper on-shore/off-shore collaboration.

At the time I joined, US Auto had close to 1000 employees in Manilla (Philippines) vs less than 200 in the US. All operational areas were represented – tech/platform, marketing, data/analytics, purchasing, finance, call center etc. In general, entry and mid-level contributors were staffed in the Philippines with the Director up to C-Suite all working out of the US. There were some exceptions to this model and there was some senior leadership in Manilla that shadowed their US counterparts. Given the size of the teams “on the ground” leadership was important – this was also pre-pandemic so everyone worked from the office.

US Auto sold commodity auto parts so the cost reduction from leveraging an off-shore workforce was an important strategic component. The cost-savings and overall value generated by the Manilla operation helped the company compete in a cutthroat, low-margin industry. Looking back, we were not as successful at creating a culture that afforded the off-shore teams more autonomy – a next level goal of building a global operation. Collectively, we didn’t move beyond the traditional ‘command and control structure, and this frustrated the offshore employees and, at times, impacted their morale and motivation.

Later, while working at Onestop Commerce, I tested a new software development model by hiring a near-shore development team out of Tijuana to supplement our in-house team. Onestop was Los Angeles based so the teams could easily collaborate in-person (three-hour drive) and they were in the same time zone – the cost delta between Asia and Mexico reflects some of this convenience. We were also able to organize our workflow to hand off distinct and discrete projects with tightly-defined deliverables. This allowed them to work independently with less oversight. The combination of talent level, ability to communicate and defined deliverables led to successful outcomes.

By the time I reached Jukin in 2018, I had gained extensive experience in establishing international teams across various functions and locations all of which went into building a best-in-class off-shore operational team. We (it took many hands) leveraged technology and modern digital operations to scale a 150+ person team in India from the ground up. As we built the team, we adapted our strategy as needed but over time some best practices emerged. I view these as important pieces of a successful remote strategy though, to be clear, each situation has its unique needs. There are always specific contexts that need to be addressed for any given company or project.