# Consensus vs Consent

## The What

**Consensus**: everyone says yes. It is **transparent** and **collaborative**, but **slow**. You might need to do [Nemawashi](/tech-lead-handbook/product/nemawashi.md) to get the border consensus. Check out [consensus mechanisms](https://ethereum.org/en/developers/docs/consensus-mechanisms/) in Crypto to get a better idea of why it is slow.

**Consent**: no one says no. It is **transparent** and **fast**, but **less collaborative**.

When you come up with a situation, Which strategy you should use and when?

## The How

Some scenarios I can think of in my daily workflow

### Ship it and iterate it later.

<mark style="background-color:green;">Immediate Action - no agreement is needed</mark>

For small bug fixing or small changes, just do it and give people a heads-up.

A high level of confidence is required. The change works as expected and doesn't break functional or non-functional requirements, it might not be perfect, but it is good enough to ship.

### Ship it if no objections.

<mark style="background-color:green;">A few minutes - no one says no</mark>

For small changes, give people a heads-up first before action.

You are confident in the change, but you would like to give people a chance to stop you.

### Request a second pair of eyes

<mark style="background-color:yellow;">A few hours - someone says yes</mark>

For small or medium changes, you would like someone else to help you QA your change.

It is not uncommon for new team members or junior developers. It is also a good way to share knowledge.

### Request reviews

<mark style="background-color:yellow;">A few hours or a day - someone says yes</mark>

For changes that are impacting customers, you should probably ask your Product Manager or UX Designer to review them first.

Be aware of the PM's tight calendar and be prepared for late response. You should probably try async (Slack, Email, Trello, Jira) over sync (Zoom, meeting). You should always QA your changes before sending them for review. Avoid silly mistakes and save time for both parties.

### Request sign-offs

<mark style="background-color:orange;">More than a day - someone says yes</mark>

Changes that require stakeholders' sign-offs.

You should have passed all internal reviews and polished the change to a point where it can be shipped at any time.

### Workflow changes

<mark style="background-color:red;">No rush. Be patient.</mark>

It will impact everyone's day-to-day flow. As a bare minimum, you should get the border consent, no one says no.

### Architecture changes

<mark style="color:red;background-color:red;">No rush. Be patient.</mark>

**consensus** - everyone says yes

You will need debates, challenges, and revisions to get the team engaged.

## :white\_check\_mark: Exceptions

Hotfixes

Non-functional changes

## :red\_circle: Red Flags

Handball the duty to someone else

Overuse extract pair of eyes

Try to please everyone

## :scroll: Tips

You can't make everyone happy.

{% hint style="success" %}
You can't make everyone happy.
{% endhint %}

{% hint style="info" %}
The purpose of communication is to move people to action
{% endhint %}

## :hole: Pitfalls

{% embed url="<https://thedecider.app/consensus-decision-making>" %}

{% embed url="<https://thedecider.app/consent-decision-making>" %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://jamiewen00.gitbook.io/tech-lead-handbook/product/consensus-vs-consent.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.