Analysts and dbt

Analytical decisions still need domain knowledge

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 makes them available for review and testing before others rely on them.

One change can need several kinds of expertise

Suppose a register misses an agreed inclusion criterion. An analyst can investigate the records, explain the mismatch and propose a model change. The domain owner confirms the intended criterion. An engineer may help if the change also affects a shared ingestion rule or requires a new access arrangement. Those contributions can meet in the same pull request.

The analyst does not need to hand over the whole task because it uses dbt. Nor should the author settle an uncertain clinical definition alone. Bring in the expertise needed for the decision, while keeping the requirement, implementation and validation evidence together.

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 typical contributions. Job titles do not settle who can make a particular decision. 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.

Participation grows with familiarity

A first contribution may be a description, a test or a small staging correction. Later work may define a shared measure, assemble a published dataset or investigate a production failure. These are all parts of analytical work, and each can be reviewed at an appropriate scope.

You are not expected to know the whole platform before contributing. You are expected to understand the change you propose, explain its limits and involve another person where the decision needs their authority.

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.

The following data chapter introduces the sources and identifiers. The later discovery, design and review chapters show how to turn your understanding of a question into a change the team can inspect.