Looker JOIN 2019 - Namely's Alexander Jia shares the new rules of modern BI projects

The most challenging conference to cover? No, it's not the one with no news stories. It's the one with a big news story you can't really address.

That was the conundrum at Looker JOIN 2019. With Google's agreement to buy Looker for $2.6 billion (June 2019) looming over the show, Looker executives were unable to say much on the record. That's a story that will (mostly) have to wait.

Yes, I got a few nuggets I'll share at the end of this post - most of it centering around the potent question of infusing Google's AI assets into Looker's BI/data platform. But the bigger reveal on what this all means, and what the roadmaps will look like, is for next year.

Aside from the Google/Looker storyline, the biggest news of the show was the formal announcement of the January 2020 Looker 7 release. There is some interesting stuff there, including new SDKs, a developer portal, expanded multi-cloud capabilities (perhaps surprising given the Google acquisition), and a slew of third party integrations and APIs (Slack, Dropbox, Box, etc).

But if you're not familiar with Looker, it's easy to get confused. Yes, a cloud-based, flexible and open BI solution sounds forward-thinking, but it raises questions: Is Looker a data platform? Is it a dashboarding solution? Is it a self-service BI tool? Does it enable embedded analytics? Can you put Looker's analytics in your own software offerings for clients? Is it an ecosystem of data apps? The answer: all of the above, potentially. The best concise explanation of Looker comes from their Wikipedia page:

Looker makes use of a simple modeling language called LookML that lets data teams define the relationships in their database so business users can explore, save, and download data without needing to know SQL.

Namely's Alexander Jia - data is a people problem

That's a start. But how does that play out in the real world? Namely's Alexander Jia spoke to that in our interview, prior to his Looker presentation. Jia bills himself on his LinkedIn profile as a "data and analytics leader." Little did he know that qualified him for a good-natured grilling from me, as I assessed his credentials for myself. When I asked Jia how he got his start with analytics (as an intern at Label Insight), he certainly gave a Looker-like answer:

I think data, at least the way that I approached it, is very much the intersection of not just business and tech, but how do you speak everyone's language? How can you be the person that brings it all together, both from a data perspective and a people and a process perspective?

As the Head of Business Intelligence at Namely, Jia gets to put his BI leadership to the test. Namely wasn't Jia's first exposure to Looker, but at Namely, a US-based human resources software company, they were using Looker differently:

Most companies, both of my previous jobs included, use Looker first as a BI platform. Then they evaluate the opportunity for an embedded solution. Namely actually started the opposite way. They knew they wanted analytics; they knew that data was going to be a core to the success of their product, and they didn't want to reinvent the wheel.

So they brought in Looker first as an embedded solution, and then we thought about, "How can we get even more value out of this, and how can we make sure that we have a data culture both inside and out?"

But Jia wasn't brought into Namely to promote BI software. He was brought in to build and lead an internal BI/data team. So where did he start? 

I think first step is vision and strategy. What does BI really mean? I think you have to do that at all levels, but especially at leadership, and ask: what are we trying to accomplish here?

 Yep, I took that data cheese. How do you do that? Jia sees five BI goals:

• fast, data-driven decisions
• self-service analytics
• single source of truth
• powering of data culture
• proactive discovery of new opportunities

Pretty good list, but why not try to stump Jia? Didn't he leave out "intelligent decision support?" In other words, prompting users with prescriptive possibilities from the data to help them do their jobs?

Jia says that already fits into the five (perhaps the first bullet?). Admittedly, it's an advanced capability. As he told me:

It really depends, to some degree, on what you believe the responsibility of the BI team is. Today, that's a very nebulous question. I think everyone's job descriptions look the same, but what we actually do is very different.

And yes, Jia has that prescriptive part in his approach:

You're right, data generally goes from descriptive to predictive to prescriptive.

How do we turn data into a verb?

But Jia isn't amongst those who are looking AI to solve data through prescriptive tech alone:

At the end of the day, in many ways, data is a people problem. How can we make sure that we remove the contextual and technical barriers to people making the right decisions, and guide them down a path of curated data discovery?

Good question. And what is Jia doing about that?

I see my job as two pieces. One: how can I just make the data available? But two: how could I make asking the next question a joy instead of a chore? It's got to be easy. It's got to just feel great, clicking and drilling down and exploring from here.

To borrow the words of my good friend KK, who I met yesterday, who is chief data officer at Farfetch, how do we change data from a noun to a verb?

Once your BI vision and priorities are clear, you can kick tires on software:

Once you handle the vision and strategy, you make sure everyone's on the same page about it. Then you do have to think about, what is your toolkit? To some degree, whether or not Looker's the right solution for you depends on what you want to achieve with it. Who's going to use your data platform?

