Консенсус — всегда ли это хорошо? Приведите примеры.

Консенсус — всегда ли это хорошо

Этот вопрос проверяет мое мышление, способность видеть grey areas, и когда быть твердым лидером.

Короткий ответ: НЕТ

Консенсус не всегда хорошо. Иногда это инструмент для скрытия неправильных решений.

Когда консенсус ХОРОШО

1. Стратегические decisions

Если мы решаем: "Нам нужна микросервисная архитектура", это affects всю компанию на годы.

Здесь консенсус важен потому что:

• Tech lead должен быть на борту (он implement)
• Lead engineer должен быть на борту (architecture)
• PM должна быть на борту (product impact)
• Если someone disagree strongly, скорее всего что-то важное missed

2. Hiring decisions

Hiring wrong person может destroy team culture.

Консенсус: если 3 из 4 интервьюеров скажут "pass", мы pass даже если один person likes candidate.

3. Major pivots

Если мы меняем entire product direction, нужен консенсус что старое solution didn't work и новое направление имеет смысл.

Когда консенсус ПЛОХО

1. Speed matters

Decision нужна быть made quickly. Consensus может быть slow.

Пример:

• Конкурент запустил фичу
• Нам нужно реагировать за неделю
• Консенсус может занять две недели

В этом case, PM должна make decision (при input) и move forward.

2. Creative decisions

Когда много мнений, часто результат это "bland middle ground".

Пример:

• Design team предлагает bold, innovative UI
• Engineering говорит: "это hard to implement"
• PM может быть conservative
• Consensus: middle ground который никого не happy

Better: PM decides "we go bold" или "we go conservative", с reasoning.

3. Когда есть clear owner

Sales leader знает что нужно customers. Tech lead знает что feasible.

Если я (PM) имею полный информацию и input от обоих, я могу make decision.

Я не нужу consensus от Sales и Tech, если я understand обоих sides.

4. Когда один person имеет stronger expertise

Если engineer говорит: "это database optimization невозможно", я should trust his expertise, even если другие disagree.

Consensus в этом case это waste of time.

Real примеры

Пример 1: Я был ПРАВ to force без consensus

Situation:

• Team wanted to redesign UI (beautiful, но took 3 месяца)
• Customers needed feature (был requested 20 раз)
• Design team wanted their vision
• Engineering needed clear requirements

My decision (without consensus): "We do the feature first (2 weeks). Then we redesign (2 months later)."

Design team unhappy. But мы launched feature в срок. Customers happy.

Если бы я ждал консенсус:

• 2 месяца議論 о UI redesign vs feature
• We launched оба позже
• Customers уже ушли

Lesson: Consensus может быть paralyzing.

Пример 2: Я был WRONG to не ждать consensus

Situation:

• Я хотел запустить marketplace feature
• Engineer said: "This requires major refactoring"
• I: "We don't have time"

My decision (without consensus): I force: "Let's do it quick, refactor later"

Result:

• Feature launched (happy me)
• Codebase became mess (unhappy engineer)
• Later refactor took 6 месяцев
• Technical debt killed future development

Если бы я ждал consensus:

• Engineer would explain: "1 month refactor now saves 6 месяцев later"
• I would understand the trade-off
• We would do refactor first (right decision)

Lesson: Sometimes engineer right, и consensus выявил это.

Когда PM должна быть твердой

1. Customer demand clear

Если 50% пользователей просили feature, PM должна push it even если team disagree.

2. Data supports decision

Если метрики show что direction правильный, PM может overrule subjective opinions.

3. Timeline critical

Если компания будет dead если не move fast, PM должна decide и move.

Когда PM должна ждать consensus

1. Стратегические pivots

Если changing entire product, нужен buy-in от leadership.

2. Large investments

Если требует 6 месяцев development, лучше be sure это right decision.

3. Organization changes

Если reorganizing team или changing processes, consensus важна for adoption.

My framework

Speed test:

• Если decision нужна быстро (дни), я decide с input
• Если есть время (недели), я seek consensus

Reversibility test:

• Если легко откатить (e.g. feature flag), я decide быстро
• Если hard to откатить (e.g. architecture), я seek consensus

Expertise test:

• Если someone имеет clear expertise (e.g. DB architect), я trust them even without consensus
• Если мнения equally informed, консенсус important

Stakes test:

• Если stakes low (minor feature), я decide быстро
• Если stakes high (platform decision), консенсус important

В interview

"Консенсус не всегда хорошо.

Consensus это инструмент, не goal.

Когда consensus important:

• Стратегические decisions
• Hiring
• Major pivots

Когда consensus медлительная:

• Speed matters (конкурент moved)
• Creative decisions (стает bland)
• Clear owner (я know right answer)
• One person имеет expertise

My framework:

1. Speed test: если decision нужна быстро, decide быстро
2. Reversibility: если легко откатить, decide
3. Expertise: trust expert even без consensus
4. Stakes: high stakes требует consensus

Real example: I wanted запустить feature, engineer said нужен refactoring первый. Я ignored consensus, forced feature launch. Later, technical debt killed development. Engineer was right.

Lesson: Consensus выявляет concerns которые я miss. Sometimes нужно listen.

But also: consensus могу быть paralyzing. If я have full информация и input, sometimes best decision это просто decide и move.

Good PM это balance между decisiveness и collaboration."