The E-Myth of Analytics: Optimizing and Standardizing Data Teams
How to build systems to generate more - with less
In “The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It”, Michael E. Gerber invites small business owners to stop working “in their business”, and start working on their business. One of the central thesis of the book is that SMB owners should act as if they wanted to franchise their business. This forces them to (1) take a hard look at all their activities and processes and (2) optimize and standardize those activities and processes. By doing so, they will maximise the yield of their business, and make it replicable. This idea is similar to something that was expressed by Ray Dahlio in “Principles” - in order for a team to be successful, their manager needs to work on the team (and not in the team), and build a system that will maximize the yield of any given input.
To some extent - those advices can also be applied to analytics teams. For an analytics team - schematically - the input is the time spent on turning data into insights, the outputs are “quality insights”, and the relationship between the two can be represented as follow:
# quality insights per month =
time spent on turning data into insights / avg time needed to turn data into quality insights
For you to increase the # of quality insights generated by your team, you need to work on either increasing the time spent on turning data into insights, or on decreasing the average time needed to turn data into quality insights. You can do so by building “systems”.
Increasing the time spent on turning data into insights
The time spent on turning data into insights is very clearly a function of your total headcount -- so increasing headcount is the obvious solution, but that might not be the easiest one .
Another way to look at it is that time spent on turning data into insights is the result of the following equation:
Time spent on turning data into insights =
Total headcount time - Time spent on non-data work
The time spent on non-data work includes elements like “alignment with stakeholders”, “communication”, etc.
These tasks are essential to the success of any good data work (what’s the point of generating insights if there is no interest in them, or if you don’t properly communicate them?).
But these tasks are usually treated as “afterthoughts”. It is pretty rare to see a team with a clear strategy or process on those elements - most likely because this is not as “cool” as the real data work, and also because this is not necessarily part of their skillset.
This results in these tasks taking more time than expected and more time than it needs to be to ensure the success of the actual data work it supports.
By (1) defining clear processes on how to go about these tasks, and (2) by standardizing and optimizing these processes over time, you can drive a lot of time savings (i.e. reducing the time spent on the non-data work), and improve the quality of your output at the same time.
A concrete example of this around cross-functional alignment could be to start running prioritization sessions at the beginning of every month. In the first month of doing this, you realize that in order to have a good prioritization session you need to have a standard framework to make prioritization decisions. You introduce that in Month 2 and it works, but then you realize that to make it even better, you need to have a better process to map the potential projects for the team, so you introduce that in Month 3, etc. Overtime, with this iterative approach, you can get to a very effective process, allowing your team to spend less time on “political work” and to focus more on insight creation.
Another example around company-wide communication: you start without a clear process in Month 1 and realize that your study is not being consumed as much as it should have been. So in Month 2, you launch a monthly forum. During those monthly forums, you realize your stakeholders need to see the data presented in a certain way so it is more digestible for them so you adopt a certain format / template, etc.
Again - by optimizing those processes, not only you save time that you can re-invest in insights creation, but you also set yourself up for success, as those time-consuming non-data related processes support your team's ability to generate quality insights.
Decreasing the average time needed to turn data into quality insights.
There are a couple of factors that can influence the time it takes to turn data into quality insights. To name just a few:
The skills of the analyst
The support of the team
The availability of data
The existence of tools
Upskilling your analysts to cut the time it takes them to turn data into quality insights is the first strategy. The higher the skills, the more experience they have, the faster they can be in turning data into quality insights. While team-level training or individual coaching can generally create a lot of value, a “soft” way to upskill is by creating project “templates” so that more junior analysts can adopt best practices and learn quickly. For example, having templates can force them to think about key questions such as “what is the pain point”, “how will your results be used in real life”, etc. that ultimately will help them build stronger problem statements prior to them starting their study.
Creating ways for the team to collaborate and share their knowledge can also be a way to reduce the time to insight. It can be as easy as creating slack channels or google groups and finding some incentive for people to participate - but those tiny actions can go a long way. Once those “venues” exist, analysts can find support when they are not sure how to proceed, utilize the collective knowledge of the team and create discussion that inspires new ideas. That’s also why I believe it is great to have recurring meetings where analysts can present what they worked on - with a focus on the methodology they used, as it spreads knowledge and can give ideas.
The availability of data can be a big blocker. If you have to spend your time making complicated queries because there are no simple aggregated databases that exist, and if you have to triple-check your results every time because there is no certified or centralized data source, not only that will create unnecessary stress for the team, but you will lose precious time. Creating the right data pipelines to make downstream analysis easier can be an effective strategy - if this hasn’t already been done.
Finally, if you have to do the same analysis quite often, the existence of tools can be a way to reduce the time you spend doing repetitive work. This is quite common for things like A/B testing, where you can build / buy licenses for automated tools to do all the statistical tests for you, so that you don’t have to reinvent the wheel every time you get some data from an experiment. It requires having a specific, repeated use case but when that’s the case, that can be a great way to reduce the time to insight (and bonus point: this is also a great way to standardize the quality of the output).
Ultimately, you have a few ways to go about reducing the average time to insights - and I think I am pretty far from being comprehensive. You can also think about knowledge management, data discoverability, etc - it all depends on what are the main pain points that your team is facing.
In conclusion
We can rework our initial formula:
# quality insights per month =
(total headcount time - time spent on non-data work) / avg time to quality insights.
And while increasing your total headcount is one way to go about the problem, you might achieve similar results by taking a hard look at your processes, your infrastructure, your tools, and your “analyst support” strategy.