В 2006 году Яндекс и Google приехали в Петербург в Borland, который сокращал команду. Обе компании одновременно открывали в Петербурге свои офисы на его базе. Тогда к нам пришли замечательные ребята. Мы много общались, но больше всего запомнились слова Толи Орлова. Он сказал, что рост Яндекса на тот момент ограничивает только количество лидов, которые бы могли развивать продукты. Что роли техлида и тимлида очень существенны, и часто рост компании зависит только от наличия сильных лидеров. Тогда мне и захотелось узнать, как им стать.

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

Зачем нужны техлиды?

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

Чаще всего спрашивали: «Ты про техлида или про тимлида?». Один даже прислал ссылку на статью про отличие техлида и тимлида в компании Nielsen, где он в своё время работал. В двух словах, основная профессия техлида — это программирование, а у тимлида все-таки менеджмент. Но мы понимаем, что во многих компаниях эти роли совмещаются в одном человеке. И только чем больше компания, тем чаще оправдана отдельная роль, и отдельный техлид, который не занимается people-менеджментом.

Поэтому, чтобы во всём разобраться, я начал спрашивать:

1. Что отличает хороших техлидов?

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

Начнем с первого вопроса.

Чем отличается хороший техлид?

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

Точка зрения менеджера: очевидная

Первое, что всем приходит в голову — что у хорошего техлида должна быть экспертиза, то есть знание технологий и открытость к изучению новых. Во-вторых, он несёт ответственность за то, что он делает. То есть менеджера должно быть доверие к техлиду по техническим вопросам, чтобы не вникать в них.

Когда я перешёл на менеджерскую стезю, и мы разрабатывали сервис Яндекс.Путешествия, мой бывший руководитель и руководитель Директа Евгений Ломизе спросил, насколько хорошо у меня складывается с разработкой. Тогда я осознал, что не вникаю и не собираюсь подробно изучать техническую сторону проекта. Я был уверен — там всё будет отлично сделано. То есть у меня было очень сильное доверие к ребятам.

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

Бизнесовость для техлида состоит из двух важных пунктов. Это погружённость в продукт: понимание, кто его потребитель, какие у него основные боли, как эти проблемы решить и как продукт зарабатывает деньги. И вовлеченность — техлиду должно быть интересно, что происходит с продуктом и вообще с бизнесом.

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

Точка зрения менеджера: неочевидное, но важное

Существенно менее очевидная история про то, что с хорошим техлидом все хотят работать, в том числе, из-за собственного развития. Каждый менеджер, когда у него возникает задача, которую нужно реализовать в продукте, сталкивается с вопросом: насколько подробным должно быть ТЗ, которое он формирует? Есть разные крайности, от описания супер-подробно чуть ли не по ГОСТу до совсем наоборот. Но насколько это на самом деле влияет на конечный результат?

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

Точка зрения разработчика 

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

Точка зрения других техлидов

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

В чём все сходятся

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

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

Как развиваться?

После того как ребята ответили на первый вопрос, я спросил: «А что делать, чтобы стать хорошим техлидом и как развиваться?»

Модель мира

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

Лучшая тактика будет такой:

1. Не верить на слово даже старшим коллегам, у которых больше опыта. Посмотреть в коде, как на самом деле всё работает.

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

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

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

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

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

Книги Демарко на меня сильно повлияли, когда я работал в аутсорсе. Тогда моё понимание того, как относиться к коллегам, выстраивать работу в команде и процессы — сильно расходились с позицией моего менеджера. А прочитав «Человеческий фактор» и «Deadline», я осознал, что люди — самый важный фактор успеха разработки ПО. Это меня хорошо поддержало в той тяжелой ситуации.

Zoom in – zoom out

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

Такие люди обладают широким кругозором, что разработчики очень ценят в техлидах. И вот книги, которые говорят об этом:

Книга Андерса Эриксона «PEAK» помогает наращивать техническую экспертизу, она  о достижении успеха в своей сфере. Многие из вас слышали цитаты из неё. Например, про 10000 часов, которые надо потратить. Очень важно, чтобы эта практика была сфокусированной и направленной на конкретные вещи, в которых вы хотите прокачаться.

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

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

В третьей книге, «GRIT», психолог Анжела Дакворз пишет, что в успехе людей очень часто важную роль играют всего два фактора: страсть — супер увлеченность тем, что вы делаете и настойчивость — трудности не останавливают, а стимулируют дальнейшее развитие. Для этого она провела исследования, похожие на А/В-тесты.

Изучать новые технологии

Как говорил Аркадий Волошин (он же Чеширский кот) — чтобы стоять на месте, нужно очень быстро бежать, особенно в нашей сфере. Если вы прекращаете развиваться, вы останавливаетесь. Хорошему техлиду нужен искренний интерес к изучению новых технологий, чтобы это всё в итоге не наскучило.

