Datacast

Episode 50: Reducing Data Downtime with Barr Moses

Episode Summary

Barr Moses is the CEO & co-founder of Monte Carlo, a data reliability company committed to accelerating the world’s data adoption by reducing Data Downtime. Monte Carlo is backed by Accel, GGV, and other top Silicon Valley investors, including the former Chief Data Scientist of the U.S., DJ Patil. Previously, Barr was VP Customer Operations at customer success company Gainsight, where she helped scale the company 10x in revenue and, among other functions, built the data/analytics team. Prior to that, Barr was a management consultant at Bain & Company and a research assistant at the Statistics Department at Stanford. She also served in the Israeli Air Force as a commander of an intelligence data analyst unit and graduated from Stanford University with a B.Sc. in Mathematical and Computational Science.

Episode Notes

Show Notes

• (2:23) Barr discussed growing up in Israel and serving as a commander of the Data Analytics unit at the Israeli Air Force.
• (4:10) Barr reflected on her college experience at Stanford studying Math and Computational Science.
• (7:24) Barr walked over the two career lessons learned from being a Management Consultant at Bain and Company.
• (9:51) Barr reflected on her time as VP of Customer Operations at Gainsight, which offers enterprise solutions for Customer Success and Product teams. She helped build and scale a global team covering various functions such as business operations, customer success, professional services.
• (12:32) Barr unpacked the notion of data downtime, introduced in her blog post “The Rise of Data Downtime.”
• (17:25) Barr unveiled the four main steps in the data reliability maturity curve: reactive, proactive, automated, and scalable - as indicated in “Closing The Data Downtime Gap."
• (21:09) Barr shared the founding story behind Monte Carlo, whose mission is to accelerate the world’s adoption of data by reducing data downtime.
• (24:29) Barr explained the five pillars of data observability.
• (27:45) Barr unpacked the rise of data catalogs as a powerful tool for data governance, along with the three categories of data catalog solutions that data teams are adopting - as presented in “What We Got Wrong About Data Governance.”
• (31:32) Barr discussed the benefits of using Data Mesh - a type of data platform architecture that embraces data ubiquity in the enterprise by leveraging a domain-oriented, self-serve design.
• (37:28) Barr went over a framework that looks at the business functions and the nature of the work to score the impact and allocate the ROI of the data team - as proposed in "Measuring the ROI of Your Data Organization."
• (40:39) Barr shared five practices for designing a platform that maximizes data's value and impact inside an organization.
• (43:27) Barr reflected on the key decisions to get the first cohort of customers for Monte Carlo.
• (46:31) Barr shared valuable hiring lessons.
• (48:48) Barr went over helpful resources throughout her journey as a founder.
• (50:13) Barr dropped the final advice for founders on seeking the right investors.
• (51:18) Closing segment.

Her Contact Info

• Twitter
• LinkedIn
• Medium
• Monte Carlo

Her Recommended Resources

• Stanford's "Mathematics and Magic Tricks" course (taught by Persi Diaconis)
• "The Biggest Bluff" by Maria Konnikova
• Snowflake
• DJ Patil (Former U.S. Chief Data Scientist)
• Monte Carlo's Customers

Episode Transcription

Key Highlights

On Growing Up in Israel

• I grew up on a university campus in Israel. My dad is a physics professor, and my mom is a meditation and dance teacher. I used to go to my dad’s lab to create things and blow things up, so experimentation was something that I enjoyed as a kid.
• At age 16, I joined the Israeli Red Cross in high school, serving as an emergency medical technician (EMT). That meaningful experience shaped my life, as I literally was saving lives. After high school, I joined the Israeli Air Force as a unit commander — learning about grit, camaraderie, diligence, data downtime, and many other great things.
• Then, I traveled to South America for about 10 months, one of the best periods in my life. Shortly after that, I went to Stanford to study math and statistics.

On Studying At Stanford

