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).

Escalation as Tie-Breaker

By Christian Kaiser

In my previous post, I described how teams can remove obstacles by clearly defining who makes decisions for every area of responsibility in the team. The method includes assigning stakeholders who need to agree on every decision in the area.

An interesting aspect of it is that all stakeholders have the same level of authority over an area, i.e. all need to agree (or at least not disagree) in order to make a decision.

So what happens when the stakeholders do not agree?

I’ve observed teams become stuck when the decision is not being made and the dispute is just left standing. That is never a good option.

On other occasions, people have been more inventive and gotten things moving again, but not without breaking some rules. For example, I’ve seen one side just silently get going on the controversial project, thus creating irreversible facts. On the upside, the team can move on. On the downside, this behavior will undermine trust in the organization.

Why might intelligent people who belong to the same organization disagree?

Most likely, both sides have excellent reasons for their stance based on the context they have. For example, there may be insufficient or outdated context that needs to be communicated to one or both sides. Or perhaps the disagreement has exposed a question that no one had thought about thus far.

These situations clearly requires communication to, and action from people with the necessary context and authority. Simply put, the boss decides. After all, it is part of their job description!

Here’s how it can work: In case of a stakeholder stalemate, the next higher layer of the organization is informed and asked to make the decision (the “escalation”).

Ideally, that is just one person, but if there is no immediate common boss, it may be multiple people (e.g. the respective department heads). If these bosses do not agree either, the matter is escalated further. If needed, all the way to the top.

Doing so exposes the disagreement to a larger portion of the organization. That may come with discomfort. However, if all the obvious routes have been explored and the conflict is in fact due to a disconnect at a larger scale, it is the right thing to do and should be encouraged in every way possible.

Best Practices

So how does a boss help their team to make a decision? Three steps:

#1: The conflicting parties must give the boss the full pros and cons of the decision at hand. It is important that the boss fully understands them and demonstrates that understanding. If she fails to do so, it may create frustration and loss of trust (“I’m not surprised she decided the other way, she did not even listen to me / understand my proposal”).

#2: She then needs to make the decision.

#3: Last but not least, she needs to communicate why she made the decision this way. The reasons can actually range from “coin flip” to “judgment call” to “logical conclusion”. It’s important that there is an explanation so that people don’t have to make up one. The made-up explanation is typically a lot more dramatic than the real one!

At the end of the process, everybody can move on, knowing that a needed decision has been made. The party whose proposal was not chosen can rest assured that they have been heard and their reasoning was fully taken into account.

Potential Problems

What if people don’t know they’re expected to escalate, or are afraid to?

This is a common problem. The boss must re-iterate their readiness for escalation often, and avoid emotional behavior when it happens. A simple eye roll will discourage people strongly! And since escalation doesn’t come naturally in many organizations, the boss should actively explore her blind spots, find out when escalations that should be happening are not, and teach the team when to seek her out for decision making.

What if the boss is not making the decisions she needs to make?

In that case, the boss is failing her team. Perhaps it’s time for the team to escalate the inaction to the next level up.

What if the boss deals with escalations a lot, and it’s taking too much time?

First and foremost, making decisions is a crucial part of the duties of a manager, and should be highest priority, especially if progress is blocked. However, one clearly would want to minimize the occurrence of escalations.

Some common reasons for escalations and how to address high frequency occurrences:

• Lack of context in the teams – probably the most common reason. The remedy is to diagnose the disconnect and communicate the resolution.
• Unclear responsibilities – another form of lack of context. See above and my last post.
• Conflicting personal motivations –  this is the hardest to diagnose and fix. For example, Bob is pushing for a decision because it will help get him promoted, even though it may not be the best for the company as a whole. It takes grit and determination to address these problems, especially in bigger companies.

What if decisions are regularly escalated so highly up the hierarchy that it’s difficult for the boss’s boss’s boss to know enough details to make a good decision?

It may be time to think about changing the structure of the organization, e.g. by creating a “common boss” lower in the hierarchy.

Conclusion

As part of a series of articles on organizational health and best practices, we’ve looked at escalation, an often underused method to reach quick decisions and resolution of larger disconnects.

In my next article, I’ll use these principles as a foundation for best practices for rapid technical innovation in teams of any size.

Who’s Responsible For What?

By Christian Kaiser

Imagine everyone in your company or department knowing exactly whom to invite or not to invite to any given meeting. Imagine decisions being made without delay because everybody who needs to be in the room consistently is, and the total number of people in the room is always as small as it can be!

In my experience, there’s no better way to accelerate a project than by being crisp about who’s responsible for what, who needs to be involved when and how, and who doesn’t.

I found that a RACI-like method (applied quite informally) works well. It’s a usually quick and simple exercise, with a very high return on the time spent.

I’ll walk through the steps in the following sections:

Determining Areas of Responsibility

First, you will need to define the “areas of responsibility” you want clarity on.

The areas you use for your exercise can be as coarse or fine-grained as needed though, as long as everybody knows where the areas begin and end. To keep it simple, I like to start with few coarse areas and only split and refine when needed (i.e. if there’s a different assignment of roles needed for a sub-area).

