Anand Joshi — Building systems, teams, and technical advantage that compound.

Leading Tripadvisor's distributed data platforms now means caring for both the people and the systems behind analytics, experimentation, and products across Tripadvisor and Viator. What began as a smaller platform remit has grown into data engineering across both brands. Coaching managers, setting direction, and helping engineers grow are part of keeping that wider organization dependable.

That wider scope rests on a shared flow of activity data. Teams use it for reports, personalization, and machine learning, so reliability matters well beyond the platform team. Bringing separate feeds onto one shared platform has helped it carry more than ten times the daily data it handled in mid-2024. A simpler storage design also cuts out duplicate copying.

Experiments and newer AI-assisted booking journeys bring different demands to the platform. The experimentation integration leaves products free to change vendors, while tracking AI hotel and experience bookings helps make offers more relevant. Work with Legal and Security keeps privacy and audit needs part of the design, supported by clear decision records and reviews when incidents occur.

For engineers using these systems, the focus also turns to practical tools. Rebuilding a seat-limited internal app made it available to every employee. An AI engineering assistant grew from a small effort into a supported tool for developers across both brands, part of a wider effort to make everyday engineering work smoother.

Joined Tripadvisor to lead tracking and experimentation while several older systems still did similar work in different places. As responsibility widened to the broader data platform, a remote team took shape alongside clearer ways to own production systems, respond to problems, and grow into larger roles.

The team brought activity data into a shared stream that analytics, experiments, and other products could use. Consolidating the older systems removed duplicate work and saved more than $1 million; making the data lighter helped keep the new foundation affordable as it grew.

Once that foundation was in place, the next challenge was helping other teams use it. Self-serve onboarding and a gradual move away from older integrations turned a setup process that had taken weeks into one that could take less than a day. A new experimentation platform also made it easier for product and data teams to prepare tests and check the results.

At Tehama, leading a small team still meant staying close to the code. The team was building a cloud service that gave customers secure virtual desktops, and the role joined hands-on architecture with hiring, coaching, and the daily decisions needed to bring a young product into production.

One weak point was a fragile process that was hard to operate when something failed. Reworking it into stages made problems easier to diagnose when something went wrong and shortened the time needed to resolve incidents. That gave a lean team more room to improve the service while keeping reliability and security in view.

Moving to Samsung Ads meant working on systems with an immediate effect on what Samsung Smart TV viewers saw. Viewing information helped select relevant ads, so the way that information was processed had to connect closely with the service making the final decision. The role brought wider responsibility for that technical direction.

Rebuilding the real-time ad server and the flow of viewing data gave the product a faster, more dependable foundation. The work also crossed offices in Mountain View and Montreal, where guiding backend design and mentoring newer engineers helped the team make consistent choices about shared systems.

Moving from Finance APIs into a senior role on the Yahoo! Platform team widened the work from one product to systems shared by Yahoo! Finance, Yahoo! News, and Yahoo! Weather. Those systems handled millions of feeds and events each day. Alongside building them, the role grew to include guiding architecture and helping other teams make decisions about infrastructure they all depended on.

The Commenting Platform showed what that wider responsibility looked like in practice. Its redesign assessed comment quality and activity as conversations happened, while giving product teams a clearer view of how people used one of the company's busiest features.

Yahoo! Weather brought a different problem: updates needed to arrive and move through the backend without holding up the rest of the service. The redesign reused existing infrastructure instead of buying more hardware, avoided extra cost, and won the Yahoo! CFO Infrastructure Cost Challenge. Together, these projects made the work as much about shared technical direction as individual services.

The early full-time years at Yahoo! Finance centered on a new API platform: the behind-the-scenes service supplying financial information to Yahoo! Finance and outside partners. Building it meant making fast, reliable access to that information possible even as more products began to depend on it.

As the platform grew, so did the responsibility for its direction. The role developed into a technical lead for Finance APIs, beyond the original work of building individual services. The platform later served partners including Apple across iOS, iPad, and Apple Watch, as well as Samsung, HTC, and LinkedIn.

That wider reach made trust in the service especially important. A common way to secure Finance API access became a standard across the platform, while code reviews, automated tests, and performance checks helped the team keep it dependable as integrations grew.

The first Yahoo! Finance chapter began with an application that let people share how their investment portfolios were doing across social networks. Making that social feature useful also meant keeping up with financial information that changed throughout the day.

A way to compare a portfolio's value fairly as holdings were added or removed and share prices changed grew out of that problem. The work formed the basis of the Portfolio Boost Evaluation patent application, an early step from building a feature toward solving the systems problem beneath it.