How I communicate a decision people will not like

Open the problem before the decision closes. Argue the options in the open. Then follow up privately with the people who will not disagree in a room.

My principles

06 operating rules

Communicate before the decision is closed

Announcing a finished decision invites people to litigate it. Presenting the problem, the options, and the trade-offs while the choice is still open invites them to improve it.

Explain the problem, then the options, then the daily change

In that order. Most resistance comes from not knowing which problem the decision was supposed to solve, and what specifically changes on Monday.

Follow up one to one

Plenty of engineers will not disagree openly in a large meeting. The private conversation afterwards is where the real objections live, and those are usually the useful ones.

Name the trade-off you are accepting

Every operating change makes something worse. Saying which thing, out loud, is what separates a decision from a slogan. It is also what lets people challenge it on the merits later.

Watch the first cases and correct them

A rule is not adopted the day it is announced. I watched the first releases under the new model closely and fixed the ambiguous cases instead of assuming behaviour had changed.

A successful outcome does not redeem a bad process

If the feature shipped and the process was broken, the process was broken. Letting the result launder the delivery failure guarantees the same failure next time.

What that looked like

02 cases

A feature that succeeded and a delivery that failed

ASKfm · 2016-2021

Situation: We built a feature that identified rapidly engaging questions and promoted them to a wider audience using engagement, language, location, and user-selection logic. It was planned as a two-month MVP. It took about six months, because product requirements changed repeatedly after engineering had already designed the architecture around earlier assumptions. Parts were rebuilt. Scope expanded mid-flight. Product and engineering started blaming each other, and the release model hid the actual choice between scope, date, and quality rather than forcing it.
What I did: Made the trade-off explicit rather than arbitrating the blame: when product increased scope, engineering could not reasonably be held to the unchanged original date.
Refused to ship a degraded version to protect the date, and refused to abandon substantial invested work.
Kept the technical decisions with the engineer who owned them, including scheduled recalculation instead of reacting synchronously to every change in content weight.
Backed a configuration-driven ranking model so product could tune scoring without waiting for a release.
Used the outcome as the argument for changing the release model, rather than as evidence that the team had performed well.
Outcome: The feature launched successfully: average concurrent users nearly doubled and monthly active users rose by roughly 30%. I still describe the delivery as a failure. Every time changed requirements invalidated the architecture we should have forced an explicit re-estimation and a scope/date/quality decision, and we did not.

Product metrics are approximate historical recollection; the dashboards are long gone. The two-month plan against six-month delivery is the number I am confident in, and it is the one that matters here.

How I actually rolled the change out

ASKfm · 2016-2021

Situation: Changing the release model meant telling product leaders they could no longer keep adding work to a release. The business was declining and everyone was already under pressure. So, not a popular announcement.
What I did: Talked to product and engineering leads individually and collected their concerns before the model was fixed.
Presented the original problem first, then the options considered, then why this one, then the concrete new rules for scope changes and escalation.
Discussed objections in the open rather than deferring them.
Followed up privately with the quieter engineers, where the substantive disagreements turned out to be.
Watched the first releases under the new model and corrected the cases where the rule was ambiguous.
Outcome: Clearer ownership, and materially more honest conversations about scope and delivery. People did not have to like every decision. They understood why it was made and how to challenge it, which was the outcome I was after.