Analytics Engineering Practice
Analytics Engineering is the discipline — pioneered by Tristan Handy at dbt Labs and operationalized at companies like Hightouch — that bridges raw data engineering and downstream business consumption. Analytics engineers transform raw warehouse tables into clean, modeled, business-meaningful 'marts' using software engineering practices: version control, code review, testing, CI/CD, and modular SQL (typically dbt). Their work product is the trustworthy, well-named, well-documented dataset that an analyst, a dashboard, or an ML model can rely on. KnowMBA POV: analytics engineering is the role that bridges the gap data engineers and analysts both fail to — DEs care about pipes, analysts care about answers, and AEs care about the trustworthy semantic layer in between.
The Trap
The trap is treating analytics engineering as 'senior analyst work.' It is not. Senior analysts are great at finding insights in messy data; analytics engineers build the systems that make data un-messy. Promoting your best analyst into 'analytics engineer' without giving them the engineering toolkit (git, CI, testing, modular code) just produces a stressed analyst who now also breaks production dashboards. Hire from the analyst-with-engineering-instinct talent pool, not the 'fastest SQL writer' pool.
What to Do
Establish the AE practice with three artifacts: (1) A dbt project (or equivalent) with staging → intermediate → marts layering — never let business logic touch raw tables. (2) A testing standard — every mart has at least uniqueness, not-null, and accepted-values tests. (3) A code review policy — no one merges to production marts without a peer review. Once these three exist, the practice can scale. Without them, you have 'people who write SQL' but not an analytics engineering practice.
Formula
In Practice
Hightouch — itself a beneficiary and accelerant of the analytics engineering movement — built its entire product strategy around the assumption that companies have a dbt-modeled warehouse as the source of truth. Their reverse ETL product activates data FROM the warehouse INTO operational tools (Salesforce, Marketo). This product wouldn't exist without the analytics engineering practice that produces clean, modeled tables to activate. dbt Labs (Tristan Handy's company) coined and popularized the term 'analytics engineer' starting in 2019, and by 2024 the role was the fastest-growing job title in the data field.
Pro Tips
- 01
The dbt staging → intermediate → marts pattern is not arbitrary. Staging cleans column names and types (1:1 with source). Intermediate joins and calculates. Marts expose the final business-grade tables. Following this pattern makes refactoring 10x easier and onboarding 5x faster. Skipping it produces 800-line SQL files no one can change.
- 02
Document marts where they live (dbt yaml docs, Atlan, DataHub) — not in a separate Confluence page that goes stale in 30 days. Documentation that lives next to code stays accurate; documentation that lives elsewhere becomes archaeology.
- 03
Hire AEs who have shipped production code (any language) before. The mental model of 'this code will run again next week without me babysitting it' is the single biggest differentiator from analyst work.
Myth vs Reality
Myth
“Analytics engineers are just dbt operators”
Reality
dbt is a tool. Analytics engineering is a discipline of treating analytics code like software: tested, reviewed, modular, versioned, observed. Companies do analytics engineering with dbt, SQLMesh, custom orchestrators — the tool matters less than the practice.
Myth
“If you have a semantic layer, you don't need analytics engineers”
Reality
The semantic layer SITS ON TOP of modeled marts. Someone has to build and maintain those marts. The semantic layer is the API; analytics engineering is the application code behind it.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Knowledge Check
Your team has 12 dashboards, each with its own SQL definition of 'monthly recurring revenue.' Three definitions disagree. What is the analytics engineering fix?
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
dbt Labs (Origin of the Term)
2016-Present
Tristan Handy (founder of dbt Labs, originally Fishtown Analytics) coined the term 'analytics engineer' to describe the role his consulting firm kept hiring for: someone who could write modular, tested SQL inside a software engineering workflow. dbt (the open-source tool) became the de facto stack for the role. By 2024, 'analytics engineer' was one of the fastest-growing job titles on LinkedIn in data, with thousands of companies running dbt in production. The role's emergence formalized a discipline that had been done informally and badly for decades.
dbt Adoption (estimated)
30,000+ companies
Role LinkedIn Listings (2024)
10,000+
Industry Acceptance
Standard role at most data-mature companies
Naming a role creates the role. 'Analytics engineer' was always needed; once it had a name, companies could hire for it, train for it, and structure teams around it.
Hightouch
2018-Present
Hightouch built its reverse ETL product on the bet that companies would standardize on dbt-modeled warehouses as the source of truth — i.e., that analytics engineering would become standard practice. The bet paid off: as AE adoption grew, so did Hightouch's TAM. The company became one of the fastest-growing 'modern data stack' tools, and its product strategy explicitly assumes that customers have an analytics engineering team producing trustworthy marts.
Founding Bet
Modeled warehouses as source of truth
Funding Raised
$50M+ (Series B)
Strategic Premise
AE practice is enterprise standard
When tooling vendors build entire products on the assumption your role exists, the role has crossed from emerging to essential.
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Analytics Engineering Practice into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Analytics Engineering Practice into a live operating decision.
Use Analytics Engineering Practice as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.