From Support to Growth Oriented Data Teams (Scaling Your Data Team, Transition #1)
In this first article of the series, you will learn about the top four areas to focus on, as well as the mental models that can be used to help your data organization transition from a support-oriented to a growth-oriented one.
The ability to evolve and optimize how data teams are organized to deliver maximum value, is one of the key characteristics of highly successful data-driven organizations.
Over the years, personal experiences as well as experiences shared by colleagues (coworkers, students, industry leaders,…) helped me identify good practices to design and run efficient data organizations.
I’ve compiled these practices in a series of articles titled “Scaling Your Data Team”. Each piece focuses on a transition, a motivator for change in your organization to which you must adapt. I hope these articles help you if you go through a similar process, and overall we reduce the risk of reinventing the wheel.
In the first article of the series, you will learn the differences between support-oriented and growth-oriented data organizations as well as what mental models and resources you can use to transition from one operational model to the other.
The second article of the series focuses on centralization vs. decentralization and you can read it here: Navigating the Spectrum of Centralization vs. Decentralization in Analytics Teams.
The third and final article of the series offers a 5 steps guide to grow and split a Data Platform team and you can read it here: Scaling Data Platform Teams: A Step-by-Step Guide.
Historically, data teams have been on the receiving end of lots of data requests from other parts of the business. This traditional support-oriented approach keeps the data team busy; but in the long term, it can limit their ability to deliver net new work or prioritize high complexity topics (like deep exploration, advanced analytics or experimentation).
On the other hand, when data is considered a growth-oriented function in an organization, the company values data-informed decision making as a key driver for growth, increased efficiency, cost reduction and ultimately higher profits. In this context, data is not used just as a byproduct but rather as an strategic asset.
Transitioning from one organizational model to another is a significant undertaking that requires changes in business culture, processes, and technology. In practical terms, these are the four areas I believe companies should focus on in order to advance towards data teams being a growth-oriented function:
- Adopt a product mindset for analytics initiatives
- Invest in state of the art technology
- Protect prioritized work
- Develop a data literacy program
Let’s discuss in detail each area of focus.
Adopt a product mindset for analytics initiatives
When data teams are treated as a support function, Data Analysts are primarily responsible for fulfilling requests from other departments to provide data insights on specific topics or questions. Their primary focus is on delivering these insights as quickly and efficiently as possible, without necessarily considering the long-term strategic goals of the company.
On the other hand, a product mindset on analytics initiatives involves treating analytics as an ongoing process, with a focus on having a clear vision that contributes towards business goals, a roadmap and a set of metrics to measure success.
The first step in successfully adopting this product culture is to incorporate data and data people far sooner in the process of defining new work. Data will be helpful in determining which efforts to prioritize and in establishing an incremental and iterative product development approach. The Agile Dual Track or the Double Diamond Model are both excellent tools for this.
Both models are iterative, emphasize user-centered design and are built on the principle of testing and prototyping ideas before deciding to implement them.
This means that many of the ideas that will go through the discovery phase (in the case of the agile dual track) or the solution exploration phase (in the case of the double diamond model) will be discarded and not implemented thanks to qualitative and quantitative research (experimentation, user interviews, fake door tests,…).
If done right, this will save time to do even more discovery and experimentation which will allow you to optimize your product further. Eventually, you will be in a better position against your competition thanks to data and a lot of cumulative data-informed decisions.
Invest in a state of the art platform
Growth-oriented data organizations are built around self-service data platforms. Thanks to these platforms and the content built on top of it, decision makers are autonomous in getting the data they need whether it is via dashboards, notebooks, raw data, etc.
One of the biggest challenges here is to make sure you have the right tool for the right data consumer. Let’s illustrate this with a couple of examples:
- Most business users will not perform a SQL query to get the answers to their demands. Instead, you will need to give them a data visualization tool, a basic and documented semantic layer, and, in certain situations, an already created dashboard.
- Data Analysts won’t invest huge amounts of their time in complex technology to create simple data pipelines; you will need to ease that by adopting easier tools or simplify pieces of your infrastructure.
Purchasing 3rd party tools is not enough in this context. A state of the art platform should also include basic data products (datasets and dashboards) for the most commonly asked questions. This will mitigate the risk of reinventing the wheel every time data consumers need to use data.
Maintaining these data products with high quality (well documented, cataloged, with examples, etc.) will increase the amount of low complexity insights (counts, descriptive analytics, user segmentation,…) that can be self-served across the organization and will allow Data Analysts and Scientists to focus in higher complexity topics.
Protect prioritized work
When moving away from data being a support function, your teams will need to break the inertia of wanting to answer every question that still gets asked to them directly (instead of making the rest of the organization self-served with data).
That is the reason why you need to be very strict at protecting people’s focus to allow them to work on prioritized new initiatives that use data to achieve business goals.
Here are several process, agreements and models you can put in place to achieve that:
- Split the team’s effort between different types of work: business goals work, IT goals (or technical debt), planned/scheduled requests, and unplanned work -bugs-. (Taken from The Phoenix Project book).
- Protect business goals work by using lanes. Each lane (or subteam) focuses on one type of work so people working toward achieving business goals do not need to pay attention to requests coming to your team. (See the article Growing a feature team using lanes for more).
- Reduce unplanned work to just what is critical and cannot wait (high severity bugs). Teach team members to say no (“yes, but not now”) to move from jumping right ahead into helping everyone to actually plan requests.
- When dealing with requests, spend time making data consumers more autonomous and data literate to avoid the same requests coming again and again. Also, always ask why and document everything.
Develop a data literacy program
Last but not least, you will need to start a data literacy program so that people know how to use the tools they have available and the important data assets for the organization.
This program can involve training employees on how to collect, analyze, and interpret data, as well as how to use it to solve real business problems, launch experiments, build Machine Learning models, etc.
Don’t block the creation of the program just because you think it is a huge endeavor and needs to be perfect. You don’t need to build all the pieces of the data literacy program at the same time. Begin small, train a small group of individuals on the most relevant topics, then iterate.
It is important to note that as you add new building blocks to your self-serve architecture (data catalog, experimentation platform, etc.) you will also need to create training sessions for those. Eventually, you will have a collection of training sessions you should also teach to every new employee.
In parallel to this more formal program and regardless of how the data department is organized in your company, the fact of data folks working hand in hand with people from other disciplines (Product Managers, UX Designers,…) will also help increase data literacy. Don’t underestimate this power!
Final words
In this article, we have highlighted the four areas of focus that can help data organizations transition from a support-oriented to a growth-oriented model.
We have done that without addressing much how the data team should be organized as these areas of focus are independent of the level of centralization or decentralization (embedding) of your Data Analysts, Data Scientists and Data Engineers.
The second article of the series focus on the transition from centralization to embedding of data folks and, spoiler alert, vice versa; you can read it here: Navigating the Spectrum of Centralization vs. Decentralization in Analytics Teams.
The third and final article of the series focuses on Data Engineering and Data Platform teams: Scaling Data Platform Teams: A Step-by-Step Guide.
