Tim: Team evolution and dynamics

Things We Do Right
It seems like a flat heirarchy is mostly preserved in teams here. Frequent delivery seems less necessary because changing requirements for an assignment aren't really tolerated in an academic environment and our "customers" are readily accessible and tend to have built-in oversight.

Things That Go Wrong
The Troubled Teams symptoms seem to come down mostly to flawed leadership, incompatible personalities, lack of skills, unclear objectives, and an inadequate or otherwise hostile environment.
I feel that the problems that affected my Design Nature team experience most were about communications and an unwillingness to express frustration to other team members or confront power imbalances we were uncomfortable with. I think this relates to the idea of personal safety in teams -- our size works both for and against us, and I think in this case our status as newly-minted first-years in an unfamiliar and very small social environment contributed to our team's problems. I agree with Eric's note that we may feel hesitant to raise concerns about team members -- our small community makes us more sensitive to the potential for conflict.

I almost wonder if there's a difference between how teams function in an academic structure like Olin's and how teams function in the Real World -- which could potentially indicate a failure of Olin's team curriculum. This is completely unbridled speculation since the aforementioned DN group is only real team (even in the loosest sense of the world) I've been on.

Mel: Software vs. Hardware reflections

I'm at a family reunion in Chicago and absentee from this week's meeting, sothis post is an attempt to make up for that.

Tools to promote osmunication

The first reading was on software design teams and how they could be made effective. I was especially taken by the idea of osmotic communication, which is that state of interconnectedness where team members seem to be reading each other's minds. Information flows so freely, it's almost unconscious; you bump into someone in the hall, yell across the room, peek at their monitor, modify a shared file, and move on. Like every skill that's been mastered to the point of unconsciousness, osmunication (my term for it) takes a lot of work and careful design to put the right structure in place, and then the courage to let it all go and see what happens. I've come across several free software solutions I'd love to try out to see if they will help osmunication happen faster. Anyone interested in doing a short project using one of these to see how it goes?

Basecamp and Campfire from 36signals
Open Workbench (like MS Project, but free)
Trac by Edgewall Software (the Olin Intelligent Vehicles Lab used Trac last summer; it looks like it worked well).

