The dbt governance framework that cut new project setup time 70%

At dbt Summit 2026, Kaizen Gaming's principal analytics engineers Thomas Antonakis and Stefanos Nikolaou, together with senior analytics engineer Akis Zervas, walked through the governance framework they built to keep dbt consistent across six analytics engineering domain teams. Kaizen Gaming is the company behind the sports betting and casino brand Bettano, operating in 25 markets across four continents with more than 15 million active users and 40% year-over-year growth.

As the organization grew, each of the six domain teams had adopted dbt at its own pace and on its own terms. On the surface that looked like flexibility. In practice it produced three expensive patterns.

The same source data got staged independently in as many as six places with no single definition anyone could point to. Shared infrastructure got copy-pasted instead of reused. And leadership had no visibility into test coverage or investment payoff, while onboarding a new hire meant relearning conventions that lived in several different people's heads.

Rather than build a full platform team, the two principals picked exactly three layers to centralize and left everything else with the domain teams. The first is a foundational models project (the speakers call it their Core project) holding company-wide spine models as lightweight views with no orchestration overhead, referenced by every downstream project.

The second is an internal utilities package of shared macros, tests, and configuration, propagated to subscriber repos automatically through a subscription mapping file, so a single merge replaces what used to take 15 manually opened pull requests. The third is infrastructure and AI tooling as code: dbt project and environment configuration moved out of the UI and into Terraform using the dbt Labs Terraform provider, with CI scoped only to affected projects, merge and apply rights limited to the two principals as code owners, and a separate manual approval step before anything applies to production.

On the AI side, the team built a central enablement repository with roughly 16 analytics-engineering-specific skills wired into both their warehouse and dbt's MCP server, so every engineer's AI agent starts from the same context regardless of which tool they use.

The results they shared: new project lead time down 70%, a $10,000 annualized savings from templated project setup, roughly 15x time leverage on shared configuration fixes through the utilities package, and AI onboarding for new hires down from a multi-day, ad hoc process to about 30 minutes. Fifteen merge requests against the shared repos in the 30 days before the talk were offered as evidence the framework is an active system, not a document nobody opens.

The speakers closed with a simple decision rule for what to centralize: pull something into the shared layer when no single domain truly owns it, when every team would otherwise solve the same problem independently, or when the inconsistency is costly at the organization level rather than being real business logic. Leave it with the domain team when it encodes actual business judgment or when getting it wrong only affects one team.

Asked about access control for AI agents, the speakers said all of their analytics engineers share the same access level today, and that authentication for agents connecting through GitLab, Atlassian, or Databricks MCP servers is handled centrally by the platform team via SSO. As one of the speakers put it, "governance and autonomy do not need to be in conflict."

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →