Mel: Communications - Notes

Question of the night: How do you tell people what they need to know?
This begs several questions, such as "What are the different ways you can tell people?", "When do you tell people?", and "What do people need to know?"

Order of events

1. Brief on the Question of the Night by Mel
2. Topic activities (12-20 minutes each)
• Presentation on presentations by Chris
• Email on emails from Liana
• Dialogue on dialogues facilitated by Tim
• Spec sheet on spec sheets made by Eric
3. Communications Triage
4. Metadiscussion and feedback

All participants chose to stay past 9pm to wrap up the metadiscussion, making the total time 1 hour and 40 minutes.

If anybody has their pages or notes from the actual evening, it'd be great if you could scan and upload them (link to the file in the comments). This post makes much more sense in context.

Chris: Presentation on Presentations

• Powerpoint is terrible for presentations; it's a marketing tool.
• Abbrevs. everywhere
• Short points in sentence fragment form
• No hierarchy of points - which points are important?
• Make handouts instead
• Higher information density
• People can read them beforehand
• Interestingly enough, Chris didn't bring a handout for us
  
• Powerpoint information retention is horrible
• Miller's Law - humans can remember 7 unrelated things at once
• So of your 40 slides, they'll remember the last 7
• Quick, do you remember my first point?
• Presenting should be a dialogue, not a dictation
• Like good teaching! Professors convey information, they don't sell it.
• Eric: Default "I'm listening to presentations" behavior is to sit back and disengage - interesting automatic reaction.

A great presentation, and one that was much better without the powerpoint. Chris had a broad topic and a wide range of information he could have covered, and I think he did a great job of narrowing in on technical presentations and common mistakes in such. I would have liked to see a sheet of notes handed out beforehand, since that's one of the presentation tactics he recommended, and I wish we'd seen more examples of good presentations instead of mainly talking about how to avoid bad ones, but those are minor things.

More time for this topic would be good; we had to cut short a discussion on the presentation styles of different Olin professors in order to move on to the next topic. I actually think an expanded version of Chris's talk ought to be given before every Expo; too many presentations at Olin, no matter how fluently we speak or how well we carry ourselves, still follow the "I'm going to read bullet points off my powerpoint!" pattern, and it's starting to drive me nuts.

Liana - Email on Email
After reading the email Liana had written as a briefing on how to email, we segued into disucssion and questions. It was noted that some people recieve 1 email a day anothers recieve hundreds, so a time-efficient way to triage messages was good; if you think something is important, make it such that a busy person can as well.

Short pleasantries at the start of an email were accepted, but long paragraphs inquiring about your colleague's son in an email asking him to send in a report were not. We distinguished "social" emails from "work" emails; it's possible for emails to be letters sent via the internet, with life stories and funny flash movies, but that's separate from email that's meant to get work done (which should be all business). Don't mix business and personal stuff in a single email.

Email is good for getting information, making things happen by telling people what needs to be done, reminding folks of deadlines, informing people of priorities, and scheduling meetings. It's terrible for conveying emotion; don't hit on people via email and certainly don't get angry over it. If there's a miscommunication - for instance, if you recieve an angry email - don't email back; go talk to the person face to face, or give them a phone call. You'll get more context that way and things won't escalate.

The more you know a person, the less you're likely to misinterpret the tone of something they write. Building trust and relationships with someone else can help you communicate more efficiently in the long run because you know what they mean when they say something.

It was a great talk, facilitated by Liana's concise (and hilarious) email, which she brought printouts of for everyone. I was particularly happy that we talked about the social/communications dimension of what email is good and bad for and how it can be used, along with the mechanics of efficient email (put action items at top, use subject lines, etc). and I wish her email could be sent out to all freshmen at the start of their second semester at Olin.

Tim on Dialogues
Tim's talk centered around the difference between dialogue and discussion. Discussion ("We're not having an argument, we're having a discussion!") is when everyone comes to the table with a position and proceeds to try to "win" the discussion by converting everyone else to their position. Senior members dominate, junior members are afraid to voice their opinion, and things go downhill from there. It's not productive; it's a power struggle that's disguised as an attempt at productivity.

In contrast, dialogue is a cooperative attempt to find a team direction by having everyone become observers of their own opinion. How does a team dialogue? Everyone's got to be aware of the difference between discussion and dialogue, and everyone needs to actively work towards having a dialogue; that increases your chances a thousandfold.

"Thought forms lenses," said Tim. "Then you lose awareness of those lenses, and it's dangerous because then you see reality through it and you don't know [you're seeing reality through lenses]." He did a great job at giving an overview of his topic and incorporating other people's comments and suggestions into it, but it felt rushed (my fault in scheduling, not his) and I would have loved to have more time for our actual dialogue on dialogue. Tim brought notes and came up with a few excellent questions, which I've posted below in the hopes to spur dialogue on dialogue on this blog. I'm also posting these to Planet Olin; I think it would make an excellent community chat topic.

1. Peter Senge (in his book "The Fifth Discipline") likens team dialogue to "being in the flow" - like a jazzy musician or a basketball player. Is this something you've experienced in a team?
2. Do we interact as colleagues at Olin? Is there a perception of hierarchical meritocracy? Does that - and should it - color our discussions of teamwork?
3. Are we exposed to dialogue at Olin? What can we do to try to integrate this kind of team consciousness into the Olin curriculum?
4. How do you encourage people to suspend their assumptions? How do you practice suspending assumptions? Do you think you're comfortable with it?

Eric on Specifications
Ah, technical information. How do you get an entire team on the same page about what's going on with a project? Eric brought a spec sheet for how to do this via spec sheets. They're documents that take a collaborative effort to create, the culmination of the "design" phase of making things. Interestingly enough, the spec sheet Eric brought in wasn't collaborative, since only he had seen it beforehand; I would have liked it to evolve during the course of the meeting so we could all create the spec sheet on spec sheets during it.

"Think of it as the wiki for your project," Eric said. "It's a working document." It should constantly be evolving as different team members contribute, and ownership needs to be taken by everyone - spec sheets aren't the project leader's "What We Should Do" bullhorn. Basically, they answer the question "What are we doing, how, and why?" with an answer that's provided by and agreed on by everyone, and the team can then get on the task of actually doing it.

A dialogue on how to get everyone to contribute followed. Eric pointed out that the information he read on spec sheets was largely geared towards programming teams, where the divide between "coder" and "designer" was very distinct, but we agreed that the broader idea of spec sheets for team unity were great for pretty much any project. All of us thought that this talk should have been had at the beginning of , be it POE or HPV or Design Nature or UOCD.

Communications triage
I'd made a couple flashcards with different bits of information beforehand. An officemate comes into your office and complains she hasn't recieved a part from your coworker, a phone call from your Japanese supplier, an article in the newspaper about your competitor's new project, a text message from your wife, a request to proofread a memo, and so on.

We went through and quickly talked about each in turn, triaging them into action categories. Should you forward an email? Should you find your officemate in person, post a clipping on the company fridge, make a phone call, schedule a meeting? I was surprised at how many of the things were most efficiently handled in person. The deck was unbalanced and biased towards email/in-person/phone communciations; it was noted that it would have been nice to have a better mix (have some where a spec sheet would be appropriate, a conference, a presentation).

Finishing up and commentary

Eric pointed out that the readings were very working-group focused (see the previous post on the difference between working groups and teams), which they were. I responded that having a working group learn how to communicate efficiently is what I've seen transform it into the possibility of having a team, since it's hard to be a team when you're not all on the same page.

We ended on a note from Liana on the communal reading's assertion that "projects depend on relationships." Better communication and good relationships make people more effective and efficient, she pointed out, but higher efficiency shouldn't be the reason you seek to make good relationships with your coworkers. Intent matters; people aren't machines you can feed "friendly communications" into and get more work out of. The real test of communication and the relationship between two people often comes during crisis moments; when a coworker is having trouble, do you worry about them, or do you worry about the project getting done? Act on what you say. It's easy to say you care or that you're listening, but when it comes down to the wire, it's sometimes very hard to do.

The most common refrain of the night was "I wish we'd done this at the start of !" The consensus seemed to be that this was a really helpful 1.5 hours (and we kept running short on time, so this could be longer) and that we should find ways to share this with other Olin students. We'll be looking at this again at the end of the semester to see if we can put something together on it and our larger experiences

Overall, an awesome night. Thanks, everybody!