Lazy Consensus

Sharing requires consensus. Getting several groups to agree is hard, requires compromise and consumes time and effort. As a community gets bigger getting everyone to engage and agree gets progressively harder. However, making prompt decisions is a critical activity for any inner source community. For example:

• Defining the shared forward technical strategy for a capability.
• Planning how to execute a complex change, and working together to do so.
• Deciding who does a piece of unpopular but critical work.

How to Agree Efficiently

Two key principles to agree efficiently:

1. Do it asynchronously. This is a fancy word for ‘write it down’.
2. Learn from open source and be lazy.

Write it Down

Good advice already exists about how to optimise for asynchronous work:

• Dropbox Remote Toolkit
• GitLab All Remote Handbook
• “Collaborate with kindness” in Slack

The key points are:

• Communicate by writing or recording video clips.
• Use paragraphs not sentences: an asynchronous conversation is slow if you treat it like a normal conversation.
• Don’t be asynchronous for urgent jobs like incident response.
• Ensure all participants are doing several things in parallel: asynchronous communication requires you to wait, so participants need to be able to pick up other work while they do so.
• Still use synchronous time – but save it to prepare for next asynchronous period, discuss sensitive issues or make complex decisions.

A benefit of asynchronous communication is a written record of technical decisions similar to ADRs. This means you can ‘catch up’ with a discussion you join half-way through – a key enabler for a large community – and they form a valuable reference for the future.

Be Lazy

Lazy consensus means that when you think you know what the community would like to see happen, you can assume that you have consensus in favor of the proposed work and get on with it. You don’t have to insist people discuss and/or approve your plan, and you certainly don’t need to call a vote to get approval.

Source: Apache Community Lazy Consensus Doc

Lazy consensus attempts to avoid unnecessary discussion or wasted time by using the following process for agreement:

1. Publish a written proposal to an appropriate audience with a deadline for feedback/objections.
2. Assume silence is agreement.
3. Discuss any concerns raised; encourage alternative solution proposals alongside any concern.
4. Assume approval after once you have addressed all concerns and the feedback deadline has passed.

This approval process is both asynchronous friendly and time efficient. It does however require an engaged audience: missed proposals and late objections cause disruption and upset. A skilled proposer judges the engagement level and reduces this risk by leaving a longer consultation time, or socialises the proposal more explicitly with key stakeholders.

Assuming silence is agreement is efficient, but it has the disadvantage of ambiguity:

The problem with no response is that there are five possible interpretations:

1. The post is correct, well-written information that needs no follow-up commentary. There’s nothing more to say except “Yeah, what he said.”
2. The post is complete and utter nonsense, and no one wants to waste the energy or bandwidth to even point this out.
3. No one read the post, for whatever reason.
4. No one understood the post, but won’t ask for clarification, for whatever reason.
5. No one cares about the post, for whatever reason.

Source: Bryan Warnock

The key to lazy consensus is to avoid ambiguity by ensuring the right people see the proposal, and that they have the opportunity to object. You can reduce ambiguity by:

• Publish proposals in a standard place & format. Document this for your community.
• Notify the right people so they know about new proposals. This may be an email, a slack channel, a meeting. For example, defining capability maintainers helps guide who the “right people” are.
• Publish proposals at the right time. Don’t expect engagement on a non-urgent proposal in the middle of a rush to reach a hard sporting deadline.

Don’t Be Too Lazy

Lazy consensus is an efficient starting point, but has limitations. Some aspects of change require explicit buy-in from certain stakeholders, who must explicitly approve the proposal.

For example:

• When a change introduces a new 3rd party dependency the security, data protection and legal teams must have time to review this usage. Such teams typically require you to wait for an explicit approval before proceeding.
• When a change is both significant and non-reversible, such as a breaking change to a core API, you may need to explicitly seek approval from a wider group of stakeholders.

In these cases you can use lazy consensus to reach a draft proposal, then seek explicit approval from the relevant groups. This hybrid approach combines the efficiency of lazy consensus with the explicit approval required for some changes. Clearly agree (and document) with your stakeholders who you can use lazy consensus with, and who requires you to wait for explicit approval.

Example: Significant Change

A simple but effective convention is for the proposer to raise a GitHub issue on the capability repository describing the change, why they need it, and any alternatives they considered. An asynchronous written discussion can then follow. To ensure the required engagement for lazy consensus, you can highlight the proposal in a community slack channel. GitHub issues allow ‘+1’ type reactions, and the same is available on any Slack message. The proposer can judge the level of engagement based on reactions and comments and re-advertise if necessary.

A more formal approach that has the benefit of producing an edited summary for future reference is to define a request for comment (RFC) process. The proposer raises a pull request against a capability repository to add a markdown proposal document, usually with a standard template and naming convention. Advertise this in the same way as a GitHub issue to encourage written discussion. However PR review semantics and notifications are also available, with the final result an edited proposal document for future reference. The proposal has a clear end point: a merge (accepted), or closed (rejected).

For example:

• Amazon ADR Guidance : guidance on architectural decision record process from Amazon.
• Rust RFC repository : a simple but effective RFC process.
• Golang Proposals : interesting use of ‘likely accept’ and ‘likely decline’ statuses to prompt the community for final feedback.

Example: Strategy Planning

You can treat strategy planning exactly like significant change, but as strategy is more complex and expansive it usually deserves a different treatment.

• Goal alignment and ideation sessions are worth spending some of your limited available synchronous time on. In this case allowing asynchronous preparation (e.g. submitting ideas via a Miro board shared in advance) helps to focus the workshop time and is more inclusive for those who can’t attend. For large communities, running multiple sessions in different timezone-friendly slots encourages more engagement.
• The result of such synchronous sessions is often obvious consensus in some areas, and clear contention in others: if this is the case a natural next step is to use your normal process for significant change to reach consensus in each area (e.g. via RFC or written discussion).
• Strategy planning needs a clear leader (e.g. the capability owner) who uses their judgement to determine which topics to agree via a normal asynchronous process; and which are too complex or too politically sensitive and require direct synchronous engagement.

Example: Unpopular Work Assignment

In this example a challenging priority call exists that affects several divisions. Each division has their own prioritisation mechanism, but all require quantified benefits, teams impacted, and effort/cost to make a decision. While the priority decision itself is likely made synchronously, you can create the document that informs that decision asynchronously.

• You can use a RFC-like process to create a document to submit into a division’s prioritisation process, e.g. a lean canvas. Use a master document (e.g. GitHub markdown) with the required information which is then re-formatted (e.g. lean canvas slides) for different priority processes.
• Submit the agreed document for prioritisation into the most appropriate (or several) divisions.

---

by: Rob Tuley
in: 03 May 2023
tags: WoW
category: Academy