Photo: Susan Merrell

Entries in teamwork (4)


Humanizing your emails

Recently a colleague emailed my intern group list-serve without a clear salutation, addressing them as "you." One intern replied to the email, triggering a copy to the whole list-serve, thinking the you was in fact just her, rather than the collective you.

This got me thinking about how often emails mis-fire in this way, and about the root causes.

In today’s world of mobile devices, I have noticed that people sometimes reply to emails without a full appreciation of who was cc’d on the original email, or whether their reply might be going to many people. I think this happens because mobile devices do not display all the meta-data about a message the way we typically see them on larger computer screens.

Sometimes someone who is bcc’d and receives the message on a mobile device, replies to all because their phone does not show cc and bcc lines. Even though this does not reply to all the people who were bcc’d, it DOES reply to all who were cc’d. This can be extremely problematic.

Therefore, for professionalism and safety and quality reasons, I recommend the following practices, which I try to model:

Begin your emails with a salutation that makes it clear who is being addressed, such as “Dear X”. My colleague did not do this, and the use of "you" may have inadvertently misled each recipient.

If you are cc’ing anyone, mention this explicitly after the salutation, such as “Dear X, and cc’ing Y and Z”

Never bcc anyone. If you want them to see the message, forward it to them after sending.

Be aware when replying to a message that if the message originated as part of a distribution list (list-serve), your reply may go back to the whole list-serve by default, even if it looks like you are only responding to a named sender.

Generally be aware that people may be reading your email on a mobile device with a small screen and more limited formatting options, and in different time zones on devices that may or may not adjust for time zone differences.

If you can, avoid attachments. Paste useful content into the body of the message – with minimalist formatting. People often don’t see that attachments are included, especially if they are checking email on phones. Recently I was in a meeting where someone had received a bunch of attachments but denied getting attachment #7. Their email program (Outlook) displayed two lines of attachments and then you have to scroll to see more attachments. Which this person did not know to do. Therefore they kept denying that they had received attachment 7, even as the sender insisted it was attached. Attachment 7 was a critical part of a proposal that ideally would have been reviewed before the meeting. So if you do include attachments, list them in the body of the email in a numbered list.

Take the time to compose emails that short-circuit several cycles of communication. For example, when trying to arrange a meeting with someone, propose 1 definite time and offer 3 available backup times. Specify time zone. Always include an absolute date (never “tomorrow” or “Friday”). See my blog article on fully specified requests at When a meeting is confirmed, I will typically send an email with all the pertinent details (date, time, call-in information etc) and send a calendar invite with that information in both the "location" and note fields. The huge advantage of calendar invites is that they generally appear grayed out on people's calendars until they are accepted. Even if recipients overlook the email, they will usually notice something appearing on their calendar. However, email systems are not fully interoperable, so calendar invites may not function for others the way they do for you. That's why I do send a duplicate email summarizing the calendar item for people who are outside of my organization.

Generally in all communications, do some perspective switching and anticipate how the message is going to be received, accessed, interpreted, stored, and shared. The best book I have ever read on strategic communication, in which you anticipate the first, second, and third-order effects of your messages, is the book “When talking makes things worse”. Out of print, available at your library. Along these lines, use the subject line to summarize any request and deadline, as recipients do review subject lines while screening emails. Make judicious use of any ways to flag emails. My email system allows me to add an urgent mark (!), plus request a delivery receipt and read receipt, and schedule a reminder to emails. These layers communicate to recipients that I really, really want to make sure the email does not slip through the cracks. Overusing such flags will backfire, but generally I have good results with them. However, as with other issues, you cannot assume they will work similarly on all email systems.

As for the actual contents of the email, I try to limit each email to a single topic that matches the subject line, and structure the email so that a recipient can respond with a yes or no or very simple and short response, and move our collaboration forward. Finally, as with all communication, proceed with curiosity, fallibility, and perspective-taking. The primary implication of these is that I am always testing my assumptions with my respondents ("Did I understand correctly that you are requesting X, or am I missing something?"). Look over an email and count the question marks before you send it. Typically people make 10 or more statements for every question. When I review transcripts of really productive conversations, I find ratios more in line with 3 or 4 statements for every question. How do you feel when people communicating with you include questions to test their assumptions or solicit your views? My guess is you feel included and collaborative. The philosopher Immanuel Kant pointed out that a key ingredient of humanism was treating people as ends in themselves, not as means to an end. My experience is that asking questions is inherently humanizing.

When I look over these strategies for composing professional emails, they boil down to reconstructing the context for face to face, heart to heart communication that is otherwise likely to go missing from the electronic medium. Context such as the who, what, when, where, and why surrounding the communication. Context is humanizing. What a strange word, humanizing. Why would we need to humanize anything that we are involved with? Isn't our mere presence in an activity inherently humanizing? Well, no, not in the sense of being humane to each other. Something we need to keep in mind when communicating through machines.

