# Consensus vs Consent

## The What

**Consensus**: everyone says yes. It is **transparent** and **collaborative**, but **slow**. You might need to do [Nemawashi](https://jamiewen00.gitbook.io/tech-lead-handbook/product/nemawashi) 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>" %}