Как тимлиду научиться делегировать

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

Я был разработчиком и перешел в тимлиды по принципу самого сильного программиста в комнате. Когда я стал тимлидом, мне казалось, что могу сделать все быстрее и больше, чем другие. Я брал на себя все больше задач, работал по двенадцать часов в день и в итоге выгорел. Я чувствовал, что не могу ни на кого положиться. Тогда я понял, что нужно изучать делегирование. Я начал изучать тему, пробовать и ошибаться. И в этой статье я хочу рассказать про свой опыт, поделиться практиками и советами.

Что такое делегирование? Определение и суть

Для начала определимся, что такое делегирование. Это не просто передача полномочий, а передача задач, полномочий и ответственности от руководителя членам команды. Это не сброс задач на других, а осознанный процесс, который включает:

• Постановку задачи: четкое объяснение, что нужно сделать, зачем и каковы критерии успеха,

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

• Передача ответственности. Сотрудник отвечает за результат, но вы как руководитель остаетесь ответственным за весь процесс.

Делегирование не про избавление от работы, а про эффективное распределение задач внутри команды. Каждый работает на своем уровне компетенции и развивается. Когда задачи распределены правильно, команда работает лучше и быстрее, потому что каждый занимается тем, что получается лучше всего. Это ответственность руководителя – найти для людей работу, которая подходит им лучше всего. Если тимлид берет на себя слишком много задач, он становится «узким горлышком» процесса, команда ждет его одобрений, что замедляет работу.

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

Со временем я понял, что делегирование – это инструмент для развития команды. Он помогает сотрудникам расти и становиться увереннее и самостоятельнее. Когда вы передаете задачи команде, у сотрудников появляется возможность работать над новыми задачами, которые выходят за рамки их текущих обязанностей. Это помогает развивать навыки и расширять экспертизу. Когда они справляются с такими задачами, их уверенность в себе растет, они начинают верить в свои силы и брать на себя больше ответственности. Так появляются новые лидеры.

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

Практический шаг 1: Определение, что можно делегировать – матрица Эйзенхауэра

Теперь перейдем к практическим шагам, из которых состоит делегирование. Я расскажу про несколько техник, которые помогли мне, и считаю их эффективными. Я надеюсь, что они помогут и вам.

Первое: нужно определить, что можно делегировать. Не все задачи можно делегировать. Есть стратегические задачи, которые вы должны делать сами. Это работа, которую за вас никто не сделает. Все остальное с разным уровнем ответственности можно делегировать.

Чтобы определить, что можно делегировать, есть инструмент – матрица Эйзенхауэра.

Суть заключается в распределении задач по двум шкалам: важно–неважно и срочно–несрочно. В итоге получается четыре зоны.

Все, что попадает в квадрат «важно и срочно», вы должны делать сами. Это задачи, которые нельзя делегировать:

• Решение критического бага в проде,

• Устранение конфликта в команде,

• Устранение блокера для разработки,

Это «пожары». Важно не допускать, чтобы они вас заваливали.

Все, что попадает в квадрат «важно, но не срочно», нужно делегировать или планировать. Это:

• Планирование долгосрочной архитектуры проекта,

• Разработка стратегии развития команды,

• Постановка долгосрочных целей.

Главное – не допускать перехода этих задач в квадрат «важно и срочно», когда сроки провалены, а задача не начата. Нужно стремиться к тому, чтобы как можно больше задач оставалось в этом квадрате, потому что вы можете делать их без стресса или делегировать без риска. У вас будет время вмешаться, если что-то пошло не так. Это невозможно сделать с задачами из квадрата «важно и срочно».

Все, что находится в квадрате «неважно, но срочно», нужно делегировать. Это:

• Написание документации,

• Решение мелких технических вопросов,

• Участие в неважных созвонах.

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

Все, что находится в квадрате «неважно и не срочно», нужно выкидывать. Даже если вы оставите эти задачи в листе ожидания, вы их не сделаете, потому что будут появляться задачи важнее и срочнее. Экономьте силы и выкидывайте их сразу.

Практический шаг 2: Выбор правильного сотрудника для делегирования

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

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

Для повышения мотивации и вовлеченности выбирайте задачи, которые соответствуют профессиональным интересам сотрудника. Если сотрудник стремится развиваться в какой-то области, поручите ему задачу, которая поможет ему в этом.

Пример неудачного делегирования: Когда выбор сотрудника оказался ошибочным

