Analytics in the enterprise: How The Department of No can say yes - Mixpanel
Product Analytics

Analytics in the enterprise: How The Department of No can say yes

Parker Tarun

Raise your hand if you think what you’re doing in data is actually aligned with the needs of the business.

On a good day, a third of the hands in the audience shoot up. By most measures, 33% is pretty strong. The catch here is that the “audience” consists entirely of analytics and data management professionals.

“And that’s a really good day,” Edd Wilder-James clarified. As VP of Technology Strategy at Silicon Valley Data Science, it would be fair for Edd to find this number dispiriting. He doesn’t.

Instead, he’s optimistic and working to improve it. When he goes around and speaks at conferences, it’s this tension between business and data that his peers are interested in.

“Sure, folks are curious about the tools and the architectures and so on,” he said. “But invariably, the conversations always come round to this culture thing: How can I persuade my bosses that investment in providing data services is actually worth it?”

The existential dissatisfaction in analytics departments is felt far and wide. It has very little to do with what’s technically possible, and more to do with how convention restricts data teams.

“Somewhere along the line, analytics became the Department of No, because they became very focused on the cost center,” Edd said. “When you’re in that place, and you’re not connected to this bigger picture of What am I doing that ends up creating value?’ then you lose sight.”

Edd is determined to give sight back to data professionals and, in the process, also transplant a new vision to the entire enterprise.

Keeping the lights on

Edd believes analytics evolved into the Department of No passively, much in the same way IT departments have. CIOs got distracted and they became more skittish around the bold vision they promised to bring to the enterprise.

“In IT departments throughout the enterprise, for example, there are two brands of CIO,” he said. “One is a heritage brand that is focused on keeping the lights on. People say, ‘I don’t really know how everything I’m doing is related,’ because they’re deep in a service organization whose KPIs are things like, ‘Are we delivering the support on time?'”

This KPI is, of course, vital. What’s missing is something grander in scope.

The other kind of CIO, Edd said, “is a modern brand that wants to be aligned with the business.”

In the abstract, most of us would choose the modern brand over the heritage, but that’s in the abstract. There are real fears and inefficiencies keeping the status quo in place.

This same tension has emerged in data and analytics teams, being as they’re either embedded in or adjacent to information technology. Many would say this tension can be characterized as companies that have a data strategy or not, but Edd thinks it’s more complicated.

“Heritage” companies might often have a data strategy, or at least something resembling one. It’s just built wrong. According to Edd, the difference between a “heritage” and modern in analytics hinges on a preposition.

“Data strategy needs to move from this notion of what you can do to data, to what you can do with data,” he said. “You can’t just be using applications for reporting. You have to answer questions like, ‘who are my most valuable customers? What can I do to increase the return rate? What can I automate and how can I improve time to market?

This is an important distinction, lest “keeping the lights on” be considered a sound data strategy. Keeping the lights on is important. But there’s so much more— so much that you might be daunted.

Luckily, Silicon Valley Data Science has a model to jumpstart a data strategy.

Defining the strategy

A data strategy can be a threatening thing. For an organization already tasked with keeping the proverbial lights on, it requires extra dedication. It requires identifying where data and business needs can meet.

That might feel like a large undertaking, and Edd doesn’t want building a data strategy to be a beast of burden. He wants it to feel fundamental.

As a credit to that, Edd’s set up a simple, little Socratic dialogue for analytics leaders and their operations counterparts. The people responsible for the data strategy (in different companies, it’ll be different leaders) should get together and think on three questions…

  1. What is the most important problem to your business?
  2. What data assets do you have that can help with this?
  3. Which data solutions are actually possible to create?

Devised by Silicon Valley Data Science’s CTO, John Akred, this is what it takes. Filtered down through these three questions, you will be able to begin pegging data-strategic projects against their larger business plan.

“Data strategy is all about aligning those three things and coming out with this idea of what comes next,” Edd said. “Not only will we solve these problems, but along the way, we’re going to build a capability in being data driven that we didn’t have before as a side effect.”

Of course, this model is only possible if all involved are committed to creating a more data-driven organization. For some, a top-down data strategy might seem like a tall order. In those cases, there are ways to slowly influence data-drivenness.

If Edd’s conference chatter is any indication, this is what data folks struggle with the most.

Empowering the organization

Data-drivenness is really a get what you give situation. While professionals outside of analytics might be most resistant to data-driven change, those within it also have adjustments to make.

“There’s a mindset change for the custodians of data,” Edd said. “You have to throw open the doors, in a sense. You have to have to give the organization Lego blocks of data that can help them.”

By which Edd means your center of excellence needs to be an embassy, and not an island. It has to provide a means for outsiders to travel in your metrics-based world. Maybe that’s tools, maybe that’s seminars, maybe that’s a hotline. How you scale it will depend on your organization.

If product groups and finance groups have to fight tooth and nail to get the insight you can reap easily, though, something’s broken. So while it’s probably still the case data is centralized on your team, you need to build a more efficient workflow that allows every other team to get access.

“Whatever you do and however you manage data, it has to be done in a way that helps people see the greater good,” Edd said. “Because a lot of them are threatened. Data is not in itself a neutral entity. Data carries with it a history.”

This is why with is a better preposition than to. Presenting the data in a way that encourages and invites usage is as important as having good data in the first place.

Good luck

From there, it’s a horse-to-water situation. You can push for all of this in your company and still fail.

At conferences, Edd sometimes finds himself in the unfortunate position of having to suggest career moves for analytics folks.

“People say, ‘We do all of this and people still make decisions for political and gut reactions. The person with the loudest voice, the highest paid person in the room makes a decision.’”

Edd’s a problem solver, but even he occasionally has to shrug: “Frankly, I sometimes say, ‘Maybe you should look for another job.’

Is a culture of data that helpless at your company? The vast majority aren’t. For analytics people, the trick is deducing whether politics are the natural state of your organization or a temporary gap between the central business problems and data itself.

If it’s the latter, even the most data-averse companies can make the journey. Using Edd’s Socratic dialogue, analytics professionals can lay the foundation for their strategy, and move companies toward doing things with their data, instead of to their data. The urgency of hooking the business machine up to the data machine is crucial.

But it’s not as complicated as some make it seem.

“At the end of the day,” Edd said, “find a problem you can solve.”


Get the latest from Mixpanel
This field is required.