Let’s use an example: Baconwrappr.com is a fictional small startup of a handful people. Everybody’s wearing a number of big hats, and their areas of responsibility are rather coarse: “Sales”, “Finance”, “Engineering”, “Marketing”.

As Baconwrappr.com’s business grows, they hire additional people. They now have James, a sales executive. Mike, one of the founders, still works directly with a few key clients who he has a personal relationship with. In order to reflect that, the group split the “Sales” area into “Sales (client X and Y)” and “Sales (everyone else)”.

The company also hired a great product manager, Sean. Now “Product” becomes a new area of responsibility that is separate from Engineering.

To record things for discussion purposes, I like to put them into rows in a spreadsheet, like so:

NB: Google Apps seems particularly well-suited for this purpose because it allows collaboration between multiple contributors, plus no documents are passed around in email, creating confusion about which one’s the right one and how to merge.

Assigning Roles

Then you need to assign roles for the appropriate people in the team, in each area. Start with putting the names of people on top of columns to the right, like so:

Assigning the roles is quite simple, since there are only a small number of roles to choose from. Here are the ones I use:

Owner

The person in this role drives the whole area of responsibility forward. It could be simply someone who actually does the actual hands-on work, or a delegate like a program manager, team manager etc., if a whole team covers this area. This is the person who drives the decision process and calls the meetings. Please note that ownership means just that, and does not include final decision authority.

There can only be one owner for each area of responsibility. If you find yourself thinking about creating multiple owners for some area, think about whether your should split the area instead.

Stakeholder

A person in this role needs to agree when decisions in this area are made. Owners are also stakeholders by definition. Stakeholders are mandatory attendees to decision making in this area. If they cannot make it, they must send a delegate with decision authority. Or in other words, no decision that affects the area can be made without them.

There should be as few stakeholders as possible to be able to make decisions quickly. Ideally, there’s just one: the owner. But for a variety of reasons, many organizations choose to have more than one pair of eyes on the area.

Before assigning someone stakeholdership or asking for stakeholdership yourself, ask yourself whether the team could instead find ways to trust the owner or other existing stakeholders to make decisions. After all, stakeholdership comes with a commitment of time and focus. For example, the team might decide instead to increase the owner’s level of context by training them, or by bringing them into conversations they’re not part of yet.

Informs decision

People in this role are invited to meetings or are otherwise consulted when decisions need to be made. They are not mandatory attendees at decision meetings and are also not required to agree with a proposal.

To the contrary, if you find that you would like someone to be mandatory attendee to decision making meetings, they should probably be a stakeholder.

None

This is actually a very important role. Someone with this role in a particular area is not involved, e.g. not invited to the decision making meetings, therefore does not need to spend time and can focus fully on other areas. You’ll want to maximize the number of these.

 

In case you’re missing a role along the lines of “informed”: I like to simplify by not calling such a role out separately. In most small to medium size organizations, the default for this role should be “everyone”, at least for opt-in information channels.

Some people may argue that everyone in their organization already knows what each others’ role is, and that might certainly be true in their case. However, I have found it to be false in most cases. Specifically, it is often very difficult to organically disperse this knowledge crisply when new people come on board.

I was often surprised about how many disconnects were exposed after writing things down and discussing it with the people involved. For example, multiple people might think they’re the owner, or, even worse, it turns out that no one thinks they own a particular area.

Responsibilities are expressed as field colors at the intersection of people and areas of responsibilities. Pick your own color scheme! I’m using RED for owner, GREEN for stakeholder and YELLOW for informer.

Here’s baconwrappr.com’s matrix:

You’ll notice that it is not only clear how the roles are distributed in a particular area (horizontal), but also which hats and how many of them everyone wears (vertical).

I’ve seen very productive reality checks come out of this exercise, e.g. when someone realizes they cannot really own two major areas and be stakeholder in three more, or that a certain area has too many stakeholders. It’s often satisfying for the team to mutually agree on “downgrading” someone’s role, e.g. from “stakeholder” to “informs”, or even to “none”, because it likely translates into increased focus for the other (probably no less important) roles, and into faster decision making overall.

In our example, Mike, as a founder, started out wanting to be a stakeholder in all the areas, but then realized that he would be content (and already very busy) with informing Finance and Marketing decisions, and not being involved in Engineering decisions at all.

Communicating It

When the group is satisfied with the result, it’s time to communicate it to whoever needs to know (probably everybody). How you do that is up to you.

Since the semantics do need some explaining to folks who have not been part of the exercise, I’ve found it useful to go over the details with the team and have extensive Q&A rather than just attaching it to an email to all@.

Summary

• There’s often confusion about responsibilities, especially over time and through team changes
• A rather simple and short exercise can provide clarity and focus
• It allows to define the nature of involvement crisply
• The team can agree upon a efficient distribution of responsibilities after careful deliberation

Next Time

You may have noticed that I did not touch on what happens when stakeholders disagree. How can a decision be reached in that case? I will cover best practices around this in my next post.