Mistakes I made as the head of analytics (and what I’d do differently now)

The shift toward transformation-as-code fundamentally changes how we architect data pipelines, and learning from real failures matters more than theory. When analytics leaders struggle with dbt adoption, it's rarely about the tool itself—it's about treating transformation as an afterthought rather than a first-class concern in your data stack. I've seen teams spin up dbt projects without establishing proper governance layers, lineage visibility, or test coverage conventions, only to face trust issues downstream. The architectural implication is clear: transformation governance must be baked into your CI/CD pipeline and version control from day one, not retrofitted. This connects to the broader shift where business users increasingly demand transparency into data quality and logic, making analytics engineering as critical as infrastructure engineering. My concrete takeaway is this—before scaling dbt usage across your organization, invest in establishing a reusable project structure, enforce dbt tests as contract mechanisms, and build observability into your DAG. The teams winning with modern transformation are those treating their dbt projects like production code, with pull request reviews, staging environments, and clear ownership models.