As I write this, I've begun to hum one of my favorite songs, Rehumanize Yourself, by The Police, on the great album, Ghost in the Machine. "I work all day in a factory/I'm building a machine that's not for me/There must be a reason that I can't see/You've got to humanize yourself." If we are to build machines through our emails, let's build them for and with each other.


Continuous improvement through critical reflection

One of the mantras I have adopted in my life is: "there is no such thing as failure, only feedback."

Corollary: Back in my days at a high tech startup, my colleagues and I would regularly try to raise money from venture capitalists. We would come back to the office after making our pitch and employees would ask, "Well, did you get the money?" Our CEO would say, "No, but we learned a lot." So the expression was born in our office: "Learning is what you get what you don't get a check."

I do like to extract maximum learning from failure or feedback or not getting a check or whatever you want to call it. I have evolved a short template for reflecting critically on my performance. After any experience (e.g. giving a talk, putting on a training workshop, writing a grant, etc), I write down my answers to the following questions:

1. Current goals? What was I trying to accomplish? (These are usually carried over from a previous attempt, see last item below.)

2. Achievements? It's important to note and celebrate the ways in which I did accomplish or contribute to my goals. As my daughter's first-grade teacher says: give yourself a pat on the back.

3. Failures? What did not go well or according to plans, hopes, desires?

4. Success factors? What did I or other people say or do, or what was happening in the environment, that contributed to the achievements above?

5. Barriers? What did I or other people say or do, or what was happening in the environment, that contributed to the failures (or inhibited the achievements) listed above?

6. Next goals? What am I going to work on next time? I carry those over to the next performance.

Just as an example, here is my reflection after conducting a workshop that I give periodically on decision making:

Goals? – experiential; shorter (6 hours); same content. Focused only on skills.

Achievements? Individual, realistic practice (e.g. with computers), focused (not distracted by sharing  a computer). Finished on-time. Students were all engaged, even at the end of a long week. Students did arrive at skills they will need (confident).

Failures? Half-trained (not a lot of process training); Not ready to initiate a phone call; Did not present the service delivery lifecycle very well; (in SF Margot took us through the clinic before, recording of Margot initiating a phone call). The context. This was presented week before.

Success Factors? Computers available: kept away until they needed them (no checking emails). Experiential worked (practice, role playing). Undergrads had very fresh perspectives. No model clash.

Barriers? Limited time availability (of medical students – almost sporadic availability).

Goals for next time? Integrate the skills and process training? Immediate follow up and practice? Pipeline of patients waiting to be served? Process training would include scripts, practice calling, etc. Add time and split between two days? Video clip of process (project for student). Course for undergrads (intense), weave in medical students. 

In addition to using this framework to reflect episodically, I use it every week with my team. Each of us responds to those six questions with reference to the week we just completed.

Here are some excerpts of my reflections from last week (redacted for privacy):

LAST TIME GOALS  -  Finalize performance reviews; Film SCOPED promo; Fix budget for Mendocino in CMS Innovation; SSU affiliate agreement; BCT paper – check calculations; SV/O2O/MAP manuscripts; Reimbursements.

ACHIEVEMENTS - Performance reviews; SCOPED promo v1; CMS Innovation grant submitted; BCT paper moving along; PANCAN; Shanti; QL WCRC; IHPS adv bd meetings - leadership summit idea; CERC idea well received. Some progress on SSU.

FAILURES - Did not get to O2O/MAP manuscripts; reimbursements; CS video and marketing materials; 

BARRIERS - Grant collaborator canceled meeting, did not complete draft on time.

SUCCESS FACTORS - Grant collaborator put more resources on project and team rallied to submit a promising proposal.

UPCOMING GOALS - Mtg with John and Jill; SV/O2O/MAP manuscripts; SSU; CHQI Feb privacy mtg; reimbursements; Feedback; BMB syllabus; Promo video to Trina

Each week I share my reflections with my team, and they share theirs with me, and we discuss all the elements. It's a powerful way of going beyond setting/reporting on goals... to reflecting on the dynamics surrounding our productivity.


Reframing our approach to teamwork

I rely on Argyris and Schon's work in Action Science for key frameworks that help me serve as a more effective collaborator and program leader. Lately I've been paraphrasing some of their key observations and concepts using terms that are more comfortable and natural for me.

One of their key insights was the ubiquity of our mental models favoring unilateral control. They articulated a whole model, Model 1, with governing variables, core values, predicted behaviors.

