Six Steps To Smarter Analytics: An Engineer’s Guide To The ADLC

When I think about analytics development, it’s impossible to separate the process from its purpose. The goal isn’t just to build data models or create dashboards—it’s to deliver something reliable, scalable, and valuable to the people relying on it. To do that, you need a structured approach that ensures every step adds to the bigger picture. That’s where the Analytics Development Lifecycle (ADLC) comes in.

The ADLC, named and popularized by Tristan Handy of dbt Labs, is a process that combines people, tools, data, and standards to create reliable, scalable, and trusted analytics systems. But the ADLC isn’t just a process; it’s a way to create order in a field that can often feel chaotic. It’s about breaking down the journey from raw data to actionable insights into clear, manageable stages: requirements gathering, data exploration, data cleaning and model building, testing, deployment, and iteration.

In this article, I’ll walk you through each stage of the ADLC as I’ve experienced it in my own work as an Analytics Engineer. I’ll share practical insights on what works, what doesn’t, and the challenges you’re likely to encounter at each step. Whether you’re looking to fine-tune your approach or gain a fresh perspective, this breakdown is designed to connect with the realities of our work as analytics engineers.

Stage 1: Requirements gathering

Let’s start with the most important stage: requirements gathering. This is where you sit down with stakeholders and figure out exactly what they need. What are they trying to solve? How will they measure success? Are there dependencies or deadlines? This phase is about getting as much clarity as possible, and the more time you spend here, the easier the rest of the process will be.

For example, maybe your Product team needs to understand how users are using a specific feature of a product. Or, maybe your marketing team needs insights into how a piece of content is performing.

One thing I’ve learned is that requirements are rarely static. Stakeholders may change their minds or priorities might shift — and they don’t always think to update you. For example, a change in strategic goals (focus from customer acquisition to customer retention) or new user behavioral insights might alter the requirements of a project. That’s why I’ve made it a habit to check in regularly, even if it’s just a quick async message, to make sure nothing has changed.

Building a good relationship with your stakeholders is also key. If they trust you, they’re more likely to communicate openly, which can save you a lot of frustration later.

Stage 2: Data exploration

Once you know what your stakeholders need, the next step is to figure out if you have the right data. This is where data exploration comes in. You’re essentially trying to answer a few questions: Do we already collect this data? If so, where is it? Is it in a database? A model? A random spreadsheet somewhere? 

Tip: You don’t want your data living in ungoverned spreadsheets. Sigma gives you a spreadsheet UI with a direct connection to live cloud data, so you don’t have to worry about security or governance.

If stakeholders can see the raw data and how it’s structured, it gives them a better understanding of what’s possible—and what isn’t.

One challenge I’ve seen other analytics engineers face is data discoverability. In many cases, the data already exists, but it’s not documented or easily accessible. That’s why you should create logical folders to organize datasets, workbooks so that everyone can find them easily and add clear descriptions to datasets and workbooks to explain their purpose. But regardless of how mature your analytics setup is in terms of data discoverability, you should make it a habit of regularly exploring what’s available.

I’ve also found that involving stakeholders during this phase can be helpful. If they can see the raw data and how it’s structured, it gives them a better understanding of what’s possible—and what isn’t.

Tip: If you’re using Sigma, you can view endorsed workbooks, explore workbooks created by top creators or Ask Sigma to see recommended workbooks and analysis to discover more data easily.

Stage 3: Data cleaning and model building

Data cleaning is where you roll up your sleeves and get to work. This stage is all about making the data usable by cleaning up errors, removing test records, and standardizing formats. For example, if you’ve worked with Salesforce data, you’ve probably seen fields with the “__c” suffix. That doesn’t mean much to the average user, so you have to transform it into something more readable. Tools like dbt help with making the data transformation process seamless. 

Once the data is clean, the next step is to build the data model. This is where you take everything you’ve learned so far and structure the data to answer the questions your stakeholders care about. Depending on the business logic and the problem you’re trying to solve, you can combine multiple staging models in dbt to build mart models that are tailored to the business needs. These mart models can be explored in Sigma which makes it accessible to non-technical business users who may not know SQL or may not be familiar with a tool like dbt. 

Tip: Sigma lets you integrate dbt jobs with Sigma so you can access the docs and metadata generated from the dbt jobs directly in Sigma. 

Stage 4: Testing

Testing is where you validate everything you’ve built so far. For me, this involves creating a development version of the model and sharing it with stakeholders. I always say, “Don’t wait until it’s perfect—get it in front of people early.”

This stage is less about finding technical bugs and more about making sure the model aligns with what the stakeholder actually needs. Sometimes, even if you had a great requirements-gathering session, you might realize during testing that you misunderstood something. It’s better to catch that now than after deployment.

Don’t wait until it’s perfect—get it in front of people early.

Tip: Sigma’s version control allows you to roll back to a previous version of a workbook or dataset. This is especially useful if new configurations, filters, or formulas during testing cause discrepancies in results.

Stage 5: Deployment

Deployment is when you make the model available to everyone who needs it. At this stage, your focus shifts to ensuring the system is reliable and scalable. The model should be intuitive enough for non-technical users to interact with it without constant help from the data team.

In Sigma, you can define a dataset, which serves as a reusable building block for your data model. You can also define metrics which are dynamic and reusable calculations specific to a data source. Metrics help ensure consistent and accurate calculations and any business user across your organization can leverage these approved metrics. 

But just because the model is deployed doesn’t mean the work is done. That’s where iteration comes in.

Stage 6: Iteration

Iteration is about continuous improvement. Once a model is live, I keep an eye on how it’s performing and listen to feedback from stakeholders. Are there new questions they need answered?

One thing I’ve learned is that iteration is an ongoing process. You’re never really “done.” Business needs evolve, and so should your models. Being adaptable is key to staying relevant and useful to your stakeholders.

Making the ADLC work for you

For me, the Analytics Development Lifecycle (ADLC) is more than just a framework—it’s how we approach analytics as a collaborative and iterative process. Throughout every stage, collaboration is key. As a data team, we don’t want to work in silos. We’re enabling stakeholders across the organization—whether they’re in sales, marketing, product, or engineering—to make better decisions. And when they succeed, we succeed.

Building trust is another crucial piece of the ADLC. As I’ve often said, trust in data takes time to build but can be broken in seconds. That’s why it’s important to focus on creating reliable systems, standardizing calculations, and ensuring everyone has confidence in the outputs.

Trust in data takes time to build but can be broken in seconds.

Scalability is also at the heart of a mature ADLC. It’s not just about answering today’s questions—it’s about creating systems that can grow with the organization. From reducing repetitive ad-hoc requests to enabling self-service data exploration, scalability makes our workflows more efficient and sustainable.

Finally, iteration is what makes the ADLC a living, breathing process. Once a model is live, the work isn’t done. Stakeholder needs change, business goals evolve, and it’s our job to ensure the systems we build keep up. That constant improvement is what transforms analytics into a core function of the business, not just a tool or a process.

The ADLC has helped me approach analytics development with more clarity and purpose. It’s a way to ensure that the systems we create are reliable, scalable, and trusted—so we’re not just building data models but empowering the people who rely on them.

‍