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

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

2. Второй скилл очень связан с первым. Нужно учиться смотреть на любые задачи, технологии, рефакторинги и процессы с точки зрения их влияния на продукт в целом. Нужно всегда уметь ответить на вопрос «а зачем я это делаю»? Условно, вот хочу я затащить библиотеку для DI. Если я это делаю, потому что она сейчас в тренде и все авторитеты индустрии выступают на конференциях, рассказывая про нее – это плохой знак. Надо всегда уметь дать максимально внятно оценить соотношение того, сколько сил придется потратить на какое-то действие к тому, какое влияние оно окажет на проект.

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

4. Также, во многих компаниях и командах тимлид – это важный партнер менеджера, будь то продакт или проджект-менеджер. Поэтому всегда стоит быть в курсе того, как устроены процессы, и постоянно думать о том, что в них можно подтюнить. Это больше про проджектовую часть. Если говорить про продуктовую – надо учиться не стесняться задавать вопрос «а зачем мы это делаем». Не во всех командах есть здоровая культура общения продуктового менеджмента с разработкой, поэтому задачи могут прилетать от людей, которых видишь только раз в год на корпоративе. С этим надо бороться. Если продакт и тимлид регулярно общаются – это помогает обоим принимать более качественные решения.