The decision mosaic: Every piece in place

Third in a series on group decision-making, based on Ch. 10–11 of Making Meetings Work. The previous post introduced decision crystallization.

As described in the previous post, a substantive decision is not monolithic but a collection of smaller decisions. Tropman (Ch. 11) calls these the decision elements and taken together they form the decision mosaic. When meeting to make the decision, its elements are best considered in a certain sequence, one that minimizes back-tracking and organizes the elements into an elegant pattern. Where do you start?

How do decision elements depend on each other?

Out of all the elements in the decision mosaic, at any point in the discussion, one will likely be the determinative element, the one upon which the rest depend. This element fixes the context in which the others will be decided, much as a striking piece in a mosaic draws the eye and the viewer sees all its neighbours in relation to that piece.

In the last post, I cited Tropman’s example of a meal’s main course as the determinative element in planning a meal, setting a dominant flavour against which the side dishes provide contrast. Although software teams rarely do meal planning, we’re familiar with dependency analysis, from the practice of identifying and managing dependencies between system components. What sorts of dependencies might we have to untangle in the mosaic of a typical technical decision?

Software development as unfolding decisions

In software development, a decision is rarely “green field”, unconnected to other choices. Rather, a project unfolds via a series of decisions, decided by meetings of representatives of the relevant groups.

When exploring a decision at project start, the determinative element is often the terms of reference: The boundaries that are already set by external authorities or circumstances. You will want to ensure at the outset that everyone understands the bounds circumscribing the group’s choices.

Example: Setting a latency objective

As the project continues, the constitutive elements of the decisions and their interdependencies will change. For example, when designing a microservice, one of the first decisions will be setting its service level objectives (SLOs). These are the determinative element for many other decisions, such as designing for tight latencies or selecting a failure recovery mechanism. A team will typically have to know such objectives—including those service indicators for which there are no objectives—before making many other choices.

The decision for the SLOs will itself be a mosaic of smaller elements, such as:

These in turn would constitute their own mosaics. Some might even spawn a separate project, such as estimating seasonal demand variation or surveying availability statistics for competing services. In that case, the team would either have to postpone defining the SLOs or else set provisional levels, subject to revision upon conclusion from the subproject. While this process can be frustrating, recognizing that the determinative element cannot be decided without further information also contributes to efficient decision-making, as it prevents the group from committing to decisions on other elements that might be overturned when the determinative one is decided later, once full information is available.

Decision rules aid setting a determinative element

The decision rules may be used to select the determinative element. If you know that one element of the decision mosaic elicits particularly strong responses, you may choose to make it the determinative element and consider it first or, equally valid, defer it for later. If you start the discussion with this element, you gain insight into which choice the intensive rule will utlimately recommend. If you instead begin by deciding a few simpler, less-contentious elements, the group’s sense of accomplishment and progress can develop a useful energy for tackling a difficult item. There is no single right agenda, so long as whichever you pick is informed by the emotional dynamics of the group. That will make it far more likely to lead to a cohesive, well-accepted final decision.

Proposing a determinative element to the group

How does this work in actual meetings? Locating the determinative element, the constituent of the overall decision mosaic to tackle first, is an approximate process. You have to do it in real time, accounting for new points and emotional shifts in the group, all the while scanning the group for levels of participation, occasionally tempering members who tend to overcontribute and soliciting opinions from the more timid members.

When the group is addressing a complex decision, once you have identified a determinative element, you need to propose that the group focus on it. If this seems daunting, bear in mind that groups are often desperate for exactly this sort of leadership. There’s an odd but persistent aspect of group psychology, that a group will tend to talk around a choice but will never be able to decide on it until it is expressly stated. If you propose to focus on a specific element of the decision, group members will typically be grateful and more importantly, take your suggestion and apply themselves to that focus.

The decision rules can aid setting a determinative element

You can introduce the focus informally, with something like, “Our capacity planning and choice of technology stack all seem affected by the service’s latency objectives, so how about we focus on setting those percentiles first?” There is no need to use the nomenclature described here. The notions of “determinative element” within a “decision mosaic” are useful for identifying the items you, as decision leader, need to identify whereas simple descriptive language is enough to set a direction for the group.

From determinative element to decision

Choosing a determinative element and setting it as the group’s focus is only the first step. You also need to know how to lead the group to converge on a decision for that element and move on to the next determinative element. That will be the subject of the next post.

Appropriate preparation improves the process

In this post, I have focused on identifying the decision elements in real time, amidst the helter-skelter of a meeting. This is only part of the process. In fact, while the final parts of this process must be done in the meeting, you will be most successful if you spend time preparing beforehand.

In these posts, I am focussing on Tropman’s Chapters 10 and 11. His first nine chapters recommend best practices for meeting preparation. I don’t mean to discount the importance of those activities with this series. I focus on the decision-making process in meetings because that is the outcome that matters, the one that grabs readers’ attention. Working backwards from this beneficial outcome, the value of preparing for a meeting becomes apparent.

As a rule of thumb, when I am scheduled to chair a meeting, I like to spend as much time preparing for it as is scheduled for the meeting itself. In fact, should I find myself only spending a few minutes setting the agenda for a one-hour meeting, I reflect on my choices to see if there’s something else I need to do. Sometimes meetings only require minor preparation but I am surprised at how often apparently simple agendas have hidden complexities, like reefs just underneath smooth water, threatening to rip the keel from your boat.

Informal conversations with meeting members can give you the outlines of issues before entering the meeting, averting unpleasant surprises in the meeting itself. Listen for such issues as:

These discussions will not reveal every issue that might arise in the meeting but what they do reveal will allow you to organize your thoughts in advance. Forewarned is forearmed.

Practicing

This concepts are difficult enough and their interplay in actual meetings is fast enough that before actually trying to intervene in a meeting, simply practice identifying them. At your next meeting to make a substantive decision, note down all the different elements. How do they interdepend? After the meeting, reflect a few minutes on how the choices unfolded. Did the group select one element after another, with minimal backtracking, or did were they trapped in cycles of re-decision? With benefit of hindsight, can you identify a more efficient, effective sequence of elements that the group could have followed?

As you become more comfortable identifying decision elements, organizing them into the larger mosaic, and choosing the one that influences most of the others, you will be able to identify them in the maelstrom of an actual meeting. In the next post, I will describe how to lead the group to selecting and deciding the elements in efficient sequence.