Leading an analytics and data engineering team taught me more through missteps than successes. Now, advising teams on dbt implementations, I see my own past errors repeated. Here’s a technical breakdown of where we went wrong.
We treated our data platform as a static asset. After an initial dbt migration, we stopped tracking new features. The team kept building ‘faster horses’—complex workarounds within known patterns—instead of evaluating if new platform capabilities, like dbt Mesh for multi-project architecture, offered fundamentally better solutions. We maintained a monolithic monorepo when Mesh could have provided domain teams autonomy with clear contracts, reducing bottleneck dependencies.
Our initial data estate became sacrosanct. We performed a lift-and-shift migration, moving everything—including unowned, unused models—into dbt. This created immediate technical debt. The correct approach is to migrate only what has clear ownership and purpose, then immediately refactor the layers to fit current needs, not preserve the old shape.
Orchestration was schedule-bound, relying on cron. We should have adopted event-triggered job execution via API from the start, modeling dependencies rather than timed schedules. This design would have positioned us to adopt features like state-aware orchestration seamlessly, instead of requiring a painful rewrite.
We managed dbt Cloud jobs manually. We overlooked the dbt Terraform provider, failing to define jobs, permissions, and environments as code. This led to configuration drift and a lack of reproducibility. For any scaled deployment, infrastructure-as-code is non-negotiable.
Governance was deferred until it became a crisis. We built models without owners, neglected the dbt style guide, and under-invested in documentation and testing. This created a fragile data product layer. This neglect has a new cost: AI tools like those using dbt’s MCP server require rich, reliable context. Without governance, you’re automating chaos.
Finally, I traded a ‘fail-fast’ engineering mentality for perceived stability. As a lead, I avoided small, time-boxed experiments. This eliminated the iterative learning that allows teams to adapt. Engineering leadership requires creating safe spaces for technical experimentation, not eliminating it.
The pattern across all errors was reactivity. We learned about capabilities only after needing them. The antidote is institutionalizing exploration: assign team members to track specific tools and hold regular sessions on emerging patterns. The compounding returns come from building ahead of the curve.
Source: dbt Labs Blog