Engineers present
19 Aug 2014
Xored has always been a small company, where everyone knows each other. Well, not anymore. Recent couple of years we’ve grown to a point, where I’ve never seen some colleagues. We used to have 2-3 projects, now we have dozens of them. Needn’t to say, that most people have little to no idea, what the others are doing. This is bad for company culture, knowledge reuse, and just dreary. To fight it, I organise regular meetings, where people present their work to the others. Currently, it takes the form of biweekly talks, each of which is a review of some product, that we’re doing. Quite unimaginatively, they’re called “What we’re doing” (in Russian: “Что мы делаем” = ЧМД). This is the last one, which was at Friday (look, how excited those girls are):
I’m telling you all this, because I’d like to share observations I made while organising the talks. I humbly hope, that they may be interesting, and even useful for someone, who would like to give a talk. Bear in mind, though, that they may not apply to all situations.
I intentionally avoid the question “what to tell about?” here. Generally, you can either concentrate more on business value (who the customers are, what customer problems you solve, how much money you earn, etc), or on technology (what technical problems you solve, which frameworks you use, what development process you have, etc). Which one to choose depends greatly on the audience and your purpose. Obviously, engineers lean towards technology, which is not always justified. But this is a completely different story.
What I want to talk about now is typical peculiarities in ways how engineers present their work. It looks like there are some distinct trends.
First of all, almost everyone thinks, that their work is not interesting. When I come to a team and ask if they can tell about their project, the first answer is always “We don’t have anything interesting to tell”. After that, we usually discuss the details of the project and easily find possible talk topics. But still, engineers are always sceptical until the last moment. Even if they agree, that there is something to tell the colleagues, they usually imagine the talk to be short. But it’s never the case. We consistently exceed scheduled time because of flood of questions from the audience. I guess, no one of the speakers expected, that they would’ve got so much attention.
After choosing a topic, the next thing is talk planning. Engineers are often wrong about it. Typically, people (even technology guys) like to see real things or discuss concepts, rather then listening about technical details. But this is exactly what engineers like to put in their talks: give long code snippets of how they use framework X or language Y, meticulously explain, how they setup environment for their app, and so on.
My theory is that this happens because of lack of understanding, how a tutorial differs from a talk. Engineers read tutorials, which typically have a lot of code samples and technical details. Which is a good thing! On the other hand, talks are almost useless, when you try to learn a new framework or language, so engineers don’t use them much. When you come and ask them to give a talk, they instinctively try to give a tutorial instead, because in their experience tutorials are the most useful. And guess what?
A tutorial in the form of a talk is rubbish.
Talks are good for spreading ideas, explaining concepts and demonstrating results, but not for learning details. In your talk, you’d better answer more “what” questions (“what can you do with framework X?”, “what features are included in the recent release?”, “what problems to expect with this approach?”) and less “how” questions (“how to do this in framework X?”, “how is feature Y implemented?”). Note, that I’m not urging to avoid “how” questions completely — a question “how have we overcome problem Z?” is completely reasonable, if you manage to cover it without a lot of details. A rule of thumb here is that if you can’t explain something without a code snippet, skip it. Code snippets are OK only if they are complementary, but not necessary, to what you’re saying.
Another observation is that engineers tend to concentrate too heavily on obvious things and neglect not so obvious ones. It seems completely illogical. May be, this is because engineers love precision and accuracy, therefore feel safe only when they talk about stuff they know thoroughly. But the trickier stuff is the more chances you don’t have sufficient knowledge to answer all possible questions. So, engineers could discuss basic things endlessly (just like myself here :)) — this is simply a safer strategy. Mind thought, that this is also a great strategy to make your talk boring as hell. Tell about specifics of your project, not about widely known facts. It can be hard to distinguish the two, but this is your duty as a speaker.
However, when telling specifics, please avoid your project’s slang. This is another pitfall engineers tend to fall into. Do not assume, that if you give definitions to all terms, everyone will immediately get a grip on them. Not a chance! One thing which is more boring than banalities is definitions. So, the audience simply ignores them and, thus, a major part of your talk. If you want to be understood, use as many common words as possible.
And last, but not least: show it live! If your project is not a kernel module, make a life demo of it. If it is, make a demo anyway (you just need some extra creativity). For an unknown reason, engineers put screenshots of their apps into slides. Some don’t even think about a demo. Others say: “Yeah, I plan to give a small demo at the end”. This is all boring.
If you aim for wow effect (and you should), demo is an immense help. Make it the central part of your presentation, start with it. Don’t think, that you need to explain all concepts before the demo. Explain briefly while giving the demo. Give in-depths explanations, architecture diagrams, and so on, after the demo, and the audience will forgive you a great amount of tedium.
Sure, this is harder, than presenting screenshots and reading from slides. But reading from your own slides is lame anyway. Many engineers believe, that the worst crime is being mistaken or mess something up (bigger chances of that with live demo). Being dull, even for the sake of accuracy, is a much greater crime for speakers.
OK, to recap:
- You can find interesting stuff to tell about, no matter what you do;
- Tell about ideas, concepts, results and plans. Skip technical details;
- Don’t waste time explaining obvious things, but explain tricky stuff better;
- Explain tricky stuff in well-known terms;
- Make demo the central part of your presentation;
- You may not be absolutely accurate, but you must be entertaining.