If the answer to that question is, "I want everyone to use data because I want to be a truly data-driven company," then you need a way to truly democratize without losing a single source of truth. I think that's what Looker does, and that's why I'm a fan.

On functional data champions and the pursuit of BI maturity

And of those five BI project goals, does Looker help Jia's team check all those boxes? "Absolutely," says Jia. But Looker isn't the entire data architecture. Jia's scope at Namely includes their entire data pipeline, their infrastructure, and, of course, their people.

I put a lot of thought into: how do we build the right relationships of trust? As a data team, how can we understand both the strategic level of the 30,000 foot view, so we know how every piece of data rolls up to a company-wide metric like AR and NPS, but also from a tactical level, from a boots on the ground, how can we avoid getting ivory-towered, and make sure that every given person in the company has the right sort of experience when they open up a Looker dashboard?

How can we avoid getting ivory-towered? That's a good one. If your goal is to democratize data, you better figure that one out. And how does Jia do it? One key is to empower business team leads:

We work a lot with what we call our functional data champions. You can think of them as part representatives for the needs and the use cases for Looker within a team, and part internal evangelists. They help us spread the good word of data within each of their organizations.

One thing is certain: Jia's approach works at scale. His "BI team" is just him and one associate. Together, they support 500+ Namely users. So how does Jia assess his progress? Via his BI maturity model, and a roadmap, which looks at data as both a product and a service. Yep, he got me again. What about that maturity model?

Think like the Gartner maturity model, but really cool and on a PowerPoint slide.

And the maturity stages?

1. It's all in Excel.
2. Each team has their own siloed approaches to using data, but it's labor-intensive, it's duplicative, and you don't have a single source of truth.
3. Single source of truth. "That's when you're actually bringing in Looker and centralizing a lot of those responsibilities and functions."
4. How can I create an enterprise-grade KPI framework? How can I tie performance management to data? "Because until it's tied to performance management, no one's going to really care about this."
5. You're moving past descriptive, into predictive and prescriptive.

And where is Namely now? Jia puts them solidly into step four. So if tying data to performance management is so crucial, have they made progress? "Absolutely," he tells me. Such as?

Our client success team has a base and a variable compensation, and the variable compensation is based on retention. All the retention metrics come out of Looker. They are empowered on a variety of different levels, both strategically: over the last two months, how have I done on retention? But also very tactically, as in: let me dig into where I personally as a CSM can improve, and all the way up to the director of client success, who can see the exact same picture that everyone else does. I think having that sort of alignment is super powerful, because everyone is looking at the same thing.

Everyone is actually empowered to ask the next question.

The wrap - speculating on Google, Looker and acquisition culture

I agree with Jia that tying data into performance is important, but it's also a bog pit. If you're not careful, those performance metrics end up being punitive, a form of surveillance culture - another case of measuring the wrong things. Jia responds:

It's a people problem. How can we say it in the right language and have really the right underlying principles of transparency and empowerment to make it not this oppressive thing? It's got to feel like you don't have to do all of this reporting stuff anymore, and with that time saved, you get to do cooler things. That's got to be how you frame it for every single person.

And yes, we talked about that prescriptive analytics phase. That's a conversation I hope to continue - and share - after the Google's purchase of Looker is finalized, and the AI-Looker roadmap gets clearer. Namely also embeds Looker as its analytics offering to its own customers, but that's another article.

Talking to Looker customers at JOIN 2019, I picked up on a collective sense of optimism about what Google can do for them. In short, the pieces seem to fit, and the resources Google can apply here are promising to them. But there is also concern, for understandable reasons. Massive entities like Google have to prove they will be good stewards of their acquired assets (and the customers involved). Only time will judge whether Google handles that properly - including the continuation of the true multi-cloud flexibility Looker is pushing in Looker 7. 

Then there is the culture bit - Looker has a distinct culture, proven out by job titles such as a childhood friend of mine who is the VP, Department of Customer Love. The cultural compatibility between Looker and Google seems good on the surface (data geeks unite), but that inspired customer relationship you would call "love" is not something Google has ever excelled at. I get the sense Google is eager to learn from Looker along those lines, and how that can be applied to their enterprise services, but time will again be the judge.

One thing I was particularly struck by at this show is how "cloudy' the data conversations were. That happens at most every BI show these days, but I've never heard as many customer mentions of Snowflake (cloud-based data warehousing).

Looker's founders placed a couple of bets in 2012 that are panning out: they bet on the cloud, and also on SQL. When you consider all the bustle in the NoSQL market, SQL wasn't a no-brainer for an analytics startup. Of course, Looker has been doing a lot to hide NoSQL from business users, so that one SQL-savvy admin like Jia can support a large, SQL-indifferent business team. In Namely's case, that seems to have panned out. Future Looker JOIN customer stories will round out the picture.