One caveat: these solutions are geared towards software development teams, as is the book chapter referred to above. Software != hardware. To change software, you type. (It's not an easy process by any means; sometimes changing one line of code ripples down through dozens of other files.) However, it's a lot easier to modify than hardware, which you need to get material for, machine, polish, install... If you're writing a program, it's possible to notice something six months after writing the first file and still have a chance at going back and fixing it. If you're building a house, you can't repour the foundation after you've installed the windows.

Keep this in mind while you're reading about software development practices. Most of the same things apply to other teams; some of it will not.

Choosing a team leader

The second article examined case studies of several successful and unsuccessful teams. In all these case studies, the leader was seen as having a clear role in the success or failure of the team. Specifically, the leader must be respected by her team and have a style of leading that transforms the people he works with. This is echoed in the book Good to Great by Jim Collins; leaders need to be quietly transformational.

"Project Agamemmon" was one case study, a team led by a new manager named "Frederick." The team ultimately fizzled; Fredericks's lack of experience was cited as one primary factor. Without technical expertise, he couldn't earn the respect of his workers, and ended up fading into the background as the leader-in-name-only with one of the senior technical workers taking up the real lead.

It's tough to pick a leader; often the best leader is not the one with the most technical expertise, and often the ones with technical expertise are not the best at motivating others. (Olin tries to produce people who can do both, but this issue still comes up). It's a little easier to pick a team leader if all the folks in a group already know each other's skills and strengths at the start; in those cases, everyone almost automatically knows who ought to be in charge. But on a team where nobody knows each other and skill sets seem to be even enough at the start not to set someone apart from the rest, how do you choose a good leader? (Or do you even choose a leader at all?)

I'd love to hear what people think about this.

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.

Mel: Teams vs. Working Groups

Brought this up at our first meeting last night, but didn't do a good job of explaining it. The difference between teams and working groups is an important one that's difficult to articulate, especially since most people label working groups as "teams."

Working groups

A working group's performance is a function of what its members do as individuals. There is no sum > sigma(parts). You take the work, divide it into people-hours, and portion it off. The metric for how well a working group member performs is how well they complete the person-hours of work apportioned them. Incidentally, this sounds an awful lot like the capitalist labor society Marx criticizes in the Communist Manifesto; people are hot-swappable work-hour units with different skill sets.

Since individual accountability is a convenient thing to have, most organizations (especially large ones) use working groups, and they use them well. Most committees, councils, task forces, and "teams" are really working groups. Most Olin projects, since they're relatively short-term (0.5-1 semester), are really working groups, and I'd generalize this to most short-term technical project groups in general, though I can't back that up. These groups are usually called teams, since "team" sounds good, but saying something's a team doesn't automatically make it one.

Here's what the powerpoint presentation says about working groups:

• They share information, perspectives, and insights.
• They make decisions that help individuals do their jobs better.
• They reinforce individual performance standards (the work-hour units metric I mentioned earlier).
• They focus on individual goals and accountabilities; members do not take responsibility for results other than their own.
• They do not develop incremental performance contributions requiring the combined work of two or more members (sum !> sigma(parts)).

Working groups are not inferior to teams! Sometimes they're the quickest, most effective way to get the job done; on small-scale, short-term projects, they almost definitely are. At Olin, we learn how to serve on working groups with extreme efficiency.

Teams

Let's begin with the powerpoint's bullet list again. Now, teams:

• They require both individual and mutual accountability.
• They rely on more than group discussion, debate, and decision.
• They rely on sharing information and best-practice performance standards.

This begs the question of what they do rely on. Gimme a second here.

• They produce work through the joint contributions of their members.
• They make possible performance levels greater than the sum of the individual bests of team members.
• Their performance includes both individual results and "collective work products" (what 2+ members must work on together - it reflects the real joint contributions of team members, not just sums of individual work-units).

Teams rely on interdependence and this sum >> sigma(parts) phenomena. My own theory is that teams are effective at getting their entire group into a collective flow state. Since the flow state is naturally the most productive mode of any individual person, having a way to keep all their individuals in flow state is to have a way of getting sum = sigma(parts) at minimum. But teams go further by enabling one individual's flow state to merge with another's - and this is where the sum-is-greater-than-the-parts phenomena comes in.

The team phenomena is most obvious in athletics and music. Good sports groups are teams; good orchestras, choirs, and drum troupes are teams. They can't afford to be otherwise.

Teams don't have to be working on the same project. Whereas working groups congregate around a job at hand and dissolve when the job is finished, teams endure past the completion of an assignment.

Teams have 10-year reunions. Working groups reconvene to complete another task.

A comparison

The powerpoint had a nice chart that showed some key differences succintly. I don't think it's complete, but it comes pretty close. (The formatting here may be wonky; sorry about that. It's standard html, but I can't get Blogger to like it.)

Working group	Team
Strong, clearly focused leader	Shared leadership roles
Individual accountability	Individual and mutual accountability
Purpose is the same as the broader organizational mission	Purpose that the team itself delivers
Individual work products	Collective work products
Runs efficient meetings	Encourages open-ended discussion and active problem-solving meetings
Measures its effectiveness indirectly by its influence on others (such as financial performance)	Measures performance directly by assessing collective work products
Discusses, decides, and delegates	Discusses, decides, and does real work together

Teams are illogical. They shouldn't work; they do things inefficiently on account of the overhead it takes to transform a working group (and they all start out as working groups) into a team, but once that point is passed, their performance rate skyrockets.

I'd also like to point out that Apollo Groups (groups made from the highest-performing individuals) are ineffective when you think they'd be completely great - this is a subtle corollary of the nature of team vs. working group dynamics and performances.

Sources

Powerpoint presentation on teams

I've had several discussions with different individuals on this topic, but I believe it was Mark Penner who first showed me the article (from his New Ventures class) that first got me thinking about it. I have no idea what article it was, where it was from, or where it went, though - if someone from the class knows what I'm talking about, I'd like to find that article again.

Week 1: Reading

My experience with design teams is fairly limited. Before Olin, Odyssey of the Mind was my only real experience with integrated team activity; our designs were only fortuitously successful. Team activity was mentioned in high school but not given any real emphasis -- we quickly broke team problems into division-of-labor scenarios that we worked on independently because teamwork was perceived as difficult and of lower quality. Design Nature at Olin revolutionized the way I see design activity and design teams.

Snodgrass outlines two sets of design metaphors: the rationalist model of design and the romantic model of design.
The point that there's no one formal design process to supercede all others in all cases is an important point. I'm not sure how I feel about discounting intuition.
Snodgrass quotes Heath: "Heath believes successful designers have a method, 'but it is not yet an explicit method.'" Will it ever be quantified? Is it even possible to quantify? It sounds like Snodgrass is suggesting no; I feel like I have to agree to some degree. Is that why we started this IS? I don't think that's an answer we're likely to get.
What's the Olin curricular design model look like? Are we in the analysis-synthesis-evaluation mode? Design Nature definitely does, particularly for the instructor-directed hopper project. Elsewhere?
It would be interesting to see what the post-realistic world looks like.

Team of one: So are teams really useful? Is the wider perspective attained from using teams the best way to do things? / an efficient use of person-hours? Why does everyone use the team model if teams aren't really the best answer? Is it really just an effective model for peer review? I get the feeling that wider perspectives are useful, but it seems like these perspectives are just as likely to be wrong as right. What's the balance? I'd like to ask people in industry about this.

Belbin evaluation
I was interested to find that my Team-Worker score on the Belbin inventory was zero. That doesn't square with how I view myself operating within a team and I'm wondering why I interpreted my the statements in the inventory as outside my experience. Is my limited experience biasing my response away from my "real" orientation, am I not really acting in a manner consistent with how I vew myself? I'll have to think about this when my next team project swings around.

Mel: Background information

Thought it would be a good idea to start with an introduction, so you can get a sense of what kind of filters I'm running all my blog posts and conversations through.


Pre-Olin


Before Olin, I was peripherally within a social group and participated in several team-intensive activities, notably math team, drama club tech, math modeling, improv, and the newspaper. Most of my time was spent as an individual working while the rest of the group (social or working) puttered around me; I would poke my head in as often as I thought I needed to. I wasn't divorced from the group - often I'd fill the role of teacher and translator - but my mode was very much "knock something out, pass it on."

At Olin

I'm mildly more social at Olin and definitely more adept working in groups, though I still tend to knock things out independently. Sophomore year I was Editor-In-Chief of Frankly Speaking, the school paper, and promptly recieved a painful crash course on how to not lead a team - so I've had my share of failures. I'm a notoriously prolific tutor, and I suspect this is the main reason seem to respect my judgment more than they should given my actual technical ability. I love to teach and explain things, so I often end up writing plenty of documentation and working with group members who need to catch up.

Teammates have described me as a "swiss army knife," able to fit anywhere, work with mostly anyone, and do most anything; I've pointed out in return that I can do many jobs, but don't fit any of them particularly well ("I can hack at many things, but I can't do more than hack"). I'm better at helping others get work done than I am at getting my own work finished. I have a marked tendency to gravitate towards the role of Alpha-Teacher-Geek, but dislike this preference and attempt to counteract it by consciously stepping back; this doesn't always work.

I have a tendency to think meta in a mildly narcisstic manner, so you'll hear many analyses of my actions (and analyses) in this blog.

Belbin self-perception inventory scores

One article Tim sent out this week had a Belbin self-perception test attached. It's analogous to the Myers-Brigg (for the record, I am a strong INFP), but is focused on how you function within a team context. Click here for an explanation of the categories.

1. Plant - 19 (Extremely high)
2. Resource Investigator - 14 (Very high)
3. Implementer - 12 (High)
4. Teamworker - 10 (Average)
   
5. Coordinator - 7 (Average)
6. Monitor Evaluator - 5 (Low)
7. Complete Finisher - 2 (Low)
8. Shaper - 6 (Ridiculously low)

I'm not surprised by the low Complete Finisher score; if anything, I'm an "Incomplete Fini-Ooh, Shiny!" and need plenty of hounding in that department. I was surprised by the high Resource Investigator score, though. I'm not extroverted, am mildly uncomfortable around unfamiliar people, and am terrified of speaking on the phone (I'm hearing-impaired, so it takes me a while to get used to a new person's voice, and if I can't lipread, I'm lost). I do ask a lot of stupid questions, write copious amounts of email, and read prolifically, so that might make up for my awkwardness around, y'know, actual people.

And that's enough about me.

How are you?

Temporary placeholder

This is the blog for the DTD independent study. This post will be replaced by the proposal (minus names and stuff) and an intro when we get approved by the mighty committee that is isurb. ]