The Unplanned Path to Amazon
How I ended up in tech without ever studying it
I didn’t set out to work in tech. There was no long-term plan pointing me toward Amazon, no clear idea that I would end up working with engineers or building systems. If anything, my early path was moving in a completely different direction.
Music was the center of it all.
I started playing saxophone young and stayed with it for years. Lessons, practice, performances. It shaped how I spent my time and how I thought about progress. By the time I graduated from Buffalo State with a degree in saxophone performance, the expectation was simple. This was the direction my life would follow.
What I didn’t realize then was that the path would change quietly rather than all at once.
Where things began to shift
My first job out of college was in mortgage collections. It wasn’t connected to music, and I didn’t have a deeper reason for choosing it beyond getting started and earning a paycheck. But once I was there, something began to stand out.
I found myself paying attention to how things worked.
Not just completing tasks, but noticing the systems behind them. The reports that took longer than they should. The same issues appearing again and again. Processes that depended too heavily on manual fixes or individual knowledge.
I started asking questions, mostly to myself at first. Why is this done this way? Why does this break here? Is there a better way to handle it?
Those questions didn’t come with immediate answers, but over time they pushed me to try small improvements. I built simple Excel trackers to organize work. Then I made them more efficient. Then other people started using them.
Without realizing it, I had started learning.
Building skills without a roadmap
There wasn’t a clear moment where I decided to learn business or move into something more technical. It happened through repetition and necessity.
I used Excel more often because I needed better visibility into the work. I learned SQL because it helped me find answers that weren’t easily available. I paid attention to how data moved between systems because that was often where problems started.
Each new skill came from trying to solve something specific.
Over time, the nature of my work changed. I wasn’t just completing assigned tasks anymore. I was improving the way those tasks were done. That shift created new opportunities, even if they didn’t come with new titles right away.
At Bank of America and later at M&T Bank, I started working more closely with different teams. Operations, compliance, technology. Each group had its own perspective, and they didn’t always align.
I noticed that many problems weren’t technical limitations. They came from a lack of shared understanding.
One team would explain what they needed in business terms. Another would interpret that into something slightly different. The result would work, but not quite in the way it was intended.
I found myself naturally stepping into that space, asking questions on both sides and helping clarify what was actually needed. Over time, that became a core part of how I worked.
The compounding effect over time
Looking back, there wasn’t a single turning point that changed everything. It was the accumulation of small shifts over several years.
I spent time building dashboards and reporting tools that made data easier to understand. I wrote requirements that translated business needs into something actionable. I mapped processes to identify where they broke down and how they could be improved.
At Citi, this became more structured. As a Senior Business Analyst, I was working closely with data from the Enterprise Data Warehouse, identifying quality issues and helping resolve them. I was also coordinating with stakeholders across teams to improve how data was used and understood.
The work was becoming more complex, but the approach stayed consistent. Understand the problem clearly. Break it down. Build something that improves it.
At some point, I realized I was no longer trying to learn these skills. I was using them.
Getting into Amazon
When I joined Amazon, I came in as a Business Analyst.
That part often gets overlooked, but it matters.
I wasn’t stepping directly into a technical leadership role. I was building on what I already knew. Working with data, supporting decision-making, and continuing to operate between business and technology.
Even at that level, the environment was different. The pace was faster. The expectations were higher. Problems were larger in scope and less clearly defined.
But the foundation held.
I focused on understanding the systems, the data, and the people involved. I looked for gaps. I asked questions. I built solutions where I could.
Over time, the scope of my work expanded.
I started taking on larger initiatives. Working more closely with engineering teams. Getting involved earlier in the lifecycle of projects, not just analyzing outcomes but shaping how things were built.
That progression led to the next step.
I moved into a Technical Program Manager role, where I was leading efforts across teams, driving system development on AWS, and managing complex initiatives like large-scale content migrations and reporting frameworks.
Get Ziccarelliandrew’s stories in your inbox
Join Medium for free to get updates from this writer.
From the outside, it might look like a jump.
From the inside, it felt like a continuation.
What the experience actually felt like
At each step, I felt slightly ahead of where I thought I should be.
There was always more to learn. More context to understand. Moments where I had to figure things out as I went.
That feeling never fully went away.
But over time, I stopped seeing it as a signal that I wasn’t ready. It became a sign that I was still growing.
Each role stretched me in a different way. Each challenge added another layer of understanding. The progress didn’t feel dramatic in the moment, but it was steady.
Looking back
If I step back now, the path makes more sense than it did while I was in it.
Music taught me how to practice and stay with something long enough to understand it. It trained my attention in a way that carried into everything else.
That same approach showed up in how I worked with data, how I solved problems, and how I navigated complex systems.
The industries changed. The roles evolved. But the underlying pattern stayed consistent.
What I would say to someone on a similar path
You don’t need a perfectly aligned background to move into something new.
What matters more is how you approach the work in front of you.
Most people spend a lot of time thinking about what they don’t have. The right degree. The right title. The right starting point. I did that too at times. It’s easy to look at roles in tech or business and assume there’s a fixed path you’re supposed to follow.
There isn’t.
What actually matters is whether you’re paying attention to the opportunities already around you.
In almost every role I had, there were problems that didn’t quite make sense. Reports that were inefficient. Processes that were unclear. Data that didn’t line up. Those moments are easy to ignore because they aren’t formally assigned work. But that’s where most of the growth lives.
Start there.
Pick one thing that feels inefficient or unclear and try to improve it. It doesn’t have to be perfect. It just has to be better than it was before. That’s how you begin building real skills.
The next step is learning just enough to solve the problem in front of you.
You don’t need to master SQL to start using it. You don’t need to become an expert in Excel to build something useful. Learn what you need, apply it immediately, and let the next problem pull you forward. That cycle is more effective than trying to learn everything upfront.
Another piece that made a difference for me was becoming comfortable sitting between teams.
A lot of value comes from understanding how different parts of an organization think. Business teams focus on outcomes. Technology teams focus on implementation. When those two don’t align, progress slows down.
If you can listen carefully, ask clear questions, and reflect back what you’re hearing in a way that both sides understand, you become useful very quickly. That skill doesn’t require a specific background, but it does require patience and attention.
It also helps to take ownership before you’re asked to.
Early on, no one told me to build dashboards or map out processes. Those things came from noticing gaps and deciding to do something about them. When you do that consistently, people start to trust you with larger problems.
And those larger problems are what create momentum.
There will be moments where you feel like you’re slightly out of place. Where you’re not fully confident in what you’re doing. That doesn’t go away as quickly as you might expect.
It didn’t for me.
But over time, you start to realize that feeling is part of the process. It means you’re stretching into something new. The goal isn’t to eliminate it. It’s to keep moving forward anyway.
If you stay consistent with this approach, things begin to connect.
The skills you build in one role carry into the next. The problems you solve become examples you can draw from. The gaps you step into become part of your identity.
And eventually, you look back and see a path that didn’t feel clear while you were walking it.
It just felt like figuring things out, one problem at a time.
That’s still how I think about it now.
And it’s enough.
