How Milk Bar is driving data adoption with Looker

Data-driven desserts

“Wait, why does a bakery need a data engineer?” I get that a lot. I’m a data team of one at Milk Bar, the popular dessert brand by chef Christina Tosi, of Chef’s Table and MasterChef fame. In addition to sampling literally every cake, cookie, or truffle that our R&D team sends over to our office, I’m responsible for wrangling information across our omni-channel business. Like any modern retail company, we rely on strong business intelligence and a data-driven culture to open new stores, launch new products, streamline operations, and unify our customer experience online and in store.

Looker allows my colleagues to engage with the ever-growing pool of data generated by our business. Every week at Milk Bar, our leaders discuss a scheduled performance report on the health of our company, store managers receive updates on the previous day of sales, our demand planner pulls sales volumes for forecasting, and our marketers run various analyses to guide their spend. I’m proud to say that about 75% of our 30 users are actively using Looker in a given week.

But it wasn’t always like this!

Preheating the oven

In the past, Milk Bar operated like most restaurants or food companies, which lag far behind when it comes to analytics. Our finance team was the conduit for information, and every request required pulling reports from multiple systems and stitching them together in Excel. We were in the 7th level of shared sheet hell. It was a time-consuming process and discouraged people from asking questions or hunting down data to inform their decisions.

As a one-person team, I knew that I would need to build a platform where my colleagues could answer data questions on their own. I didn’t want to tuck data away in databases that required SQL queries and become the new bottleneck for information. At the same time, I knew that even the best self-serve platform wouldn’t be enough to cultivate a data-driven mindset across the company. I was certain I would need to develop a culture of data seeking and exploring at Milk Bar.

Getting a taste for data

When it comes to rolling out new tools, engineers and developers tend to have a terrible habit. We’ll spend days or weeks building a tool or a feature and only spend a few hours on documentation, training, and communication. If we want to drive data adoption and encourage a data-driven mindset for our companies, that has to change. We have to become like Steve Jobs, convincing people why they should buy an iPad when they already own a phone and a computer. That requires real empathy for our users and some persuasive skills. If you build it, they might come, but they probably won’t unless you’ve stepped into their shoes and answered, “Why should I use this?” and “Okay, so how do I use this?”

Practical steps for driving data adoption

Here are some practical steps that I’ve taken at Milk Bar to help our company drive data adoption. None of these ideas are a silver bullet on their own, but cumulatively, they teach, nudge, and encourage our users to develop a more data-driven mindset.

Train early and often

Milk Bar is a small company, so I can afford to train every new Looker user in group sessions. I hold beginner and advanced training sessions to make sure each person with a license knows how to use the tool, including Browse and Explore. I aim to train new employees during their first week of work (even if it means sinking an hour of my day in a one-on-one session). Why? I want Looker’s data platform to be ingrained in their habits and workflows from day one.

I can’t stress this enough — if you teach someone to use a tool and they don’t get it or they later find it frustrating, they’ll look for another way to answer their questions. Before you know it, their alternate path to a solution will become a habit. Good luck getting them back to your tool!

During training, I emphasize that anyone can reach out to me for a follow-up training session, ask me to check their work, or sit down together and build a query. I want the barrier to entry to be so low that it would be strange to seek out the same information any other way.

Develop data explorers, not data consumers

We are an Explore-first company, and we encourage our users to self-serve their own requests. Dashboards are great for busy people, but dashboards primarily describe, not diagnose. Additionally, dashboard-heavy instances usually require an army of analysts making tweaks and changes for users who don’t feel empowered to take responsibility for their own questions. I want my colleagues to be active users of Looker, not passive users. Throughout our use of Looker, I’ve noticed that individuals spend a lot more time in Looker when they feel empowered to answer their own questions.

Find and support your data ambassadors

Each team has 1-2 people who have organically developed into Looker power users. These people are ambassadors for Looker across the company, and the word-of-mouth credibility they provide is powerful. Identifying these folks is critically important to continued data adoption. Here at Milk Bar, I make sure I support these people well by meeting with them quarterly to gather feature requests and concerns. By supporting them in this way, I can continue to point new Looker users in the direction of the power users on their teams so they know they have someone else to go to with questions.

Communicate updates thoroughly

I add each new user to a contact group that I frequently email with release notes: new explores, dashboards/looks, examples of cool things other Looker users are doing, etc. I send these emails monthly. These are all updates I should document anyway, so my thought is, why not email them out as an extra touchpoint for people who have forgotten about or lost interest in Looker? Who knows — maybe the new explore I released will suddenly make Looker relevant to one of my colleague’s jobs when it previously was not.

Consider a weekly performance report

Our weekly performance report goes out to most people in the corporate office every Monday afternoon. This helps reinforce Looker as the single source of truth for performance metrics, and is a natural invitation for people to go deeper in Looker when they have questions about the weekly report.

Collect feedback (and automate it!)

People won’t give much unprompted feedback unless their ability to do their job is significantly hampered. Your users simply don’t have time to explain their minor frustrations or confusion to you. Instead, they’ll probably just stop using your platform. To avoid this, you have to ask them. One way I did this was by setting up an Airflow job that uses i__looker and the Looker API to email inactive and active users different email templates asking for feedback on their experience. This is just one example of how to gather user input, and yours doesn’t have to be that technical. If you’re looking for a simple way to begin collecting feedback, start by setting a recurring calendar reminder to contact new users and ask for feedback on their experience.

Be a user

I try to spend some time in Looker exploring and answering my own questions. Sometimes, this helps me find bugs before my users do! Other times, I find interesting insights that I can pass on to my stakeholders: insights they may not have known how to pull or may not have thought to investigate. It’s a lot easier to provide good user experiences if you take some time to be a user yourself.

Start making your company more data-driven

I’m a firm believer that to have real success with any product, you have to:

• Remind people it exists and demonstrate how it makes their lives easier
• Understand the frustrations of active and inactive users and fix them
• Create a community of users who can help and support each other

I believe the same goes for driving data adoption at your company by using Looker. It’s important to be an engineer or an analyst, but don’t forget to be a product manager too. Remember that good things come when you train, demo, document, and communicate! You’ll find that the extra effort has a compounding effect on data adoption and (hopefully) the success of your business.