Mel : Tasks - reading notes

One of the articles Chris sent out has a section on the creation of team norms. Norms are vital to the success of a team, especially a distributed one; they're the expectations people have and the unspoken assumptions they work with. Synchronizing assumptions at the start is important... and impossible, for the simple reason that when you begin work on a project, you don't know what you're going to do.

2.5 years into my Olin education, I now look back at the ambitious calendars and gannt charts from freshman year and laugh at how confident we were that we'd make them, and how much stress we went through when we started to slip from them. Times and plans and tasks will change. You can't let matters slip and slip and slip, but you can't plot out exactly what you will do a year from now. So how do you lay the ground rules and set tasks without unduly constraining your team?

Lay out assumptions and expectations, not timelines.

It's important to know why people are on a team, what they can offer, how much they want to put into it, and what they expect to get out of a project. What are you used to? What do you silently expect from others? Who likes to be bothered when anything goes wrong, and who'd rather be emailed? Who hates faxes? Who gets paranoid if they haven't heard back from someone in a week? What do you consider important, and what is crying wolf? Going around attempting to voice assumptions is a powerful thing. It's an awkward conversation at first, but it's great once you get going. I've been quite enlightened by these.

Practice test-first development.

In sofware, test-first development means that you write your tests first; that is, you write a program to test your program before you write the program you're testing. You create a way to determine whether your code is finished and successful. It's two birds with one stone; by creating a test case first, you've defined both your goals and a clear-cut way to tell whether you've reached them.

This applies to domains outside of software engineering as well. Everyone's got to agree on what the team is trying for, and everyone's got to agree on what it will mean to reach that goal and how you'll tell when you get there. Are you having outside evaluators come in? Who? Will you stop at n% optimization, x units, y happy customer letters?

You're looking for something that you can point to and say absolutely "we're there" or "we're not there." Something like "make inverted pendulum controller more stable" is open to debate. What's "more stable," and when are you stable enough? A better goal would be something like "inverted pendulum will stabilize itself for at least 5 seconds without outside intervention at least 7 times out of 10." You're either there or you're not.

Assign responsibilities, not roles.

The person responsible for the work getting done and the person doing the work are often the same person, but not always. Instead of telling people "you do this," tell them "make sure this happens." That leaves them open to find the best route to making sure whatever it is happens. Sometimes it's doing it themselves. Sometimes it's asking someone else to chip in. Sometimes it's hiring someone outside to do it for you. In other words, it's on your plate, but you don't have to eat it; just make sure your plate's clean by next week.

Use next-actions and milestones, not beancounting task lists.

"Master Yoda said I should be mindful of the future!"
"But not at the expense of the present. Be mindful of the living Force, young Padawan."
-Star Wars: The Phantom Menace

One of the most powerful concepts of the book Getting Things Done is that of the next action. Don't worry about all the thousands of things you'll need to do to reach your faraway goal. What is the next thing that needs to be done, right now, to get towards that goal? That - not the gazillions of future things - is the task you should assign.

Reply-all when norms are updated.

It's impossible to nail down norms, assumptions, calendars, and everything at the first meeting. You don't know each other, you haven't worked together, you've never done this before and you have no idea how it turns out. Great! Make sure everyone knows that. When you realize that a norm or a procedure isn't the way you think it ought to be, tell people. Make sure everyone's always on the same page; keep your brains in synch as much as possible. Keep those communication lines open.

There you go, Chris. 30 minutes of free association and development of the concepts in the readings. Much of the structure was taken from the third article with the name I can't find, but the analysis and thoughts are my own.

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!

Mel: Communications assignments

Before everyone came to tonight's meeting on Communication, here's what happened.

First, Mel was a slacker and very forgetful and didn't send the readings out for nearly a week. Everybody read "The Art of Project Management," specifically the chapter on Communication and Relationships, p. 170-184.

Each individual was given a different reading set in addition to these and an assignment to present their topic to the group in the form of whatever topic they were given. For instance, Chris did a presentation on presentation and Tim facilitated a dialogue on dialogues. The individual readings were as follows.

Chris on Presentations: Edward Tufte booklet, "The Cognitive Style of Powerpoint: Pitching Out Corrupts Within"

Liana on Email: "The Art of Project Management," section on email p. 193-197. Also:
http://www.43folders.com/2005/09/19/writing-sensible-email-messages
http://www.webfoot.com/advice/email.top.html ("Context" and "Summary" sections)
http://www.wordsintime.com/articles/article-howtowriteemails.html (bullet points)
http://www.43folders.com/2005/02/15/five-fast-email-productivity-tips/ (points 2 and 3)

Tim on Discussions: "The Fifth Discipline," chapter on Team Learning, p. 233-269 with emphasis on p. 246-247 and 259-269.

Eric on Specifications: "The Art of Project Management," chapter on Writing Good Specifications, p. 130-147

Mel read all of the above, created the Communications Triage flashcards, and is writing these notes as her self-imposed assignment.