DATA STRATEGY
A Guide To Building a Data Department From Scratch
Some practical advice on where to start from someone who’s been there before
Most resources I come across when looking for advice and best practices on how to build a data department at a middle-sized company are either about creating a data-driven organization or building a data team. However the position I found myself in more than two years ago required a more pragmatic approach:
As the first (and only) data person at an organization, how can you concretely start to introduce data best practices and build a data department?
Have you recently been asked to build a data department at a given company? Do you plan to take on this role in the near future? Or, out of curiosity, have you always wondered how an organization went from using almost no data to having a multi-person data team? If so, this article is made for you.
Setting the scene
When I got hired as the first “data person” at my current company in November 2021, I was faced with a blank field. The top management had unlocked the budget line for one data person, but the company was far from being data-driven. My manager had previously worked with tech and data roles, but his background was not extensively related to data roles at organizations. Finally, none of my colleagues in the tech department (mostly software engineers) had ever held a position related to data engineering, analytics or science.
So I gathered all the tools I had at my disposal. I could count on my previous experience as a data team lead at a scale-up company and on the skills I had acquired as a strategic consultant. Other valuable assets were to be found online: there are countless books and articles listing pieces of advice to create a data-driven organization or to build a data team. Asking questions to peers in the data community and to colleagues from other departments would also prove to be useful for the journey ahead.
In this article my ambition is not to teach you theoretical fundamentals that you could find online or in books. They are precious resources you can definitely rely on. But nothing beats experience in the field. What I want to share here is my unique experience of how I went from very limited corporate data usage to a successful data team at my current organization in just two years.
First things first: Make it clear what you’re doing here
This may sound ironic but this is the first step I took: make it clear to myself and to others what is expected from me in this new role. Being hired at a new position, and even more at a position that did not exist previously, implies that one should “write” their own job description — or rather, make the theoretical job description they got hired based on, a reality.
To do so, my strategy was to organize one-on-one meetings with colleagues from other departments, whether they are team leaders or not. The goal is to understand what is already in place and how different people in the company position themselves in relation to data-related challenges.
The set of questions I asked was the following:
- General questions about data: What does “data” mean to you? Have you already worked with data roles? Do you know what is the job of a data analyst/scientist/engineer?
- Questions about their affinity with data in their daily work: How do you evaluate your performance? How do you monitor your daily activity? How do you plan for the future?
- Questions about their current use of data: What are the main metrics you currently track? How do you measure and visualize them? Can you show me the tools you use?
Following these interviews I had a first idea of the tools used in the company, where data was lying and how it was used by business stakeholders. I documented the outputs of the interviews conducted and my main takeaways at a central place (you can use any collaboration tool like Notion or Miro). This allowed me to come back to this initial work whenever I needed during the first months of my new job.
And then: Develop a strategic approach to data challenges
Based on the takeaways from the previous step and on my own experience I chose to adopt a two-pronged approach: combining quick wins (low effort, high value, but low robustness on the long run) and long-term projects (high value, high robustness, but high effort required). Dividing my agenda in two allowed me to conduct both types of actions simultaneously.
Quick wins along the handyman’s path
Talking to the main stakeholders is beneficial for visibility, but the hardest part remains: proving them that your work as a data analyst is valuable and will serve their own interests.
During the interviews I had listed the pain points that each stakeholder was facing. Later I prioritized them starting with the analyses or actions requesting the highest “effort invested / value created” ratio. As an example, the first type of action I took was to update an obsolete date-based filter in a dashboard already in use. Then I carried out a rather uncomplicated analysis for an operational issue. Don’t be fooled: the first actions will probably not be the most challenging from a technical perspective, but the delivered value is so much worth tackling these easy issues first.
While doing so, it is important to regularly switch departments: if I plan to work for the Marketing department for 3 weeks, then I would go work for the Operations department for the 3 following weeks, even if the Marketing team keeps expressing data needs. Although it can be frustrating, this is the only way to cover most departments within a few months. In the end I found this approach to be beneficial as I convinced many different people that my work could help them with their job.
Building for the future along the builder’s path
While working on first data analyses delivered to business users, you should invest time to build the future. The reason why this part is essential is that conducting basic analyses will come to an end: when you will have unlocked the most basic needs of other departments, they will likely ask you for more complex analyses or they may want to access the data themselves. To be able to answer this type of requests once they emerge, this is necessary to start building the foundations of a data platform as soon as possible.
For more than a year, I was the only person in charge of everything related to data. I had to find allies in different job positions who could support me in building the future of data at our company. On the technical side I worked with the tech lead who I shared the goals of a dedicated data platform with. We discussed the best tools to choose based on a benchmark I conducted and tried several solutions by building proofs of concept. This is how we decided to implement Airflow, BigQuery, dbt and LookerStudio as the first building blocks of our data stack.
On the business side, my main ally was my manager, who could help me develop my ideas during brainstorming sessions. Having someone who challenges your ideas will make your vision clearer and reinforce the argumentation. Topics of discussion during the first months included the scope of action I could/should take at the company, the prioritization of all the projects I had listed, the best way to structure and later present the company’s data strategy to the top management. This is how I found the confidence to conduct all the actions that would eventually lead to building a strong data department.
Conclusion
As I detailed it in this article, my main pieces of advice if you are about to start building a data department at any organization are:
- Start by stating the obvious: make it clear what your role will be
- Conduct interviews with colleagues from all departments to get a clearer picture of the current state of data use at the company
- Develop a data strategy based on a two-pronged approach: combine the handyman’s path with the builder’s path to ensure you deliver value quickly while building strong foundations for the future
If you want to learn more about the role of Data Strategist, the role I gradually took on within my company, I recommend the following article:
