By Maryam Ilyas
In a world where data teams are scaling fast and GenAI initiatives demand ever more robust and business-aligned data models, the role of the Analytics Engineer has never been more crucial (or more misunderstood). Whether you're hiring for the role, growing your team, or improving how you use data, understanding this role can make a big difference. As an active analytics engineering consultant for the past five years, I’ve come across the same misconceptions time and again. Some of them sound trivial, but they can lead to misaligned expectations or missed opportunities for collaboration across data roles. In this post, I unpack five of the most common misconceptions, and why getting them wrong might be holding your team back.
Let's dive in
- Misconception 1: You’re only considered an analytics engineer if you’ve used dbt in at least one of your projects. This misconception might have some basis, as every time I Google “analytics engineer,” the first hit I get is a link to the dbt website where they explain the role of analytics engineering (it’s a great read: What is Analytics Engineer by dbt). While dbt has definitely played a major role in popularizing the term in recent years, they weren’t the first to introduce it. That credit goes to Michael Kaminsky, who wrote this article in 2019: The Analytics Engineer by Michael Kaminsky first time the term “Analytics Engineer” was introduced and clearly explained (also very much worth the read). So while dbt has become nearly synonymous with the role today, analytics engineering as a practice existed before it , and isn’t defined solely by using dbt. A good example is how Microsoft describes the Analytics Engineer role - and even offers a certification for it (the DP-600) - which doesn’t require any knowledge of dbt at all.
- Misconception 2: Analytics engineering is just data engineering with a fancy name. It’s true that both roles work closely with data and often share similar technical foundations. But while data engineers are more focused on building scalable data platforms, creating ingestion pipelines, and are usually more technically skilled, analytics engineers sit closer to the business. They focus on translating business needs into clear data requirements, shaping data models, writing transformation logic, and applying business-focused data quality checks. This helps data engineers build the right data models, without having to rework the whole model every time the business changes its mind about what they want to see in reporting.
- Misconception 3: You don’t need data analysts if you have an analytics engineer on your team. It’s a mistake to think analytics engineers can fully replace data analysts. While analytics engineers are skilled in applying software engineering best practices, like; modular code, version control, CI/CD, and automated testing, they’re not meant to take over the analyst’s role. Data analysts bring deep business knowledge, strong stakeholder relationships, and the storytelling ability to turn data into actionable insights. Analytics engineers make sure the data behind those reports is clean, reliable, and structured to support the right conclusions. These roles complement each other - they’re not interchangeable.
- Misconception 4: Analytics engineers are only useful in a Data Mesh team structure. Data Mesh setups definitely benefit from having analytics engineers, especially because the shift to Data Mesh brings a cultural change, one that requires data engineers and analysts to collaborate more efficiently and effectively. But that need isn’t unique to decentralized teams. Whether in centralized or decentralized structures, analytics engineers play an essential role in bridging the gap between data engineering and analytics, helping both sides collaborate more smoothly.
- Misconception 5: Analytics engineering is just SQL writing. Analytics engineering isn’t just about creating data models or writing transformations in SQL based on business requirements. What makes someone an analytics engineer isn’t the tools or programming languages they use, it’s the way of working. Analytics engineers bring software engineering practices into analytics workflows: things like CI/CD, version control, and modular code design. So instead of writing a stored procedure for one dimension and then copy-pasting it for others, analytics engineers build reusable templates and work in a modular way. This creates more reliable pipelines and removes deployment risks. It’s that engineering mindset focused on scalability, structure, and reliability, that sets analytics engineers apart.
If any of these misconceptions ring true in your organization, it might be time to rethink how you’re defining and structuring your data roles. Investing in the right understanding (and the right talent) can lead to greater speed, quality, and alignment between data and business goals
👉 Curious how analytics engineering could boost your team’s effectiveness or where your setup might be falling short? Reach out directly to Maryam or get in touch with the team at dataroots to explore how we can help.