Fast Collaborative Decision Making

By, Christian Kaiser

In previous posts, I wrote about being crisp about who the decision makers are, and a simple process to break ties. Both help create nimble, well-informed organizations. Today, I will outline how to build on this foundation to implement technical decision making that scales well to organizations with dozens of senior technical contributors, but still allows making decisions quickly and effectively.

Let’s take a look at what we want to achieve.

Ideally,

• decisions are made quickly (expediency)
• the collective time spent on this process is minimal (efficiency)
• all stakeholders plus a broad set of other contributors are able to bring in their knowledge and experience so that the best possible decision can be made (inclusiveness, collaborativeness and cooperativeness)
• everybody who needs and/or wants to know is fully informed about
  • what is being decided,
  • when the decision making will take place,
  • whether a decision has been made, and
  • what the final decision was (transparency)
• decisions stick until there is significant new information (effectiveness)

In my experience, there is little refined culture around technical decision making in many organizations, and the resulting ad-hoc process regularly misses some of the goals above. I’m sure the esteemed reader can recite several examples off the top of their head.

Here is one that illustrates several misses:

A small group of engineers (let’s call them Team A) makes a high-impact technical decision after careful deliberation in several meetings and rolls it out to the rest of the company.

Then others (who had not been involved in the decision process and therefore hear of the decision for the first time) quickly point out a number of flaws, some of them seemingly quite serious.

It turns out that Team A had actually thought of some, but not all of the flaws because they had not been aware of some technical detail outside of their area of expertise.

The flaws that were considered were traded off against other advantages. However, Team A did not communicate that part.

There are only ugly choices at this point:

• Team A admits to the issues they had missed, then goes back and address them. This requires honesty, is probably somewhat embarrassing and will take additional time.
• the company can move on based on the flawed decision. Less painful and more expeditious, but obviously problematic.
• some variation or combination of the above

Let’s assume Team A chose to fix the decision, and after several months, the company has made great progress in implementing it. Some of the original decision makers have left the company, switched projects or got promoted into a less hands-on role.

The project is now in the hands of Team B, comprised of smart and experienced engineers. However, none of the members of Team B were in the room when Team A made the original decision, and since it was not documented, they have no way of knowing why and how it was made. One of the team members points out a major drawback of the plan of record that does not seem to have been considered by Team A, so they get together to discuss a remedy.

There are four possible outcomes in this situation:

• Team A had not considered the flaw. Team B recognizes that correctly and modifies the plan to avoid the flaw. This is a positive outcome because it decreases overall project risk. Perhaps late, but better late than never.
• Team B cannot determine with certainty whether Team A had considered the flaw or not, assumes that it did and dismisses the concern. In this case, a project risk that could have been fixed remains, plus the team walks away with the unease of uncertainty. Overall, a big negative.
• Team A had considered the flaw, and Team B reconfirms their original decision. This is a negative outcome. The team lost some time in the discussion, but at least there are no new additional project risks.
• Team A had considered the flaw, but Team B assumes they did not, thus not investigating why they had traded it off. Team B then decided to change the plan, leading to additional work and later, materialization of another (worse) flaw that is unknown to Team B as of the time of decision. This is the most negative outcome as it adds risk to the project, some of it yet unknown.

The astute reader has probably noticed that only one of these outcomes is positive, and that better communication about the original decision could have avoided most of the downside.

Other examples for suboptimal decision-making processes that may be familiar:

• consensus-based decision making – highly inefficient and often fails to create good decisions (or any decision at all)
• failure to have the right people in the room – too many or too few

A Better Way 

Let me describe a decision-making process that I’ve found to allow a great balance between the tradeoffs while still achieving the goals. It consists of three phases: Drafting, Review and the Decision Meeting.

The Drafting Phase

The process begins when a team identifies the need for addressing an issue that requires non-trivial exploration and investigation – more than can be done in a meeting or in the hallway. For example, a client-server protocol is needed. Or the scope of a new middle tier service needs to be defined. The team identifies and assigns one or more people to investigate the issue and draft a proposed solution. The drafting phase typically has a deadline of less than 2-3 weeks in the future. If that seems too short for the issue at hand, it may be useful to break the task into parts that can be addressed individually.

The goal and desired output of the drafting phase is a document that describes a proposed solution at some level of detail that’s deep enough for thorough understanding and review by all the stakeholders, but that is still coarse enough so the document can be reviewed in less than an hour of time (e.g. three to five pages of technically dense material).

The draft must also include:

• a description of the known requirements at the time of the writing,
• any assumptions about unknowns that were made, and
• a high-level description of design alternatives and why they were discarded.

The Review Phase

At the end of the drafting phase, the document is opened for review by the team, by virtue of one of the drafting team members sending out an announcement like this:

From: tigerteam@bacon.com
To: eng-all@bacon.com, product-all@bacon.com
Subject: ACTION REQ’d: Design Proposal for Client/Server Protocol Ready for Review

All,

The first draft of a design for the new client/server protocol is ready for review! (link)

Please review it and, if you have concerns, ideas or any other relevant information, please leave them as comments in the document. We would like the stakeholders (Dilip, Frank and Kathy) as well as Jeff to review and comment. All others are very welcome, but optional.

We will work to address and resolve your comments quickly, but please don’t delay your review so we have time to react. We will meet 8 days from now on Thursday, April 7th at 10am in the Sequoia conference room to discuss and decide.

Comments are due 24 hours earlier, on Wednesday, April 6th at 10am at the latest, to give us a chance to process them before the meeting.

Now is the time to get involved! We appreciate your input.

The “Tiger Team” (Lily, Joe and Wu)

Please note the broad distribution and the clearly set expectations.

