Collaboration Explained by Jean Tabaka

Collaboration Explained is the second of the two books that I read. After reading some overviews and glossing over the table of contents, I expected this book to fill in some of the implementation details lacking from the “Wisdom of Teams”, with a focus on agile and scrum methodologies. Like the “Wisdom of Teams” it appeared geared toward project managers rather than software developers. My impression was that this book could make for a dry and prolix reading experience, with main arguments that would be more effective on an organized reference card. But as the saying goes, never judge a book by it’s cover. If by reading this book I could see eye to eye with my project leaders, I would consider the time reading it well spent.

The first four chapters provide the definitions and context which form the foundation for remainder of the book. The first chapter contains a definition of the word Collaborate copy and pasted from a dictionary. This seems to be a secret agreement for authors of such books: always show the dictionary definition of your book title’s keyword near the beginning. The author then describes Collaborative Cultures and splits the cultures into four categories: command and control, competence, collaboration and cultivating. I can see how each has it’s own time and place. I think command and control would be perfect if all of the following hold: 1) the commander has successfully completed the same exact project in the past 2) the commander has in depth knowledge of all aspects of the project 3) the project members lack any exceptional skill set for the project. The competence culture is akin to the United States being a Republic. The best and brightest are chosen to enter the government and run the country. Okay, maybe that was a bad example. A cultivating culture is where members are encouraged to grow and learn. Great for academic arenas but not for companies who hire people to accomplish goals. And of course, a collaborative culture is the main theme of this book.

I have a couple of gripes with the chapter about collaborative teams. The first is an oft repeated illustration that I am starting to take objection to. It’s the widespread idea that when teams are confronted by change they turn hostile. In the author’s words, the people become annoyed, frustrated, and defensive. Perhaps I am fortunate but I have never witnessed this behavior in my career. Most of my coworkers reacted professionally in these situations. Naturally the people had many questions before accepting the change. This is good, as following with blind faith encourages people to let their critical thinking skills rot. I hope the author does not misinterpret this period of questioning as being defensive; it is rather a period of learning. If the agent of change can present cogent arguments then the members will happily welcome the changes, at least in my experience. I am suspicious that the author is using a straw man argument here.

The second is the idea that people need some anxiety to perform well. Numerous scientific studies have shown a myriad of unhealthful effects of prolonged anxiety. Employees should plan on working for the long run, not in stressful sprints. And the very idea that people need to be threatened to perform well is repulsive to me. Just like team members should expect mutual accountability among members, I expect the same between my employer and me. I take pride in delivering my best work on a daily basis. When managers reduce their tactics to anxiety inducing threats it shows utter disrespect for the employees.

Beyond those two gripes, the chapter did point out some interesting classifications of team members. The author states that the most successful teams have a mixture of personalities that combine synergies well. This makes sense, but I would also suspect that another reason for this is that the personalities represent different skillsets of the members. The Dominance or Drive members probably do most of the managerial items. The Influence members probably are very apt to collect user input and brainstorm new ideas. The steadfast members are probably skillful at doing the necessary grunt work that others would ignore. And the conscientious members are probably skillful number crunchers and fact checkers and are useful for specification writing and quality assurance among others. So I think the skillsets augment the personalities and vice versa.

Chapters five through eleven gets our feet wet with some gritty details of meeting preparation. Admittedly I have not seen many of her suggestions in action. The author categorizes types of meetings: status, planning, working session and retrospective, pretty self explanatory. After giving some precepts on how to conduct oneself as collaborative leader, which by the way should be practiced in general in my opinion, the author starts providing some guidelines for the meeting coordinator. Some seem like a lot of work, such as surveying the participants, and I’m not sure that guideline is necessary if you know your coworkers well enough. In her “Setting the list of attendees” section, she insists that only employees who absolutely need to be at the meeting should attend. I have been to plenty of meetings where this is not the case. I think her subsection “Their preparation for the Meeting” should be at the toplevel of her guidelines. She lists items such as “Reading to do”, “Materials to bring”, etc. This could help many of the working session meetings that I have attended be more effective.

On a side note, I have mixed feelings about daily status meetings. I know project leads loves them so they can report progress to the stakeholders. But the other purposes the author lists, such as bringing forth any impediments to your project, I usually handle separately without the need for the meeting.

So I’ve come up with a solution that would hopefully make all parties satisfied. After each employee is done working for the day, they will email 1) what they have done, 2) what they plan to work on tomorrow and 3) what problems are getting in their way to an administrative assistant. The next morning, the administrative assistant will in turn gather all of the updates, organize them into the correct medium and either post them to a wiki, email them or both. Ideally this will happen before all the employees arrive to work the next morning. It might be a case where contracting this work to a company in a different timezone would be beneficial.

While I would love to see if the above would work, later in the chapter dealing with distributed teams the author does warn that face to face contact and verbal communication is important for the team. So perhaps it would only be suitable to replace short status meetings where the members have plenty of contact amongst each other throughout the day.

The author continues her meeting preparation guidelines by explaining how to prepare the agenda. She makes an interesting comment about how much time a meeting coordinator should spend preparing for a meeting. A general rule is to spend twice the expected meeting length for meeting preparation. Not only would following this rule make for more effective meetings, but I bet it would cut down on the number of meetings I would have to attend!

The meat of the agenda is a set of questions that will lead to the purpose of the meeting. The author does explain that deviating from the agenda is okay as long as there is a consensus. She also recommends estimating the amount of time each agenda item will take. She says it is best to post the agenda in the meeting room, along with ground rules and the meeting’s purpose. Each meeting should result in an action plan that provides each attendee a task to move the project forward. She also advocates having a separate communication plan, but I don’t see why those tasks cannot be rolled into the action plan. Next she gives some tips about setting up the meeting room and what food and beverages to provide. Nothing too profound in that section.

The next group of chapters are about techniques for actually conducting meetings, all from the facilitator’s point of view (minus the guerrilla facilitation chapter). There is no lack of details in these chapters. The author covers everything from what style paper to use for timelines (use rolls of butcher paper found at your local art supply shop) to managing dysfunctional attendees. A few reoccurring words of advice the author stresses are 1) always know the purpose of the meeting 2) time box 3) use a parking lot for discussion items that should be addressed later 4) hit the timer and say nothing else. The author seems to list that last item every time the facilitator is to ask the group a question. Overall the author did a very thorough job covering the techniques.

The last section dealt with collaborating with small teams and distributed teams. Nothing groundbreaking here, most of her recommendations stayed in align with conducting normal meetings.

Just like with The Wisdom of Teams, I enjoyed the anecdotal examples the most. So much so, that if I would have been hired as the book’s editor, I would have presented those stories at the beginning of each topic rather than after. I believe this would have engaged the reader more and switch the learning style from passive to active. If you read the stories first, you will be actively trying to identify the problem before hand, and the author’s explanation afterwords would confirm or correct your judgment. This would have made for a better learning experience for me.

In looking back at the two books, both seem to advocate against dominating managers from getting in the way of performance. I would have found it interesting if the authors investigated Holacracy organizations. [1] [2]

I believe a copy Collaboration Explained should be available in every office. It makes a great reference and go-to guide for every meeting facilitator. I hope to see the techniques described in the book being used throughout Trinet and will encourage its instructions when I attend my next floundering meeting.

[1] http://holacracy.org/ [2] http://en.wikipedia.org/wiki/Holacracy