Analysts and dbt

Engineering practices do not settle analytical meaning

There is a real reason people associate dbt with engineering. A dbt project is code in Git. Changes are reviewed, tested and deployed through controlled environments. Models have dependencies and production schedules. Someone has to operate the platform, manage access and recover it when it fails. Those are engineering concerns, and pretending otherwise would make the system less safe.

But dbt is not only the platform that runs the SQL. It is also where the organisation records what its data means. Which diagnoses define a register, what counts as a current relationship, which date should be used for recency, what one row represents and which population an output includes are analytical and domain decisions. Engineers can help make those decisions reproducible; their job title does not give them sole authority to make them.

Analysts already make these decisions in worksheets, stored procedures and dashboards. Contributing through dbt does not turn the decisions into a new category of work. It gives them a shared home, exposes their dependencies and puts them through review and testing before the organisation relies on them.

Hats, not badges

A person normally has a strongest discipline, but useful analytical work often requires more than one hat. An analyst may bring in a dataset, define a tested model, build the output that uses it and then investigate a failed production run. An engineer may explore model outputs to diagnose an ingestion problem. A clinical lead may challenge an unexpected result and change the requirement. The work moves between modes even when the people do not change.

Rigid hand-offs make the work slower and less reliable. If every analytical definition becomes a ticket for an engineer, the person writing the code is separated from the person who understands the question. If every platform or information-governance decision is left to an analyst working alone, specialist risks are missed. The aim is to bring the required expertise into one reviewable workflow.

Different work needs different authority

A better boundary than “analysts use dashboards; engineers use dbt” is to ask what kind of decision is being made and who has the knowledge and authority to make it. Several people may contribute to one change.

These are centres of gravity, not permissions attached to job titles. An analyst who understands the project can safely change a shared reporting model. An engineer who does not own a clinical definition should not silently settle it. Review brings the other hats to the change when its consequences require them.

Analysts can work across the analytical system

Analysts are not merely downstream consumers of this dbt project. They are often end-to-end builders of analytical products, and the project should help them work safely across the lifecycle rather than forcing artificial hand-offs. Depending on the work, that might mean:

• bringing data in through an established ingestion route, then cleaning, linking or indexing it so that it is usable downstream;
• translating a question into a subject, population, grain and time relationship, then finding and extending the relevant models as tested dbt models or, where target-lag refresh is appropriate, a Snowflake dynamic table;
• composing shared models into a governed published product, including disclosure controls and the dashboard or application through which it is used; or
• reviewing, validating and following a change into production, including investigating failures in the models they understand.

No analyst is expected to perform every task on every change. The point is that analytical work does not stop at the entrance to dbt. Git makes decisions reviewable, tests record expectations and the DAG exposes dependencies. These practices let other people inspect and rely on analytical judgement.

What an analyst is not expected to own alone

Participation does not mean operating every part of the platform. An analyst may use an established ingestion route or build under agreed Snowflake conventions; changes to the ingestion platform, warehouse-wide permissions, deployment architecture, service credentials or shared cost and security controls need engineering support. Clinical definitions, legal bases and disclosure policies need domain and governance authority, even when the analyst implements them. Contributors should recognise when a change crosses these boundaries and involve the right reviewer early.

Why this gives analysts more leverage

A worksheet can answer one question quickly, but the analyst usually pays the source-cleaning and interpretation cost again when the next question arrives. A well-designed dbt change leaves behind a tested model that other analysts can find, understand and compose. Over time, new work starts nearer the decision and farther from messy source mechanics.

That is why analyst participation is essential in a mature project. The value is not simply that more people can write models. It is that the people closest to the questions can improve the shared domain model as they answer them. The next lessons explain the data and conventions they are contributing to; later, finding models and designing models show how a request becomes a safe piece of project work.