Теперь я тимлид, но почему мне так плохо? Практические советы

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



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


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

    Во-первых, практически главный вопрос о жизни и нашей тимлидской вселенной — кто такой тимлид?


    «Быть тимлидом быть очень круто!» — думал Евгений, только им став: «Буду решать очень важные вопросы». А получил наверняка и вам знакомое горькое чувство, когда на стендапе после докладов о сделанных фичах и пофикшенных багах и сказать-то нечего. Ты вроде как ничего и не сделал: на митинги ходил, на почту отвечал. Или вообще удар, когда подчиненный говорит, что ты же не пишешь код, зачем ты изображаешь, что делаешь code review.

    В этот момент в зале раздались аплодисменты — тут у многих болит.

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


    Иннокентий: мастер планирования, разбирается в бизнес метриках, знает кучу аббревиатур. Но его команда не знает, что творится снаружи, не знает, как их работа связана с бизнес-задачами. В команде Иннокентия нет гибкости и нет роста.

    Степан: очень крутой разработчик, может закрыть за один день больше задач, чем весь отдел. Конечно, он думает, что все остальные в его команде не так хороши, не доверяет им сложных задач. Как следствие, bus factor=1 и никакой надежды на рост сотрудников.

    Игнат: стоит лицом к бизнесу, а к команде чем-то другим. Не берет ответственность, не очень понимает, что творится в команде.

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


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

    Совет известный — делегируй! Но распихать задачи в Jira — это не делегирование. Делегировать надо ответственность, а не задачи. Например, пускай ревью проводит кто-нибудь из команды.

    Второй пункт, тоже вроде банальный. Но обязательный.

    А еще заведите блокнот (ок, это может быть приложуха) и прочитайте уже Дорофеева (хотя бы в таком коротком варианте). И тогда можно будет заняться непосредственными задачами тимлида: фокусировать, растить, вдохновлять, коммуницировать, думать о людях. Техлид может не работать с людьми, а тимлид — должен.

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

    Лайфхак: если в рабочей атмосфере разговор по душам не получается, предложите подвезти и коварно разговорите.

    Напоследок Евгений предлагает вспомнить о философии Икигаи, и желает нам с вами встать на путь к его поиску и на этом пути никогда не быть несчастными.


    Такая вот смесь практики и экзистенциализма очень понравилась слушателям на Saint TeamLead Conf. Дальше в ТОП-5 вошли доклады:

    2. Оцениваем процессы в команде разработки на основе объективных данных / Сергей Семенов.

    3. Коммуникации как performance-зона работы тимлида / Александр Зиза.

    4. Роль тимлида в рекрутинге / Катерина Гаврилова

    5. Как оценить эффективность команды / Алексей Катаев

    Оставайтесь с нами, скоро откроем видео этих выступлений и что-нибудь про них опубликуем. Видео можно ловить на youtube-канале, а новости конференции в рассылке.
    • +50
    • 34,5k
    • 9
    Конференции Олега Бунина (Онтико)
    712,00
    Конференции Олега Бунина
    Поделиться публикацией

    Комментарии 9

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

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

      Тогда легко сказать менеджеру, что «нам нужен отдельный SCRUM master / engineering manager, пусть и управляющий несколькими проектами».

      Я часто играю несколько ролей в проекте, но разделение соблюдается и я легко и беспроблемно могу передать (или принять) роли девелопера, тех.лида, SCRUM master, engineering manager или архитектора.

      Я не архитекторо-девелоперо-менеджер, я человек с определенным опытом и несколькими ролями, которые не пересекаются в одной точке пространства-времени.

      Это позволяет остальным членам команды понимать, где границы между карьерными путями, какие роли им доступны и чем они отличаются. И где они разделяются. И не смешивать все в кучу.

      Это же позволяет не рушить процессы внутри команды. Играешь роль девелопера — подчиняешься процессам девелопмента. Заодно помогает наводить дисциплину просто примером — я, <павлиний список тайтлов>, следую всем правилам, код ревью, тесты и т.д. как нормальный девелопер.

      ИМХО
      • НЛО прилетело и опубликовало эту надпись здесь
          –1
          Есть простенький психологический тест Климова на определение направления профессиональной деятельности. Если не в свое направление попал, то будет дискомфортно.
            +2
            Тест Климова крайне общий и как все тесты очень сильно зависит от текущего настроения и положения дел.
            +1

            Как-то неожиданно статья закончилась на самом интересном месте...

              –1
              Это призыв посмотреть видео:) Это один из тех докладов, которые не хочется полностью пересказывать или расшифровывать
              0
              Хоть я и не тимлид, но было очень интересно)
                0
                «распихать задачи в Jira» — может это и не делегирование, но даже такая деятельность, осуществляемая разумно, может способствовать росту сотрудников и результативности команды
                  +1
                  Не знаю, будь ты тим лидом, директором, хоть главой крупной корпорации… Если ты занимаешься не любимым делом, везде будет плохо…

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

                  Самое читаемое