• Stanford was like Disneyland, but for my brain. I entered a world where there were different stations, rollercoasters, and stimulations that engaged me.
• I took many theoretical math courses, but my favorite one is called “Math Magic” with my favorite professor Persi Diaconis. We had to come up with our own magic tricks and showcased them to other classmates.
• I also worked in the Statistics department on Monte Carlo simulations — a way to approximate value that has wide-ranging applications.

On Lessons Learned As a Management Consultant

• I loved the people at Bain’s and had a lot of fun working with them. That set the tone for the rest of my career: work with people you love.
• I loved the variety of being a management consultant. One day I worked with a semi-conductor company, the next month would be a retail company, and after a quarter would be a hedge fund, for example. The common thread for all these clients was that they all need data to improve their operations and strategy. I spent a lot of time in R and really enjoyed working with data.

On Scaling Gainsight's Customer Operations

• At Gainsight, I met a group of folks whom I was extremely excited to work with and thought highly of. Furthermore, Gainsight created a new category (customer success) and brought a lot of quantitative elements to it.
• As the VP of Operations, I led several different teams. One was called Gainsight-on-Gainsight (GonG), where we ran an internal incubator to test out many data ideas for our customers.
• As a global team, we faced many of the scaling challenges that the working world faces today due to the pandemic. We had Zoom meetings and bring-your-own-drink virtual happy hours back then already. I definitely learned how hard it was to scale a company, so it’s important to do it with people whom you appreciate and work on a problem that you care about.

On Data Downtime

• The reality for any data professionals is that they are often the last people to know about it when data breaks. This was quite a frustrating experience for me at Gainsight.
• In my experience working with companies in the last decade, many companies suddenly decided to become data-driven and hire lots of data scientists/data engineers. But on the other hand, they got stuck on the fundamentals like what data to use, where the data lies, or are the data trustworthy. And when they actually started to use the data, they saw broken data pipelines and wonky dashboards, which have a tremendous impact.
• Data downtime (which refers to moments when data is missing, inaccurate, or otherwise erroneous) affects all data-driven companies today, regardless of their industries. The name is a corollary to application downtime. We have a great data infrastructure that takes lots of raw data. But when do we learn that there’s a problem? When someone at the end tells us that there’s something wrong in his/her report.
• Testing and monitoring, which are standardized in software engineering, are still in infancy for data products.

On Founding Monte Carlo

• At Gainsight, I experienced the problem of data downtime first hand. I actually hacked together a bare-bone way to manage this. When I left Gainsight, I talked to hundreds of data leaders to understand their top of mind. Data downtime came up again and again, ranging from small startups to large organizations.
• I realized that software engineering has a way to manage this problem with solutions such as New Relic, Datadog, AppDynamics, etc., that help you understand the health of specific systems. For some reason, this was not the case for data.
• Inspired by the desire to make the lives of data teams easier and bring in concepts from software engineering that has been tested/tried/proven, my co-founder and I worked with design partners to help them solve this problem — bringing reliability, trust, and accuracy to their data. We were delighted with our early traction/results, so we decided to go all-in and started Monte Carlo.

On Data Observability

• Similar to software applications, data can break for many different reasons. There should be a coherent set of metrics that we agree on to look at, monitor, instrument, measure, and analyze in order to understand the health of the data. Thus, we came up with the five pillars of data observability.
  • Freshness is a set of metrics around how up-to-date your data is, when it was last refreshed, how often it gets refreshed, and whether it is refreshed at a cadence you expected.
  • Distribution is a set of metrics at the field level, including the distributions, uniqueness, missing values, null values, and range.
  • Volume refers to your data tables' completeness, such as row counts, byte count, table size, etc.
  • Schema is about understanding who makes changes to the data and when.
  • Lineage helps with understanding the upstream root causes and downstream impacts.

On Data Catalogs

• Data governance helps you answer some fundamental questions: Where can I find this data? What does this data mean? Where does this data come from? Can I trust this data? Where is the most important data for us? To answer them, you need to have data catalogs to keep an inventory of metadata.
• We have seen three main things that companies do to implement data catalog:
  • They can build in-house (like Airbnb). Obviously, this takes certain investment, requirements, and specialization.
  • They partner with third-party vendors (like Informatica).
  • They can tap into open-source solutions such as Apache Atlas and Lyft’s Amundsen.
