In 2020, the Data and Analytics team at Torch started with one of our founding engineer’s interest in supporting the company to make more data-driven decisions. The company supported and invested in this program after some early wins proved valuable. The concept of dedicated data teams was (and still is) relatively new; however, more companies are rapidly starting to adopt the narrative that organizations need data teams.
At a fast-growing startup like Torch, priorities can change unexpectedly. Altering business and product strategy is an ongoing effort. Reorganizing and expanding teams is part of the game. This ever-evolving environment brought to light how much our company could benefit from having a dedicated data team to ground our strategies, goals and decisions in data-backed analyses and findings.
At Torch, we took an engineering approach to building our Data and Analytics Team. As our headcount and customer base grew, we saw a need to grow the team as well. In early 2021, we added an Engineer from our Product Engineering team to help support the growing demands of data within the organization. The team of two partnered with internal stakeholders to provide data and insights to support their decisions.
We quickly realized that as the company grew, this service model would not help the team be truly impactful to the business. We needed to be strong partners for our stakeholders and provide them with tools and resources so that they could feel empowered to answer their own questions.
Data Team as a Product vs. Service
In most organizations, data teams are usually set up as service organizations, supporting the needs of other departments. This way of operating is more reactive in that we were providing insights and answering questions for other stakeholders as issues arose. This approach only allowed stakeholders to react to issues after they arose, rather than to plan and develop strategies for the future. It also limited the team to having a superficial impact whereas a product approach empowered the team to create a foundation and build upon it, allowing the team’s influence to grow over time.
Positioning the data team as a product rather than a service allowed us to develop a deep understanding of our stakeholders goals and pain points, which in turn shaped the way we modeled our data and built our warehouse. It also provided a clear scope for the responsibilities of the team. This way of operating is more proactive. By switching to the data-as-a-product model, we were able to build tools and provide analysis that helped drive changes to our product and offerings and facilitate good decision-making.
Structuring the Team
There is no single right way to structure a data team. Your team’s structure should support your company’s and business’ needs. Typically, the most common ways to structure the team are:
-
decentralized teams – “plant” data members (data analysts, data engineers, data scientists, etc.) into each organization within your company
-
centralized teams – all data members are part of the data team and act as liaisons or ambassadors to other organizations
The Data and Analytics team at Torch leverages a centralized structure, in which all analysts and engineers are part of the same reporting structure and work together with the shared goal of developing data products for both Torch and our customers. By centralizing all data-related roles, we ensure standardization of metrics, terminology and prevent duplication of work. This makes it easier to scale in the long run since all analysts will be working on a common data platform. It also enables each team member to share their technical knowledge with each team member without having to attend every meeting for every organization within Torch and helps teams across the organization speak the same language when it comes to data points they are making decisions on.
A centralized data team at Torch helps us strengthen cross-departmental communication and be more efficient.
Growing the team
With a team of two generalist engineers, we still needed to grow the team and hire more team members to support the modern data stack. We strategically decided to hire one person at a time, depending on the need of the team and business. The most pressing need was to organize and transform our data in a meaningful way, as well as a way to build reporting and dashboards to surface data insights. This led us to search for an Analytics Engineer and a Data Analyst.
Many organizations fall into the trap of hiring a data scientist/ ML engineer even if they don’t have any immediate ML/ AI needs. Such highly specialized roles should be fewer in number and added to the team once a solid data platform has been created. Emilie Schario, Data Strategist-in-Residence at Amplify Partners, talks about how hiring a “data scientist” early on is a bad idea because setting up the core foundation of a data team requires a variety of skills that data scientists are usually not equipped with. In a podcast episode of the Practical AI on building data teams, the hosts talk about how they made the mistake of prematurely hiring a stellar team of data scientists who unfortunately did not have any understanding of how DevOps and deployments worked. They had not taken into account the variety of other engineering skills they would need to get the team up and running.
At Torch, we value building strong teams with a diverse skillset and carefully select our hires to ensure that are a culture add over culture fit so we took on a more generalist approach to hiring. As a lean team, we wanted to make sure that each team member was able to play to their strengths and experiences but also had room to grow into their role. A team of strong data analysts will only get you so far if no one on your team has a good engineering background and vice-versa. Prioritizing right attitude over right experience is much more likely to prove to be a winning bet.
Sources:
- How Typeform built a data team in under 6 months – Typeform blog
- Data as a Product vs. Data as a Service
