Three Lessons Learned from Overcoming the Inertia Against Technical Presentations

Fear of speaking and feelings of an inadequate technical knowledge base can often be a paralytic combination, especially to those newer to a technical field. Imposter syndrome and feelings of inaptitude can easily become dominant, resulting in a self-fulfilling prophecy with high levels of inertia.

Thankfully, I have a low level of unease regarding speaking in front of people, including to groups upward of 60 people. While my presentation experience has largely not been about technical topics, much of the skillset translates over. As I mentally prepared myself for the idea of giving a technical talk, I still had to overcome the serious sense of imposter syndrome that I could provide anything meaningful to the conversation as a developer with one year of experience. Over the past two weeks I have given a technical presentation twice to groups of approximately 20 people, and am preparing to give the same presentation to approximately 150 people next month. During this process, I discovered three key areas which challenged my preconceived notions that had thus far prevented me from stepping out.

The Ramp-up

For the past two months, I have been getting more intrigued about GraphQL and diving into implementing it for a mobile project in my spare time. GraphQL, in short, is the answer to bloated API responses from traditional REST endpoints. Whereas REST will return all of the data for a particular API call, GraphQL allows you to be declarative in the data that you need and will only return that data. It’s an amazing paradigm shift, especially when API calls are nested or need to combine data from multiple routes. If you are interested in a more detailed overview of GraphQL I highly recommend checking out https://howtographql.com. I’ll likely write something up in the future as well, but that’s not the point off this particular post.

About a month ago, I was asked to talk about how I built this site using Gatsby, a static site generator using React approximately 3 hours before the meetup was to take place. It was a pretty low key meetup that I have been going to for the past year, so I went with it. As I was talking through how Gatsby uses GraphQL for its data layer, there was significant interest in further discussion. I asked around after the presentation, and decided to do a more in depth presentation on the basics of GraphQL for both the server and the client. 4 weeks later, I gave my first 45 minute prepared technical presentation.

Three Important Lessons Learned

Through the process of presenting on GraphQL twice in the 10 days, I came to several key realizations which helped to overcome the initial inertia of resistance. While the resistance of presenting on a technical topic and feelings of inadequacy are very real, they are based in fear and logical fallacy.

You don’t need to be an expert developer with 5 years of experience to teach something. This was at the heart of my reticence of stepping out there. In my mind, only the brilliant developers who had things figured out were qualified to speak about a particular topic. From what I observed, I built up this idealized perspective of developers who had reached some level of programming enlightenment and were bestowed with the gift of sharing their knowledge to the masses. This may seem overblown, but it is the exact straw-person argument that is at the heart of imposter’s syndrome. I believed that people who are very knowledgable are skilled or experts at everything; however, this assumes the construct of linear knowledge acquisition. Knowledge is substantially more complex and non-linear. People are all in various stages of knowledge and skillset across a diverse breadth of topics. While someone may be highly knowledgeable in one area, they may have a cursory knowledge in another. Our ability to be experts in any given range of topics has an inverse relationship to the number of topics. It’s ok to not have all the answers, even as a presenter. This does not speak ill of the presenter, but speaks to the depth of the many different topics and technologies that we interact with on a daily basis.

The ability to synthesize a complex topic and talk about it in a cogent manner is a very valuable skill. Communicating to people who may not know anything or as much as you do regarding a particular topic, requires challenging your assumptions of their existing knowledge. How do you determine the appropriate level of base understanding to expect the audience to know? Where is the right balance between explaining some things in more detail for those who may be more unfamiliar, yet not becoming so verbose as to lose interest from those who know more? One tool that I have seen speakers use and have started implementing myself is gauging knowledge about a particular topic through early audience engagement and then adjusting emphasis on portions of the presentation accordingly. Additionally, identify if the topic can span across multiple platforms or programming languages. If it does, identifying areas which are shared and where some details are specific to your implementation can also be helpful. This hit me quickly as I was co-presenting to a group of PHP developers and had to check myself for speaking in terms that were more applicable to JavaScript implementation, or at least providing some additional explanation when those concepts were reached.

Presentations, like software, are an iterative process. There is a fine balance between something being good and what we deem perfect. Unfortunately, it is easy to idealize the perfect implementation which can keep us from pursuing something in the first place or be too afraid to expose it to the world lest imperfections be discovered. The latter concept, combined with imposter syndrome can easily result in not starting at all. I don’t want to present on something until I know enough and can answer any question that I am thrown and the presentation is perfect. This is an impossible task. Knowledge doesn’t grow without increased practice and repetition, including the ability to present on a topic. My first presentation was far from perfect. It was disjointed at times, lacked some flow control, and definitely needed some improvement. I could easily have let this stop me from presenting it in the first place or from pursuing future presentations. However, listening to both positive and constructive feedback allows for the presentation to evolve through an iterative process, much like software does. Presenting on a topic is not that different from programming a piece of software. We scope out the desired specifications and get to work on the initial implementation. Somewhere along the way, there is some initial prototype feedback which confirms some directions and alters course in others. We find bugs along the way, where things didn’t work the way we expected, and work to correct them. We continue to refine and develop, always engaging in the process. We need to view presentations and our ability to do them in a similar manner. If we cling to the concept of perfection, we likely won’t get started in the first place.

Speaking on technical topics has been a very valuable experience for me. It has encouraged my learning process and resulted in many network connections that I did not previously have. More importantly, engaging in the process has altered the expectations I set for myself and provided a more realistic perspective on presenters that I respect. You don’t need to be an expert to teach others, even teaching people who have more overall experience than you do. The matter that someone has a wider breath of experience overall does not equate to knowing a particular system in depth. They too may be new to that particular concept. We can all be teaching and learning from each other. As we tear down the fallacies which feed into our imposter syndrome, I hope that more people will take those first steps to embracing and sharing the knowledge that they are passionate about.