Почему не работает практика 'open door policy' в IT-командах

Давным давно в одном богатом городе и компании я гордился своей open door policy.
"Моя дверь всегда открыта!"
А оказалось - это создаёт проблемы.

Что происходило:
Понедельник, 10:00. Сажусь за задачу.
10:15. Разработчик: "Можно вопрос?"
20 минут.
10:40. Другой: "Быстрый вопрос!"
15 минут.
11:20. Третий: "Минутку?"
25 минут.
К обеду задачу не начал.

Начал закрывать дверь:
Стук. Джуниор Маша:
"Дверь закрыта, но срочный вопрос..."
Не могу отказать.

Тимлид заметил:
"Ты никогда не доступен. Жду по часу."
Я: "Как? Моя дверь открыта!"
"Физически открыта. Но ты всегда занят. Open door не значит доступен - значит занят 24/7."
CEO объяснил:
"Open door policy не работает в IT. Это хаос. Разработчикам нужен фокус. Структурируй доступность."

Что изменил:
Правило 1: Office Hours - 14:00-16:00
Только это время - доступен. Остальное - дверь закрыта.

Правило 2: Async First
Можешь написать в Slack - пиши, не заходи.

Правило 3: Срочное = прод упал
Всё остальное - ждёт Office Hours.

Первая неделя:
Утро. Табличка "Deep work до 14:00".
Разработчик видит. Пишет в Slack. Отвечаю через час.
14:00. Office Hours.
Три человека. Час разобрали всё.
Остаток дня - работаю.

Через две недели:
Вопросов стало меньше. Async решает 70%. Фокусное время появилось.
Антон: "Раньше заходил 5 раз в день. Теперь думаю: правда срочно? Обычно нет. Пишу в Slack. Всем лучше."

Тимлид через месяц:
"Ты стал доступнее."
Я: "Дверь открыта меньше!"
"Да. Но когда открыта - реально доступен. Теперь я знаю когда прийти."

CEO через три месяца:
"Команда довольна. Что изменил?"
"Убрал open door. Ввёл структурированную доступность: 2 часа office hours + async. Все знают когда прийти."

Почему open door не работает у вас:
1. Убивает фокус
2. Непредсказуемо
3. Поощряет мелочи

А что работает:
Office Hours + Async First + Критерии срочного

Доступность ≠ постоянная открытость. Доступность = структурированное время когда реально можешь помочь.

А как организуете доступность?