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 “of their business”, and begin working on their business. One in every of the central thesis of the book is that SMB owners should act as in the event that they desired to franchise their business. This forces them to (1) take a tough have a look at all their activities and processes and (2) optimize and standardize those activities and processes. By doing so, they’ll maximise the yield of their business, and make it replicable. This concept is comparable to something that was expressed by Ray Dahlio in “Principles” — to ensure that a team to achieve success, their manager must work on the team (and never within the team), and construct a system that can maximize the yield of any given input.
To some extent — those advices may 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 connection between the 2 could be represented as follow:
# quality insights per thirty days = time spent on turning data into insights / avg time needed to show data into quality insights
So that you can increase the # of quality insights generated by your team, you must work on either increasing the time spent on turning data into insights, or on decreasing the typical time needed to show data into quality insights. You’ll be able to accomplish that by constructing “systems”.
Increasing the time spent on turning data into insights
The time spent on turning data into insights may be very clearly a function of your total headcount — so increasing headcount is the apparent solution, but which may not be the simplest one .
One other technique to have a look at it’s that point spent on turning data into insights is the results of the next 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 purpose of generating insights if there isn’t any interest in them, or in the event you don’t properly communicate them?).
- But these tasks are frequently treated as “afterthoughts”. It’s pretty rare to see a team with a transparent strategy or process on those elements — almost certainly because this shouldn’t be as “cool” as the actual data work, and in addition because this shouldn’t be necessarily a part of their skillset.
- This leads to these tasks taking more time than expected and more time than it must be to make sure the success of the particular data work it supports.
By (1) defining clear processes on easy methods to go about these tasks, and (2) by standardizing and optimizing these processes over time, you’ll be able to drive a whole lot of time savings (i.e. reducing the time spent on the non-data work), and improve the standard of your output at the identical time.
A concrete example of this around cross-functional alignment might be to start out running prioritization sessions at first of each month. In the primary month of doing this, you realize that with a purpose to have a superb prioritization session you must have a normal framework to make prioritization decisions. You introduce that in Month 2 and it really works, but then you definitely realize that to make it even higher, you must have a greater process to map the potential projects for the team, so that you introduce that in Month 3, etc. Time beyond regulation, with this iterative approach, you’ll be able to get to a really effective process, allowing your team to spend less time on “political work” and to focus more on insight creation.
One other example around company-wide communication: you begin with out a clear process in Month 1 and realize that your study shouldn’t be being consumed as much because it must have been. So in Month 2, you launch a monthly forum. During those monthly forums, you realize your stakeholders have to see the information presented in a certain way so it’s more digestible for them so that you adopt a certain format / template, etc.
Again — by optimizing those processes, not only you save time that you could re-invest in insights creation, but you furthermore may set yourself up for achievement, as those time-consuming non-data related processes support your team’s ability to generate quality insights.
Decreasing the typical time needed to show data into quality insights.
There are a pair of things that may influence the time it takes to show data into quality insights. To call just a number of:
- The talents of the analyst
- The support of the team
- The supply of information
- The existence of tools
Upskilling your analysts to chop the time it takes them to show data into quality insights is the primary strategy. The upper the abilities, the more experience they’ve, the faster they could be in turning data into quality insights. While team-level training or individual coaching can generally create a whole lot of value, a “soft” technique to upskill is by creating project “templates” in order that more junior analysts can adopt best practices and learn quickly. For instance, having templates can force them to take into consideration key questions comparable to “what’s the pain point”, “how will your results be utilized in real life”, etc. that ultimately will help them construct stronger problem statements prior to them starting their study.
Creating ways for the team to collaborate and share their knowledge may also be a technique to reduce the time to insight. It might 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 good distance. Once those “venues” exist, analysts can find support once they usually are not sure easy methods to proceed, utilize the collective knowledge of the team and create discussion that inspires recent ideas. That’s also why I think it’s great to have recurring meetings where analysts can present what they worked on — with a give attention to the methodology they used, because it spreads knowledge and can provide ideas.
The supply of information generally is a big blocker. If you could have to spend your time making complicated queries because there are not any easy aggregated databases that exist, and if you could have to triple-check your results each time because there isn’t any certified or centralized data source, not only that can create unnecessary stress for the team, but you’ll lose precious time. Creating the suitable data pipelines to make downstream evaluation easier could be an efficient strategy — if this hasn’t already been done.
Finally, if you could have to do the identical evaluation very often, the existence of tools generally is a technique to reduce the time you spend doing repetitive work. This is kind of common for things like A/B testing, where you’ll be able to construct / buy licenses for automated tools to do all of the statistical tests for you, so that you simply don’t need to reinvent the wheel each time you get some data from an experiment. It requires having a selected, repeated use case but when that’s the case, that could be a fantastic technique to reduce the time to insight (and bonus point: this can be a fantastic technique to standardize the standard of the output).
Ultimately, you could have a number of ways to go about reducing the typical time to insights — and I feel I’m pretty removed from being comprehensive. You may as well take into consideration knowledge management, data discoverability, etc — all of it depends upon what are the fundamental pain points that your team is facing.
In conclusion
We will rework our initial formula:
# quality insights per thirty days = (total headcount time — time spent on non-data work) / avg time to quality insights.
And while increasing your total headcount is one technique to go concerning the problem, you would possibly achieve similar results by taking a tough have a look at your processes, your infrastructure, your tools, and your “analyst support” strategy.
This text was cross-posted to Analytics Explained, a newsletter where I distill what I learned at various analytical roles (from Singaporean startups to SF big tech), and answer reader questions on analytics, growth, and profession.