Reagle’s Collaborative Work Style

This is a description of my work style, first written in the nineties while working at the W3C—though I sometimes slip up.

↪Leadership

Leadership and process should be tools, not a hindrance. Leadership should identify goals, clear the path, and provide the resources to get the job done. Process should be collected experience/wisdom instead of arbitrary rules.

↪Meetings

As the law of two feet implies, a meeting is a place to learn and/or contribute, so I try to give my full attention to a meeting. I prefer meetings to begin and end on time, keep to the agenda, and have the attention of all participants; failing this, perhaps the meeting should close or disinterested people should leave. While Twitter and solitaire are a sign of disinterest, quietness is not necessarily so; so I try to encourage balanced discussion by following the rule of three and one: try to speak at least once, but no more than three times without being sure everyone who might contribute has.

↪Documentation

I document my expectations, dependencies and requirements, and I try to extract clear commitments from others. I’ve probably read your email, and I try to review your documents, but I’m not reading your mind. Make sure you say what you mean and get an affirmative response or commitment from me if you want to be sure I understand.

↪References

I frequently refer to resources (web pages or email archives) when I wish to discuss work, policies, expectations, discussions, and agreements. I prefer specific references and citations over unsubstantiated claims and hand-waving. While this is a habit that takes some time to implement efficiently, it also saves the reader time by requiring precision by the author, saves everyone time by reducing ambiguity, and even saves the author time by reducing redundancy: once something is written, it need not be written again. References and citations should not be interpreted as aggressiveness or defensiveness, but completeness.

↪Action items

I take and give action items; action items have an action, name, and completion date.

↪Commitments

A commitment is an agreement by an entity that is accountable. An action item commitment is associated with a name, not “someone” (never gets done) or “one of them” (not very fair to the other people).

↪Warnings

I work to meet my commitments, if I can’t I will say so as soon as I know. Not being able to do something is fine, just say so. Then one can re-prioritize, re-negotiate, or re-assign that commitment. Letting something go to completion date and fail is bad; it could’ve been discussed but now all dependencies are thrown off.

↪Consensus

When coming to a group decision, I aim for rough consensus. I try to achieve consensus through discussion (structured by good mediation) and then polling the group for some formulation of the policy that is agreeable. Asking the right question of the group can be difficult, but part of coming to consensus is discovering the right question to ask.

↪Ownership

All topics, issues, resources and chains of command should have an owner: a point of contact and accountability. This is true even for consensus-decisions. Also, this does not preclude the delegation of constituent tasks.

↪Final say

While I believe consensus is important, sometimes it can’t be readily achieved. Then, I believe the owner of an issue has the final say, they ultimately get the credit or blame (though everybody who contributes has a share as well).

↪Step aside

If I can’t do it, I will get out of the way. This is not to say I think others will do a bad job. If I disagree with someone, who is probably more knowledgeable and motivated, I will offer my input and let them succeed on their own terms. However, I don’t like to do things that I disagree with or don’t understand.

↪Criticism

I endeavor to always be open to constructive criticism and suggestion; criticism should be directed towards helping a person achieve their goals. (If you do not roughly share goals, you are likely not collaborating but competing.)

↪Showing

If I don’t understand what you mean, show me what you mean. If I can’t explain my position I will provide a proposal, example, or solution that shows what I mean.

↪Improvement

Practice is improved by writing a policy/proposal and then discussing, implementing, and amending it based on discussion and experience. Even if the original policy is janky, by writing it down and normatively referring to it, one encourages improvement since others will then be able to propose improvements. Frequently, practices are not documented by their immediate users since they know what works for them. When they interact with others, this is a good time to write up the best practices so others can understand and suggest improvements.

↪Laziness

And lastly—and frankly—I try to avoid work. We all have too much to do, but I believe in maxims like, “do one thing and do it well,” or “make commitments one can keep, and keep the commitments one makes.” Over-commitment and burn-out help no one, particularly one’s self. Following this work style helps me avoid that.