Евгений Антонов сегодня поднял интересную и важную тему о непоследовательности. Аргументы против уже перечислены.

Возможные возражения тоже. Да, чем выше руководитель, тем больше он видит со своего места, и его непонятные для подчинённых метания могут быть оправданными с позиций высокого знания. Однако всегда необходимо думать о долговременных последствиях. Тут, кстати, вполне уместна аналогия с детьми: можешь на него гаркнуть, чтобы он сразу сделал как ты хочешь, но гаркать придётся всегда, если не подведёшь его самого к нужному решению.

Теперь мои 5 копеек
Я всем очень советую формализовать правила в команде: роли, процессы, ритуалы. Перенести на бумагу, ну или в вашу локальную Wiki. Как часто бывает, составление документа благоприятно влияет на все вовлечённые стороны: тот, кто пишет, десять раз подумает, что именно он хочет записать. Тот, кто использует, избавлен от необходимости вспоминать, на каком дэйлике что сказали по поводу задач, и в каком чате это мелькало ещё. Вот ссылка, вот документ, вот дата последней правки, вот автор правки, вот - возможно - версионность и даже change-log правил. Сиди, читай.

В деле организации работы команды это великая вещь - создать общее поле правил и понятий. Когда у вас есть, на что опереться, легко запустить петлю обучения: подчинённый сделал не так - отправляешь читать правила - спрашиваешь знание правил - в следующий раз делает как надо. Когда у вас всё на словах, в один момент вы сломаетесь. В том смысле, что сами измените своё мнение, как надо, - под эмоциональным напором очередного жалобщика или просто из-за того, что память подвела. Исключений не бывает.

Прийти к такой минимально разумной бюрократии можно разными путями. У кого-то бирюза, у кого-то демократический централизм, где-то красная культура, - не суть. У нас в команде я отчасти формализовал то, что сразу сложилось, но основную структуру создал сам, хорошенько поразмыслив, что я хочу от команды и как вижу свою роль в ней. Далее было несколько сессий обсуждений и внесений правок. Людям проще предлагать доработать то, что уже готово на 90%, нежели вообще что-то создавать с нуля.

У меня вот такие разделы внутренних правил:
- Роли в команде
- Обязанности ролей
- Типы задач. Поля задач. Атрибуты
- Работа Разработчика
- Работа Тестировщика
- Git
- Книжечка Тимлида

В каждом разделе подробно расписана суть вопроса. Это не сухой формальный текст, а местами весьма художественное описание. Но строго логичное и непротиворечивое, не допускающее разных толкований.

Итог
Мои сотрудники всегда знают, что есть некий свод правил работы. В нужный момент я спокойно апеллирую к принятым правилам, а не к своему авторитету, "так наде" и прочему мало понятному окружающим. Я спокойно ухожу в отпуск, потому что людям есть на что опереться. Я уверенно отстаивают периметр своей команды от внезапных наскоков сбоку-сверху, потому что всегда есть чёткая аргументация, почему да и почему нет. Я легче и быстрее ввожу новых сотрудников в проект.