I’ve seen Dave Eaves give a couple of presentations on/around this topic, and always enjoy his insights. This specific presentation is one that I had not seen before, but heard about from coop. Finding the full slidedeck along with audio recording was really great – I can now get my deaves fix without having to wait until next time he and I are at the same event together.

His informal presentation style, and sense of humour, helps keep you engaged in an uncomfortable “warm fuzzy soft skills” topic that many people in software shy away from.

Some highlights that stuck with me (in no particular order):

1) For any discussion, there are four main categories of communication:
* inquire
* paraphrase
* acknowledge
* advocate
** (Hint: if both sides are doing 100% “advocacy”, its not going to end well.)
** (Related hint: in order to persuade, you need to be open to persuasion.)

2) Don’t tell people how to do something, do tell people why you want something. This leaves it open for everyone to brainstorm whats the best way to implement something – which might turn out to be better/easier/faster then your initial idea.

3) Beware of miscommunications and mistaken assumptions in irc/email/bugs.
* 7-9% are verbal – the dictionary definition of words that you use
* ~38% are paraverbal (tone, accent, volume)
* ~50% are body language

4) Is an open source company a “software company” or a “community management company” ?
* what is the core competency? Code? Code+human communication?
** I think this is what makes it so hard to get used to working in an open source environment. And hence, hard to grow an open source community.
* Ideas are fragile; egos are fragile; You need a safe place in the community where people can suggest new ideas without being immediately shot down and discouraged. Without new ideas, you are dead but just dont know it yet.

David’s presentation is focused on open source community, which makes sense given it was at FSOSS. However, it feels just as relevant to a large closed-source organization or any environment where people who dont know each other well (yet) are trying to figure out a shared solution to a shared problem.

If you work with others, or work by yourself before coordinating all the different pieces with others, then this presentation is for you. Trust me. Watch it. Maybe its something you already know, and practice daily. Or maybe, like me, you’ll find yourself taking notes and wishing you could do-over some conversations.

(Why, oh why, didn’t they teach this in CompSci when I was in university?)