Как работать без тимлида и чем это грозит

В феврале прошла конференция TeamLead Conf 2020 — одно из последних до пандемии отраслевых мероприятий в офлайне. В рамках ближайшей недели в блоге Skillbox мы разберем лучшие доклады спикеров. Сегодня — самое полезное из выступления Якова Беккера из PropellerAds. Спикер рассматривает альтернативный подход работы над проектами — тимлида.

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

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

Первый шаг на пути к эффективной работы без тимлида — распределить сотрудников по командам. Каждая команда должна быть способной закрывать любую IT-задачу от и до, поэтому включает в себя разработчиков, дизайнеров, QA-инженеров и других специалистов, которые для этого необходимы. Обычно хватает 7—9 человек.

Второй шаг — обеспечить каждой команде поддержку со стороны профессионалов: функциональных менеджеров. Они занимаются наймом, руководством и мотивацией сотрудников: составляют персональные планы развития, проводят интервью one-on-one и квартальные ревью. Каждый член команды знает, что ему есть к кому обратиться за помощью, инструкцией или просто советом.

Теперь осталось понять, что делать руководителям отделов, которые ставят разработчикам задачи. В зависимости от задачи руководитель может привлечь одну или несколько команд разработчиков. Главное — подбирать такие команды, которые могут выполнять по меньшей мере 90% задач, чтобы руководителю не приходилось искать решения на стороне. В результате сотрудники понимают, что им делать, а заказчик (руководитель отдела) уверен, что его задача будет выполнена в срок.

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

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

Решается это просто: в команде должны быть два—три лидера. Лидеры не выгорают, потому что руководитель дает им заниматься ровно тем, что им нравится. У них нет причин быть недовольными работой или переходить в другую компанию, поэтому они преданы делу и стимулируют других членов команды работать эффективнее.

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

Чтобы решить эту проблему, нужно предоставлять сотрудникам независимость и давать право на ошибку. Для этого следует заменить активный контроль на пассивный. Не стоит каждые пять минут задавать вопросы в духе: «Ну что, сделал?» или «Как там sprint goal?» Информацию о статусе задач руководителю нужно получать из других источников, например менеджеров задач или демо-версий продукта.

Соблюдение этих условий помогает компании эффективно разрабатывать проекты без тимлида.