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

В PropellerAds решили пойти по принципу «нет человека — нет проблемы» и отказались от роли тимлидов. Как компании удалось это провернуть, не только не потеряв ни одного руководителя, но и успешно привлекая тимлидов из других компаний, в своем докладе на конференции TeamLead Conf 2020 рассказал глава продуктового отдела PropellerAds Яков Беккер.

Давайте поговорим о том, кому нужен тимлид? Вопрос риторический, поскольку ответ на него знают все: тимлид нужен в первую очередь руководству.

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

Тимлид необходим руководству, которое просто обожает так называемую «игру на гармошке», когда начальники спускают вниз задачи, а потом собирают статус.

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

Что еще, кроме предоставления статуса и спуска распоряжений вниз, хочет от тимлида руководство?

Ожидание: функции тимлида

Обычно начальники хотят, чтобы тимлид умел делать хотя бы базовые дизайны. Как он будет руководить командой разработчиков, если сам не умеет писать код? 

Руководство надеется, что тимлид будет управлять процессами в команде, и станет выполнять роль менеджера продукта или проекта. Хотят, чтобы он понимал domain. 

Кроме того, тимлид должен отвечать за качество. Багов быть не должно, особенно в продакшен. Руководитель не хочет, чтобы его разбудили в 3 часа ночи, чтобы уведомить, что все упало и не работает. Очень удобно, когда есть человек, который отвечает за такие вещи и знает, как все оперативно исправить. 

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

Кого же нужно найти? 

Руководители ищут некого сказочного единорога мира кода, который должен уметь делать все. Но в реальности его не существует. 

Реальность: проблемы в работе тимлида

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

• Вся ответственность ТОЛЬКО на тимлиде;

Наверное, самая большая проблема в том, что на тимлиде лежит весь груз ответственности. 

• Отсутствие делегирования;

Часто тимлид перестает делегировать, потому что боится за качество и результат. Или он не умеет делегировать и не понимает, как делать это правильно. Многие думают, например, что делегирование — это просто спускание тасков вниз. 

• Mикроменеджмент;

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

• Слабое руководство вызывает недовольство команды;

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

Вся команда только и говорит о том, как плох тимлид.

• Тимлид выгорает;

На тимлиде куча ответственности, есть проблемы, которые нужно решать, команда им недовольна. И при этом он работает по 12 часов. Человека нужно спасать. Если спасти не удалось, он уходит из компании.

• Проблемы при уходе тимлида из компании;

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

• 25% лучших разработчиков не пишут код.

Представьте, что у вас были звезды разработки. Они писали код, а теперь его не пишут. Это ситуация — 25% лучших разработчиков не пишут код — должна приводить в ужас любого CTO.  

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

Давайте сравним две команды: с тимлидом и без. На этой картинке солдаты смотрят на своего командира (тимлида) и ждут, чтобы он их спас. На нем лежит вся ответственность. Это плохо, потому что команда ее не чувствует, вы оставили ответственность на одном человеке.

И есть другая команда:

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

Конечно, на деле все не так ужасно: есть хорошие тимлиды. Но стать единорогом в этой сфере очень тяжело. Есть большое количество курсов и тренингов, есть TeamLead Conf с огромным количеством возможностей учиться. Все это помогает нам вырастить хороших тимлидов и исправить проблемы, описанные выше.

Но в PropellerAds структура управления устроена по-другому, и это работает.

Решение: самоорганизующиеся команды

В PropellerAds есть продуктовые команды, которые стоят в центре системы компании. В них входят:

• Владелец продукта (Product Owner) — это человек, который разбирается в продукте, работает с бизнесом, строит бэклог, менеджерит риски, пишет User Story и прочее;

• Разработчики, scrum-мастер;

• Тестировщики;

• DevOps.

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

Где же руководители? Они есть у каждой функциональной группы (PO, разработчиков, тестировщиков, DevOps).

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

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

Распределение обязанностей в команде

Кто занимается разработкой — кодом, дизайном, архитектурой? 

Разработчики.

Кто занимается продуктом?

В продуктовой компании это очень важный вопрос. Например, стоит задача создать кабинет для рекламодателя. Нужно разговаривать с заказчиками каждый день. В PropellerAds PO этого направления ездит на профильные конференции, общается с рекламодателями, делает Customer Development, проводит вебинары. 

Кто занимается управлением процессами в команде?

В PropellerAds нет выделенной роли scrum-мастера. Эту роль чаще всего играет не senior-разработчик, а тот, кому это интересно. Например, QA, DevOps или middle-разработчик (junior не может). Это должен быть человек, которому интересно этим заниматься.

Кто управляет инцидентами?

Логично выделить для этого DevOps-инженера. 

Что с единой точкой входа?

После того, как ушли тимлиды, она стала сложнее. Пострадало руководство. Раньше были люди, ответственные за команду, которым можно было задать любой вопрос, и они дали бы ответ. Но теперь вопросы по продукту нужно задавать одному, по коду — другому и т.д. 

Кто занимается наймом, ростом и мотивацией людей?

Эти вопросы полностью лежат на функциональных менеджерах. В компании существует оценка удовлетворенности функциональным менеджментом, и сейчас она — 9,6. Это почти предел, и непонятно, как она может стать выше. 

Почему все так здорово? Функциональные менеджеры целыми днями ведут планы персонального развития, делают one-on-one, правильно проводят квартальные ревью, никого не обижают. Они видят свою роль в том, чтобы их команде было хорошо, а отдельным людям было приятно работать в PropellerAds, чтобы специалисты развивались и через 3 года стали лучшими инженерами. Это одна из самых важных целей функционального менеджера.

