The right way to construct 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 “of their business”, and begin working on their business. Certainly one 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 take a look at all their activities and processes and (2) optimize and standardize those activities and processes. By doing so, they are going to 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 can 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 30 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, that 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 may 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 plain solution, but which may not be the simplest one .

One other approach to take 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 a interest in them, or when you don’t properly communicate them?).
• But these tasks are often treated as “afterthoughts”. It’s pretty rare to see a team with a transparent strategy or process on those elements — most probably 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 ends in 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 the way to go about these tasks, and (2) by standardizing and optimizing these processes over time, you may drive plenty 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 may very well be to begin running prioritization sessions at first of each month. In the primary month of doing this, you realize that as a way to have a superb prioritization session that you must have a typical framework to make prioritization decisions. You introduce that in Month 2 and it really works, but you then realize that to make it even higher, that you must have a greater process to map the potential projects for the team, so that you introduce that in Month 3, etc. Additional time, with this iterative approach, you may 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 no 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 must see the info 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 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 just a few:

• The abilities of the analyst
• The support of the team
• The supply of knowledge
• 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 plenty of value, a “soft” approach 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 akin 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 can be a approach to reduce the time to insight. It will possibly 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 are usually not sure the way to proceed, utilize the collective knowledge of the team and create discussion that inspires latest ideas. That’s also why I consider 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 knowledge generally is a big blocker. If you’ve to spend your time making complicated queries because there are not any easy aggregated databases that exist, and if you’ve to triple-check your results each time because there isn’t a certified or centralized data source, not only that can create unnecessary stress for the team, but you’ll lose precious time. Creating the precise data pipelines to make downstream evaluation easier could be an efficient strategy — if this hasn’t already been done.

Finally, if you’ve to do the identical evaluation very often, the existence of tools generally is a approach to reduce the time you spend doing repetitive work. This is sort of common for things like A/B testing, where you may 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 an awesome approach to reduce the time to insight (and bonus point: this can also be an awesome approach to standardize the standard of the output).

Ultimately, you’ve just a few 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 is dependent upon what are the important pain points that your team is facing.

In conclusion

We will rework our initial formula:

# quality insights per 30 days = (total headcount time — time spent on non-data work) / avg time to quality insights.

And while increasing your total headcount is one approach to go in regards to the problem, you would possibly achieve similar results by taking a tough take 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.