# Webinar: Building a Data Department from Scratch? Tips to Get It Right the First Time

> Webinar recap from Erathos: how to build a data team, the minimum stack, and common pitfalls, with CTO Luca Piermartiri.

Source: https://www.erathos.com/en/blog/webinar-starting-a-data-team-tips-to-get-it-right
Em português: https://www.erathos.com/blog/webinar-starting-a-data-team-tips-to-get-it-right
Published: 2024-10-07
Category: Platform Updates

![Slide from Erathos's webinar on how to build a data function from scratch](https://cms-media.erathos.com/ahXcFw369LdCgEQ6er9eY2t10Q-1.png)

In October 2024, Erathos hosted the webinar “How to Start a Data Department? Tips to Get It Right,” presented by our CTO, Luca Piermartiri.

In this blog post, we will summarize what was presented and share the main highlights of the event!

We started the event by introducing the concept of a data-driven culture in companies, which you can read more about in this [blog](https://www.erathos.com/blog/por-que-sua-startup-deveria-comecar-a-jornada-data-driven-agora), and then we broke down the main behaviors within data teams that hinder business success and the proper implementation of a data-driven culture. Below, we have compiled the main dysfunctions we mapped out:

## Key Data Team Dysfunctions

1. **Data Silos**
If you use more than one system or platform to run various business processes, you end up with isolated information, leading to data silos. This dysfunction causes major delays when performing analysis, as you have to manually extract reports from each of these systems and consolidate them in Excel, for example, just to try and connect this data to gain insights. Quite a lot of work, right?
2. **Manual Processes**
Often, IT and data teams try to bypass the complex friction caused by data silos by unifying these manual processes, such as building a massive single Excel sheet or writing a Python script that only runs on one person's local machine to "fix" the issue. In addition to being inefficient for the company by wasting time on low-value tasks, this also creates a high dependency on a single professional, as they are the only one who actually knows how the data pipelines work.
3. **Lack of Trust**
Driven by data silos and manual processes, among other bottlenecks, it is inevitable that trust issues will arise regarding the metrics presented, even between different departments. Frequently incorrect data due to integration issues or temporary fixes only build uncertainty and hinder decision-making. It becomes extremely difficult to deliver high-quality data on tight, critical deadlines to drive actionable insights.
4. **Analytics Monopolization**
Another common problem in organizations is analytics monopolization by the data team, which creates a bottleneck for other business units, making them hostage when they need to run insights. Each department should have a basic level of self-service analytics to avoid relying solely on IT/Data, such as calculating commissions for the sales team, for example.
5. **"IT-ification" of Processes**
The reliance other departments have on the data team leads to an overloaded data queue, with a flood of tickets to handle both simple and complex requests. When this happens, we go back to the issue of the team being unable to deliver everything (let alone with the expected quality), and prioritization begins to stall data engineering roadmap initiatives in favor of ad-hoc business requests.
6. **Building Data Debt**
A lack of documentation for data models and projects is a common and highly expensive mistake. It not only creates dependency on specific individuals to understand what was built, but it also relies on memory to trace steps when something goes wrong, like when the same metric shows different results in two different reports. Data quality is highly dependent on documentation best practices, and unfortunately, realizing this too late can be fatal to a project.
7. **The "Ticket Factory" Trap**
Handling incoming tickets from different business units, whether they are quick, simple tasks or complex requests that require deep engineering, ends up eating up most of the data team's sprint. The goal shifts from delivering value to merely keeping things running and ensuring data is clean for consumption (in other words, constantly firefighting). Building quick workarounds and data patches to meet urgent requests is a very common mistake that avoids addressing the root cause, which is often found in the initial data infrastructure.
8. **Difficulty Measuring Impact**
All the mentioned dysfunctions make it incredibly hard to measure the data team's ROI, since most engineering hours are spent keeping pipelines running instead of developing strategic data products. The team starts being seen as a cost center because of the difficulty in measuring the business impact of the analytics delivered and the low capacity to work on long-term initiatives, as short-term fires are always prioritized.

## Three Levels of Analysis: **Strategic**, **Hands-on**, and **Process-oriented**

### Strategic View

When looking at how to build a data department from scratch through a strategic lens, a few relevant questions stand out. First: what is the actual role of the data team, what tasks will they perform, and how will this role evolve over time?

It is important to remember that this varies depending on the company, and the data team's activities will shift based on what capabilities are enabled for other departments. The data stack and processes to be built must be clearly defined, and agility, simplicity, and continuous improvement must be core values of the data team.

### Hands-on View

You only need **4 tools** in your modern data stack:

- An ingestion tool to extract/collect data;
- A data warehouse to store information in an analytical environment;
- A transformation tool to model data and deliver business value;
- A BI tool to visualize data and drive decision-making.

### Process-oriented View

To implement all this, you need to:

- Solve the Cold Start: begin with small, incremental wins and deliver quick analytics to improve the workflow of each department.
- Gain clarity on where your effort is going: track the time and engineering effort dedicated to each business unit, whether through a specific tool or a simple spreadsheet.
- Focus on business impact: after delivering initial analytics to different areas, scale back ad-hoc requests to maintenance mode, and set one major quarterly data project focused on a north star metric that tracks the data team's ROI (e.g., impact on sales conversion).

Every minute spent dealing with **data quality issues** is a minute lost solving business problems. For a starting data team, this, more than anything, defines **success** or failure.

## How We Do It at Erathos

- Erathos as the data ingestion and pipeline solution
- Data loaded into BigQuery, with transformations managed via dbt
- Looker Studio as the visualization and BI tool
- We don't build anything that isn't strictly necessary
- Our weekly standups ensure we keep track of clear, well-defined metrics integrated into our daily routine