dbt: why this is a question of team discipline, not tool selection
dbt has become a standard for data transformation. But it only creates value when a team changes how it works with data logic - not just by installing it.
When someone asks me "should we adopt dbt", my first response is almost always a question: "How is your data transformation organised today?" Because dbt is not a replacement for a broken process. It is a tool that works well when a team is ready to accept a certain discipline.
In short: dbt is a way to describe data transformation logic in SQL, keep that logic in git, test it, and document it. That sounds modest. But in practice it changes several important things at once.
What dbt is in two sentences
The tool lets you write SELECT statements that create tables or views in your data warehouse. You write the logic, dbt manages the execution order, dependencies between models, and lets you run data tests - checking for duplicates, unexpected nulls, key mismatches between tables.
The crucial point: this logic lives in code, not inside an ETL tool's UI, not inside one analyst's head, and not in an Excel file on a shared drive.
Where dbt actually creates value
First - transparency. When transformations are described in code with a change history, anyone on the team can understand where a specific metric comes from. This breaks the monopoly of "the person who knows how it's calculated".
Second - reproducibility. The same calculation gives the same result, because the logic is fixed and tested.
Third - testing. When data has tests, a broken pipeline is visible before the report user sees it.
Fourth - documentation. dbt generates documentation from the code. This does not replace a live conversation about metrics, but it creates an artefact to refer back to.
Why adoption often falls short of expectations
The most common mistake is porting what was written before into dbt without rethinking the structure. If a company had fifty tangled SQL queries with no documentation, dbt turns them into fifty tangled models in a repository. The form gets cleaner; the substance does not.
The second mistake is not changing ownership. If one person writes and one person reviews, dbt adds no value compared to "just SQL in a folder". The value appears when several people work with the same data codebase and have agreed on shared rules.
The third mistake is using it without tests. dbt with tests is data quality control. dbt without tests is just another way to store SQL.
How to decide if the team is ready
A few diagnostic questions:
- Is there more than one person writing and maintaining transformations today?
- When the logic for calculating a metric changes, is that recorded anywhere besides someone's memory?
- Is there a code review culture in the team, even just for application code?
- Who will own and maintain the dbt project a year from now?
- Is there a data warehouse (Snowflake, BigQuery, Redshift, or similar) that dbt will run against?
If most of the answers are yes, the transition will be productive. If not, the organisational questions should come first. The tool will not solve them for you.