After living with (in?) their frameworks for a decade or so, I want to share what I think are some of the manifestations of Model 1 that we can all recognize in ourselves and around us:

  1. Look good
  2. Save face
  3. Cover up mistakes
  4. Defend your turf
  5. Avoid conflict

These are natural tendencies that arise out of insecurity and defensiveness. Of course I want to look good! Especially if the alternative is what, looking bad?

The problem occurs when my attachment to looking good (or saving face, covering up, etc) inhibits me from being an effective leader or collaborator with respect to other worthy goals such as, say, providing a high quality product or service.

I've come to a point where I don't try to fight these natural tendencies in myself. But I do try to subjugate them to the higher callings in my roles as a leader or collaborator.

It reminds me of the subtleties around an old expression: "money is the root of all evil." Apparently the saying actually goes, "the love of money is the root of all evil." Similarly, I don't think we should suppress our insecure and defensive tendencies, so much as recognize them and let go of them at critical times.

I've been leading my program for several years now around a different set of practices:

  1. Curiosity
  2. Fallibility
  3. Perspective-taking

These are also totally inspired by Argyris and Schon, this time their Model 2 which characterizes mutual learning.

I try to cultivate in myself and others these tendencies as replacements for the control/insecurity/defensiveness habits.

Curiosity is the notion that we should approach collaboration as a puzzle.

Fallibility is just the notion that each of us is missing pieces of the puzzle, whenever we engage in collaboration.

Perspective-taking is the need to work a little harder to see the angles that others are seeing, in order to really understand what they are saying and doing.

These simple habits have been transformative for me. They appeal to the scientist in me. Many of us with scientific training are used to using these values over the life of an initiative or project, through quantitative and qualitative data collection, analysis, writing manuscripts, etc. Argyris and colleagues taught me to practice using these habits in real time, in every conversation. When you bring scientific attention to simple conversations or meetings between colleagues, these become incredibly challenging intellectually. (For this reason I have also found parenting to be the most intellectually stimulating and challenging role in my life: if you take every interaction seriously as a potentially formative occasion for your child, it deserves your best thinking as a chess player.)

I like to emphasize, to myself and others, the power and attractiveness of the new habits, rather than beating myself up (or judging others) for abusing the old.


Request cycle

Sometimes the same concepts converge on you from different directions. That has been the case for me in regard to a simple but powerful word: request. The idea is that in collaboration, all we can really do is issue requests of each other. Fernando Flores wrote that the request and its corollary, the promise, were the fundamental units of coordinated work. Professor Ron Howard of Stanford University adapted Flores idea into the notion of a quality commitment being one that both parties create and monitor. My version of the quality commitment is the request cycle. It goes like this:

Request - Person A has a need or complaint and expresses it as a request of Person B. A fully-specified request (I heard this phrase from a colleague who consulted at General Motors) includes the conditions for satisfaction of the request. See postscript.

Reply - Person B indicates they have heard the request, understand the conditions for satisfaction, and either accept it or decline.

[Renegotiate] - In this optional step, Person B may run into difficulties or otherwise learn that they may not be able to meet the conditions for satisfaction. The idea here is that with maximum lead time, Person B lets Person A know that they need to renegotiate the conditions for satisfaction (e.g. the deadline).

Report - Person B reports to Person A that they believe they are done. 

Recognize - Person A recognizes the report from B, and either accepts the work product as meeting the conditions of satisfaction, or rejects it and renegotiates a new understanding of what's needed and possible. Ideally the process converges on positive recognition such as thanks for a job well done.

Importantly in this kind of framework there is no reward other than recognition - the professional completion of a request cycle is intrinsically satisfying.

The college interns who work with me always wanted to add two more R's... Respect and Represent. Respect being a kind of recognition, and Represent relating to the broadcasting of your pride.

I have used this framework to manage both up and down. The only kind of relations worth having are consensual/voluntary, so we are all limited to requests, even if/when we have some kind of formal organizational authority.

As it turns out, the concept of a request is core to at least two other organizational frameworks: Non-Violent Communication and Appreciative Inquiry

PS Conditions for satisfaction

I use an old project management framework for specifying conditions of satisfaction: size, quality, resources, and timing. Size means how big a job are you asking for, what is the scope of work? Quality refers to your expectations for quality. Resources refers to, what resources do you think will be needed to complete the job? Timing usually comes down to a deadline. For example, I might ask a colleague to analyze some data. I need to specify the boundaries of the job (what data? what analysis?); the quality level (is this for a peer-reviewed manuscript or do I just need a back of the envelope analysis?); the resources ("please use the copy of Stata that we bought you using project funds last year") and the timing ("I see this as taking 8 hours, please get it back to me by noon tomorrow or let me know if I am off base in my estimate").