• The most important part of your data catalog is to have data observability.
• The “build-versus-buy” question is very much in the DNA of the company. It comes out to consideration of what’s important for the company. If the data catalog is critical to your ability to generate revenue and strategic to your business, then perhaps it’s a good decision to build in-house. Obviously, you can customize it to your needs and control the time/spec, but it is a very significant investment.

On Data Mesh

• The term “data mesh” was first coined by Zhamak Dehghani at ThoughtWorks. This idea borrows from software engineering’s distributed micro-services architecture and applies that to data.
• In a monolithic scenario, you have data consumption, storage, and transformations all in a central data lake. In a data mesh, you have a domain-oriented architecture model, where every domain handles its own pipeline.
• The transition is not easy, but here are the key pillars that Zhamak outlines for a data mesh:
  • Domain-oriented data owners: different teams own their data as a product. They are responsible for leveraging components, specific needs, and autonomy to run their own data transformation processes.
  • Self-serve functionality: moving away from a centralized model to new tooling that enables data owners to manage and own their data.
  • Interoperability and standardization of communications: we need to standardize data formatting, discoverability, metadata, definitions, etc.
  • Data observability: having data product versioning/schema/lineage/monitoring/logging, etc.
• Improving data literacy across the organization is important to make this model successful.

On Measuring Data ROI

• Barkha and I created the framework to help data teams put a quantitative value around their impact. It’s a simple 2x2 framework that allows you to identify the tangible value of your contributions:
  • On the one hand, you look at the organization's specific functions: customer success, sales, marketing, engineering, product, etc.
  • On the other hand, you examine how data contributes to those functions. This can be increasing the ROI of their operational initiatives or helping them to drive new strategic initiatives.
• In this framework, we proposed a way to take all the initiatives you have and plot them in this matrix, then use them to calculate how your data org is actually helping each of these functions.

On Building A Data Platform

• Why do you want to build a data platform? It can help you drive the product roadmap, guide sales effort, improve customer experience, and de-risk the business model.
• How can you implement a data platform?
  • Align your product’s goals with the goals of the business. If you are building a data platform for its sake, but it’s unclear how the platform ties to the company’s business, that’s a problem.
  • Gain feedback and buy-in from the right stakeholders. Taking on the customer success mindset is crucial.
  • Prioritize the sustainability of the solution. Obviously, it would help if you had quick wins to show value to your users, but building with long-term growth in mind creates a more solid foundation.
  • Know when to build versus buy. Perhaps, you want to build parts of it and then augment it with vendor solutions. Or perhaps you want to build the whole platform internally. It depends on the priority of your company.

On Getting Initial Customers

• In the early days, focus really matters. We couldn’t do everything, so we needed to figure out what to work on and how quickly to accomplish it. There are two things that we focused on:
  • One is to break the problem into very specific pain points that resonate with the different personas.
  • The second is to push our product into release very quickly. We built our product with our early customers — getting something into their hands as fast as humanly possible and iterating with them to solve their specific pain points.
• The early adopters were passionate about solving the same problem and being part of our movements.

On Hiring

• Hiring in early-stage startups requires a strong alignment between expectation and excitement. When hiring new employees, we think critically about who gets excited about our challenges and wants to create magic.
• A way for us to attract those people is to define our values very early on with only 4 people. Those values define the kind of culture we want to build and what matters to us.
• One particular value is “measure in minutes.” If you only have 30 minutes to get this thing done (ship this feature, close this deal, create this spec, etc.), what would you do?

On The Founder's Journey

• In startups, if you’re lucky, it will be a five-to-ten-year journey. The employees, the customers, and the investors must be the people whom you can trust.
• Specifically, in the early days, I found it important to have people who believed in us. Some of Monte Carlo’s investors believed in me way more than I believed in myself.