ThoughtSpot users advice on analytics - 'Jump in, make mistakes, keep talking'

It is a rare day now when an IT vendor does not mention digital transformation and the capabilities of Big Data analytics when talking to a potential customer. But as we always say, the best proof points come from customers.

The recent ThoughtSpot Beyond conference in Washington DC provided an opportunity to hear from some horses mouths (no slight intended) about their use cases.

Three customer representatives took to the stage to talk about some of their experiences – the good and the not so good. Catherine Beley, Senior Data Manager at Hulu, Vincent Ciro, Commercial Executive Director at Allergan, and Kris Curtis, the Data Visualisation Lead at Just Eat, to their collective credit, were happy to talk through some of the issues that made their hands dirty and gave them their current set of war wounds.

First question up was why they thought so many companies and organisations have still not moved ahead with any digital transformation plans? Allergan’s Ciro jumped in with an obvious but usually unstated issue that many companies need to watch for within themselves and be willing to confront head on:

We are past having doubts about the technology and related issues. What stands in the way now are human factors and psychology. Peoples’ roles change.

His advice is geared to that common saying that it is much better to make your mistakes early. This still may feel counter-intuitive to many users, but the cloud can be very tolerant. So his advice is straight forward: make the decision to jump in and do it; it is always possible to change things later.

Curtis added some advice for those leading any transformation projects, advice that is actually a complement to failing early. He told delegates that they must be confident in their decisions in terms of overall strategy and direction. That way, tactical errors can be readily accommodated , learned from and, perhaps, even exploited.

He also gave a good example of learning from an initial error in his response to a question about how a business should take that first step:

In my company the data engineering team was tasked with managing the job, and to begin with they didn’t bring in the other stakeholders. This was probably a mistake and they found a better solution, which was to make the project involvement business-wide. We found that the analysts needed to learn a completely new skills set.

Advice from the others included ensuring that whoever is running the project has to look at the company’s data sources and the platforms being used. There is a need here to match up transaction systems, or at least identify where integration or collaboration bottlenecks might be found. It is also necessary to avoid having your analysts drift into becoming data engineers.

This does suggest that an important area of job differentiation is starting to emerge, where analysts need to maintain a wider purview of the relationship between data and its business context, whereas data engineers are liable to spend time getting down and dirty with wrangling data into shape.

The subjects of Big Data and cloud elasticity are, of course, not new, but the panel was asked for any observations about managing them. When it came to Big Data Ciro noted a simple approach to the division in need that exists between data scientists and regular users. For the latter, simply build basic dashboards for those that consume the results of analytics – or manage that consumption process. For the former, essentially let the data scientists so their own thing.

Curtis observed that even defining cloud elasticity has now become a very subjective issue and that, for him, it simply means the speed with which he can spin up additional machines.

Lessons learned, benefits gained

When it came to what they had learned from the process so far Beley noted the need to be aggressive about making the move, but not so aggressive as to be `pig-headed’. There is a need to take retrospectives such as going over the steps being taken with the other stakeholders and teams – at least let them know what is happening, and take on board their feedback.

Also take advantage of change to ensure that data governance is being carried out correctly. This, she said, is time consuming, but it is also important. Indeed. It is now essential. The volume and variety of data these days means that a high level of management control and governance is now key, for losing control of any of it could easily prove fatal to any business.

Curtis pointed to another version of the potential divide between data specialists and the rest:

Work out the steps in the journey. Data engineers know the start and end points, but they don’t necessarily know the steps along the way. So don’t keep the project to yourselves. Talk about it with the other teams. And take positive action – promote the process, the steps, and everything else to do with it.

He added that the customer experience should not be forgotten either – where `customers’ equals both the customers of the business and the internal users within the business.

Making the move has several benefits, such as brining more cohesion across the business by bringing different teams together and leveraging their different experiences and skills. It can also bring much better performance and delivery of results. Tasks that would normally take a day can now be completed in two minutes.

And Ciro pointed to an important side benefit that has the potential to shift power balances within organisations:

The process has given the team a seat at the C-Level table because of what the process has delivered to the business.

My take

Some sage advice for  CIOs, business managers and other C-level participants.