Every Opportunity Is a Learning Experience

Summary

I spent my early career in IT as a developer and trainer at a time when business analysts weren't considered necessary on projects. Users were an afterthought, and the familiar cycle of build, discover the gaps late, and rework kept repeating.

A move to Ireland changed that. On a project building apps for first-generation smartphones, I experienced for the first time what real BA work looked like: business, users, developers, and testers working as one team. I learned to ask who would use the system, what they actually needed, and what the work meant for the business. Without knowing the title yet, I was already thinking like a BA.

The position I thought I wasn't qualified for turned out to be exactly what I had been preparing for all along. Today I mentor analysts navigating the same journey I once found my way through on my own.

The Early Years

My early years were shaped by business needs turning into "usable" solutions, often with little attention to ease of use. When the fit was clearly wrong, teams refactored. When it was merely close, users were told to expect "new and improved," only to inherit extra steps, workarounds, and frustration. It became a familiar cycle: build, discover the gaps late, rework, then repeat.

In the early 2000s I went to Ireland to ride that Celtic Tiger that was raging through the country. I landed a great position as a Quality Analyst with a start-up there and got to see a bigger, broader view of the IT world. Not only did they have developers, testers, and managers; they had specialists in Configuration Management, Change Management, System Design, Localization, and Internationalization. It blew my mind that IT was bigger than just the slice of what I'd seen back in Canada.

A Shift in Thinking

While in Ireland, I was selected for a new project building business apps for first-generation smartphones. The technology was exciting (colour graphics and limited web browsing), though typing on a number pad quickly wore your fingers out.

On that project, I first experienced true Business Analysis: business, users, developers, and testers working as one team. I learned the importance of asking questions: Who is going to use this functionality? What would users really want or need? Why does this matter to the business? How can this benefit everyone involved?

I recall daily conversations to sort what mattered most, what could wait, and how even small changes affected the people who would live with the outcome. That's where it clicked for me: the work goes well beyond defining "requirements." It's about aligning the what, why, and how across every group involved so no one is surprised downstream.

The team explored ideas, tested assumptions, and adjusted quickly based on feedback. For those early smartphones, that even meant designing shortcuts and pre-drafted responses. These small changes reduced effort, improved adoption, and respected the reality of how people actually worked.

I learned how to evaluate value (what business outcome are we trying to move?), viability (what constraints, like time, tech, policy, or risk, make some options unrealistic?), and reality (what will users actually do, and what will it cost them day-to-day?).

Because of this, I started to think differently. I was thinking like a BA.

After a few years of practicing this way (talking to people to better understand their whys, hows, and whats), I was guided toward a position with the actual title of Business Analyst. At first I didn't believe I was a fit for it. A Business Analyst was someone with much more experience at leadership and more skills at analyzing "things." But that was exactly the position I had unknowingly been preparing for.

The biggest value I brought to many initiatives came from how I worked to create alignment: naming trade-offs explicitly rather than hiding them in "requirements," bringing the user workflow into the room early instead of as a test script at the end, and translating decisions into impact statements: "If we choose X, it means Y for users, Z for delivery, and Q for the business." That approach earned the trust of teams and clients alike.

When the Student Becomes the Teacher

Over the next few years working as a BA, I invested hard in my skills: learning new knowledge domains, new ways of working, better forms of documenting knowledge, and how best to communicate with all the people I interacted with. I had moments of struggle and moments of celebration, alongside stretches of quiet reflection where I didn't always recognise how far I had come.

It wasn't until that fateful day I was encouraged to apply for a position as a BA trainer, alongside someone who had also been my mentor. I thought I was nowhere near her level. No way I could teach alongside her.

I was amazed when I made it through the interviews and was offered the position. I was reminded of what my mother always said: "Every opportunity is a chance to learn something, so go learn." I was now able to share what I had learned, and I realized this whole time I had been preparing for exactly this.

That position taught me so much more than I could have imagined. It's true that teachers learn from their students. I had a wonderful time, and the takeaways led me to expand from teaching into mentoring, something I now do for many people exploring Business Analysis.

Moving On Up

My varied experiences have helped me find space in a position I genuinely love and get excited to talk about. I take great pride in what I can share on projects and with others through mentoring and discussions.

Does that mean I'm done exploring new things? Not even close. I'm thoroughly enjoying the ability to share my knowledge and experience, and that appears to be guiding me toward a new chapter in speaking engagements. I'm exploring a variety of topics that I study and pull into my work as a Business Analyst, so don't be surprised if you see my name somewhere soon, attached to a topic I hope is as engaging as my path has been to me.