In My Epic Life Quest, I went over what my goals for 2015 were. One of those bullets was:
- Give 3+ Dev talks at work
Two weeks ago, I gave the first talk; an introduction to Git. This was to the whole dev team, around 15 people.
Part of the leveling up is in the act of preparing the talk, but most of it is in the delivery and feedback cycle after the talk. Or, as I said on Twitter:
I hate it when I bomb a talk.
— George Stocker (@gortok) February 11, 2015
How I know I bombed? At the end someone commented, “I still don’t know how Git is different than Team Foundation (Source Control)” — George Stocker (@gortok) February 11, 2015
Yea, that’s how I did.
So let’s talk about ‘why’ that was the case:
Initially, I had 25 slides; (all of which would take around 45 seconds a piece to go through) and then I was going to demo Git and show it in different situations. Since my audience was full of developers that were primarily used to TFVC (Think SVN for TFS;with visual integrations and no command line component), I wanted to take them through the lingo and show how TFS is different from Git before demoing Git.
In practice, however, there were a lot of questions as soon as the talk started, all from one developer. They started almost immediately with questions about Git’s branching model; or that it isn’t really different from TFS; or whatever. The developer admitted they didn’t have experience with git, and were asking these questions for understanding (in their words “because they didn’t see how it was different than TFS” or “What would we gain by moving to git”) ; but without meaning to, that developer became the heckler in the room.
Instead of asking them to hold all questions until the end; I answered their questions. That invited more questions, and because I had already opened the door; it effectively sunk the flow of the talk.
In the end, we barely got through the slides (ug, slides) and into the demo ( My rehearsals had 30% slides with 70% demo).
After the talk I sent out an anonymous feedback form, out of 14 people that attended the talk, I received two responses:
“Very informative! Maybe sticking to the flow of the powerpoint more would have made things make a little more sense from a general view, but I understand that other peoples’ questions were the main cause of going a bit tangent at some points.”
“Content was presented in a thoughtful, meaningful way. Demoing helps to clear things up to those who do not have a full grasp on the subject. Perhaps talk about one thing and then demo it right away.”
Both were great responses; and based on those responses and more reflection, here are some of the things I needed to watch out for (and didn’t):
- If your talk relies on a flow; and questions interrupt that flow; then make sure to hold all questions until the end
- a demo is worth a thousand words
- Never engage one-on-one; always bring it back to your control; at the end of the day the only person who can let you lose the flow of your talk is you
- Preview your talk by giving it to a smaller group; if you’re giving a talk to the whole dev team, then preview the talk to 2 or 3 people on that team first
- If you’re lucky enough to know the personalities in your audience, be sure to practice dealing with those personalities. If you’re giving a dev talk at work; then you know your audience.
Even though I know I bombed the talk, I find it very hard to look at this as a failure. If Shipping Things is the goal, then this talk was a success. It’s not easy (even though I’ve done it dozens of times) to give a talk to a group of people, and every time I feel as scared as I did the first time.
Yea, I failed on the outcome, but I didn’t fail from the standpoint of getting up there and doing it — and that’s what matters. I’ll get better with each talk; I just have to keep getting up there and doing it.