Чего ждут от тимлида в современных реалиях
Чего ждут от тимлида в современных реалиях
Чем с большим количеством компаний мы работаем, тем больше обращаем внимание на общий тренд. Во многих организациях, вне зависимости от размера и отрасли, видение роли тимлида (или техлида, ресурсного / линейного менеджера, а также ещё нескольких подобных ролей) в последнее время изменилась. Специалистам, которые занимают ее длительное время, становится сложнее соответствовать требованиям. Как набирать или выращивать новых таких лидеров, организации еще не знают. Но организации требуют соответствия новым ожиданиям от роли .
Рассмотрим несколько реальных историй, когда тимлиду, руководителю проектов и т.д. пришлось применять новые новыки из-за тех изменений, которые происходили с их компаниями:
Алексей руководил 4 бэк-эндерами. В его обязанности входила постановка задач, подключение к решению сложных задач в роли эксперта, оценка эффективности сотрудников. Компания росла, стали приходить новые разработчики с разным уровнем экспертизы. У Алексея увеличилось время на постановку и контроль исполнения задач (при этом его участие в сложных случаях не сократилось). Было принято решение о формировании 3 кросс-функциональных команд в рамках продукта, каждая со своим владельцем продукта. Именно они стали определять, чем будет заниматься команда. Алексей же стал тимлидом на весь продукт. При этом он потерял контроль за тем, какие задачи выполняют какие исполнители. Это затруднило оценку эффективности сотрудников и контроль архитектурных решений.
Денис руководил командой из 5 фронтенд разработчиков. Они выполняли доработки фронта по всем продуктам, получая на вход ТЗ на фронтенд. С развитием продуктов времени на постановку задач и передачу контекста требовалось все больше. Фронт стал отставать. Образовались очереди. Стало заметно "трение", связанное с передачей контекста и постановкой задач. При этом стратегия компании предполагала кратное увеличение продуктов с собсвтенным пользовательским интерфейсом в следующем году при трехкратном увеличении количества фронтенд разработчиков. Чтобы справиться с этими вызовами, очевидным казалось решение закрепить фронтенд разработчиков за продуктовыми командами. Однако для компании было важно сохранить единый UX, а для Дениса - не повторить предыдущий негативный опыт изменений в этой команде, когда решение о смене инструментария привело к многомесячным холиварам и расколу среди разработчиков.
Петр работал ресурсным менеджером в инженерном консалтинге. Особенностью отрасли и компании была глубокая и узкая специализация консультантов. Основной задачей ресурсного менеджера было обеспечение стабильно высокой загруженности консультантов в соответствии с квалификацией и потребностями проекта. Этой цели можно было достичь при одновременном вовлечении консультанта в 9-10 проектов. Со временем скорость выполнения проектов перестала устраивать заказчиков, а исполнители стали проявлять недовольство постоянным переключением контекста и отсутствием ощущения причастности к проекту или команде. Это привело к увеличению текучки специалистов и дефициту редкой экспертизы. Компания решила, что эти проблемы можно преодолеть, расширив зону экспертизы и уменьшив количество проектов на одного консультанта. Фокус компании сместился на создание T-shape культуры. Это потребовало от Петра обеспечения безопасной среды, работы со страхами персонала, развития, выделения времени на передачу знаний. Опыта для этого у него было недостаточно.
Ольга, в прошлом руководитель проектов. Отвечала за выполнение задач в срок и в бюджет (так как исполнителями были подрядные организации). Компания приняла решение отказаться от IT-вендоров и наняла в штат команду, которую Ольга и возглавила. Вот некоторые из трудностей, с которыми она столкнулась: не было формальных подрядных отношений, позволяющих требовать выполнения задачи в срок под угрозой юридических последствий. Не было начальника, на которого было бы удобно эскалировать проблемы (точнее, таким начальником стала Ольга, и эскалации стали не способом решения проблем, а ее болью). Пропала возможность быстрой замены выгоревшего или непродуктивного ресурса.
Можно заметить, что от новой роли, вне зависимости от названия, ожидается определенный набор навыков, которые не применялись и не совершенствовались ранее. Среди этих навыков мы выделяем следующие:
Во всех описанных кейсах участникам пришлось выращивать в себе недостающие навыки, чтобы справиться с теми вызовами, которые они встретили в новой роли. Так, Ольга смогла обратить внимание участников команды на то, какими способами они сами смогут справиться с имеющимися проблемами. Для этого ей пришлось на собственном примере демонстрировать навык предоставления обратной связи вместо эмоциональных выпадов при общении с командой (в последствие это стало общим правилом). Изменить привычный стиль лидерства, отдав все заслуги по развитию продукта команде (что привело к росту мотивации участников и готовности брать сложные и непонятные задачи). Алексей создал дэшборд с метриками для выявления отклонений. Эти метрики использовались не для наказания людей, а как индикаторы отклонений в производственном процессе. Кроме того, Алексей передал функцию управления архитектурой в команды, включая ответственность за принимаемые решения. Петр начал проводить эффективные 1-on-1, применять инструменты Management 3.0 для работы с внутренней мотивацией вверенных сотрудников, строить для сотрудников планы развития компетенций. Денис, прежде чем закрепить фронтендеров за продуктовыми командами, спланировал это внедрение изменения по модели Коттера. Он донес до команды, что предстоящее масштабирование команды усугубит текущие проблемы с обеспечением единообразия UX. Он помог разработчикам самоорганизоваться и принять решение о создании библиотеки компонентов, позволившей решить проблемы единообразия, переиспользования и владения кодовой базой.
Описанный тренд - содержательное изменение роли лидера / руководителя - подтверждает актуальность непрерывного обучения и получения новых навыков. Для этого существует множество специализированных программ обучения.
Рассмотрим несколько реальных историй, когда тимлиду, руководителю проектов и т.д. пришлось применять новые новыки из-за тех изменений, которые происходили с их компаниями:
Алексей руководил 4 бэк-эндерами. В его обязанности входила постановка задач, подключение к решению сложных задач в роли эксперта, оценка эффективности сотрудников. Компания росла, стали приходить новые разработчики с разным уровнем экспертизы. У Алексея увеличилось время на постановку и контроль исполнения задач (при этом его участие в сложных случаях не сократилось). Было принято решение о формировании 3 кросс-функциональных команд в рамках продукта, каждая со своим владельцем продукта. Именно они стали определять, чем будет заниматься команда. Алексей же стал тимлидом на весь продукт. При этом он потерял контроль за тем, какие задачи выполняют какие исполнители. Это затруднило оценку эффективности сотрудников и контроль архитектурных решений.
Денис руководил командой из 5 фронтенд разработчиков. Они выполняли доработки фронта по всем продуктам, получая на вход ТЗ на фронтенд. С развитием продуктов времени на постановку задач и передачу контекста требовалось все больше. Фронт стал отставать. Образовались очереди. Стало заметно "трение", связанное с передачей контекста и постановкой задач. При этом стратегия компании предполагала кратное увеличение продуктов с собсвтенным пользовательским интерфейсом в следующем году при трехкратном увеличении количества фронтенд разработчиков. Чтобы справиться с этими вызовами, очевидным казалось решение закрепить фронтенд разработчиков за продуктовыми командами. Однако для компании было важно сохранить единый UX, а для Дениса - не повторить предыдущий негативный опыт изменений в этой команде, когда решение о смене инструментария привело к многомесячным холиварам и расколу среди разработчиков.
Петр работал ресурсным менеджером в инженерном консалтинге. Особенностью отрасли и компании была глубокая и узкая специализация консультантов. Основной задачей ресурсного менеджера было обеспечение стабильно высокой загруженности консультантов в соответствии с квалификацией и потребностями проекта. Этой цели можно было достичь при одновременном вовлечении консультанта в 9-10 проектов. Со временем скорость выполнения проектов перестала устраивать заказчиков, а исполнители стали проявлять недовольство постоянным переключением контекста и отсутствием ощущения причастности к проекту или команде. Это привело к увеличению текучки специалистов и дефициту редкой экспертизы. Компания решила, что эти проблемы можно преодолеть, расширив зону экспертизы и уменьшив количество проектов на одного консультанта. Фокус компании сместился на создание T-shape культуры. Это потребовало от Петра обеспечения безопасной среды, работы со страхами персонала, развития, выделения времени на передачу знаний. Опыта для этого у него было недостаточно.
Ольга, в прошлом руководитель проектов. Отвечала за выполнение задач в срок и в бюджет (так как исполнителями были подрядные организации). Компания приняла решение отказаться от IT-вендоров и наняла в штат команду, которую Ольга и возглавила. Вот некоторые из трудностей, с которыми она столкнулась: не было формальных подрядных отношений, позволяющих требовать выполнения задачи в срок под угрозой юридических последствий. Не было начальника, на которого было бы удобно эскалировать проблемы (точнее, таким начальником стала Ольга, и эскалации стали не способом решения проблем, а ее болью). Пропала возможность быстрой замены выгоревшего или непродуктивного ресурса.
Можно заметить, что от новой роли, вне зависимости от названия, ожидается определенный набор навыков, которые не применялись и не совершенствовались ранее. Среди этих навыков мы выделяем следующие:
- Эмоциональный интеллект.
- Ситуационное и служащее лидерство.
- Делегирование.
- Обратная связь.
- Создание экосистемы метрик.
- Мотивация команд.
- Управление изменениями.
- Выстраивание и поддержка сообществ.
Во всех описанных кейсах участникам пришлось выращивать в себе недостающие навыки, чтобы справиться с теми вызовами, которые они встретили в новой роли. Так, Ольга смогла обратить внимание участников команды на то, какими способами они сами смогут справиться с имеющимися проблемами. Для этого ей пришлось на собственном примере демонстрировать навык предоставления обратной связи вместо эмоциональных выпадов при общении с командой (в последствие это стало общим правилом). Изменить привычный стиль лидерства, отдав все заслуги по развитию продукта команде (что привело к росту мотивации участников и готовности брать сложные и непонятные задачи). Алексей создал дэшборд с метриками для выявления отклонений. Эти метрики использовались не для наказания людей, а как индикаторы отклонений в производственном процессе. Кроме того, Алексей передал функцию управления архитектурой в команды, включая ответственность за принимаемые решения. Петр начал проводить эффективные 1-on-1, применять инструменты Management 3.0 для работы с внутренней мотивацией вверенных сотрудников, строить для сотрудников планы развития компетенций. Денис, прежде чем закрепить фронтендеров за продуктовыми командами, спланировал это внедрение изменения по модели Коттера. Он донес до команды, что предстоящее масштабирование команды усугубит текущие проблемы с обеспечением единообразия UX. Он помог разработчикам самоорганизоваться и принять решение о создании библиотеки компонентов, позволившей решить проблемы единообразия, переиспользования и владения кодовой базой.
Описанный тренд - содержательное изменение роли лидера / руководителя - подтверждает актуальность непрерывного обучения и получения новых навыков. Для этого существует множество специализированных программ обучения.
Возможно будет интересно
