When people see “Excel” or “data analytics” on my profile today, they often assume I’ve always been adept at working with spreadsheets and data. The truth couldn’t be further from reality. There was a time when I didn’t even know what a pivot table was.
Looking back, that moment became one of the most defining experiences of my career—not because it marked the beginning of my report automation skills, but because it changed the way I approached learning. The lessons I took away from that internship have influenced every role I’ve held since, long after I stopped thinking about pivot tables.
My First Week: Feeling Completely Overwhelmed
It was my first week as an intern at Johnson & Johnson, and like many interns, I was eager to prove that I would succeed. During onboarding, my supervisor introduced me to my responsibilities, including a project that would ultimately shape the trajectory of my career: automating a monthly report called the Inbound Scorecard.
The analyst who owned the report walked me through the entire process. For nearly an hour, he explained how the report worked, the business context behind it, and the tools required to produce it. Every month, the report took approximately 20 hours to complete manually.
As he spoke, I tried to absorb everything he was saying. He referenced pivot tables, Microsoft Access queries, data relationships, and formulas as though they were common knowledge. Meanwhile, I was struggling just to keep up with the terminology. Rather than thinking about how I would automate the report, I was simply trying to understand the language being used.
By the end of the meeting, I realized I was still struggling understand some basics, so I asked the only honest question I could think of:
“What’s a pivot table?”
It wasn’t the question I wanted to ask, but it was the question I needed to ask.
Choosing Curiosity Over Pride
That moment taught me an important lesson much earlier than I expected in my career.
When we’re new to a job, there’s often pressure to appear competent. It’s tempting to nod along in meetings, hoping you’ll figure things out later rather than admitting you don’t understand something. I could have done exactly that, but it would have slowed my learning and made the project much harder.
Instead, asking a simple question gave me a starting point.
I’ve since realized that confidence isn’t pretending to know everything. Confidence is being secure enough to admit what you don’t know and trusting that you can learn it. Those two mindsets may look similar from the outside, but they lead to very different outcomes. One protects your ego in the short term; the other accelerates your growth over the long term.
That realization shaped the rest of my internship.
Learning One Concept at a Time
Once I understood how much I had to learn, I committed myself to learning it.
I spent time watching tutorials, reading documentation, experimenting with spreadsheets, and rebuilding examples from scratch. I didn’t have a structured curriculum or formal training plan. Instead, I focused on understanding one concept at a time and applying it immediately to the project I had been assigned.
At first, progress felt slow. Every new topic seemed to reveal more things I didn’t know. However, over time I began noticing something encouraging. Concepts that had once felt intimidating gradually became familiar. Tasks that initially required careful step-by-step instructions eventually became second nature.
This experience fundamentally changed my expectations about learning. We often imagine expertise as the result of a breakthrough moment, but in reality it usually develops through consistent, incremental progress. Each small improvement builds upon the previous one until, almost without noticing, you’ve become capable of solving problems that once seemed impossible.
Looking back, I wasn’t becoming an expert because I was exceptionally talented. I was becoming more capable because I was consistently willing to learn.
From Completing Tasks to Improving Processes
Several months later, the report that once required nearly 20 hours of manual work each month could be generated in just 8 seconds with the click of a button.
The dramatic reduction in processing time was rewarding, but it wasn’t the most valuable outcome of the project.
What mattered far more was how my thinking had evolved. At the beginning of the internship, my goal was simply to understand Excel well enough to complete the assignment. By the end, I found myself thinking beyond individual formulas and focusing instead on the overall process. Rather than asking, “How do I finish this report?” I was asking, “How can this process be redesigned so no one has to spend 20 hours doing repetitive work?”
That shift—from completing tasks to improving systems—became one of the most valuable skills I developed. Technical tools will inevitably change throughout your career, but the ability to analyze a problem, identify inefficiencies, and build better solutions remains valuable regardless of the software you’re using.
The Most Valuable Skill Wasn't Excel
People frequently ask me what technical skills they should learn to become more competitive. Excel is certainly valuable, as are Power BI, automation tools, and the many technologies that continue to reshape the workplace.
But when I think about what that internship actually gave me, I don't think first about the Excel functions I learned. I think about what happened when I was given a problem I didn't know how to solve.
I started with almost no knowledge of the tools involved. Instead of allowing that gap to define what I could accomplish, I treated it as something I could work through. I found resources, practiced, made mistakes, asked questions, and kept going until the unfamiliar became familiar.
I've encountered that same pattern repeatedly throughout my career. The specific tools and responsibilities have changed, but the process has remained remarkably similar: I'm given a problem, identify what I don't know, learn what I need, and apply it until I can solve the problem effectively.
That's why I no longer view a lack of experience with a particular tool as a reason to avoid an opportunity. If I already know how to use something, that's useful. If I don't, I now have evidence from my own career that I can learn it.
What I Tell My Mentees Today
This is also one of the biggest concerns I hear from early-career professionals I mentor. They worry that they aren't qualified enough for an internship, a new position, or a stretch assignment because they don't yet have every skill listed in the job description.
I understand that hesitation because I've been in a similar position. Sitting in that first meeting, I didn't have the technical knowledge I needed to complete the project. What I did have was the ability to recognize the gap and do something about it.
That's the distinction I try to emphasize with my mentees. Instead of asking, "Do I know everything this opportunity requires?" a more useful question is, "Do I have the ability and willingness to learn what I don't know?"
There is an important difference between being unqualified for something and being unfamiliar with it. The first may mean you aren't ready yet. The second simply means you haven't learned it yet.
My own career has given me plenty of opportunities to encounter unfamiliar territory. I eventually expanded beyond Excel into business intelligence, automation, and executive reporting, but I didn't start each of those chapters with complete knowledge of what I would need. I started by learning enough to take the next step.
That approach has made new challenges feel less intimidating. I don't need to know exactly how I'm going to solve a problem before I begin. I just need to be willing to figure out the first part.
What "What's a Pivot Table?" Taught Me
If I could go back to that first week as an intern, I wouldn't change the fact that I didn't know what a pivot table was. That knowledge gap was uncomfortable, but it gave me an opportunity to discover something more important about myself: I could take something that initially seemed completely foreign and make it understandable through persistence and practice.
The 20-hour report becoming an 8-second automated process was a great accomplishment, but the bigger accomplishment was what happened in between those two points. I went from struggling to understand the terminology in a one-hour meeting to understanding enough about the underlying process to redesign it.
That experience changed the way I approach opportunities where I don't have all the answers. Instead of seeing unfamiliar requirements as a signal to step back, I see them as an indication that there is something new for me to learn.
And that is probably the most useful lesson I can pass along to someone early in their career: you don't have to know everything before you begin. You have to be willing to learn once you do.
My career in data and business intelligence didn't begin with expertise.
It began with a question.
"What's a pivot table?"
