Когда специалист становится тимлидом, на него обрушивается лавина новых задач. Например, налаживать взаимодействие внутри команды, собирать качественную обратную связь, улучшать процессы, а иногда и пересобирать команду. Как справляться с этим, описано во множестве источников, но практические кейсы дают больше понимания, доходчивее будет только собственный опыт. Мы спросили у тимлидов Lamoda Tech, с какими вызовами они справлялись (или нет) в своей практике — внутри и за пределами компании.
Коллеги поделились историями о перестройке растущей команды, старте в новой роли, неочевидных способах найти своего кандидата, развитии сотрудника и о том, как легко не заметить тревожные сигналы в команде. Возможно, в этих кейсах вы найдете ответы на свои вопросы или узнаете себя.
1. Как вырастить команду и не потерять фокус
Салих Салихов
Тимлид команды разработки рекламной платформы
Вызов
В моей команде долгое время работало 13–14 человек. Это уже довольно много для одной команды, но мы справлялись. В процессе акселерации компании произошла новая волна найма, и нас стало вдвое больше. Синки разрослись, а я как тимлид все свободное время посвящал 1-to-1 с сотрудниками.
Решение
Мы поняли, что нужно распилить одну команду на две, наняв второго тимлида. Также у нас уже была кросс-функциональная команда, куда входили DS-специалисты и первая линия поддержки.
Чтобы логично распределить участников в команды и равномерно их нагрузить, мы составили карту продуктовых блоков, куда включили основные продуктовые направления, в которых планировали вести разработку. Затем спросили у бизнес-оунеров, сколько задач планируется в каждом блоке в ближайшее время. Исходя из их ответов, мы увидели примерную картину распределения нагрузки на бэкенд, клиентов, поддержку, ML или внешние API.
Результат
Так появилась core-команда, которая отвечает за внутреннюю логику и эффективность рекламы, и команда интерфейса, ответственная за опыт пользователей и рекламодателей (а не только за интерфейс, как можно подумать из названия).
Сейчас мы улучшаем и налаживаем распределение задач по командам, наблюдаем и собираем обратную связь. Время отладки совпало с онбордингом новых специалистов, поэтому в моменте перфоманс просел. Но в итоге мы смогли четче формировать бэклог и распределить зоны ответственности, сохраняя гибкие границы.
Какие особенности мы увидели:
Плюсы | Минусы |
Стало легче планировать работу и распределять нагрузку
| Задачи в блоках появлялись неравномерно.
|
Каждая команда имеет свои фокусы по задачам
| Не все разработчики были довольны попаданием в «свою» команду, поэтому меняли состав на ходу
|
У тимлидов есть время на стратегическое развитие команды, а не только на 1-to-1 с разработчиками | Границы между командами изначально были жесткими, но мы начали подхватывать задачи друг у друга, чтобы уравновесить загрузку |
Что делать, если вы «переросли» одну команду:
Начните с задач и людей, а не со структуры.
Придумайте рабочую модель, но будьте готовы ее пересматривать.
Говорите с командой — не все нюансы видно из диаграмм.
Изучите оргдизайн. Я следовал брошюре «Оргдизайн продуктовой компании» Алексея Воронина — она небольшая, но полезная.
2. Из «своего парня» в руководители: как заслужить авторитет и доверие в новой роли
Яна Шишкина
Тимлид группы разработки промоакций
Вызов
Представьте, что вы растете внутри команды несколько лет, делитесь с коллегами успехами и неудачами, обсуждаете идеи за кофе или за кружкой пива после работы. Иногда вступаете в конфронтацию, отстаиваете свое мнение, секретничаете о проблемах.
И вдруг все меняется: вчера ты был «своим парнем», а сегодня — руководитель этой же команды. Как перейти от роли коллеги к роли лидера? И что нужно делать, чтобы заслужить доверие и авторитет в качестве руководителя у тех, кто давно привык работать с тобой плечом к плечу?
Решение
Год назад, когда я стала тимлидом команды разработки, передо мной возникли два вызова: завоевать доверие в новой роли и выстроить границы, которые позволят мне установить прозрачные ожидания от команды. Расскажу, что делала для этого.
1. Завоевать доверие команды.
Сменить должность означает сменить не только роль и обязанности, а подход к взаимодействию, чтобы команда воспринимала меня как надежного наставника и опору.
Я исходила из портрета руководителя, идеального для меня самой, поэтому стала «помогателем» для ребят, активно их поддерживая. Что сюда входило: следование договоренностям, управление ожиданиями на основе фактов, а не ложных надежд, помощь в достижении целей по росту и продвижению сотрудников.
Кроме того, я стала связующим звеном в поиске компромиссов между техническими задачами и бизнес-целями.
Например, мне удалось отстоять решения команды по срокам и запуску MVP проекта перед бизнесом. Я объяснила позицию с учетом долгосрочных рисков и смогла найти вариант, который устроил и техническую команду, и стейкхолдеров. Это позволило защитить ресурс команды на полугодие, сохранив уже «сыгранную» команду целиком для совместной работы над проектом.
2. Устанавливать границы и принимать менеджерские решения.
Когда я была в статусе линейного разработчика, мы внутри команды общались неформально. Теперь же требовалось выстроить новую связь «сотрудник-руководитель». Я делала это в открытых диалогах на 1-to-1: четко проговаривала свои ожидания, требования и задачи, а также метрики, по которым мы сможем оценить результат.
Чтобы выстроить баланс между хорошими отношениями в команде и своей объективностью как руководителя, при принятии решений я ориентировалась на цели — личные и командные. Это работало одинаково в случае конфликта или распределения тасок между разработчиками, чтобы быстрее зарелизить фичу в продакшен.
Главные вопросы, которые и сейчас помогают мне принимать решения, — как будет лучше для команды, и какие есть риски? При этом важно рассматривать команду как единый механизм, частью которого я тоже являюсь.
Были кейсы, когда кто-то из специалистов, с кем у меня были довольно хорошие неформальные отношения, начинали обижаться: «Эта задача не для меня», «Я бы хотел заниматься проектом N, но ты передала его на другого техлида». Все подобные проблемы я решала на 1-to-1, проясняя пожелания сотрудника и прикидывая, а какой профит мы сможем получить для всех сторон, если сейчас заменим ему проект или задачу.
Результат
Прозрачные правила и реалистичные ожидания позволили выстроить новые границы, чтобы команда понимала мои решения и признавала авторитет, оставаясь в доброжелательных отношениях.
3. Как собрать свою команду мечты
Елизавета Ляпина
Продакт-лид группы навигации и рекомендаций
Вызов
Как продакт-лид мне нужно найти не просто специалистов, которые формально подходят под вакансию, а людей, с кем можно пройти долгий путь. Однако формальные интервью в духе «расскажите о себе» и монологи по пунктам из резюме редко помогают понять, твой ли это человек.
Решение
Вместо стандартного диалога я использую ситуационные кейсы — они занимают большую часть интервью. В их основу ложатся сложные или нетривиальные задачи, с которыми гипотетически может столкнуться продакт. В рукаве у меня всегда несколько сценариев, их выбор зависит от кандидата: реакцию на какую сложность хочется оценить именно в этом разговоре. Вот какие кейсы могут быть:
1. Ты продакт ранжирования. Все изменения внедряешь через A/B и видишь рост денежных метрик. На встрече топ-менеджер говорит: «Моя выдача однообразна: одни и те же бренды, нет новинок, все черное. Скучно листать. Сделайте разнообразную ленту!». Твои действия?
2. Ты уже год развиваешь чат-бот онлайн-стилиста, и до запуска остался месяц. Вдруг узнаешь, что маркетинг запустил своего бота — у него другой функционал, но то же позиционирование. Как отреагируешь? Что делаешь дальше?
Результат
Такой подход помогает увидеть, как человек мыслит, формулирует, работает с возражениями и со стейкхолдерами в живом процессе.
Иногда в ответах звучат дежурные формулировки вроде «нужно приоритизировать». Кто-то упирается в прошлый опыт: «с таким не сталкивался», а на вопрос «зачем?» отвечает: «просто стейкхолдер так сказал». Здесь я сразу понимаю: нам не по пути.
Но бывают и другие люди. Те, кто не боится мыслить вслух, сомневаться, уточнять, выходить за рамки знакомого. Кто не пытается казаться идеальным, а действительно разбирается в задаче — прямо здесь. Это может быть важнее, чем строчки в резюме. Такого кандидата я однажды и наняла: формально опыт был скромный, но умение здраво мыслить склонило меня сделать выбрать его среди других специалистов. Как результат — отличные показатели и абсолютный мэтч!
Интервью в формате заготовленного монолога — это прекрасно. Но точно ли это та информация, которая поможет вам сделать выбор?
4. Как вырастить хорошего лида из инженера
Ольга Ермолаева
Head QA
Вызов
Для меня в такой задаче главная проблема – не потерять хорошего инженера, который станет плохим лидом. Для этого важно проводить с инженерами 1-to-1, обсуждать планы развития, и, если человек проявляет лидерские качества, помогать и поощрять его в этом.
Расскажу, как это сработало с моим сотрудником, замечательным QA-инженером. Помимо своей основной деятельности он предлагал и внедрял улучшения внутри команды, смотрел, что получается. Если улучшение помогало, он выносил его на другие команды, выступая на внутренних встречах.
На 1-to-1 он с воодушевлением рассказывал про свои успехи и неудачи, мы обсуждали, как лучше сделать. И том числе он выразил желание развиваться как менеджер — потому что ему это интересно и в кайф.
Решение
Чтобы специалист смог проявиться как тимлид, я решила провести эксперимент. Собрала и передала QA-инженеру материалы для изучения основ тимлидства, а затем мы обсудили, что он возьмет на себя проведение 1-to-1 и составление индивидуального плана развития для трех коллег. Эти цели сотрудник включил в свой новый ИПР, который он согласовал со мной.
Эксперимент, какими бы ни были его итоги, позволяет безболезненно попробовать новую для себя роль на практике и при этом оставляет пространство для маневра, если вдруг новая роль не понравится, или специалист с ней не справится.
Результат
По итогам эксперимента сотрудник успешно изучил теорию и справился с новыми задачами на практике. В это время он продолжал работать на роли инженера. А как только в компании появилась возможность, получил позицию QA-лида, на которой успешно работает по сей день.
Как провести эксперимент для сотрудника, который хочет вырасти до тимлида:
Договариваемся о проведении эксперимента, в него войдут:
сроки начала и завершения + реперные точки для контроля происходящего,
суть эксперимента (в нашем случае это были новые обязанности без фактического повышения в должности),
критерии успешности и не успешности + метрики, которые собираем и проверяем на контрольных точках
2. Проводим эксперимент по оговоренному плану.
3. Подводим итоги.
5. К чему приводит гиперответственность
Ольга Ермолаева
Head QA
Вызов
Про выгорание написано и сказано множество всего, но в реальности это всегда выглядит по-разному, особенно когда речь идет про «горящих» подчиненных.
У меня в команде была очень крутая QA-автоматизатор, назовем ее Машей. Мы брали ее в команду с условием, что 80–90% времени она будет заниматься автоматизацией, формируя процесс с нуля.
Но, как водится, в команде случился коллапс, и было необходимо пилить фичи в ускоренном темпе. Маша как ответственная, даже гиперответственная сотрудница, не смогла держаться в стороне от потоковых задач и заниматься только автоматизацией, пока все вокруг горит. Она стала все чаще подключаться к ручным задачам, и через некоторое время занималась только ими.
Команде это было удобно, но я понимала, что автоматизация нам нужна не меньше. На 1-to-1 с Машей мы неоднократно договаривались, что по крайней мере на один день в неделю она полностью уходит в автотесты, что бы ни происходило. Тимлид команды разработки тоже был в курсе этой договоренности.
Но гиперответственность и синдром отличника очень мешали Маше, и автоматизация продвигалась крайне медленно.
Решение?
Дошло до того, что на 1-to-1 Маша сказала, что больше так не может: у нее огромный стресс на фоне происходящего, нарушился сон, и она решила уволиться.
Мы долго обсуждали разные варианты: ротация в другую команду, вывод из команды и работа только над автотестами в спокойной обстановке. Но было поздно – человек сгорел «в угли» и нуждался в длительном восстановлении.
Здесь сошлось множество факторов, но в первую очередь, это мой факап как менеджера. Ранее я не сталкивалась с подобными случаями, и понадеялась на то, что специалист понимает, что делает, и к чему все идет, не приняв во внимание высокую тревожность и гиперответственность.
Как можно было решить проблему и получить результат?
Вывести специалиста из команды сразу, как только начались «марафоны» с ручными задачами.
Посадить отдельно от команды, чтобы Маша могла спокойно пилить и настраивать автоматизацию тестирования.
Провести ротацию в другую команду, где обстановка более спокойная.
Заключение
Никто не рождается идеальным руководителем, и никто не может избежать ошибок. Надеемся, эти истории помогут вам придумать решения для подобных задач раньше, чем вы с ними встретитесь. А те, кто прошел огонь, воду и медные трубы — поделитесь в комментариях, как вы поступали в похожих ситуациях?
Если вы увидели близкие себе принципы и ценности, вам интересно строить сильные команды и расти самим — возможно, нам по пути. Сейчас мы ищем тимлидов в команды разработки (PHP/Go), продуктовой аналитики, DBA, а также руководителя направления SRE.