Шаг выбора задачи для человека очень важен. У меня была такая история. Достаточно нагруженный склад, на котором работает WMS 24/7. Для этой WMS готовилось небольшое обновление. Оно было не критичным и неважным. В нем было несколько фичей, направленных на юзабилити. Так как это было не критичное обновление, тестирование поручили молодому тестировщику, который только пришел в команду. Это была почти его первая задача. Он тестировал, не нашел багов, и обновление выкатили в прод.

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

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

Практический шаг 3: Четкая постановка задачи – метод SMART

Четко поставленная цель – залог успешного выполнения работы. Уделите достаточно времени формулировке задачи, и это окупится качественным результатом и сохранением ресурсов на переделках.

Здесь помогает метод SMART. Каждая буква обозначает критерий, которому должна соответствовать задача. Задача должна быть:

• Specific – Конкретная. Четко сформулирована, без двусмысленности,

• Measurable – Измеримая. Должны быть критерии, по которым можно оценить,

• Achievable – Достижимая. Задача должна быть реалистичной и выполнимой с учетом,

• Relevant – Релевантная. Задача должна быть значимой и соответствовать общим целям,

• Time-bound – Ограниченная по времени. Должен быть четкий срок выполнения.

Например, вместо формулировки «Напиши документацию» используйте формулировку: «Напиши документацию к следующей пятнице по API, включающую примеры запросов и ответов. Документация должна быть размещена на Confluence». Это четко поставленная задача: конкретная, измеримая, достижимая, релевантная текущей команде и ограниченная по времени.

Практический шаг 4: Контроль без микроменеджмента

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

Объясняйте, что чекпоинты – это не контроль, а инструмент для успешного выполнения задач. Делегируйте с умом, сохраняя баланс между доверием, свободой, которую вы даете, и контролем, чтобы задача выполнялась эффективно, а команда чувствовала вашу поддержку.

Практический шаг 5: Обратная связь – ключ к росту команды

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

Давать правильную обратную связь – отдельный вид искусства. О том, как это делать, есть много информации, приемов и советов:

• Будьте конкретными. Указывайте, что было сделано хорошо, а где требуется улучшение. Например: «Ты отлично справился с подготовкой документации, особенно понравилась структура и детализация».

• Старайтесь задавать вопросы вместо прямых указаний. Спросите: «Как ты думаешь, что можно улучшить в этом процессе?» Это помогает сотруднику самостоятельно анализировать свои действия.

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

• Создавайте атмосферу доверия. Команда должна чувствовать, что может обратиться к вам за советом или помощью без страха осуждения.

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

Главная проблема: Мы знаем, как делегировать – но не делаем

Можно было сказать, что на этом все и статья закончена. А теперь поговорим серьезно.

Мы поговорили про то, что такое делегирование. Мы проговорили про инструменты делегирования. Оказывается, что сам процесс делегирования и инструменты для него либо интуитивно понятны, либо широко известны.

Кто не знал, что такое матрица Эйзенхауэра? Кто не знал, что такое SMART-цели? В чем тогда проблема?

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

Причина 1: Страх потери контроля

Я начинал путь с позиции разработчика. Когда я перешел на позицию тимлида, передача любой задачи отзывалась во мне глубокой болью. Уже позже, рефлексируя над своим поведением и наблюдая за коллегами, я понял, что проблема не в том, что мы не знаем, как это делать, а в том, что мы боимся это делать. У каждого есть свои страхи и опасения, с которыми нужно работать. Первое, что нужно сделать, – признать, что я чего-то боюсь. Попробуйте задать себе вопрос: почему я все понимаю, но не делаю это? Почему я нахожу себе отговорки вроде «сейчас не время» или «я доделаю эту задачу и передам»? Эти страхи могут быть осознанными или подсознательными, но они влияют на эффективность управления командой.

Давайте поговорим про эти страхи, про причины, которые заставляют нас так делать, и про то, что с этим делать.

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

• Привычка делать все самому. Многие начинали путь разработчиками, где успех зависит от личных усилий. Переход к управлению требует смены мышления. Теперь успех зависит от всей команды. Это вызывает дискомфорт и страх, что команда не справится без постоянного контроля.

• Недостаток доверия команде. Если вы не уверены в компетенциях сотрудников, вы будете бояться делегировать. Это особенно актуально для новых команд или команд, где сотрудники еще не показали надежность. История про доверие проходит через всю тему делегирования: доверие к себе и доверие к команде.

Что с этим делать?

• Начинайте с малого. Делегируйте небольшие задачи, которые не критичны для проекта. Это поможет привыкнуть к тому, что команда может справиться без постоянного контроля.

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

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

Причина 2: Боязнь, что сотрудники сделают хуже