Их задача заключается в развитии людей и в продвижении по эффективности. 

Из-за того, что есть роли (PO ответственен за продукт, QA за инциденты и пр.) может показаться, что ответственность лежит на определенных людях. На самом деле, это не так, ее несет вся команда. 

В компании используют Slack. Как вы думаете, кого кастуют в случае инцидента? Чаще всего — не конкретного человека, а всю команду. Например, кастуют команду Core, и отвечают три человека: PO, разработчики и QA — каждый по своим вопросам. То есть точкой входа становится не конкретный человек, а команда.

Структура управлением бизнеса

Как в PropellerAds управляют бизнесом? Есть руководитель направления, например, определенного формата рекламы. У него в подчинении маркетинг, продажа и оптимизация. И этому руководителю выделяются 1-2 продуктовых команды, чтобы они выполняли 90-95% его тасков, и ему не пришлось искать помощь на стороне.

Получается эффективно, потому что команды понимают, для кого они работают, а заказчик понимает, кто для него работает.

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

Структура управления технологией

В PropellerAds есть функциональный менеджер разработки — R&D-менеджер.

Он организовал четыре направления и нашел тех, кто согласился их вести. Во главе направлений встали senior, каждый из них лидер. Кто-то ведет ротацию, кто-то данные, кто-то фронтенд, кто-то back office.

R&D-менеджер собирается с командами, строит технологическую стратегию, презентует ее на стратегической сессии и т.д. 

Решение: все проблемы устранены

Что получила компания в итоге:

• Ответственность всех членов команды — от нее стало очень сложно спрятаться;

• Несколько человек в команде являются точкой входа; 

• Командная работа вместо микроменеджмента; 

• Команды довольны руководством; 

• Лидеры не выгорают. Выгорают обычно от того, что человек занимается нелюбимым делом, или не способен сделать то, что от него требуют.

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

• 25% лучших разработчиков снова ПИШУТ код. И это просто вау! 

Проблемы

Выше нарисована, казалось бы, идеальная картина. И все же в PropellerAds есть определенные проблемы. 

Проблема командной ответственности

Бывает, в одной из десяти команд, коллективную ответственность воспринимают так, будто ответственности не несет никто. И вот кастуешь команду из восьми человек по какому-то вопросу, а ответа нет. Пропустили Sprint Goal — и это никого не волнует. Раньше по этому поводу нервничал бы хотя бы тимлид. 

Управлять тимлидом легче, чем целой командой: его можно мотивировать, или поменять. 

Эта проблема решается просто: в команде должно быть 2-3 лидера. 

Обычно PO — лидер по определению. Он строит продукт: как же он может не быть лидером? Остаются еще два: например, QA и разработчик. То есть должны быть ребята, которые тащат команду на себе, не потому что им сказали это делать, а оттого, что им самим это нравится — они чувствуют азарт. В большинстве команд так и происходит. 

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

Проблема управления матричной структурой

Руководителям легче управлять иерархией. Ты собрал троих человек, чтобы обозначить задачи, они, в свою очередь, поставили их своим подчиненным. 

Без тимлидов в компании становится сложнее. Но можно наладить успешное взаимодействие, если есть три важные вещи. 

• Доверие;

Очень важно доверять друг другу, потому что иначе команда не сможет функционировать. 

• Независимость;

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

• Пассивный контроль.

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

Проблемы карьерного роста

Тимлид, должность которого упразднили в компании, может остаться этим недоволен. 

Давайте задумаемся, чего хочет человек, который мечтает стать тимлидом:

• Иметь авторитет и, как результат, получить влияние и независимость;

• Саморазвиваться;

• Зарабатывать больше денег. 

Чтобы получить все это, можно построить карьеру внутри компании.

Карьера разработчика в PropellerAds

С тимлидами в компании было бы движение по иерархической лестнице. У них не было бы другого пути: хотели они или нет, но должны были бы превратиться в мифического единорога. И чем лучшими тимлидами они могли стать, тем дальше могли продвинуться по карьерной лестнице. И если CTO уволится, то получится получить его место! Но часто ли вы видели увольняющегося CTO? 

Сейчас в PropellerAds можно стать функциональным менеджером. У СТО есть команда из шести человек: Head of Analytics, R&D менеджер, Head of QA и люди, которых можно назвать руководителями высшего звена. 

Можно стать техлидером, или product-менеджером, они всегда нужны: каждый квартал что-то происходит. Как этого добиться? Поинтересуйтесь продуктом, domain, клиентами, сходите на курс, предложите себя. 

Если вы middle-девелопер, можно стать scrum-мастером, или коучем. 

Кроме того, можно вырасти в business owner.

Все в руках сотрудников.

Изменение структуры

Легко ли создать структуру, которая сложилась в PropellerAds? Относительно тяжело. Гораздо проще организовать иерархию тимлидов. 

Описанная система гораздо сложнее, в ней много противоречий. Но в PropellerAds без тимлидов достигли гораздо большей эффективности, чем раньше. И с гораздо более счастливыми людьми.

TeamLead Осень 2020 пройдет 29 и 30 апреля 2021 года. Приобретайте билеты и становитесь частью единственной профессиональной конференции только для тимлидов.

А программный комитет Saint TeamLead Conf 2021 ждет ваши доклады.

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