Four building blocks for scaling insights — Part 1: The embedded model
From the very beginning in 2013, insight driven decisions have been part of Kolonial.no’s culture. However, this has become more challenging as the company has grown to become the leading online grocery retailer in Norway with more than 400 employees and an annual revenue that crossed 1 billion NOK in 2019.
Simply delivering insight on request just doesn’t scale, and is also not the way we would like to work. With a growing demand for insight, we have changed the role of the Data & Insight team from being data providers to insight enablers — making it possible for our colleagues to independently work with data and analysis. (That being said, we still do ad hoc analysis when it requires our special skill set).
Over the past six months, we have made our decision makers self served on insight and been able to scale with the growing need for insights without recruiting a bunch of analysts. This is the first part in a series of posts describing how we have approached this challenge.
Realizing the potential in data
The mission of the Data & Insight team is to realize the potential in data. Data Science is applied to improve the end user product, examples include product recommendations and personalized shopping experiences. Data products are also important in improving the performance of our operation and distribution through automation, an excellent example being route optimization. We also realize the potential in data through our colleagues where our aim is for them to make as much impact as possible with their decisions.
The deliveries of the team is therefore twofold:
- Delivering data products to improve the customer experience and the operation
- Be a support function for decision makers at all levels across Kolonial.no
How we work to create data products and use the power of data algorithms is not covered in this article as the main focus is on how we create impact with self served insights.
In this post we will introduce the four building blocks and the rational for our transformation of the role of the Data & Insight team and the tools we use to achieve that. The first building block, our embedded organizational model, will also be covered here. The following three blocks will then be described in more detail in dedicated posts soon to be published.
1: Embedded organisation
Recruiting the right kind of people
The right kind of people and the organisation of them is the first step. We have designed a recruitment process with a set of data points that are as objective as possible to be able to compare candidates fairly and make sure they have the right competency. We test their business understanding, their analytical problem solving skills and their technical ability to work with data. Although the strength of those three capabilities are weighted a bit differently between our product analysts, data scientists and data engineers, they can all work across our insight stack and solve problems end to end independently. We of course also make sure their personal qualities are well suited for their tasks and that they are a good fit for our culture. Finally, and equally important — we use a lot of time to make sure we’re a good match for the candidate so they can grow well in the company.
It is worth mentioning that as we want our decision makers to do as much as possible themselves, the role of the analyst is probably both more technical and at the same time more focused on enabling others than in traditional analytical teams. This means that they all are fluent in SQL, can implement data transformations and like to help others by teaching and mentoring them in doing analysis themselves and using them in the right way. When they do build dashboards and do ad hoc analysis, it is usually the more tricky stuff.
The embedded model
When you have the right people with the right skill set, it is important to give them the best conditions to create as much value as possible. Many people have written a lot about different ways to structure analytics (this article summarize the topic quite well). I have seen and tried a couple of them and believe strongly that the embedded model is the best for our needs. Most of our product analysts and data scientist are embedded in our cross functional product teams together with product, UX and developers, and working towards a subset of the business. In our case it looks like this:
The main pros for this way of working is the domain specialisation we achieve, something that is quite important for us with such a wide range of problems we are working to solve. We are also close to all the business units and can be invited (or even invite ourselves) into discussions when bigger decisions are about to be made. That’s when we actively make sure analysis and their assumptions are sound. Our team members are part of the product teams, making sure performance is measured, experiments are set up correctly and they impact prioritization, product roadmaps and strategy.
As the Director for Data & Insight I depend on our embedded product analysts and data scientist to be in close contact with our main stakeholders from day to day and pick up what is important. This final argument for the embedded model gives us speed and makes sure we are involved in the right places instead of relying on information only passing through formal reporting lines.
You don’t need a big team
This post is based on a presentation I did called “How we scaled insight to 400 people with four analysts and one data engineer”. By looking at the team chart above, you can see that this is not completely the whole story. But until February 2020, when I held the presentation, we only had four analysts, and two of those four started within the last three months. Of course our data scientists also work with insight part of their time, but our main contributor to insights are our product analysts.
It is though important to have product analysts, data scientist and data engineers gathered in the same discipline wide team with aligned goals (we use OKRs), knowledge exchange, cooperation and competency development. Data & Insight act as a team. We have biweekly team meetings to plan and follow progress on common projects. We also have biweekly deep dive sessions where we show our work to each other, get input on problems we are trying to solve and discuss analytical methods and technology. All of this is important to have some centralisation for all the people working in Data & Insight.
While only five people were in charge of doing all this, they were all along supported and encouraged by both other team members, the rest of product & tech and the insight consumers.
Stay tuned for the next part covering out insight infrastructure
Self served insight is not only dependent on great people, it also requires a good infrastructure and a stack that supports self served processes. That is the topic of part two, The evolution of our insight infrastructure. It is then followed with our thoughts on how we align and establish standardization in part three, Best Development practises. Finally, in part four, we explain how we train and support the organization to become self served with insight, where our Data University has a central role.
Feel free to check out other post from my colleagues in Product & Tech here on Medium such as how we work with DevSecOps or how we have solved alignment and execution on strategy.
We are also looking for great people to help us double our capacity and tech team (and one more thing) and have posted new positions in the Data & Insights team.
