When do we actually need a data team — and who should we hire first?

The short answer

You need a data capability when two things are true at once. First, decisions are being delayed, or they are being made on numbers people do not trust. Second, the work has become recurring rather than one-off. A data capability is simply the reliable ability to turn raw data into answers people act on.

The first move is not always a hire. A permanent hire is a large, slow, fixed commitment. If the work is still lumpy, or its shape is not yet clear, a scoped project or an embedded team often gives you the same capability sooner and with less risk. Hire when the work is continuous, specific to your business, and you can attract and keep the right person. Until then, borrow the capability and learn what you actually need before you commit to headcount.

What this usually looks like

The shift rarely arrives as a single event. It shows up as symptoms, and they tend to appear together.

• One analyst is overloaded, and questions now wait in a queue.
• Spreadsheets keep multiplying, and each rebuild takes a little longer than the last.
• Reports arrive late, and the decision has often moved on by the time they land.
• Different teams quote different figures for the same thing, and no one owns the definition.
• Workbooks have become load-bearing. A renamed tab or a broken formula can take out a board report.

One or two of these is normal for a growing company. All of them together mean the setup has been outgrown. At that point, continuing to muddle through costs more than fixing it. You simply pay the cost in delayed decisions rather than in an invoice.

Start with these questions

Before you write a job advert, work through a short decision tree. Each answer points to a role or a delivery model, not straight to a hire.

The roles, in plain English

Three roles do most of the work, and they are often confused. Here is each one in plain English first, then precisely.

A data analyst answers questions. In plain terms, they take a business question and come back with a defensible number, a chart, or a report. Precisely, they explore data, build and maintain reports and dashboards, and work directly with stakeholders. They sit closest to the decision.

An analytics engineer makes the data trustworthy. In plain terms, they turn messy source tables into clean datasets everyone can rely on. Precisely, they do modelling: the work of shaping raw source tables into clean, tested datasets with a clear, agreed meaning. They own the semantic layer, which is the single place where each metric is defined once, so every report uses the same definition of “revenue” or “active customer”. They also write tests that fail loudly when the data is wrong. This is the role most growing companies are missing.

A data engineer moves data reliably. In plain terms, they build the plumbing. Precisely, they build and run pipelines, which are the automated paths that move data from source systems into where it is used, and they handle integration and orchestration. Orchestration is the scheduling and sequencing of those jobs, so each step runs in the right order and a failure is caught rather than passed silently downstream. This role earns its keep once volume and reliability demands are genuinely high.

Alongside these sits BI capability. BI stands for business intelligence, which is the tools and practice of building and reading reports. Sometimes this is a dedicated role. More often, at an early stage, the analyst covers it.

You do not have to add any of these through a permanent hire. A scoped project delivers a defined build with a clear end, such as a first warehouse or a reporting rebuild. An embedded or fractional team is a small external group that works inside your business, giving you senior capability now without a full internal team yet. That is what an embedded data team is for: consistent progress while the shape of the work is still settling.

How the work actually sequences

The work has a natural order, and ignoring it is expensive. More dashboards do not help if the data beneath them is wrong. So trustworthy, modelled data usually has to come before more reporting, not after it.

For most companies the sensible sequence is: get answers with an analyst, then make those answers trustworthy and repeatable with analytics engineering, then harden the pipelines with a data engineer once managed tools can no longer keep up. Each layer stands on the one before it.

The common mismatch is hiring against the title rather than the constraint. A senior data engineer hired to “build reports” will build excellent infrastructure that answers no one’s question. A junior analyst asked to fix pipelines will be out of their depth and unsupported. Both outcomes are avoidable. Match the hire to the layer that is actually blocking you, not to the role that sounds most foundational.

The piece a growing company most often skips is the analytics engineer. Their job is small, owned, and testable. As an illustration, a single model that defines “active customer” once, with a test attached, so every report reads the same figure:

-- models/marts/active_customers.sql
-- One definition of "active customer", read by every report.
select
    customer_id,
    max(order_date) as last_order_date
from stg_orders
group by customer_id
having max(order_date) >= current_date - interval '90 days'

-- test: active_customers.customer_id is unique and never null

The value is not the SQL. It is that the rule lives in one place, the test fails the moment two rows share a customer, and no team can quietly invent its own version of “active” in a private spreadsheet. That is the trust an analytics engineer produces, and it is why the role usually comes before more dashboards.

What good looks like

What “right-sized” looks like changes with stage. As a hypothetical progression:

• Early. One capable analyst, or a fractional analyst, answering questions against a tidy source or two. No warehouse and no pipelines. This is enough for a while, and stretching past it early wastes money.
• Growing. An analyst plus analytics engineering, so definitions are owned and reporting is trustworthy. Managed connectors move the data; your effort goes into modelling and definitions, not custom plumbing.
• Scaling. A small team where analysis, modelling and engineering are distinct roles, with clear ownership of definitions and reliability, and a manager who sets priorities.

The signal that a stage fits is quiet. Numbers are trusted. Answers arrive before the decision does. No single person’s holiday stops reporting. Right-sized is not the largest team you can justify; it is the smallest team that keeps decisions moving.

Common ways this goes wrong

• Hiring too early. A senior specialist with too little well-defined work spends a year underused, and may leave out of boredom before the real work arrives.
• Hiring the wrong first role. Building infrastructure before there is a question that needs it is the classic version — impressive plumbing, no answers.
• Hiring one person to do three jobs. Analyst, analytics engineer and data engineer are different disciplines. One generalist expected to be all three will do all three thinly.
• Leaving no one to manage them. A first hire with no manager, no clear priorities, and no one to unblock them will stall, however capable they are.
• Under-levelling the role. A junior with no senior to learn from plateaus, and the definitions that no one owns stay disputed.

Too late is usually the costlier mistake, because you pay in decisions made on bad numbers rather than only in salary. But both mistakes are real, and both are avoidable by matching the move to the constraint.

When a hire is not the answer

Not every data problem is solved by adding a person. Some are solved by a better tool, a tidier definition, or a direct connection from a BI tool to the source. A hire, or a team, becomes the right answer only when the work has become a system to run rather than a task to finish — when it recurs, spans systems, and needs a clear owner. If you want an outside read on whether you are at that point, how we work sets out how we scope it before anyone commits to headcount.

A decision guide

Read from the constraint you actually have, not from the org chart you imagine. The first move follows the gap.