Про даты в граните...

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

Очень жаль говорить вам это, но, вы теперь не двигаетесь так быстро, как раньше.
Кроме этого, то, что вы поставляете, больше не будет таким же качественным, как раньше.
И со временем вы тоже начинаете это видеть.
Вы же не глупый.

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

И то самое чувство неловкости, когда ты видишь, что твои команды поставляют некачественный продукт.

И вы понятия не имеете, почему.
А ответ прямо здесь: вы больше не двигаетесь быстро из-за ВАШЕЙ коммуникации.

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

Что вы могли сделать вместо этого?
Когда команда не уложилась в дату релиза, вы могли бы поддержать ее вместо того, чтобы наказывать лидеров команды.
Можно использовать эту возможность, для создания и поддержки культуры решения амбициозных задач с вызовом.
Вы могли бы сказать:
"Я понимаю, почему вы не попали в обозначенную дату релиза.
Но я бы предпочел, чтобы вы оставались амбициозными и иногда не укладывались в дату, чем были консервативными и всегда попадали.
Я не хочу, чтобы вы перестали быть амбициозными по умолчанию.
И мы хотим, чтобы больше команд были такими, как вы".

В этот момент вы либо видите ценность этого подхода, либо пытаетесь найти причины отказаться от него.
Появляются отговорки типа: "А как насчет запусков, которые имеют внешние обязательства?"
Ну вы же умный, вы знаете ответ.

Тем не менее, давайте объясню:
1. Большинство дат запусков не должны быть зафиксированы внешними обязательствами.
2. Но для каких-то запусков все же требуются внешние обязательства (перед клиентами, или регулирующими органами, или партнерами и тдтп)
3. Для запусков из п2 определите консервативную дату, которую вы почти наверняка достигнете.
4. Но даже для них попросите команду проработать амбициозную внутреннюю дату. Ничего страшного, если они не уложатся в эту дату. Но важно иметь эту цель.

Почему? Потому что помните закон Паркинсона: "Работа заполняет все время, отпущенное на неё..."

Вы когда-нибудь замечали, как команды всегда с трудом укладываются в дату, независимо от того, насколько консервативно они ее установили?
Даты — это простое, но неверное выражение скорости, амбиций и энергии вашей команды.

Хотя, если вы все еще хотите сохранить свою увлеченность достижением всех дат, я не уверен, что смогу (или даже хочу) убедить вас в обратном.

Но тогда я также гарантирую, что вы потратите всю свою карьеру, управляя командами, которые движутся медленнее, чем они могут на самом деле, и/или поставляют продукцию более низкого качества, чем они могут на самом деле, и вы потратите всю свою карьеру, настраивая проверки, процессы, ганты, эксельки и кнуты/пряники, пытаясь и проваливая попытки решить проблему, которую вы создали изначально.
Удачи вам 😉!

PS я уже слишком ленив написать такое сам, поэтому это просто вольный перевод, но подписываюсь под каждым словом
#management