# How I explain decisions people will not like
Source: https://manaienko.com/how-i-work/decisions-people-dislike/
Author: Artem Manaienko

I want people to be able to tell me I am wrong. Especially when a decision makes their work harder. I explain the problem, listen before the decision is final, and make time for the people who would rather talk privately.

## My principles

03 operating rules

1.  [01 Bring people into the decision early](#practice-decisions-people-dislike-principle-1)
2.  [02 Explain what changes in their work](#practice-decisions-people-dislike-principle-2)
3.  [03 Make room for a private conversation](#practice-decisions-people-dislike-principle-3)

### Bring people into the decision early

When I can still change the decision, I explain the problem and the options and ask for feedback. I want to hear what I have missed while there is time to do something about it.

### Explain what changes in their work

I go through why we chose this option, what we give up, and what people will need to do differently. They may still disagree. I need to be clear about who owns the decision and how to raise a problem with it.

### Make room for a private conversation

At ASKfm, many engineers would not challenge a decision in a group. I followed up one to one and heard concerns that had not come up in the meeting. I could not assume silence meant agreement.

## Changing the release rules at ASKfm

01 case

### Asking product and engineering to work differently

ASKfm · 2016-2021

**Situation:** A roughly two-month MVP had taken about six months as requirements kept changing. Product and engineering were blaming each other. I wanted to change the release rules, which meant asking product leaders to stop adding work without reconsidering the date. The feature launched successfully, but I still judged the delivery process a failure. The business was declining and everyone was already under pressure.

**What I did:**
-   Spoke with product and engineering leads individually about the problem and their concerns before presenting the change to everyone.
-   Explained the options, the trade-off we were accepting and why we chose one main feature per release. Went through the new rules for scope changes, re-estimation and escalation.
-   Discussed objections together, then followed up privately with quieter engineers.
-   Watched the first releases closely and clarified the rules where people understood them differently.

**Outcome:** It became clearer who owned each decision and how to discuss changes to scope and dates. We still had disagreements and delays. The useful change was that people had enough context to question a decision and knew how to raise it.

The [release model itself](https://manaienko.com/how-i-work/delivery-when-scope-stops-being-honest/) has its own section.