Еще один распространенный страх – боязнь, что сотрудники сделают что-то неправильно. Тимлид может думать: «Они сделают хуже, чем я» или «Дольше объяснять, проще самому сделать». Это приводит к тому, что задачи команды замыкаются на одном человеке. Тимлид, сам того не понимая, становится «узким горлышком» для команды.

Почему возникает этот страх?

• Высокие стандарты качества. Многие тимлиды привыкли выполнять работу на высоком уровне и боятся, что сотрудники не смогут соответствовать этим стандартам. Этим особенно страдают тимлиды, которые выросли как самые сильные программисты в комнате.

• Боязнь последствий. Ошибки сотрудников могут повлиять на результат проекта, на репутацию тимлида или на отношения с заказчиком. Это заставляет тимлидов брать задачи в свои руки. Отсюда возникает недоверие к команде.

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

Что с этим делать?

• Нужно принять, что ошибки неизбежны. Это часть обучения. Вместо страха используйте ошибки как возможность для обратной связи и роста команды.

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

• Устанавливайте четкие критерии успеха. Объясняйте, что вы ожидаете и как будете оценивать результат. Это помогает команде понять задачу и снижает вероятность ошибок.

Причина 3: Страх потерять авторитет

Страх потерять авторитет в команде при делегировании – распространенное явление среди руководителей, особенно начинающих. Этот страх скрывается в нескольких факторах.

• Неверное представление о роли лидера. Многие руководители ошибочно считают, что их авторитет зависит от личного участия во всех задачах. Кажется, что если не контролировать все, то команда перестанет уважать. Это мышление возникает из-за стереотипа, что лидер должен быть героем, который решает все проблемы самостоятельно. В реальности авторитет лидера строится на умении вдохновлять, направлять и развивать команду, а не на личном участии в решении рутинных задач.

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

Что делать с этим?

• Сменить фокус с «я» на «мы». Авторитет лидера зависит не от личных достижений, а от способности создавать сильную команду. Делегируя задачи, вы показываете, что доверяете команде и инвестируете в ее рост.

• Четко объясняйте цели и формулируйте, зачем нужно делегирование: «Я доверяю тебе эту задачу, потому что знаю, что ты справишься. И это поможет тебе вырасти».

Фундамент делегирования: Доверие – к себе, к команде, к процессу

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

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

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

История Сергея: Пример мастерства делегирования

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

Был Сергей, тимлид в небольшой команде со сложным технологическим стеком. Сергей был необычным. Он не был похож ни на одного другого тимлида в соседних командах. Он не писал код, не тестировал, не проводил код-ревью и плохо понимал всю ту магию, которую делала его команда. Команда считала Сергея слабым звеном. Когда они спрашивали его: «Сергей, а что ты делаешь в нашей команде?», он отшучивался и говорил фразу: «Я делегирую, и в этом моя сила».

Сергей был мастером делегирования. Он знал, кому поручить задачу, чтобы она была сделана идеально. Когда нужно было писать сложный алгоритм, он звал Аню, которая обожала математические задачи. Когда нужно было делать дизайн, он звал Диму, который был фанатом дизайна. Он даже кофемашину в офисе делегировал Саше, который когда-то работал бариста и знал, как приготовить идеальный капучино.

Сергей никогда не лез в детали. Он говорил: «Я верю в тебя, сделай так, как считаешь нужным». И команда справлялась. Более того, они начинали делать все лучше. У руководства к Сергею тоже не было вопросов. Хотя всем было понятно, что он плохо понимает техническую часть проекта, все задачи, которые попадали в его команду, делались и делались в срок.

Однажды Сергея перевели на другой сложный, проблемный участок. Команда, которая считала, что Сергей ничего в ней не делает, осталась без тимлида, который «ничего не делает». Команда посыпалась. Задачи дублировались, сроки срывались, заказчики были недовольны. Через какое-то время они стабилизировались и выправились. Но после этого случая я больше не слышал от этой команды, что Сергей был слабым звеном. Они поняли, что Сергей был супергероем своей команды. Его задача заключалась в том, чтобы команда работала как единое целое.

Тимлид как дирижер оркестра

А теперь представьте, что тимлид – дирижер оркестра. У него в руках партитура – план проекта. Он стоит перед группой музыкантов – своей командой. Каждый музыкант – эксперт в своем деле. Дирижер не играет на всех инструментах одновременно. Его задача – координировать, вдохновлять и направлять музыкантов. Он знает, кто какой инструмент освоил лучше всего, и делегирует партии этому музыканту. Точно так же тимлид распределяет задачи внутри команды: один пишет код, другой тестирует, третий занимается документацией. Дирижер следит, чтобы музыканты играли в одном темпе, а тимлид следит, чтобы задачи выполнялись вовремя и соответствовали плану.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.