Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.
Я опросил более 400 тимлидов, чтобы провести деконструкцию некоторых из страхов тимлидов. Результаты опроса и исследование рынка тимлидов помогло понять, как с ними справиться, и я хочу поделиться результатами. Простые лайфхаки помогут меньше страдать от синдрома самозванца не только тимлидам, но и вообще любым специалистам, которые еще недавно выполняли конкретные задачи, а теперь руководят командой исполнителей.
Это страх того, что в один прекрасный день вы не сможете принести своему мужчине или женщине мамонта, потому что потеряли работу. И не сможете найти новую, потому что тимлиды не нужны на рынке труда.
Один из вопросов в моем опросе был: «Как вы стали тимлидом?» И действительно, оказалось, что всего 14% тимлидов приходят с рынка, остальные так или иначе растут внутри компании.
По данным компании New.HR, которая помогла мне проанализировать рынок труда, сейчас по всей России открыто примерно 500 вакансий тимлидов.
По разным данным в России появляется примерно 50 тысяч новых разработчиков в год. Это люди, которые заканчивают вузы, или те, кто из пекарей становятся фронтендерами.
Проведём простой расчет: на 50 тысяч разработчиков по стандартной пропорции семь к одному нужно 7 тысяч новых тимлидов. Вспомним, что 15% этой потребности компании закрывают наймом с рынка, — получим примерно тысячу новых вакансий в год.
То есть вакансии и потребность в тимлидах есть — «миф опровергнут».
Ниже навыки, которые используют в работе от 50% до 90% опрошенных тимлидов (чем больше размер шрифта, тем больше людей указали этот навык в числе используемых в работе).
Получается, что основные умения тимлидов не привязаны к конкретной компании. Если вы умеете мотивировать людей, находить, что им важно, вы сможете использовать эти навыки и в другой компании. Поэтому третий миф тоже скорее миф.
На схеме приведен совокупный доход gross (фиксированный оклад+премии до налогов) по данным аналитической HR-компании Korn Ferry по 91 московской компании (7800 человек). Аналитики Korn Ferry приходят в разные компании (IT и не IT), берут все данные о зарплатах сотрудников и о том, чем они занимаются, а потом приводят к собственной системе грейдов. CTO, у которого нет ни одного сотрудника в подчинении и он все время разрабатывает, в этом исследовании будет находиться в грейде обычного разработчика.
По горизонтальной шкале отмечены перцентили, то есть 50% людей получают меньше, чем указано в точке p50, а 50% соответственно больше. То же и для p10, p25, p75 и p90 — 90% людей из референтной группы зарабатывают меньше.
В терминах зарплатных вилок это значит, что, выходя на рынок, вы можете рассчитывать на:
Не исключено, что кому-то эти значения покажутся сильно завышенными, а кому-то наоборот — устаревшими. Это значит, что ваш опыт находится в области хвостов нормального распределения и, возможно, его пора актуализировать.
Теперь, когда мы разобрались с мифами, давайте посмотрим, какие рецепты использовать, чтобы чувствовать себя увереннее.
Ходить на собеседования полезно, и вот почему.
Ходить по собеседованиям не обязательно значит хотеть сменить работу. Это не страшно, за это не наказывают.
Матрица 2 на 2 — универсальная штука, она простая, но выглядит достаточно умно. Подойдет и в данном случае.
Например, вы наняли разработчика, потому что на интервью он показался вам хорошим специалистом, но через полгода стало понятно, что он не подходит для вашей команды. Тут вы вспоминаете, как принимали решение о найме, и делаете поправки в своих принципах подбора кадров, чтобы в дальнейшем совершать меньше ошибок.
Бывают и ситуации, когда свою роль сыграло чистое везение. Это не значит, что вы хорошо принимаете решения и надо впредь надеяться на похожий сценарий. Если вам повезло, это отлично, но опять же свои принципы нужно пересмотреть.
В этом может помочь проект Teamlead Roadmap. Это развесистая карта из разнообразных компетенций, которые ожидаются от тимлида в разных компаниях. У каждой ветки развития есть большое описание: что в себя включает, как прокачать, на что обратить внимание, как делать не надо и т.д.
Многие считают, что став менеджером, вы моментально разучитесь разрабатывать. Поэтому книга «Как подсидеть тимлида» советует задавать тимлиду открытые вопросы о недавних изменения в технологиях и не давать отделаться абстрактными ответами типа «Да, выглядит интересно, надо попробовать». Другой способ подкрепить неуверенность тимлида в своих силах изощреннее:
Эти страшные истории основаны на внутренней уверенности тимлида в том, что:
Вернемся к опросу и посмотрим, как тимлиды оценивают свои технические навыки по отношению к остальной команде.
Что интересно, уверенность в своем техническом уровне коррелирует с тем, насколько много тимлид программирует.
Если тимлид много кодит, он ведёт за собой команду очень уверенно. Но чем меньше он работает руками, тем ниже его уверенность — в районе 10% тимлид становится легкой добычей для того, кто собрался его подсидеть.
В среднем 40% рабочего времени тимлид занимается инженерными задачами — пишет код, если он тимлид разработки.
Очевидным образом этот процент коррелирует с размером команды. В маленькой команде из 3-4 человек тимлид скорее всего «играющий тренер». Но с ростом команды времени на код остается все меньше и меньше, и тимлид и правда постепенно забывает, как разрабатывать. Этот миф отчасти верен.
Несмотря на то, что мифы о снижении уровня инженерной компетенции тимлида частично оправдали себя, есть верные пути борьбы со вторым страхом.
Servant Leadership — это интересная управленческая философия, которой, например, придерживаются в Booking.com.
Не делайте так. Не думайте, что раз вы тимлид, то вам нужно взять в работу самое блокирующее, сложное, горящее или просто прикольное из бэклога. Взяв на себя самую важную инженерную задачу, вы с высокой вероятностью переключитесь на другие, тоже важные и срочные дела типа митингов, планирования и т.д.
То есть хотите писать код — пишите, но делайте то, что не заблокирует работу вашей команды. Беря на себя задачу разработчика, выбирайте то:
Например, автоматизируйте рутинные вещи, правьте старые баги, делайте нужные фичи — все, что принесет пользу, а не помешает вашей команде.
Это самый сложный из страхов. Когда в один прекрасный день ты просыпаешься и вдруг понимаешь, что тебе не очень хочется идти на работу, которая до этого нравилась. Ты пытаешься вспомнить, что прикольного сделал за последнюю пару недель, и на ум приходит только механическое перетягивание задачек из столбика «TO DO» в столбик «IN PROGRESS». Ты понимаешь, что перестал видеть смысл в том, чем занимаешься.
Вот что отвечали люди на вопрос, в чем их мотивация работать тимлидом, почему они стали тимлидом.
На первый план вышли такие аргументы, как возможность большего влияния на проект, самостоятельность в принятии решений, работа с командой и людьми и саморазвитие. Всего половина людей отметили, что их мотивацией является зарплата. Причем заметьте, я не просил выделить главный фактор, а вообще спрашивал, ради чего они работают.
Интересно, что 12% опрошенных говорят, что им не нравится быть тимлидом...
Так распределились ответы на вопрос: понимаете ли вы, как руководитель оценивает вашу работу?
К сожалению, 75% опрошенных тимлидов не знают, как руководитель оценивает их работу или не уверены в этом. Очевидно, когда не понимаешь, что от тебя хочет руководитель, трудно понять, что вообще делать.
Сначала напишите вообще все, что есть в голове хорошего и плохого про работу. Отложите на время получившийся документ с потоком мыслей и сходите погулять или просто переключитесь на что-то другое. Вернувшись, перечитайте записи и попытайтесь выделить свои мотивационные факторы — позитивные или негативные. Сравните, насколько текущая роль, проект, компания отвечает этим мотивационным факторам. Если удалось отметить лишь малую часть, то, возможно, именно поэтому ваша работа вам кажется бессмысленной.
Может быть, книги «Как подсидеть тимлида» и не существует, но эти и другие страхи преследуют многих тимлидов. Когда я 7 лет назад впервые стал тимлидом небольшой команды, я боялся подвести свою команду и старался работать больше всех. Следующим пришел страх, что я не компетентен как менеджер. Потом команда выросла, я стал отходить от разработки и заниматься людьми, появился страх того, что я не шарю в разработке. Я смотрел на других руководителей — они казались умнее меня. Страхи множились.
Приведенные в статье рецепты помогали мне справляться. Каждый раз, когда я встречал новый страх и неудобство, я рефлексировал и искал причины. Обычно я составлял список проблем, каждую из которых обдумывал по отдельности и находил понятное решение. Поэтому я надеюсь, что эти советы помогут и вам. А если чувствовать себя уверенно в роли тимлида вам мешают совсем другие моменты, используйте сырые данные опроса, исследование рынка и полезные материалы, чтобы самостоятельно опровергнуть мифы, и делитесь результатами в комментариях.
Боритесь со своими страхами и помните, что вы в этих страхах не одиноки!
Я опросил более 400 тимлидов, чтобы провести деконструкцию некоторых из страхов тимлидов. Результаты опроса и исследование рынка тимлидов помогло понять, как с ними справиться, и я хочу поделиться результатами. Простые лайфхаки помогут меньше страдать от синдрома самозванца не только тимлидам, но и вообще любым специалистам, которые еще недавно выполняли конкретные задачи, а теперь руководят командой исполнителей.
Страх №1. Ты не востребован на рынке
Это страх того, что в один прекрасный день вы не сможете принести своему мужчине или женщине мамонта, потому что потеряли работу. И не сможете найти новую, потому что тимлиды не нужны на рынке труда.
Книга «Как подсидеть тимлида», совет №6: Расскажите, что завидуете храбрости тимлида по отношению к работе. Ведь если разработчик уходит из компании, он может найти новую работу чуть ли не за один день, а тимлид примерно никогда, потому что кому нужны тимлиды?Этот страх порождают разные истории и мифы. Разберем их на основе результатов опроса, в котором приняли участие тимлиды с разным бэкграундом, с разным опытом, из разных команд.
Тимлидов не нанимают, а растят внутри команды
Один из вопросов в моем опросе был: «Как вы стали тимлидом?» И действительно, оказалось, что всего 14% тимлидов приходят с рынка, остальные так или иначе растут внутри компании.
На рынке нет вакансий
По данным компании New.HR, которая помогла мне проанализировать рынок труда, сейчас по всей России открыто примерно 500 вакансий тимлидов.
По разным данным в России появляется примерно 50 тысяч новых разработчиков в год. Это люди, которые заканчивают вузы, или те, кто из пекарей становятся фронтендерами.
Проведём простой расчет: на 50 тысяч разработчиков по стандартной пропорции семь к одному нужно 7 тысяч новых тимлидов. Вспомним, что 15% этой потребности компании закрывают наймом с рынка, — получим примерно тысячу новых вакансий в год.
То есть вакансии и потребность в тимлидах есть — «миф опровергнут».
У тимлидов нет универсальных навыков
Ниже навыки, которые используют в работе от 50% до 90% опрошенных тимлидов (чем больше размер шрифта, тем больше людей указали этот навык в числе используемых в работе).
Получается, что основные умения тимлидов не привязаны к конкретной компании. Если вы умеете мотивировать людей, находить, что им важно, вы сможете использовать эти навыки и в другой компании. Поэтому третий миф тоже скорее миф.
Буду получать меньше, чем сейчас
На схеме приведен совокупный доход gross (фиксированный оклад+премии до налогов) по данным аналитической HR-компании Korn Ferry по 91 московской компании (7800 человек). Аналитики Korn Ferry приходят в разные компании (IT и не IT), берут все данные о зарплатах сотрудников и о том, чем они занимаются, а потом приводят к собственной системе грейдов. CTO, у которого нет ни одного сотрудника в подчинении и он все время разрабатывает, в этом исследовании будет находиться в грейде обычного разработчика.
По горизонтальной шкале отмечены перцентили, то есть 50% людей получают меньше, чем указано в точке p50, а 50% соответственно больше. То же и для p10, p25, p75 и p90 — 90% людей из референтной группы зарабатывают меньше.
В терминах зарплатных вилок это значит, что, выходя на рынок, вы можете рассчитывать на:
- 144–294 тыс. рублей, если являетесь профессионалом, который, возможно, менторит пару человек, но едва ли исполняет весь набор функций тимлида.
- 175–357 тыс. рублей, если вы тимлид небольшой команды.
- 225–491 тыс. рублей, если вы тимлид большой команды в 10-30 человек или менеджер менеджеров.
Не исключено, что кому-то эти значения покажутся сильно завышенными, а кому-то наоборот — устаревшими. Это значит, что ваш опыт находится в области хвостов нормального распределения и, возможно, его пора актуализировать.
Как победить страх, что ты не востребован на рынке
Теперь, когда мы разобрались с мифами, давайте посмотрим, какие рецепты использовать, чтобы чувствовать себя увереннее.
Рецепт №1: Ходите по собеседованиям хотя бы раз в полгода.
Ходить на собеседования полезно, и вот почему.
- Это повышает вашу уверенность в завтрашнем дне. Дает понять, что если что-то пойдет не так (компания обанкротится, вы выгорите, ваш руководитель сойдет с ума и т.д.), вы всегда сможете найти себе что-то еще.
- Позволяет оценить ваши навыки. Длительное время сидя на одном месте трудно понять, а как вы справляетесь. На собеседовании вы получите максимально честный и жесткий фидбэк.
- Дает понимание рынка: что и где требуется от тимлидов, какие полезные практики и процессы применяются и чем они могут быть полезны вам в текущей ситуации.
Ходить по собеседованиям не обязательно значит хотеть сменить работу. Это не страшно, за это не наказывают.
Рецепт №2: Рефлексируйте и анализируйте свои решения, чтобы отделять удачу от умений.Рефлексия важна, чтобы быть уверенным в том, что ты профессионал, а не самозванец. Когда принимаете какое-то решение, например, начать новый проект или нанять кого-то, всегда запоминайте, почему приняли именно это решение. Вернитесь к этому, когда результат вашего решения уже будет известен.
Матрица 2 на 2 — универсальная штука, она простая, но выглядит достаточно умно. Подойдет и в данном случае.
Например, вы наняли разработчика, потому что на интервью он показался вам хорошим специалистом, но через полгода стало понятно, что он не подходит для вашей команды. Тут вы вспоминаете, как принимали решение о найме, и делаете поправки в своих принципах подбора кадров, чтобы в дальнейшем совершать меньше ошибок.
Бывают и ситуации, когда свою роль сыграло чистое везение. Это не значит, что вы хорошо принимаете решения и надо впредь надеяться на похожий сценарий. Если вам повезло, это отлично, но опять же свои принципы нужно пересмотреть.
Рецепт №3: Постройте план своего развития, основываясь на том, кем хотите стать.Получив фидбэк на собеседованиях и запросив его у своих коллег, проведя анализ своих решений, займитесь своим развитием. Причем не абстрактно «хочу научиться мотивировать», а прокачайте именно то, чего вам сейчас больше всего не хватает.
В этом может помочь проект Teamlead Roadmap. Это развесистая карта из разнообразных компетенций, которые ожидаются от тимлида в разных компаниях. У каждой ветки развития есть большое описание: что в себя включает, как прокачать, на что обратить внимание, как делать не надо и т.д.
Страх №2. Ты не шаришь в разработке
Многие считают, что став менеджером, вы моментально разучитесь разрабатывать. Поэтому книга «Как подсидеть тимлида» советует задавать тимлиду открытые вопросы о недавних изменения в технологиях и не давать отделаться абстрактными ответами типа «Да, выглядит интересно, надо попробовать». Другой способ подкрепить неуверенность тимлида в своих силах изощреннее:
Книга «Как подсидеть тимлида», совет №8: Организуйте хакатон и сколотите команду из своих коллег. Когда тимлид подойдет и робко спросит, почему его не взяли, скажите, что программисты на Excel и Exchange вам в команде не нужны.Для усиления эффекта книга рекомендует откопать коммиты тимлида трехлетней давности, скинуть в общий чат посмеяться. Синдрому самозванца нужна постоянная подпитка — пусть тимлид думает, что когда был разработчиком, тоже не шарил.
Эти страшные истории основаны на внутренней уверенности тимлида в том, что:
- Он должен быть умнее любого члена команды.
- Если не пишешь код, как специалист, ты не очень нужен.
- Став тимлидом, забываешь, как вообще разрабатывать.
Тимлид должен быть умнее любого члена команды
Вернемся к опросу и посмотрим, как тимлиды оценивают свои технические навыки по отношению к остальной команде.
80% опрошенных считают, что они мощнее всех в своей команде.Действительно, тимлидами часто назначают лучшие инженеров в команде, поэтому этот миф довольно состоятельный.
Что интересно, уверенность в своем техническом уровне коррелирует с тем, насколько много тимлид программирует.
Если тимлид много кодит, он ведёт за собой команду очень уверенно. Но чем меньше он работает руками, тем ниже его уверенность — в районе 10% тимлид становится легкой добычей для того, кто собрался его подсидеть.
Если не пишешь код, ты не нужен — несостоятельный миф: 34% опрошенных тимлидов вообще не считают своей рабочей обязанностью писать код и нормально с этим живут.
Став тимлидом, ты забываешь, как разрабатывать
В среднем 40% рабочего времени тимлид занимается инженерными задачами — пишет код, если он тимлид разработки.
Очевидным образом этот процент коррелирует с размером команды. В маленькой команде из 3-4 человек тимлид скорее всего «играющий тренер». Но с ростом команды времени на код остается все меньше и меньше, и тимлид и правда постепенно забывает, как разрабатывать. Этот миф отчасти верен.
Как победить страх, что ты не шаришь в разработке
Несмотря на то, что мифы о снижении уровня инженерной компетенции тимлида частично оправдали себя, есть верные пути борьбы со вторым страхом.
Рецепт №1: Попробуйте философию Servant Leadership вместо технологического доминирования.Можно вместо того, чтобы изо всех сил пытаться поддерживать технические навыки, смириться, признаться, что вряд ли у вас это получится, и стать лидером-слугой.
Servant Leadership — это интересная управленческая философия, которой, например, придерживаются в Booking.com.
Рецепт №2: Пишите код и никого не слушайте.На конференциях часто говорят, что настоящий тимлид код не пишет, он должен быть менеджером на баррикадах. Но если вы хотите писать код, в этом нет ничего страшного. Однако, есть нюанс.
Не делайте так. Не думайте, что раз вы тимлид, то вам нужно взять в работу самое блокирующее, сложное, горящее или просто прикольное из бэклога. Взяв на себя самую важную инженерную задачу, вы с высокой вероятностью переключитесь на другие, тоже важные и срочные дела типа митингов, планирования и т.д.
То есть хотите писать код — пишите, но делайте то, что не заблокирует работу вашей команды. Беря на себя задачу разработчика, выбирайте то:
- от чего не зависит успех спринта;
- что даст пользу команде или продукту;
- что можно растянуть во времени;
- что не мешает развитию команды.
Например, автоматизируйте рутинные вещи, правьте старые баги, делайте нужные фичи — все, что принесет пользу, а не помешает вашей команде.
Рецепт №3: Не хватает времени следить за технологиями? Пусть это делают за вас.Есть несколько испытанных управленческих приемов:
- Дайджесты: берете разработчика, отправляете читать статьи, просите отчет в виде выжимки, отправляете всей команде — вы великолепны!
- Техтолки: берете двух разработчиков, отправляете делать доклады, собираете команду в переговорке, слушаете доклады — вы великолепны!
- Хакатоны: берете команду, вбрасываете список технологий, покупаете пиццу, наблюдаете битву — вы великолепны!
Страх №3. Твоя работа бессмысленна
Это самый сложный из страхов. Когда в один прекрасный день ты просыпаешься и вдруг понимаешь, что тебе не очень хочется идти на работу, которая до этого нравилась. Ты пытаешься вспомнить, что прикольного сделал за последнюю пару недель, и на ум приходит только механическое перетягивание задачек из столбика «TO DO» в столбик «IN PROGRESS». Ты понимаешь, что перестал видеть смысл в том, чем занимаешься.
В книге «Как подсидеть тимлида» так советуют использовать этот страх:Откуда пошли эти шутки, в которых есть доля шутки? Опять виноваты мифы.
- Совет №10: Почаще шутите над тем, что ваш тимлид — бесполезная прослойка.
- Совет №11: Спросите, от чего в своей работе тимлид получает удовольствие.
- Совет №12: Почаще скидывайте ему статьи про профессиональное выгорание.
В тимлиды идут только за зарплатой
Вот что отвечали люди на вопрос, в чем их мотивация работать тимлидом, почему они стали тимлидом.
На первый план вышли такие аргументы, как возможность большего влияния на проект, самостоятельность в принятии решений, работа с командой и людьми и саморазвитие. Всего половина людей отметили, что их мотивацией является зарплата. Причем заметьте, я не просил выделить главный фактор, а вообще спрашивал, ради чего они работают.
Интересно, что 12% опрошенных говорят, что им не нравится быть тимлидом...
Работу тимлида нельзя оценить
Так распределились ответы на вопрос: понимаете ли вы, как руководитель оценивает вашу работу?
К сожалению, 75% опрошенных тимлидов не знают, как руководитель оценивает их работу или не уверены в этом. Очевидно, когда не понимаешь, что от тебя хочет руководитель, трудно понять, что вообще делать.
Как победить страх, что твоя работа бессмысленна
Рецепт №1: Возьмите ручку, лист бумаги и выпишите все плохое и хорошее в вашей работе.
Сначала напишите вообще все, что есть в голове хорошего и плохого про работу. Отложите на время получившийся документ с потоком мыслей и сходите погулять или просто переключитесь на что-то другое. Вернувшись, перечитайте записи и попытайтесь выделить свои мотивационные факторы — позитивные или негативные. Сравните, насколько текущая роль, проект, компания отвечает этим мотивационным факторам. Если удалось отметить лишь малую часть, то, возможно, именно поэтому ваша работа вам кажется бессмысленной.
Рецепт №2: Спросите руководителя, как он понимает, что вы хорошо работаете.Это очень важный вопрос руководителю, и ответ, что тимлид работает хорошо, если его команда работает хорошо, не должен быть для вас достаточным. Задавайте уточняющие вопросы, копайте, но добейтесь понятных критериев оценки результата вашей работы. Нельзя измерять свою работу только по успеху команды.
Рецепт №3: Фиксируйте все свои достижения и не стесняйтесь пользоваться этим списком.Наняли крутого чувака — запишите, уволили некрутого — запишите, сделали классную фичу — запишите, сделали что-то, что считаете своим достижением, — запишите. Этот список будет полезен в трех случаях:
- В вашем общении с руководителем. Скорее всего он не следит за вашей работой постоянно и не всегда в контексте того, что вы делаете. Поэтому, когда вы приходите к нему за обратной связью, ему очень тяжело вспомнить, чем вы занимались. Список хорошего и плохого поможет вам обоим.
- Когда вы пойдете по собеседованиям, вас скорее всего спросят о достижениях. Тут-то и придет на помощь список.
- Когда вы в очередной (или только в первый) раз почувствуете отсутствие смысла в своей работе, откройте этот список. Просто перечитайте его и вы поймете, что делаете действительно полезные вещи.
Рецепт №4: Делитесь с командой тремя основными целями на неделю.Заведите отдельный документ и, например, каждый понедельник вписывайте туда три своих основных фокуса, причем в терминах результата, а не процесса. Например, не провести 10 интервью с пользователями, а проверить такую-то гипотезу. Это поможет не распылять фокус и тимлиду, и команде. Кроме того, команда будет понимать, чем занят руководитель и что для него в этот момент самое важное.
Может быть, книги «Как подсидеть тимлида» и не существует, но эти и другие страхи преследуют многих тимлидов. Когда я 7 лет назад впервые стал тимлидом небольшой команды, я боялся подвести свою команду и старался работать больше всех. Следующим пришел страх, что я не компетентен как менеджер. Потом команда выросла, я стал отходить от разработки и заниматься людьми, появился страх того, что я не шарю в разработке. Я смотрел на других руководителей — они казались умнее меня. Страхи множились.
Приведенные в статье рецепты помогали мне справляться. Каждый раз, когда я встречал новый страх и неудобство, я рефлексировал и искал причины. Обычно я составлял список проблем, каждую из которых обдумывал по отдельности и находил понятное решение. Поэтому я надеюсь, что эти советы помогут и вам. А если чувствовать себя уверенно в роли тимлида вам мешают совсем другие моменты, используйте сырые данные опроса, исследование рынка и полезные материалы, чтобы самостоятельно опровергнуть мифы, и делитесь результатами в комментариях.
Боритесь со своими страхами и помните, что вы в этих страхах не одиноки!
Этот материал изначально был представлен в виде доклада на TeamLead Conf. Его можно посмотреть в плейлисте лучших докладов конференции, а другие выступления использовать для прокачки навыков тимлида, и тогда вас будет ничем не напугать.
Следующая конференция специально для тимлидов пройдет в Санкт-Петербурге в сентябре, и уже сейчас можно подать заявку на выступление — тогда у вас с Программным комитетом будет достаточно времени на то, чтобы глубоко раскрыть тему и подготовить действительно классный доклад. А если вы больше фокусируетесь на инженерных процессах, чем на людях, обратите внимание на новую конференцию TechLead Conf — она пройдет онлайн 8 июня и Call for Papers в самом разгаре.
jetcar
Брать не блокирующие задания это конечно правильно, но ведь от лида обычно ожидают что он сделает самые сложные задания, разве нет?
По остальным пунктам полностью согласен, особенно хорошо мне помогает ходить по собеседованиям, где я понимаю что я всё ещё востребован на рынке с имеющимися знаниями за требуемую мной зарплату.
datacompboy
ну Техлид и Тимлид это ж разные вещи.
Но да, часто путают…
marshinov
Если тим-лид делает самые сложные задачи, все планирует и играет на дуде, то что-то не так в датском королевстве с делегированием
EvilsInterrupt
Нет. От тим.лида не надо ждать, что он придет и запилит то, что другие не смогли. Но то что не хватило рук, с него можно спросить. Он должен четко понимать какие ресурсы были применены для решения текущих задач и почему именно именно эти задачи были взяты в разработку, а не та что не запилена? Он управляет разработкой некоторого участка разработываемого продукта. Другими словами он должен четко понимать, а вот текущего набора программиста хватает для решения типовых задач на его участке или нет? А если спросят его «кого можем сократить?» он должен знать ответ сколько по факту нужно разрабов и на основании этого четко ответить что можем уволить кого-то или наоборот надо нанимать?
Zedmor
Это совсем плохая идея. Задача тимлида научить команду делать самые сложные задачи. В принципе я вижу свою работу как подметать пол, пока остальные работают — снимать блоки, быстро обнаруживать, что кто-то залип и реораганизовать его (попарить с другим, или сесть вместе, сделать митинг-обсуждение). Брать на себя сложные задачи = мешать развитию команды, а именно это «продукт» деятельности тимлида, а не software.