It’s no secret that I’ve really loved conferences as of late.  Ever since I went to PyTennessee in 2015, I’ve really felt a renewed encouragement to further my own knowledge. I read software books for a long time, but was starting to peter out on them because I felt like a lot of what I was reading was broadly applicable, but I needed to take deeper dives on certain topics.

I started reading through HackerNews, and started finding blogs I enjoyed, but it still wasn’t enough.  But once I went to a conference, I realized just how much more I could learn.  I saw great presentations, great content, and got to talk to a lot of smart people.

That all happened in February.  That started getting some gears spinning for me.  I wanted to get the conference mindset at ADTRAN, where I work.  I wanted for us to create a culture where we could share all the great thing we knew.  So by July of that same year, I had created Tech Talks.  

I want to share some of my lessons I’ve had in implementing and curating Tech Talks at ADTRAN.

First, let’s talk about why I wanted Tech Talks:

• People were not sharing knowledge they had accumulated over years
• New hires missed out on the tribal knowledge over time
• Get people thinking outside the box and learning things they wouldn’t otherwise learn.
• A lot of our engineers could use better presentation skills

I personally wanted to become a better speaker, and start using Tech Talks to promote some ideas I had past my team and into the company level.  But I knew that it couldn’t just be the Pat Viafore Show (TM).

LESSON #0 It’s not about you!

I personally restrict myself to a talk every 4-6 months.  That means I should only show up maybe once every 10 talk sessions or so.

So I thought through some logistics, next.  I figured every two or three weeks was a good amount of time between talks, and I set the vision as being anything tech-related.  I set up an hour’s worth of time right before lunch on Friday’s.  That way, I encourage developers to talk after the meeting, as the chances of a lunchtime meeting was low.

I also talked with our training department.  They are fantastic , and helped get me set up with scheduling, registration, room logistics, and recording.  Recording was great because now, we have a backlog of 2.5 years of tech talks that I can point newbies at when they want to learn new things

LESSON #1 Learn what resources you have at your disposal.

That being said, with a bigger or smaller company, you may have different needs.  Maybe you are a small company, and can just use a conference room every month.  Maybe you are a large company and can make it a weekly thing.  Make it scale to your needs.

 

So now that I had a framework for setting up talks, now I just had to get speakers.

I started talking to the more charismatic people in the company, and explained my vision.  I tried to find some speakers.  And lo and behold, I found two speakers right off the bat.  I set them up both for 30 minute talks on the first day.  One to talk about a Python Automation Library, and the other on Eclipse IDE.  I had a second session lined up about functional programming, and then a third session, where I talk about Python Intermediate Tips and Tricks and someone else wanted to talk about Mobile GPU computing.  Then, a day before the first tech talk, my Eclipse presenter’s computer crashed.  Thankfully, I had my presentation mostly written at that point for a month out.  That brings me to the next lesson

Lesson #2 : Always have backup talks ready

 

So after that first hiccup, it started picking up.  I started getting more requests from people wanting to give talks.  We had talks on Docker, C++, Python, Functional Programming, Rust, Jenkins, and so many other cool technologies.  As we started having more and more talks, I started noticing patterns.  If we had an hour-long talk, we had typically less participation.  If we had a lot of the same topic in one day, we typically had less participation.  So I started learning what my audience wanted – a variety of topics.  So my recommendation is to mix it up.  Get talks at the beginner level and the expert level.  Get talks that are good introduction material, and get others that assume some knowledge already.  Get live technical demos  and get soft skills talks.  Talk about what’s new and out-there, and talk about existing problems that need to be solved.  Just don’t lump similar talks in the session.  This has a side benefit of getting people exposed to new technologies.  People show up for one talk for 30 minutes, and stay for another 30 minutes for something they never knew about before.

 

Lesson #3: Diversify your talks; your audience will be just as diversified.

 

