Summary
Jason Ganz makes the case that analytics engineering -- not data science -- is the discipline with the most transformative potential for most organizations. The mental model: analytics engineering is infrastructure that makes everyone else more effective. It is the unsexy plumbing that lets data analysts and data scientists do their jobs without drowning in data quality issues and metric definition debates.
Key ideas:
- AE = analyst domain knowledge + software engineering best practices. The role sits at the intersection, bringing testing, version control, and CI/CD to the analytics layer.
- Data science without data infrastructure is doomed. Smaller orgs that cannot invest millions in infrastructure see data science initiatives fall flat. AE addresses the foundation.
- Standardized metrics in code. Instead of arguing over definitions in meetings, analytics engineers encode them in dbt models. The codebase is the data dictionary.
- Demand grows with capability. Borrowing from Erik Bernhardsson's argument about software engineers (and the ATM paradox): as analytics becomes easier to produce, demand for analysts will increase, not decrease.
- Every org is unique. The way data needs to be understood is specific to each organization, which means every company needs analytics engineers -- this is not a role that can be fully outsourced or automated away.
The "demand grows with capability" insight connects directly to [[06-reference/concepts/skills-as-building-blocks]] -- as foundational skills (AE tooling) improve, higher-order skills (strategic analysis) become the new bottleneck, creating more demand for people who have them.
For [[01-projects/phdata/index]], this is a positioning argument: consulting clients do not need a data scientist first, they need analytics engineering foundations. The note about legacy data systems needing AE patterns at scale is the exact work phData does -- bringing modern data practices to enterprise environments.
This pairs with [[06-reference/2026-04-03-analytics-at-a-crossroads]] (Benn Stancil's piece on whether AE liberates or absorbs analysts) and [[06-reference/2026-04-03-data-maturity-processes-tools]] (AE is the capability that enables the jump from Data Informed to Data Driven in the Reforge framework from [[06-reference/2026-04-03-scaling-data-informed-driven-led]]).
For [[01-projects/data-marketplace/index]], the "every org is unique" observation is both a challenge and an opportunity -- generic datasets have limited value, but well-modeled, context-rich data products could command a premium.
Open Questions
- If AE is the foundation, what is the minimum viable AE setup for a 5-person startup? Is it just dbt + a cloud warehouse?
- The "unique to every organization" point has been called the analyst trap (tribal knowledge is non-transferable). Does AE actually solve this, or just move the tribal knowledge from people's heads into code that is equally hard to transfer?
- As AI coding assistants improve, does the AE role get automated before it fully matures, or does it become even more important as a governance layer?