My Journey as a Conference Speaker

I never thought I'd want to be a conference speaker, and I certainly didn't enjoy public speaking. But life has a way of surprising us, and I've found that this journey has been more personally rewarding than I ever imagined. I’m still not where I would like to be, but I have been given the opportunity to give multiple talks and improve them. As someone who is a huge evangelist for developer productivity, shouldn’t continuous improvement be part of my ethos?

It all started at Devnexus 2022. Ippon had three speakers attending the conference. I was not one of them at the time, but I was fortunate enough to go as an attendee. Watching the world-class speakers and absorbing the energy of the event inspired me to try something new. I was no longer content to simply attend conferences; I wanted to share my own knowledge and experiences with others. Before that, I had attended plenty of local meetups and other conferences, but I never left with the feeling, “I can do this, and I really want to do this.”

At first, I struggled with two main challenges: finding a topic that people would want to hear about and establishing myself as a credible speaker. How could I compete with experienced professionals who had honed their skills through years of speaking? What could I present that people would want to hear from me? I wasn’t a professional speaker, how could I compete on the same stage? In reality, conferences accept presentations from all kinds of speakers, from experienced developer advocates, technology evangelists, and those with varying levels of professional speaking experience.

At the time, my boss gave me two pieces of advice that I took to heart. “Everyone starts somewhere,” every single speaker gives their first talk at some point. I could not compare myself to those people because, at that point, they had given so many talks and polished their craft that I saw the efforts of their labor. I could get there, and I could be that person, but I needed practice. The second was Malcolm Gladwell’s 10,000-hour rule, which asserts that the key to achieving true expertise in any skill is simply a matter of practicing (in the correct way) for at least 10,000 hours. At that time, I was already a professional software engineer for many years. I had 10,000 hours of development experience under my belt, and I just had to practice a different skill: public speaking.

As a solutions architect, I've always been passionate about developer productivity. I love building products for my clients, but I also love doing it with high quality and speed to drive business outcomes. While my talks have been on various topics, they all have that same theme. It's a topic that resonates with me because I've seen firsthand how it can improve developer efficiency and overall team morale and improve everyone’s overall satisfaction in both product and tech. I preface many of my talks with the same comment, “We don’t just choose this design pattern or architecture for fun. Our technical decisions on projects are meant to accelerate our software delivery and deliver product features faster.” That’s why I firmly believe in DORA metrics to measure that productivity and a DevSecOps mindset to get us there.

My first talk was on using the facade pattern with NgRx to decouple Angular state management from components. This allows more junior developers to work with a service abstraction instead of directly interacting with and testing state management code in their components. I have been on many teams of varying UI development abilities, and state management always seems to be an issue. This is something I have frequently helped clients and other devs in my company with. What I really like about this talk is the counterargument that this is an anti-pattern, to which my response is that it can be. What it comes down to is being disciplined about the implementation and code reviews. Given time, those developers unfamiliar with NgRx can be educated and start to implement new actions and reducers, but they are unencumbered with figuring that out immediately if someone with more experience handles the initial implementation. I always love to engage with others after my talk for comments, questions, or a friendly debate if they disagree with me.

I finally had my topic ready, and it was accepted at Connect.Tech, yet another amazing conference, and I had a meetup lined up to help me prepare. How did it go, you might wonder? Well, it didn't quite meet the high expectations I had set for myself, but what I gained was an invaluable experience and a chance to grow. After all, it was my very first meetup. Was I too nervous? Most likely. Just minutes before stepping up to present, I found myself in a whirlwind of panic, confiding in one of my best friends who had come to support me. In those moments, a revelation dawned on me: the outcome didn't really matter. Of course, I wanted to give each attendee something meaningful, but why let nerves get the best of me? Isn’t embracing failure and learning from it a key part of the agile mindset? If I stumbled, I could pick myself up, refine my talk, and try again. Whatever your worst fear may be about speaking, cut it in half, then halve it again. Trust me when I say it won’t be as bad as you think. A poorly performed talk may feel unpleasant, but it will likely happen at some point. We can only work on our skills and be better next time.

Attending conferences and watching other speakers has been invaluable in helping me improve my own talks. Not only am I gaining knowledge during these presentations, but I am gleaning new techniques and strategies to improve my own – it’s very rewarding. Plus, seeing the joy it brings another speaker to let them know how much you learned from them is incredibly fun. At the end of the day, conferences are about connection with people.

I still do this at every conference I attend. Every speaker has their own way of doing things that I can learn from and improve my existing talks or be inspired to give a different type of presentation. I constantly think about how I can give a more engaging talk and captivate my audience like those world-class speakers. By watching them, I see that some have such an ability to really let their personality come out in a presentation. Conferences aren’t boring lecture halls. I want people to be engaged; I want them to laugh, feel inspired, be entertained, and leave thinking about how they can make improvements when they go back to work.

I still feel early in my experience level, but I've enjoyed every step of this journey so far and see how far I have come since the beginning. For example, new ideas for talks come to me more easily now, and I'm certainly less nervous than I was at first. Or I just manage it better. My journey as a conference speaker has been a rewarding one, full of surprises and lessons learned. I'm grateful for the opportunities I've had to share my experiences and connect with others who share similar passions. Who knows what the future holds? One thing is certain: I'll continue to learn, grow, and share my knowledge with others through engaging with the dev community. If you stayed reading this long and are interested in trying it out for yourself, I would tell you good luck and to do it. If you are struggling with ideas on topics, I would think about what you are passionate about and why you like working in tech. If you ever see me at a conference, come say hello and mention pineapple, so I know you read my blog.