But nobody uses it.

Or worse, people build workarounds around it.

So you assume the problem is the tool. Or the people. Or the process.

Usually, it’s none of those.

The Paradox Every Leader Knows

You implement controls. You deploy automation. You collect data. You generate reports.

Leadership sees all the reporting.

But no action is taken.

This isn’t a technical problem. It’s a system problem.

And it happens everywhere, not just in security, but in operations, HR, finance, compliance, data engineering. Anywhere you’re trying to get people to actually use what you’ve built.

Three Root Causes (That Have Nothing to Do with Tools)

1. Fragmented Ownership

Imagine three departments (safety, equipment, fleet management) all responsible for the same process. Each has different rules. Each makes different decisions about what’s compliant.

Now you have to present data showing conflicting information: “To safety, this is compliant. To equipment, it’s not.”

Leadership sees the contradiction and stops trusting the data entirely.

The problem: When everybody’s involved but nobody’s responsible, you get three different truths. And data becomes useless.

2. Poor Data Architecture

In one tool, a severity level is called “high.” In another, it’s “critical.”

Same thing, different words.

But to leadership: “I don’t know which one to believe.”

I’ve seen this with something as simple as headcount. Finance counts based on who got paid that month. HR counts based on who’s scheduled. Finance says 50. HR says 47. An executive sees both numbers and asks: “Which one is right?”

Nobody can act because nobody knows if the data is accurate in the first place.

The problem: When definitions aren’t shared, data doesn’t mean anything.

3. Low Tool Adoption

I automated a report that was taking 30-45 minutes every week. Beautiful dashboard. Fully automated. Ready to go.

Adoption: 10 views. All me.

People kept doing the manual spreadsheet.

When I asked why, they said: “I know, but I like this way better.”

They didn’t need a better tool. They needed to understand why the change mattered. And they needed to be part of the solution.

The problem: Adoption isn’t a tool problem. It’s a design problem.

Data Becomes Powerful When It’s Trusted and Acted On

Here’s the thing: you can’t separate the quality of your program from the quality of your adoption strategy.

They’re the same thing.

If people don’t trust the data, they won’t act on it. If they don’t understand why they should change, they’ll build workarounds. If ownership is fuzzy, nobody will take responsibility.

The best dashboard in the world is useless if nobody believes in it.

ADKAR: A Framework for Designing Adoption

I’ve looked at dozens of change management methodologies. Most are good. But one stands out for how it actually works in real organizations: ADKAR.

ADKAR isn’t complicated. It’s five stages:

Awareness — Do people know why change is happening?

Desire — Do they actually want to participate?

Knowledge — Do they understand how to do it?

Ability — Can they actually perform the change?

Reinforcement — Does the change stick?

The trick: you have to design for all five.

Most programs fail because they skip stages. They mandate compliance (Desire gone). They dump instructions in an email (Knowledge gone). They go live and disappear (Reinforcement gone).

When you think about adoption as a system, not a behavior problem, but a design problem, everything changes.

What This Looks Like in Practice

Awareness: Instead of “Surprise, we’re changing this,” you sit down with the team and explain why. Two-way conversation. They understand the reasoning.

Desire: You don’t mandate compliance. You find out their why. What’s in it for them? More productivity? Less busywork? More time for meaningful work? You find a champion, someone whose motivation aligns with yours.

Knowledge: You don’t send a 10-page email with instructions. You show them. Interactively. You make it practical. You make it short (3-minute videos, not 30-minute trainings). And you make clear what “done” looks like.

Ability: You remove obstacles. You notice when the process is too complicated and simplify it. You practice with them. You create a safe space for mistakes.

Reinforcement: This is the part most people miss. You don’t go live and disappear. You monitor adoption. You recognize and reward teams who are using it. You intervene quickly (without shaming) when old habits creep back. You embed the change in your culture and systems.

The Real Work Starts Monday Morning

When you go back to work, here’s what to do:

1. Map where your people are in ADKAR. Are they unaware? Do they not care? Do they not know how? Can’t do it? Or is it just not sticking?

2. Tailor your approach. Different teams are at different stages. HR might be embracing it. Safety might be skeptical. You don’t use the same playbook for everyone.

3. Create a communication plan. Keep it simple. What is this about? Why are you getting it? What’s next?

4. Identify and empower champions. Peer influence beats authority. Find people on your team who get it and amplify their voice.

5. Define success metrics. Not for you—for leadership. They care about outcomes: money, productivity, reduced risk. Show them how adoption connects to those outcomes.

6. Measure and reinforce. Monitor adoption signals. Recognize teams doing it right. Quick intervention when things slip. No shame, just curiosity: “Why did you decide to do that?”

What Confidence Actually Looks Like

When you get this right, here’s what happens:

• Leadership gets engaged and starts defending your work.

• Teams stop second-guessing the data and actually escalate findings.

• People know what they need to do and come to you less often (because everything’s clear).

• You stop playing defense and start playing offense, making your systems better instead of fighting to get adoption.

That’s when the adoption gap closes.

The Bottom Line

You can’t separate the quality of your systems from the quality of your adoption strategy.

They’re the same thing.

Stop thinking about adoption as a behavior problem. Start thinking about it as a design problem.

When you design for ADKAR from day one, when you build awareness, desire, knowledge, ability, and reinforcement into your program, adoption stops being a struggle. It becomes inevitable.

Watch the Full Talk

I just released a 30-minute talk breaking down all of this with real examples from construction, HR, operations, and more.

You’ll learn:

• The three root causes of program failure

• How ADKAR actually works (it’s more flexible than you think)

• Real scenarios you can practice with

• Actionable steps for Monday morning

Want to chat about your own adoption challenges? Reach out.

— Ashley

But the journey between those two roles taught me something that nobody will else will tell you:

you don’t have to know where you’re going to get somewhere amazing.

How It Started

I came into the construction industry wanting to do one thing: help people and make a positive impact.

That sounds simple, right? But in construction, impact looks different.

It’s not abstract. It’s concrete (pun intended).

When you improve a process, you see it immediately. When you automate something, people’s lives get easier. When you gather data about what’s not working, you can actually fix it.

I started small, automating processes I was doing on a daily basis. Little things. Time-savers. Nothing fancy.

But then I noticed something: if I could automate one report, I could automate all of them.

So I made a pitch. “What if we officially introduced BI/data analytics to the company?”

Nobody knew what that meant. But I knew it mattered.

One Report

We started with one BI report. One!

Now we have over a hundred reports and automated workflows across the company, touching every department.

HR. Safety. Equipment. Accounting. Operations. Finance.

That growth didn’t happen because I was a brilliant BI developer. It happened because people saw impact.

HR used data to:

• Track retention

• Measure satisfaction

• Improve training effectiveness

• Gather employee input for company improvements

Safety used data to:

• Track metrics

• in real-time

• Ensure compliance without manual work

• Identify patterns before they become problems

Equipment used data to:

• Track idle time on machinery

• See which machines were underutilized

• Improve training based on actual behavior

Today that work generates over $1 million in recurring annual ROI. We are eliminating more than 19,000 manual hours per year across three divisions. A single automated time-off workflow eliminated 1,600 hours annually and produced over $121,000 in recurring savings.

Equipment inspection tracking rebuilt across three divisions now meets compliance requirements and generates over $53,000 in annual savings.

Those numbers matter. But they are not why I do this. They are what happens when you solve the right problems for the right people.

The Part Nobody Talks About

Here is what I wish someone had told me early on, you can build something technically excellent and still get it wrong.

When I started my role, I did not understand change management. My work was disruptive by design. It meant change. And I was building things without building buy-in. I was solving problems without solving for people.

I automated work without sitting down and explaining why or how it would help them. I created friction I did not need to create. I did not understand loss. I did not understand that the way I see a solution is not the way everyone sees it.

Looking back, I created a lot of unnecessary friction because I did not understand adoption. And adoption, I have since learned, is the real implementation problem. It is not the data. It is not the dashboard. It is the moment a person decides whether to trust what you built.

That realization changed how I work. Now I design for adoption from day one. I think about ownership, definitions, and how people will actually interact with the system before I write a single line of code or build a single report.

Change management is not a phase at the end of the project. It is a design discipline.

What Real Collaboration Looks Like

Here’s the honest truth: I don’t love people in the “workplace-drama” sense.

I never have. It’s why I secretly love being behind a screen, building dashboards, organizing data, automating processes. No drama. Just clarity.

But I found something at HEI Civil that changed how I think about collaboration:

I found a community.

I have been lucky to have great mentors, especially during my early years. Laurie Morgan first believed in me when I had just one report and an idea. She gave me room to fail, room to learn, and genuine mentorship that shaped not just my career but how I approach leading others now. That kind of investment compounds.

At HEI Civil, I have a support system. Real people who show up for each other. Who help. Who listen. Who push back. Who tell me when something is not working. Who trust that when I say “let me build you a dashboard for that,” I will actually deliver something useful. Who get what I’m trying to do and support it, not because it’s their job, but because they actually care.

And that kind of collaboration... I love.

I get to talk to people across accounting, safety, equipment, HR, finance, operations. Everyone has different perspectives. Everyone thinks differently. Everyone needs data in different ways. Everyone has a different threshold for complexity, a different tolerance for change, a different definition of what “working” looks like. That variety is not a problem to manage. It is what makes the work interesting and fun.