So things were going great for a few months, but then I started getting lower attendance.  Even worse, I was begging for talks, but nobody was volunteering any.  I started worrying that people just didn’t care anymore.  This is known as the “pit of despair”.  What was really happening was just that the novelty was starting to wear off, and we hadn’t quite hit mainstream just yet.  So I had to dig deeper to get more attendance.  I went back to those charismatic people in the company, or people whose previous talks I enjoyed, or people who I knew had things to talk about.  I personally went to them and asked for very specific topics.  By finding new presenters, I was able to pull in different spheres of influence into the talks.  If one person on a team was giving a talk, most of that team showed up to support them.  Then we could hook them on other tech talks, and they might start showing up repeatedly.  It’s no surprise when I’m talking to someone now, and when they mention something interesting they are learning about, one of my first questions is “Want to give a Tech Talk on that?”

 

Lesson #4 : Most people have something to talk about, they just need encouragement

Lesson #5: Don’t be afraid of ebb and flow of attendance and # of talks.

 

So, at that point, it’s been a year in, and tech talks have been in full swing.  But I wanted more.  I wanted to get new speakers, but it was tough to get them ready to give a talk.  They had never given a talk, or they were understandably scared, or didn’t think they had anything to contribute.  This was especially true of our co-ops.

So what could I do?  I could lower the bar to entry for a talk.  I injected myself into conversations and learned what people knew about.  I was able to convince quite a few that they had something valuable to contribute, even if they’ve only had one or two semesters of school so far.  There is so much value to getting new presenters, as they might have some very new ideas that are very worthwhile to hear.

So I started making sure we had 15 minute slots available as part of our tech talk hour.  You don’t have to fit 30 minutes or an hour, you just have to get 15 minutes of a talk.  Heck, after you have audience questions and setup, it’s really 10 minutes of content.  Even this was a large bar, so now I offer lightning talks, which gave speakers a chance to talk in 5 or 10 minute slots.

Lesson #6: Find ways to encourage new speakers.

 

So as of writing this, I’ve been curating Tech Talks for 2 and a half years.  We’ve had over 120 talks in approximately 50 sessions and I’ve had approximately 55 unique speakers over that time.  Attendance has been as low as 30 engineers, but as high as 110 engineers showing up to listen to talks.  I judge an average talk to now have 60-80 attendees.  That’s 60-80 people learning something new almost every two weeks.

As a result of this, I’ve seen the following benefits:

• We’ve started to build a culture of continuous learning.  I have seen conversations where people have urged others to give tech talks on the subject (without needing prodding from me)
• Our presentation skills have far improved.  It is critical for a software engineer to be able to present their ideas.  By doing tech talks, we have learned to deliver dynamic, entertaining, and informative talks.  We’ve collectively raised the bar, even to the point that a colleague of mine noted at a local conference that “Tech Talks have spoiled them in terms of people presenting things well.”  We were watching a very dry presentation at the conference, and it was night and day.  The only way we were able to realize that was practicing and seeing talks over the years.
• We have started to know more about each other, and learn who may be subject matter experts based on previous talks.
• We’ve built up a backlog of talks that we can refer back to.  When one presenter talked about Docker, we weren’t using it throughout the company.  However,  as usage grew, we were able to refer back to that recorded tech talk.

So to recap, Tech Talks are a great way to create continuous learning and practice your presentation skills. We’ve even had a few talks that ended up being conference talks later on.  Here are my key takeaway lessons:

 

LESSON #0 It’s not about you!

LESSON #1 Learn what resources you have at your disposal.

Lesson #2 : Always have backup talks ready

Lesson #3: Diversify your talks; your audience will be just as diversified.

Lesson #4 : Most people have something to talk about, they just need encouragement

Lesson #5: Don’t be afraid of ebb and flow of attendance and # of talks.

Lesson #6: Find ways to encourage new speakers.

 

I’m interested in any feedback you have, or any questions you have if you are interested in starting your own tech talks in your workplace.