5 Tips and tricks to make an impact with data

‍

These tips were gathered from personal experiences as Payfit Head of Data and Data Manager at Criteo, as well as talks with data leaders from other companies.

Whether you’re a Data Analyst, a Data Scientist, an Ops or just writing the occasional SQL query, do comment this article with your own tips.

‍

Tip #1: Focus on impact, not on tech

Many data players are too focused on how they do things: “I’ve used this cool package” or “this dataviz is fantastic”. What matters, in the end, is that your work changed the path of events or increased trust in it. Think of it this way: what would have changed if you hadn’t done your job?

The key point here is to take the shortest (yet valid) route to having an impact. New tools, new packages, new methodologies pop up all the time, but you must stay focused on solving the business problems as efficiently as possible. Also, when presenting an app, an analysis or whatever, be sure to present clearly resulting actions items, with clear owners

Here is an example, you presented your analysis and despite your change recommendations, nothing happens! What should you do? Move to the next analysis? No! If you believe in the impact of your recommendation then try harder. Maybe a sync with the business sponsor to decide further actions to be taken? Or a follow-up meeting with action owners? Can you take some actions yourself?

This also means that what you do is not always complicated and techie. Actually, my biggest impact as an analyst in a previous experience was to build a clean and appealing Google Sheet where all teams would list their operations improvement projects, with an ROI estimation. This allowed the company to get a much clearer view on its efforts to improve operations. Was that the job of a head of data? An analyst? An Ops? Who cares, it had an impact!

Tip #2: Find TRUE business sponsors

Ones willing to let data change their work habits

Let’s say you have this great idea to improve the Customer Success (CS) efficiency. You want them to track their ticket closing time so that they can decrease it. What should you do before running the analysis and building the dashboards? Check that you have CS leaders buy-in and commitment! Otherwise, it is a waste of time, so be sure to test it and if you do not have this then simply move on to your next idea, and come back to CS later. Why? Simply because a good analysis is never enough in itself, especially if people are not ready yet to take actions derived from it.

Tip #3: Always ask “why” as in “why do you need this”

Applicable to most jobs in a (tech) company. People should tell you what’s their challenge or problem rather than what they need from you. You’ll then provide the best answer (and save you some time and iterations)

‍

Let me explain

The problem comes from asking about your attempted solution rather than your actual problem. This leads to wasted time and energy, both for people asking for help and for those providing help.

‍

A typical conversation goes like this:

• User wants to do X.
• User doesn’t know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
• User doesn’t know how to do Y either.
• User asks for help with Y.
• Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
• After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn’t even a suitable solution for X.

‍

The problem occurs when people get stuck on what they believe is the solution and are unable to step back and explain the issue in full.

‍

An example of a real-life data problem is: The dashboard will not update today.

1. Why? — The table A feeding the dashboard was not updated. (First why)
2. Why? — The transformation scheduled did not run. (Second why)
3. Why? — The transformation script is broken. (Third why)
4. Why? — The upstream tables B and C feeding table A were modified. Columns were deleted and field types changed. (Fourth why)
5. Why? — The communication between data engineering teams #1 and #2 was broken. (Fifth why, a root cause)

‍

Solution: address the symptoms in the short term (fix the transformation script). Treat the disease in the long run (improve communication between team #1 and #2 by implementing a tool like Castor)

‍

Tip #4: Define business concepts before computing KPIs

This advice comes from several experiences I had in a previous job. Always define a concept before computing any KPI on it. This will avoid misunderstanding and will create alignment and trust.

‍

How many clients do we have?

After a few days in the job I was seeing different client counts in our press releases, job offers and internal communications. I wondered why people disagree and all seemed sure that they had the correct figure.

Simple answer: there wasn’t any proper definition of what was a client.

• Is a client cross-country or country-specific?
• From which moment do we start to exclude a non paying client?
• What about subsidiaries?

This may sound silly to create alignment just to count number properly. But is has an impact on a lot of other metrics: revenue per client, satisfaction computation, …

‍

How much revenue do we make?

Here is another typical disagreement within a company.

The same issue can occur with computing company revenue. The Finance team disagrees with the Sales team that disagrees with the Customer Success team. The first belief to fight is to make people understand that they are multiple revenue concepts. There are:

• Sales revenue: focused on computing sales bonus fairly
• Billed revenue: focused on rendering the owed money to the company
• Paid revenue: focused on rendering the received money of the company

Your business may have other specific revenue computations. Make sure to identify them and clearly define their differences.

At Castor, our goal is to help data players in companies align on such concepts. Our business glossary has been made with that challenge in mind.

‍

Tip #5: Start with a business problem then see if data helps

Not the other way around. Your impact does not start from data, nor does it end with it. You’re here to find a business problem and fix it, with a mix of data, process and communication.

‍

Conclusion

Data problems are often rooted in bad communication. Either the problem is not well-scoped or the context around data is not well defined or the concepts and entities are poorly defined. Data teams, large and small, should invest early in data communication/collaboration tools.

About us

We write about all the processes involved when leveraging data assets: from the modern data stack to data teams composition, to data governance. Our blog covers the technical and the less technical aspects of creating tangible value from data.

At Castor, we are building a data documentation tool for the Notion, Figma, Slack generation. We designed our catalog software to be easy to use, delightful and friendly.

Want to check it out? Reach out to us and we will show you a demo.

‍

Subsribe to the Castor Blog