Почему-то считается, что тимлид — это более высокая ступень эволюции инженера, чем все квалификационные уровни, включая senior. При том что всем известно, навыки и умения там нужны совсем другие. Но факт продолжает оставаться фактом, в большинстве компаний тимлидами становятся лучшие инженеры. Иногда, потому что руководству кажется, что это даст сотруднику новую мотивацию и вообще — это же повышение. Иногда, в силу необходимости — наняли много новых сотрудников, и кто-то должен за них отвечать и помогать им пилить новые фичи. Неудивительно, что неподготовленный человек, брошенный в новые обязанности, как в воду, сваливается в состояние экзистенциального кризиса.
То, что доклад на эту тему был признан лучшим на конференции для тимлидов и о тимлидах, показывает, насколько действительно часто встречается такая ситуация. Но надо признать, конечно, что Евгений Кот (bunopus) заработал это «признание» еще и великолепным перформансом. С удовольствием делимся с вами его записью.
Честное слово, стоит выделить время на просмотр этого выступления. Тем более что кода и сложных терминов там не будет — можно даже с семьей посмотреть :) Но, если вы тимлид, который еще не все заделегировал, и времени у вас в обрез, ниже немного спойлеров и важных, хоть и местами капитанских, мыслей.
Во-первых, практически главный вопрос о жизни и нашей тимлидской вселенной — кто такой тимлид?
«Быть тимлидом быть очень круто!» — думал Евгений, только им став: «Буду решать очень важные вопросы». А получил наверняка и вам знакомое горькое чувство, когда на стендапе после докладов о сделанных фичах и пофикшенных багах и сказать-то нечего. Ты вроде как ничего и не сделал: на митинги ходил, на почту отвечал. Или вообще удар, когда подчиненный говорит, что ты же не пишешь код, зачем ты изображаешь, что делаешь code review.
В этот момент в зале раздались аплодисменты — тут у многих болит.
Рассмотрим теперь трех персонажей, которые будут олицетворять классические типы тимлидов.
Иннокентий: мастер планирования, разбирается в бизнес метриках, знает кучу аббревиатур. Но его команда не знает, что творится снаружи, не знает, как их работа связана с бизнес-задачами. В команде Иннокентия нет гибкости и нет роста.
Степан: очень крутой разработчик, может закрыть за один день больше задач, чем весь отдел. Конечно, он думает, что все остальные в его команде не так хороши, не доверяет им сложных задач. Как следствие, bus factor=1 и никакой надежды на рост сотрудников.
Игнат: стоит лицом к бизнесу, а к команде чем-то другим. Не берет ответственность, не очень понимает, что творится в команде.
Все они устраивают бизнес, но едва ли мы назовем их хорошими тимлидами. А все потому, что тимлид — это другая ветвь эволюции. И вот вам совет дня.
«Так ведь других-то нет!» — скажете вы. И приходится новоиспеченному тимлиду пытаться усидеть на двух стульях: синьорском и менеджерском. На одном — думать об архитектуре, закрывать задачи, помогать команде в сложных реализациях. На другом — мотивировать, растить и т.д. Нет-нет, да и просядет что-нибудь, пока на обоих пытаешься усидеть.
Совет известный — делегируй! Но распихать задачи в Jira — это не делегирование. Делегировать надо ответственность, а не задачи. Например, пускай ревью проводит кто-нибудь из команды.
Второй пункт, тоже вроде банальный. Но обязательный.
А еще заведите блокнот (ок, это может быть приложуха) и прочитайте уже Дорофеева (хотя бы в таком коротком варианте). И тогда можно будет заняться непосредственными задачами тимлида: фокусировать, растить, вдохновлять, коммуницировать, думать о людях. Техлид может не работать с людьми, а тимлид — должен.
Если ваши люди не растут — вы плохой тимлид. И вы никогда не узнаете, в чем проблема, если не будете говорить с людьми.
Напоследок Евгений предлагает вспомнить о философии Икигаи, и желает нам с вами встать на путь к его поиску и на этом пути никогда не быть несчастными.
Такая вот смесь практики и экзистенциализма очень понравилась слушателям на Saint TeamLead Conf. Дальше в ТОП-5 вошли доклады:
2. Оцениваем процессы в команде разработки на основе объективных данных / Сергей Семенов.
3. Коммуникации как performance-зона работы тимлида / Александр Зиза.
4. Роль тимлида в рекрутинге / Катерина Гаврилова
5. Как оценить эффективность команды / Алексей Катаев
Оставайтесь с нами, скоро откроем видео этих выступлений и что-нибудь про них опубликуем. Видео можно ловить на youtube-канале, а новости конференции в рассылке.
То, что доклад на эту тему был признан лучшим на конференции для тимлидов и о тимлидах, показывает, насколько действительно часто встречается такая ситуация. Но надо признать, конечно, что Евгений Кот (bunopus) заработал это «признание» еще и великолепным перформансом. С удовольствием делимся с вами его записью.
Честное слово, стоит выделить время на просмотр этого выступления. Тем более что кода и сложных терминов там не будет — можно даже с семьей посмотреть :) Но, если вы тимлид, который еще не все заделегировал, и времени у вас в обрез, ниже немного спойлеров и важных, хоть и местами капитанских, мыслей.
Во-первых, практически главный вопрос о жизни и нашей тимлидской вселенной — кто такой тимлид?
«Быть тимлидом быть очень круто!» — думал Евгений, только им став: «Буду решать очень важные вопросы». А получил наверняка и вам знакомое горькое чувство, когда на стендапе после докладов о сделанных фичах и пофикшенных багах и сказать-то нечего. Ты вроде как ничего и не сделал: на митинги ходил, на почту отвечал. Или вообще удар, когда подчиненный говорит, что ты же не пишешь код, зачем ты изображаешь, что делаешь code review.
В этот момент в зале раздались аплодисменты — тут у многих болит.
Рассмотрим теперь трех персонажей, которые будут олицетворять классические типы тимлидов.
Иннокентий: мастер планирования, разбирается в бизнес метриках, знает кучу аббревиатур. Но его команда не знает, что творится снаружи, не знает, как их работа связана с бизнес-задачами. В команде Иннокентия нет гибкости и нет роста.
Степан: очень крутой разработчик, может закрыть за один день больше задач, чем весь отдел. Конечно, он думает, что все остальные в его команде не так хороши, не доверяет им сложных задач. Как следствие, bus factor=1 и никакой надежды на рост сотрудников.
Игнат: стоит лицом к бизнесу, а к команде чем-то другим. Не берет ответственность, не очень понимает, что творится в команде.
Все они устраивают бизнес, но едва ли мы назовем их хорошими тимлидами. А все потому, что тимлид — это другая ветвь эволюции. И вот вам совет дня.
«Так ведь других-то нет!» — скажете вы. И приходится новоиспеченному тимлиду пытаться усидеть на двух стульях: синьорском и менеджерском. На одном — думать об архитектуре, закрывать задачи, помогать команде в сложных реализациях. На другом — мотивировать, растить и т.д. Нет-нет, да и просядет что-нибудь, пока на обоих пытаешься усидеть.
Совет известный — делегируй! Но распихать задачи в Jira — это не делегирование. Делегировать надо ответственность, а не задачи. Например, пускай ревью проводит кто-нибудь из команды.
Второй пункт, тоже вроде банальный. Но обязательный.
А еще заведите блокнот (ок, это может быть приложуха) и прочитайте уже Дорофеева (хотя бы в таком коротком варианте). И тогда можно будет заняться непосредственными задачами тимлида: фокусировать, растить, вдохновлять, коммуницировать, думать о людях. Техлид может не работать с людьми, а тимлид — должен.
Если ваши люди не растут — вы плохой тимлид. И вы никогда не узнаете, в чем проблема, если не будете говорить с людьми.
Лайфхак: если в рабочей атмосфере разговор по душам не получается, предложите подвезти и коварно разговорите.
Напоследок Евгений предлагает вспомнить о философии Икигаи, и желает нам с вами встать на путь к его поиску и на этом пути никогда не быть несчастными.
Такая вот смесь практики и экзистенциализма очень понравилась слушателям на Saint TeamLead Conf. Дальше в ТОП-5 вошли доклады:
2. Оцениваем процессы в команде разработки на основе объективных данных / Сергей Семенов.
3. Коммуникации как performance-зона работы тимлида / Александр Зиза.
4. Роль тимлида в рекрутинге / Катерина Гаврилова
5. Как оценить эффективность команды / Алексей Катаев
Оставайтесь с нами, скоро откроем видео этих выступлений и что-нибудь про них опубликуем. Видео можно ловить на youtube-канале, а новости конференции в рассылке.
Комментарии (9)
dim2r
26.10.2018 08:43-2Есть простенький психологический тест Климова на определение направления профессиональной деятельности. Если не в свое направление попал, то будет дискомфортно.
romas1982 Автор
26.10.2018 10:12Тест Климова крайне общий и как все тесты очень сильно зависит от текущего настроения и положения дел.
Mishiko
26.10.2018 11:47«распихать задачи в Jira» — может это и не делегирование, но даже такая деятельность, осуществляемая разумно, может способствовать росту сотрудников и результативности команды
sammorganium
26.10.2018 13:07Не знаю, будь ты тим лидом, директором, хоть главой крупной корпорации… Если ты занимаешься не любимым делом, везде будет плохо…
sotnikdv
Разделяйте менеджерскую и инженерную ветку, как минимум. Тимлид- это какой-то универсальный мутант, очень любимый на постсоветском пространстве, калька с промышленных карьерных путей.
Даже если один человек сидит на нескольких стульях и играет несколько ролей, он должен четко понимать суть и границы каждой роли. Не смешивать их, разделять время, контексты и осознавать, сколько времени на какую роль он тратит.
Тогда легко сказать менеджеру, что «нам нужен отдельный SCRUM master / engineering manager, пусть и управляющий несколькими проектами».
Я часто играю несколько ролей в проекте, но разделение соблюдается и я легко и беспроблемно могу передать (или принять) роли девелопера, тех.лида, SCRUM master, engineering manager или архитектора.
Я не архитекторо-девелоперо-менеджер, я человек с определенным опытом и несколькими ролями, которые не пересекаются в одной точке пространства-времени.
Это позволяет остальным членам команды понимать, где границы между карьерными путями, какие роли им доступны и чем они отличаются. И где они разделяются. И не смешивать все в кучу.
Это же позволяет не рушить процессы внутри команды. Играешь роль девелопера — подчиняешься процессам девелопмента. Заодно помогает наводить дисциплину просто примером — я, <павлиний список тайтлов>, следую всем правилам, код ревью, тесты и т.д. как нормальный девелопер.
ИМХО