TeamLead

С удаленной работой надо уметь работать так же, как и с обычной "оффлайн". У неё есть свои ловушки, проблемы и последствия. Давайте вместе разберемся, как эти проблемы находить, а главное - что с этим делать!

⁃ подход к подбору команды, «роли по Сереже» vs «роли по стандартным типологиям»

⁃ Чем топ-команда отличается от команды разработки

⁃ Цикл жизни команды наложенный на цикл развития ее лидера

⁃ Враги и друзья команды

⁃ Мои ошибки при формировании команды

⁃ 5 советов тем, кто завтра окажется в моей роли

В течение нескольких лет мы спрашивали разные команды, с которыми работали, какие факторы, на их взгляд, могут разрушить доверие. В результате мы собрали и проанализировали множество ответов и сгруппировали их в более короткий список из 23 основных факторов, разрушающих доверие в команде.

Расскажу про инструменты, которые помогает выстраивать обсуждения вокруг существующих или потенциальных проблем с доверием и находить возможные решения.

Как рассказывать о своем опыте и шарить экспертизу коллегам?

От скучных daily scrum meeting к интересным стендапам и зажигательным митапам?

Как погружать в контекст, но не перегружать?

Расскажу об опыте моем и компании по подготовке митапов и спикеров.

Остановимся на форматах стендапов, что они дают спикерам и командам. Как это влияет на «пороки команды».

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

Существует много докладов, статей и подкастов про то, что должны делать тимлиды, и какими качествами обладать.

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

Где-то вам нужно собрать команду с нуля, где-то расширить команду с 5 до 50 человек за 3 месяца, а где-то вывести команду из кризиса за те же 3 месяца, иначе все компании конец. Везде нужен тимлид, но везде нужен разный тимлид, с разными скиллами и разными сферами деятельности.

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

- Существует множество способов создать великолепную команду, а возможно ли разделить одну прекрасную команду на две блестящие?

- Поговорим о том, как помочь команде преодолеть сложные этапы разделения и неопределенности в ее развитии.

- Разберем, какую нематериальную мотивацию можно использовать, когда все предыдущие цели становятся неактуальными и требуется новый импульс.

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

Очень часто тимлиду приходится не только управлять команду, но и участвовать в процессе найма и отбора кандидатов. Поговорим о том, как эффективно настроить этот процесс и сэкономить время при отборе.

- Какая технология в описании вакансии, увеличила количество откликов в 3 раза?

- Как составить сценарий разговора, чтобы рекрутёр мог без вас выявить все красные флаги за первые 15 минут скрининга? Действуем по принципу Fail Fast.

- Какие вопросы задавать на собеседовании, чтобы понять, что кандидат действительно хорош в работе, а не просто умеет проходить собеседования?

Также расскажу о тех лайфхаках, которые нашел для себя за 2 года проведения собеседований.

Бонусом расскажу об особенностях найма в международную команду.

Индивидуальный план развития (ИПР) – популярный инструмент в арсенале тимлида.

Нюансы варьируются от компании к компании, и даже между разными командами в рамках одной компании. Где-то есть карта или матрица компетенций (или Job Description), задачи для развития для сотрудника подбираются в соответствии с матрицей. Где-то фиксируется не только конечная цель, но и промежуточные вехи, с привязкой ко времени – честный роадмап.

Шарить ИПР на команду, подключить бота с напоминаниями, ввести грейды, проводить ревью для обратной связи – эксперименты с ИПР можно встретить самые различные.

Везде по-разному, но довольно часто можно встретить и кое-что общее: инициатива с ИПР “замерзает”.

Вроде начинали делать и вроде что-то получалось, а потом интерес пропал, причём с обеих сторон. Сотрудник рад, что он него «отцепились», можно сосредоточиться на понятных задачах. Компания расценила, что халявный способ выжать больше пользы из сотрудников не сработал – суеты много, а отдача ниже ожидаемого. Тимлид рад, что можно меньше внимания уделять непонятным гуманитарным делам; глядишь, и попрограммировать останется время.

А потом случается новый проект, в котором нужна новая технология, а её в команде никто не знает – хотя можно было изучить в рамках ИПР. Или люди уходят из команды с обратной связью, что не ощущают развития, только застой – хотя какой-то “не только текучкой” можно было бы позаниматься в рамках ИПР.

Таким образом получается, ИПР нужен, но не работает? Нужен – да, не работает – я видел обратное.

В докладе поделюсь историями из опыта – как отношение к ИПР и результативность процесса получалось изменить в лучшую сторону за счёт более неформального подхода. В чём этот подход состоит и как работает на практике – расскажу в докладе.

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