When trust is there, the conversations feel different. We are solving problems together. That is the collaboration I love. Not forced. Not performative. Not drama-filled. Just genuine partnership built on a track record of follow-through.

I get to learn how the entire construction industry works. I get to help people in ways they didn’t even know they needed help. And they help me back, by asking tough questions, pushing my thinking, teaching me their departments inside and out.

Every single interaction teaches me something new.

But none of it would work without the foundation: trust and a real community.

That’s why I’m still here, because collaboration with these people, in this environment, is something special. And that’s worth showing up for.

Where the Work Is Now

The work grew in ways I did not plan for. One report became a hundred. One automation became an entire workflow infrastructure. A small pitch became a complete data and automation function with formal governance, documented standards, and an active self-service BI program supporting daily operational decisions.

We have moved beyond buying software off the shelf. We are building custom solutions that solve our specific problems. We are scaling automation across divisions. And we are now doing something that did not even exist when I started, AI governance.

I have designed a full AI governance framework covering approved tools, usage guardrails, prompt documentation standards, data handling, confidentiality rules, and output validation processes.

My team has operated under that framework for over twelve months across Power BI development, Python automation, and AI-assisted reporting workflows. I am now leading the initiative to scale it enterprise-wide.

That work is what I am most proud of. Because it means we are being intentional about something that most organizations are still treating as a free-for-all. When 800 people are affected by the tools and systems you build, intentionality is not optional.

Every solution we build isn’t just about one dashboard or one report. It’s about how we implement change across the entire organization. How we train people. How we ensure adoption. How we sustain it as the system grows.

The work got bigger, but the principles stayed the same: clarity, trust, and people.

Now I’m building systems that directly impact our quality and operations. Every tool we create, every process we automate, every piece of governance we put in place ripples across the company.

That’s a different kind of responsibility.

And it’s why change management matters even more now.

Deciding What to Build

One of the biggest shifts in my thinking has been how I evaluate what is worth building.

Early on I built things because I could. Because I saw a process that could be automated and I automated it. Now I ask different questions. How do we scale this? How do we maintain this? How do we get people to trust it? How do we embed it in our culture? What is the ROI? What does success look like in six months? Who owns this when I am not in the room?

Every initiative I run through that lens now. It is not enough to solve the technical problem. The solution has to be cost-conscious, documented, scalable and built to be owned by the teams responsible for it. That is true whether I am building inside HEI Civil or advising a client through A River of Data.

That practice is also what I bring to organizations through my consulting work. Founders, CFOs, and operators in construction, trades, and small-to-mid-size organizations who are drowning in fragile manual systems. My job is to help them replace those systems with infrastructure that is reliable, understandable, and built to last beyond my involvement.

Sharing the Framework

I first spoke at Trimble Dimensions in 2023 to a fully booked room of over 100 attendees. I came back in 2025 and received a 4.75 out of 5 session rating, highlighted as one of the most impactful sessions of the conference.

In 2024 I was featured as a “SUPERSTAR” during Women in Construction Week in Transportation and Construction GIRL for contributions to BI and automation in the industry.

In 2026 I spoke at SnowFROC on a topic I think about constantly: why security and governance programs fail not because of bad design but because of poor adoption.

Every time I get in front of a room, I learn something I did not expect. The questions people ask tell me where the real gaps are. Not the gaps I assumed from my own experience, but the ones organizations are actually sitting inside of.

What I keep hearing, people know they need data strategy. They do not know where to start. They are afraid of doing it wrong. They have been burned before by implementations that looked good on paper and fell apart in practice.

But what stays with me after every session is not the questions. It is the people who come up afterward. The ones who say that what I shared gave them a framework they could actually take back to their team. That instead of spending the next two years fighting for credibility, fighting for budget, fighting to prove that data is worth the investment, they finally had a way to create impact first and let the impact make the case.

That is why I keep showing up to speak. Because what took me years of friction, failed rollouts, and hard-won trust to figure out, I can give someone else in an hour. That shortcut matters. I know what it costs when you do not have it.

That is the problem I am built to solve.

For Operators, Leaders, and Anyone Who Have Been Burned Before

If you are a leader in construction, trades, or operations and you are reading this because you are trying to figure out whether to invest in data infrastructure: the answer is yes. But the how matters more than the what.

The organizations I see struggle are not short on tools. They are short on strategy. They bought the software. They did not build the adoption plan. They have dashboards nobody looks at and automations that broke six months after implementation because no one owns them.

What I build, whether inside HEI Civil or through A River of Data, is infrastructure that is built to be owned. Documented, governed, and designed for the people who will actually use it after I am out of the room.

If that is the problem you are sitting inside of, I am available for engagements in English and Spanish.

The mission has not changed. It just scales differently now.