Ресурсы для развития

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

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

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

Soft skills

Про то, что техлиду важно развивать soft skills, мне говорили особенно те ребята, кто перешел в зарубежные компании. Я прочитал книгу Айзексона «Инноваторы» и выделил для себя интересную мысль. Автор утверждает, что крутые инновации развиваются в командах. А чтобы хорошо взаимодействовать в команде и что-то эффективно делать, надо уметь хорошо коммуницировать, понимать мотивацию друг друга и уметь мотивировать. Для всего этого как раз и нужны soft skills.

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

Чтобы хорошо понимать эмоции и мотивацию как себя, так и коллег, рекомендую две книги:

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

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

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

Обратная связь

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

• Что мне стоит продолжить делать?

• Что мне стоит начать делать?

• Что мне стоит прекратить делать?

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

В Яндексе есть свой процесс оценки руководителя. Там достаточно много пунктов, но 6 из них, как мне кажется, важны для техлидов:

1. Превращает идеи в конкретные цели и планы;

2. Берёт ответственность за результаты и сроки;

3. При возникновении сложностей ищет решения, а не причины неудачи;

4. Способен пересмотреть решение;

5. Доверие и уважение в коллективе;

6. Поощряет совместное принятие решений.

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

Учиться у других

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

Не надо бояться нанимать людей, которые «умнее вас». У меня даже есть такой чек-лист при собеседовании. Я всегда пытаюсь понять, в каких аспектах человек, которого я нанимаю (неважно, на какую позицию или грейд), может дополнить команду и в чём он будет круче ребят, которые уже есть. Потому что самые крутые команды, с моей точки зрения, дополняют друг друга.

Ещё один момент — это советы. Казалось бы, очевидно, что нужно прислушиваться к советам коллег и проактивно их спрашивать. Но многие не умеют этого делать. Один из моих коллег Даня Пономаренко, который сейчас работает в Apple, рассказал, как научился советоваться. Сокращённо все можно свести к таким тезисам:

Люди любят, когда с ними советуются, и лучше понимают, чем вы занимаетесь, какие сложности у вас есть. Если советоваться перед тем, как делаешь, то не придётся переделывать. Советоваться — это не перекладывать проблему или просить решение, а увидеть готовое хорошо структурированное решение, получить ответ на вопрос или варианты реализации.

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

Опыт

Вы не можете мгновенно стать крутым! Для этого нужно время. Надо делать разноплановые проекты на разных ролях, чтобы наращивать свою экспертизу в разных сферах. Читать книги, посещать конференции. А ещё у техлидов, как у успешных продакт-менеджеров, должны быть свои портфолио факапов. Это ваш опыт, который позволит не повторить подобные ошибки в будущем. Его не надо бояться —  ошибок не совершает тот, кто ничего не делает.

Выводы

Резюмируем атрибуты хорошего техлида:

• Техническая экспертиза и доверие менеджеров к ней;

• Бизнесовость, то есть вовлечённость в продукт и понимание того, как он влияет на бизнес, а также — что нужно и что не нужно делать для развития бизнеса;

• Способность менять свою модель мира и видеть мир на разных уровнях детализации;

• Умение учиться у других, развиваться самому и развивать других;

• Призвание и страсть.

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

Благодарю моих друзей и коллег за их ответы:

• Даня Пономаренко, Яндекс, Одноклассники, Twitter, Apple

• Вадим Цесько, Яндекс, Одноклассники

• Миша Карпов, Яндекс, VK, Skyeng

• Андрей Малов, JPMorgan, Nielsen

• Илья Тетерин, Яндекс, Apple

• Егор Ушаков, Oracle, JetBrains

• Женя Цуринов, Яндекс, Google

• Дима Щитинин, Яндекс, Одноклассники

• Денис Танаев, Яндекс

• Влад Долбилов, Яндекс

• Антон Булычев, Яндекс

• Андрей Зиновьев, Яндекс

• Азат Разетдинов, Яндекс

• Антон Иванов, Яндекс

• Витя Рудометов, Oracle

• Дима Цыганов, Яндекс, Booking, Google

• Рома Абрамов, Яндекс, CarPrice, СберАвто

• Антон Волохов, Яндекс, Apple

• Ваня Кожевников, Яндекс, Facebook.

Видео моего выступления на TechLead Conf 2020:

Объединенная конференция DevOpsConf 2022 и TechLead Conf 2022 пройдет 13 и 14 июня на самой инновационной и технологичной площадке в Москве — в кампусе Сколково. Программа сформирована, а билеты можно купить здесь.

Осталось всего полторы недели до встречи техлидов!