Как найти хорошего DS Team Lead?
При найме на руководящую позицию нередко делают основной акцент на софт скиллы. В некоторых случаях и вовсе ими ограничиваются. Однако на одних софт скиллах далеко не уедешь, ведь приходится отвечать за результаты всей команды.
🤔 Какая может быть природа таких заблуждений? Одним может показаться, что хардовая часть вовсе не зависит от тим лида, ведь он сам практически не пишет код. Другим причудиться, что успешность проектов зависит только от трудолюбия и скиллов команды и, конечно же от навыка руководителя правильно коммуницировать внутри и вовне, а также правильно презентовать результаты. В результате этих суждений, методом исключений хард скиллов, как раз остаются только софт скиллы.
Кто-то приходит к мысли, что хорошим DS Team Lead может стать любой менеджер. Тем не менее, хороших Тим Лидов, которых я встречал в индустрии, объединяют следующие факторы: они все в прошлом Senior DS и имеют опыт успешной монетизации данных. Далее, подробно расскажу, почему это так важно.
✅ Бывший Senior Data Scientist
➕ Качественный найм. Вспомним еще раз, что код пишет не тим лид, а его команда. Тем не менее существует небольшая проблема - нужно нанять эту команду. Более того, любой руководитель должен стараться нанимать людей скилловее себя. Как распознать эти скиллы, если у тебя нет базы? Например, сейчас все пишут про BERT на позицию в NLP, но как среди них отобрать тех, кто шарит, если никогда сам его не обучал? Никак, все кандидаты для тебя будут одинаковые. Когда харды неразличимы, то решение будет приниматься на основании софтов. Выход, кажется, есть - переадресовать синьору техническую часть собеседования. А кто наймет синьора?)
➕ Принятие несложных технических решений самостоятельно. Отсутствие технической экспертизы у руководителя нередко тормозит процесс принятия решений или, что хуже, даже приводит к неправильным решениям. Вы наверно слышали о встречах в составе 10 менеджеров вертикали и двух разработчиков. Теперь вы знаете первопричину. В некоторых компаниях дата сайентистами могут управлять даже проджект менеджеры. Знаете, это обычно печальное зрелище, так как на любой технический вопрос другого Тим Лида, требуется консультация команды, которую нужно закинуть в следующий двухнедельный спринт(
➕ Развитие команды. А тут зачем база? Безусловно, существуют курсы по закрытию теоретических пробелов, можно учиться у более опытных коллег в команде, код ревью адресовать синьорам. Тем не менее, как выявить западающие компетенции и начать их развивать у конкретного члена команды?
➕ Минимизация микроменеджмента и бюрократии. Представьте, что вы не вдупляете, чем занимается ваша команда, но отвечаете за результат. Какие ваши действия? Правильно, вы попытаетесь проконтролировать все этапы работы команды. Чем больше вы не в теме, тем больше микроменеджмента и бюрократии стоит от вас ожидать. Если вы в теме, то по косвенным признакам, подобно опытному преподу на экзамене, вы сразу выявите студента, который не выучил материал, что вам позволит не мешать работать остальной части команды.
➕ Признание от сильной команды. Не разбираясь в базе, будет сложно выстраивать коммуникацию с командой. Будет невозможно понять, о чем они там говорят на встречах. В конфликтных ситуациях по техническим вопросам, будет сложно быстро понять кто прав, а кто нет. Наконец, будет тяжело оценить по достоинству инициативы, с которыми будут приходить заряженные члены команды. В итоге, часть решений будет принята неправильно, коммуникация будет скорее формальная, а вовлеченность команды и признание руководителя пониженными.
При найме на руководящую позицию нередко делают основной акцент на софт скиллы. В некоторых случаях и вовсе ими ограничиваются. Однако на одних софт скиллах далеко не уедешь, ведь приходится отвечать за результаты всей команды.
🤔 Какая может быть природа таких заблуждений? Одним может показаться, что хардовая часть вовсе не зависит от тим лида, ведь он сам практически не пишет код. Другим причудиться, что успешность проектов зависит только от трудолюбия и скиллов команды и, конечно же от навыка руководителя правильно коммуницировать внутри и вовне, а также правильно презентовать результаты. В результате этих суждений, методом исключений хард скиллов, как раз остаются только софт скиллы.
Кто-то приходит к мысли, что хорошим DS Team Lead может стать любой менеджер. Тем не менее, хороших Тим Лидов, которых я встречал в индустрии, объединяют следующие факторы: они все в прошлом Senior DS и имеют опыт успешной монетизации данных. Далее, подробно расскажу, почему это так важно.
✅ Бывший Senior Data Scientist
➕ Качественный найм. Вспомним еще раз, что код пишет не тим лид, а его команда. Тем не менее существует небольшая проблема - нужно нанять эту команду. Более того, любой руководитель должен стараться нанимать людей скилловее себя. Как распознать эти скиллы, если у тебя нет базы? Например, сейчас все пишут про BERT на позицию в NLP, но как среди них отобрать тех, кто шарит, если никогда сам его не обучал? Никак, все кандидаты для тебя будут одинаковые. Когда харды неразличимы, то решение будет приниматься на основании софтов. Выход, кажется, есть - переадресовать синьору техническую часть собеседования. А кто наймет синьора?)
➕ Принятие несложных технических решений самостоятельно. Отсутствие технической экспертизы у руководителя нередко тормозит процесс принятия решений или, что хуже, даже приводит к неправильным решениям. Вы наверно слышали о встречах в составе 10 менеджеров вертикали и двух разработчиков. Теперь вы знаете первопричину. В некоторых компаниях дата сайентистами могут управлять даже проджект менеджеры. Знаете, это обычно печальное зрелище, так как на любой технический вопрос другого Тим Лида, требуется консультация команды, которую нужно закинуть в следующий двухнедельный спринт(
➕ Развитие команды. А тут зачем база? Безусловно, существуют курсы по закрытию теоретических пробелов, можно учиться у более опытных коллег в команде, код ревью адресовать синьорам. Тем не менее, как выявить западающие компетенции и начать их развивать у конкретного члена команды?
➕ Минимизация микроменеджмента и бюрократии. Представьте, что вы не вдупляете, чем занимается ваша команда, но отвечаете за результат. Какие ваши действия? Правильно, вы попытаетесь проконтролировать все этапы работы команды. Чем больше вы не в теме, тем больше микроменеджмента и бюрократии стоит от вас ожидать. Если вы в теме, то по косвенным признакам, подобно опытному преподу на экзамене, вы сразу выявите студента, который не выучил материал, что вам позволит не мешать работать остальной части команды.
➕ Признание от сильной команды. Не разбираясь в базе, будет сложно выстраивать коммуникацию с командой. Будет невозможно понять, о чем они там говорят на встречах. В конфликтных ситуациях по техническим вопросам, будет сложно быстро понять кто прав, а кто нет. Наконец, будет тяжело оценить по достоинству инициативы, с которыми будут приходить заряженные члены команды. В итоге, часть решений будет принята неправильно, коммуникация будет скорее формальная, а вовлеченность команды и признание руководителя пониженными.