Когда специалист становится тимлидом, на него обрушивается лавина новых задач. Например, налаживать взаимодействие внутри команды, собирать качественную обратную связь, улучшать процессы, а иногда и пересобирать команду. Как справляться с этим, описано во множестве источников, но практические кейсы дают больше понимания, доходчивее будет только собственный опыт. Мы спросили у тимлидов Lamoda Tech, с какими вызовами они справлялись (или нет) в своей практике — внутри и за пределами компании.

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

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-лида, на которой успешно работает по сей день.

Как провести эксперимент для сотрудника, который хочет вырасти до тимлида:

1. Договариваемся о проведении эксперимента, в него войдут:

• сроки начала и завершения + реперные точки для контроля происходящего,

• суть эксперимента (в нашем случае это были новые обязанности без фактического повышения в должности),

• критерии успешности и не успешности + метрики, которые собираем и проверяем на контрольных точках

2. Проводим эксперимент по оговоренному плану.

3. Подводим итоги.

5. К чему приводит гиперответственность

Ольга Ермолаева

Head QA

Вызов

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

У меня в команде была очень крутая QA-автоматизатор, назовем ее Машей. Мы брали ее в команду с условием, что 80–90% времени она будет заниматься автоматизацией, формируя процесс с нуля.

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

Команде это было удобно, но я понимала, что автоматизация нам нужна не меньше. На 1-to-1 с Машей мы неоднократно договаривались, что по крайней мере на один день в неделю она полностью уходит в автотесты, что бы ни происходило. Тимлид команды разработки тоже был в курсе этой договоренности.

Но гиперответственность и синдром отличника очень мешали Маше, и автоматизация продвигалась крайне медленно.

Решение?

Дошло до того, что на 1-to-1 Маша сказала, что больше так не может: у нее огромный стресс на фоне происходящего, нарушился сон, и она решила уволиться.

Мы долго обсуждали разные варианты: ротация в другую команду, вывод из команды и работа только над автотестами в спокойной обстановке. Но было поздно – человек сгорел «в угли» и нуждался в длительном восстановлении.

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

Как можно было решить проблему и получить результат?

• Вывести специалиста из команды сразу, как только начались «марафоны» с ручными задачами.

• Посадить отдельно от команды, чтобы Маша могла спокойно пилить и настраивать автоматизацию тестирования.

• Провести ротацию в другую команду, где обстановка более спокойная.

Заключение

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

Если вы увидели близкие себе принципы и ценности, вам интересно строить сильные команды и расти самим — возможно, нам по пути. Сейчас мы ищем тимлидов в команды разработки (PHP/Go), продуктовой аналитики, DBA, а также руководителя направления SRE.