When people ask me why I speak at conferences, I used to have a quick answer. “To share knowledge.” Or “to give back to the community.” Both true. Both easy to say. Neither one is the real reason.
The real reason took me years to find. And it starts with a project that nobody used.
The Project That Worked
Early in my career I rebuilt a process I was proud of. There was a report the team was putting together by hand every week. Thirty, maybe forty-five minutes of copying, pasting, and checking. Every single week. So I automated it. Clean data model. Fully refreshed. A dashboard that looked good enough to put in a slide deck.
I shipped it and I waited for the thank-you notes.
A few months later I checked the usage. Ten views. All of them were me. The team was still doing the spreadsheet by hand. When I finally asked one of them why, the answer was not what I expected. “I know. I just like my way better.”
That sentence lived in my head for a long time.
The Part I Didn’t Tell Anyone
I decided it was my fault, but in the wrong way. I did not think “I skipped a step.” I thought “I am not good enough at this.” If the work were better, people would use it. If I were better, people would use it. So I worked harder on the technical side. I learned more tools. I made things faster and prettier. And I kept running into the same wall.
Nobody warns you that imposter syndrome does not feel like doubt. It feels like a to-do list. It feels like “one more certification and then I will be legit.” I was building better and better things, and I was getting quieter and quieter about it, because every time something did not land, I read it as proof.
I was building things without building buy-in. I was solving problems without solving for people.
Going Down the Rabbit Hole
At some point my mentor spoke to me about change management and frameworks. I stopped reading about tools and started reading about people. Psychology of adoption. Behavior change. Why humans stick with something that is slower and worse when something better is sitting right there. Why “I like my way better” is not laziness. It is trust. The spreadsheet had never let that person down. My dashboard had no track record. Of course they picked the spreadsheet.
That was the first time I understood that correct and adopted are two different things. You can be a hundred percent right and still lose, because nobody experiences your logic. They experience the change. And change has a cost that shows up on their side, not yours.
So I went searching. Frameworks like ADKAR. Research on habit loops. How people decide what to believe when two numbers disagree. Boring on paper. Life-changing in practice. Because for the first time, the failures had a shape. They were not random. They were predictable, which meant they were preventable.
The People Who Set Me Straight
I did not get there alone. I had a few people around me, managers and mentors, who did something I did not know I needed. They did not tell me the work was bad. They also did not tell me it was great and leave it there. They told me the truth: this was not a build problem, and it was not an Ashley problem. It was a change management problem.
That reframe did two things at once. It gave me something I could actually fix. And it took the weight off. I stopped asking “am I good enough?” and started asking “what did I skip?” That is a much better question. It has an answer.
It was not a build problem. It was not a me problem. It was a change management problem.
What Changed When It Clicked
Once it clicked, I could not unsee it. Every project got a new first step. Before I write a line of code, I ask who owns this, what they call the thing, what they will stop doing once it exists, and what happens the first time it disagrees with the number they already trust. I talk to people first. I find the champion in the room. I plan the hard part, the follow-up, the reinforcement, the part where you show up on week six and make sure it stuck.
That is the work behind the numbers I get asked about. One report became over a hundred reports and automated workflows. A single time-off workflow gave back 1,500 hours a year. Across the company that work now generates more than $1M in annual cost avoidance and returns over 19,000 hours a year to the business. Not because the code got smarter. Because the projects started being adopted. The gap between “correct” and “used” closed, and everything on the other side of that gap is where the value lives.
And the imposter syndrome? It did not vanish. I still feel it sometimes. It just stopped running the show. It turns out a lot of what I was calling “not good enough” was actually “did not know this yet.” Those are very different things.
So, Why I Speak
Every time I stand in front of a room, there is somebody in it who is where I was. They built the thing right. Nobody used it. And they are quietly deciding that it means something about them.
I speak because I want to get to that person before they believe the fake story in their head. I want to hand them the reframe that took me years and a few good mentors to find. It is not a build problem. It is probably not a you problem. It is a change management problem, and those have answers.
That is the whole reason. Not “sharing knowledge.” Not “giving back.” I speak so other developers, managers, and leaders do not have to learn the hard way what I learned the hard way.
Building something correct is not the same as building something people use. Once you know that, you can never go back to building the old way.
If you are sitting inside a project that works and nobody uses, I would love to hear about it. I speak and consult in English and Spanish. Start a conversation.
