Все вокруг повторяют мантры про «не сдаваться», хакатоны и борьбу с техническим долгом. Эти слова звучат правильно — но почему тогда команды, которые им следуют, часто буксуют на месте? Может, дело не в мотивации, а в том, что мы слепо копируем сценарии, которые давно не работают? Пора выйти за рамки привычного.

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. Публикую перевод интересной статьи для техлидов от технического консультанта Авива Бен-Йосефа, автора книги The Tech Executive Operating System.

«У нас никто никогда не сдаётся!» «Посмотрите, какой хакатон мы провели!» «Мы жёстко закладываем время на борьбу с техдолгом».

На первый взгляд — правильные и вдохновляющие лозунги. Но на деле это просто рекомендации, которым имеет смысл следовать… если вы хотите управлять посредственной командой.

Как технический лидер, вы часто попадаете в ловушку «общепринятых» практик. Но что, если именно эти практики тормозят развитие вашей команды и организации? В этой статье — шесть нестандартных установок. Они могут показаться непопулярными, зато помогут выстроить устойчивую, инновационную и по-настоящему эффективную команду.

Никаких микро- и нано-команд

Собирая команду из менеджера и 1–2 специалистов, вы фактически создаёте дополнительные управленческие издержки без ощутимого эффекта. Такие «нано-команды» редко бывают самодостаточными, а часто либо разваливаются слишком быстро, либо наоборот, почему-то существуют дольше, чем нужно. В итоге вам приходится ломать голову над тем, как распределять задачи в раздробленной структуре — только чтобы кто-то мог поиграть в управление и потешить своё эго.

Я регулярно вижу организации, где управленческие издержки фактически достигают 100%. Это не про масштабирование, а про потакание неэффективности. Можно было бы просто убрать половину менеджеров, чтобы выйти на адекватные размеры команд и более простую оргструктуру.

Команды нужно создавать тогда, когда без них становится по-настоящему больно. И команда должна быть достаточно большой, чтобы быть автономной — а не просто «рабочей группой», которая существует ради галочки.

Никаких хакатонов

Хакатоны — это хаос на адреналине. Отлично подходит для пиццы и тимбилдинга, но почти бесполезны, если говорить о долгосрочных результатах. В итоге вы получаете сырые проекты, которые умирают сразу после того, как мероприятие заканчивается. Если вы действительно хотите системно внедрять инновации — откажитесь от хакатонов. Вместо этого используйте перерывы.

Перерыв — это запланированная пауза в обычной работе, когда команда может заняться чем-то значимым. В отличие от хакатона, перерыв не доказывает, что вы способны собрать что-то за 36 часов. Он позволяет создать результат, который останется и будет работать дальше. Это шанс сфокусироваться на скорости разработки, протестировать новую продуктовую идею или разобраться с давно назревшей операционной проблемой. Перерыв делает ставку на качество, а не на скорость. И главное — результаты не исчезают в забытой ветке. Прочесть больше о перерывах можно в бесплатной главе книги Авива Бен-Йосефа The Tech Executive Operating System.

Никаких жёстких сроков на разработку

Техлиды любят размахивать флагом «технического долга», чтобы выбить себе отдельное, неструктурированное время на разработку. Намерение благородное, но реализация чаще всего проваливается. Большинство вещей, которые мы называем «техническим долгом», на самом деле им не являются.

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

Когда технический долг становится частью дорожной карты, это дисциплинирует процесс. Команда начинает фокусироваться на том, что действительно важно, а не на том, что просто удобно прикрывать словом «долг».

Не жалейте времени инженеров

В некоторых инженерных командах считают, что время разработчика священно и бесценно. Его нужно «защищать», чтобы пальцы печатали код без остановки. Продукт должен выдавать идеальные спецификации, а инженеры — держаться подальше от клиентов и тикетов поддержки. Прекрасная схема… если цель — создать команду, полностью оторванную от реальности.

Инженеры должны понимать контекст своей работы. Поощряйте их хотя бы раз в квартал следить за успехами клиентов или работой саппорта. А ещё лучше — пусть периодически берут на себя эти роли хотя бы на день. Не превращайте продуктовую команду в «нотариуса», который должен подписывать всё подряд. Ожидайте совместной, итеративной работы.

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

Стремитесь к здоровой текучке

В вашей команде никто никогда не уходил? Это не повод для гордости, а red-flag, тревожный сигнал. Значит, никому так и не удалось перерасти свою роль и выйти за рамки команды.

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

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

Преодолейте излишнюю профилизацию

Давать людям задачи, в которых они сильнее всего, на первый взгляд кажется отличным способом повысить производительность. Но на деле это делает команды хрупкими. Когда один человек становится «единственным экспертом» в какой-то области, вы сами создаёте узкие места, бутылочные горлышки, и застой.

Поощряйте инженеров выходить за пределы зон комфорта. Ещё лучше — закладывайте возможность переходить между направлениями каждые 12–24 месяца. Внутреннее «перекрестное опыление» делает команды устойчивее, предотвращает разобщённость и помогает людям оставаться вовлечёнными. Речь не о том, чтобы бросить человека в незнакомую задачу без поддержки. Речь о том, чтобы строить культуру обучения и адаптивности.

Выводы

Эти принципы вряд ли принесут вам лайки в конкурсах «лучшая команда года». Но они помогут построить организацию, которая будет сильнее, гибче и ближе к своей реальной цели. Если хотите создать что-то по-настоящему значимое, пора перестать играть по чужим правилам — и начать писать свои собственные.

Напоминаю, что это был адаптированный перевод статьи технического консультанта Авива Бен-Йосефа.

Больше интересного контента об управлении командами и процессами — в моём телеграм-канале Teamlead Good Reads. Подписывайтесь!