The McCarthy Protocols
I write to call your attention to a unique new body of work that has the potential to change much of what we do in the software industry. Before launching into the details, I need to offer the following qualifier: I am not a party to this work, I have no way to profit from it, and I have only a distant acquaintance with the people who have pioneered it.
Whenever you enroll yourself in a group effort — say a software development project — you make a tacit agreement to be bound by certain rules that govern interaction within the group. The rules make up a protocol which establishes such things as who may speak when and on what subject, what attitudes are out of bounds, how much frivolity is OK, how much deference needs to be paid to certain key issues and to managers, senior members, etc.
Usually the rules of the protocol are informal, unwritten, implicit, and unexamined. If you believe (as I do) that the quality of team interaction is more important to the eventual success of the endeavor than any other factor, then the unexaminedness of the interaction protocol should be of concern to you. We all know when the team is “in the groove” or “out of the groove,” but what courses of action do we have in our quiver of tools to optimize this most essential characteristic of our work?
Beginning in the mid-nineties, Jim and Michele McCarthy and their colleagues at McCarthy TeamworX began to develop an explicit interaction protocol that they call “The Core.” At the heart of The Core are a few dozen interaction patterns (good ones and bad ones) and a set of formulas intended to help the team achieve an advantageous response to each pattern. These formulas, or Core Protocols, are little ceremonies that team members conduct at opportune moments in the work.
The beginning of a group work session or meeting offers such an opportune moment. Usually such events begin with some light banter and then settle suddenly into a focus dictated by a designated leader. The focus may be solid or intermittent, may drift, or may lose out entirely to competing threads and concerns. Holding focus is dependent on the skills of the leader. Since this same leader is also the one who chose the focus in the first place, success or failure of the interaction is almost entirely in his/her hands.
The Core proposes instead that the meeting ought to begin with a Check In ceremony. Check in is a loosely scripted formula by which each person binds himself/herself to the purpose of the interaction. It gives each participant the opportunity to mention something about his/her state at the beginning, explicitly the emotions called up by the interaction. The group responds to each person’s Check In by saying “Welcome.” The revelations of Check In are, by the etiquette of protocol, out of bounds in the discussion that follows. There is also a Check Out protocol that allows members to remove themselves in an undamaging way from the interaction, and a Pass protocol by which they can remain but stay passive.
Who needs it?
My first response to the Core Protocols was to wonder who really needs more formality in the workplace. I like the informal give-and-take that is a mark of the healthy workplace and I appreciate the way that such bantering can build informal guidelines for the work that follows. I had the sense that Check In might feel artificial, or “cheesy,” to use the McCarthy’s own term for it. As I explored the idea more deeply – reading Jim and Michele McCarthy’s new book, Software for Your Head [Addison-Wesley, 2002] – I began to feel otherwise. I have been a party to far too many meetings where the bantering phase was delightful and the rest of the meeting a total frustration. And meetings are only a part of the frustration endemic in our field, most of it interaction-related. We can do better.
Is The Core is a crucial advance toward better software development? I’m clueless. But I am relatively sure that it is a worthwhile attempt to deal with the true essence of our work.
Invest an hour to find out more
The Core is a radical and bold undertaking. I’m not willing to say (yet) that it has entirely succeeded, but I am willing to say that you need to know about this work and the McCarthys’ readable book about it. Reading Software for Your Head will change you and change your practice. Whether you adopt the Core Protocols or not, you won’t be unaffected by them. If you had to choose between a project in which every task were performed in an ideal way, or one in which the team interactions were optimized, you would probably opt for optimized interactions. Yet we agonize endlessly about process (how stuff gets done) and not at all about interaction. The McCarthys offer a fresh voice and an exciting new direction for you to consider.
Tom DeMarco is co-author (with Tim Lister) of Waltzing With Bears: Managing Risk on Software Projects, forthcoming from Dorset House, 1Q03.
This article can also be found here.