The broad distribution makes sure that everybody who would like to be involved will know about the matter to be decided on, and the fact that it is up for discussion at this time.

In this phase, it is mandatory for stakeholders and a set of additional contributors chosen in advance to read and understand the document, and optional for all other team members. The voluntary nature of the latter allows non-stakeholder team members to choose freely between contributing their cognitive cycles and experience, or to opt out of the time commitment if they have more pressing stuff to do or if they trust others in the team to provide adequate input and feedback.

This is a nice compromise solution for the conundrum between being inclusive by allowing everybody to provide input and the cost of the time commitment involved. It is my experience that people who care about the mission and get a chance to provide critical input are strongly motivated to do so, and will make time.

The review phase should be no shorter than two or three working days to give everybody the time to respond at a time that’s convenient for them, and no longer than about a week in order to maintain the proposal’s focus and energy.

Review Mechanics

Google Docs provides a very powerful mechanism for review – it allows everybody to review the same document at the same time even as it changes, and comment on clearly delineated parts of the document. Others can respond to a comment or “resolve” it. It’s like a simple issue-tracking system, but rendered inline in the document, and updated in real time for rapid collaboration. It’s amazing to watch sometimes how comment threads pop up and grow within minutes.

Best practices for working with this feature:

• only the document owners are allowed to edit the text of the document, all others can comment. This can be enforced by setting comment/edit permissions as required.
• everybody (document owners and reviewers) should engage to allow the maximum amount of evolution of the document. Avoid waiting for close to the deadline to make changes.
• document owners can and should resolve comment threads as soon as possible after making changes that address the comments. Example:
  • A reviewer discovers a typo or other oversight and creates a comment to that effect. Later, one of the document owners simply fixes the text and resolves the comment.
  • This could range all the way to adding whole sections to the document based on the feedback.
• After the review phase has ended, the document owners should distill remaining (and sometimes lengthy) comment threads into an “Remaining Open Issues” section in the document to prepare for the decision meeting.

The Decision Meeting

After the review phase, the team comes together in an in-person meeting to make decisions. Specifically, the decision to be made is to either “ratify” the proposal and make it the new plan for record, or to do another iteration. It is important to insist on these being the only possible outcomes.

The invitation for such a meeting could look like this:

From: tigerteam@bacon.com
To: dilip@bacon.com, franks@bacon.com, kbeyer@bacon.com
Cc: eng-all@bacon.com, product-all@bacon.com
Subject: ACTION REQ’d: Design Proposal for Client/Server Protocol Ready for Review

Thanks for your participation in the review of our draft design for the new client/server protocol! With your help, we made great progress and caught several issues.

We will meet tomorrow, Thursday, April 7th at 10am in the Sequoia conference room to discuss all unresolved feedback (see document (link)), and, if things go well, make a decision on the spot. Everybody who has participated in the discussion should have received a meeting invite. If you’re marked as optional in the invite, you may attend, but don’t have to.

Again, we will *not* review the draft in the meeting, but just go through the unresolved issues. You’re expected to be familiar with the document.

If the issues are sufficiently resolved, the stakeholders (for this matter: Dilip, Frank and Kathy) will make a decision in the meeting!

See you tomorrow!

The “Tiger Team” (Lily, Joe and Wu)

Again, please note the clearly stated expectations and deadlines, and an explicit list of the stakeholders (and therefore decision makers).

The required attendees for the meeting are:

• The document authors
• All stakeholders for the matter at hand
• team members who participated in the review and whose comments are still unresolved at the time of the meeting

Other participants in the review are invited as optional.

This one’s important: If a stakeholder cannot attend, they must send a delegate with decision authority. If a stakeholder is not present (either in person or with a delegate), the meeting must be postponed until all decision makers are in the room.

At the time of the meeting, everybody is expected to have read and understood the document. The meeting host allows only discussions about comment threads that have not been able to be resolved, not about the proposal per se.

If there are no unresolved matters, there is no discussion, and the stakeholders immediately move to make the decision to ratify the draft. Thus, the meeting may end long before its scheduled end and everybody in the room gets some time back. Or, if this is the expected outcome, the meeting host may schedule multiple decisions for the same time slot.

If unresolved issues do remain at the end of the allotted discussion time, the stakeholders can either make a decision anyway, or ask for an amended proposal. In this case, the process is reset to the drafting phase (perhaps with a shortened review period if the changes are not major).

Executed well, this process is very efficient. I’ve seen groups make 2-3 high-confidence decisions about meaty technical matters within a 60 minute meeting (after some practice, of course!).

After the Decision

If the proposal is ratified, the document is updated with any new material that came out of the review or decision meeting, and becomes plan of record. It will be archived in a place where it can be easily discovered. This allows everybody in the company to learn the details and also the history of the plan of record in the future.

With the decision, the team implicitly agrees that the plan of record will not be re-discussed unless substantial new information has come up that may invalidate the decision.

In that case, the team would likely follow the same process again, starting with a new draft (that refers to the old ratified proposal, of course, and explains what has changed).

Summary

The process described above meets many desirable criteria for decision making processes.

It is transparent, collaborative, cooperative, inclusive and participatory, and therefore well-received in organizations that value these principles.

In large teams, the process will typically take between two and four weeks from inception to decision. This is a good compromise between speed, cooperativeness and thorough communication. In smaller teams, it could be a lot faster (e.g. a couple of days for teams of 5 or less).

In any case, decisions will still be made quickly once the context is available and reviewed because there is no consensus required – it is up to the stakeholders.

—

This concludes my three-part series on organizational best practices (part 1 and part 2). In upcoming posts, I will write about other aspects of organizational culture (e.g. team building, compensation).