Вы отдали задачу инженеру, а через три дня она снова у вас: то с ворохом вопросов, то сделана наполовину, то с честным «я не был уверен и решил дождаться тебя». Делегировали ведь по‑настоящему, не сами сели делать, — почему вернулось?

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

На чём оно ломается

  • Самая частая поломка — отдать задачу, но оставить себе все решения.

    Человек берётся, упирается в первую же развилку (какую библиотеку взять, ломать ли обратную совместимость, где компромисс по срокам) и идёт спрашивать, потому что решать не уполномочен. Формально задача у него, фактически вы по‑прежнему её ведёте, просто его руками. Лечится это тем, что вместе с задачей вы отдаёте и право принимать решения, и его границы: вот в этих рамках решай сам, а если упрёшься во что‑то за их пределами — тогда приходи.

  • Вторая поломка — непонятно, что считать готовым.

    «Сделай интеграцию с платёжкой» без критерия готовности толкает человека в одну из двух крайностей: либо он принесёт голый счастливый путь без обработки ошибок, либо месяц будет вылизывать то, что никому пока не нужно. Договоритесь заранее, что на выходе: какой результат, к какому сроку и какого качества достаточно на этом шаге. Тогда у него есть с чем сверяться, а у вас — основание сказать «готово» или «ещё нет» не по ощущению, а по уговору.

  • Третья — нет точки сверки.

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

  • Четвёртая поломка маскируется под делегирование, а на деле это сброс.

    Кинуть задачу одной строкой без контекста — «разберись с этим тикетом» — не то же самое, что делегировать. Без понимания, зачем это нужно и как связано с остальным, человек не сможет принимать те самые решения, которые вы вроде бы ему отдали, и будет либо угадывать, либо возвращаться с вопросами. Передавайте вместе с задачей её смысл: какую проблему закрываем и почему именно сейчас.

  • И пятая — обратное делегирование, когда задача переезжает обратно к вам незаметно для обоих.

Выглядит это так:

— Слушай, я застрял на той интеграции, не пойму, почему вебхук иногда не доходит. Глянешь?

— Давай я посмотрю вечером.

Всё, задача снова ваша: вечером смотрите вы, а инженер ушёл ждать. Он принёс чистую проблему, вы её приняли. Чтобы так не случалось, проблему он приносит уже с вариантами, и разговор идёт иначе:

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

— Логично. С чего начнёшь проверять?

— Сначала гляну логи на дубли, добавлю идемпотентность.

— Давай. Если за день не прояснится — приходи, разберём вместе.

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

Сколько свободы отдавать

Делегирование часто воспринимают как переключатель — либо «делай как я сказал», либо «делай что хочешь», — и из‑за этого половина конфликтов. На самом деле это спектр, и полезно держать в голове несколько ступеней: решаю сам и говорю как сделать; решаю сам, но объясняю почему; спрашиваю твоё мнение, но решаю сам; решаем вместе; решай сам и держи меня в курсе; решай сам и можешь не отчитываться. В Management 3.0 этот спектр оформлен как семь уровней делегирования, где команда вслух проговаривает, кто на каком уровне по каждому типу решений.

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

И уровень не выдаётся навсегда. По мере того как человек набирает опыт в задаче, вы сдвигаете его вверх по спектру: то, что вчера согласовывали вместе, сегодня он решает сам и просто упоминает на синке.

Как отдавать, чтобы не возвращалось

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

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

Здесь стоит сказать про главный тормоз — соблазн сделать самому. Почти всегда отдать задачу медленнее и больнее, чем сделать её своими руками: объяснить, подождать, поправить результат, который вышел хуже вашего. На короткой дистанции это правда, и поэтому лиды так часто скатываются обратно в роль самого продуктивного инженера.

Больше об управлении читайте в материалах:

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

  • 16 июня, 20:00. «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться

  • 23 июня, 20:00. «Как тимлиду победить синдром самозванца». Записаться

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