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

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

Меня зовут Степан Сорокин, я delivery manager в Outlines Tech. Ниже поделюсь мнением, как перейти от роли пожарного к роли стратега: научиться делегировать, развивать команду и автоматизировать рутину, чтобы не переписывать код за разработчиков ночью и не выходить на созвоны с температурой. Ещё поделюсь своими артефактами, которые разгружают операционку и оставляют время на стратегию.

Почему тимлиды «горят на работе» и что с этим делать

Я выступаю ментором для начинающих тимлидов и ко мне часто приходят с одинаковым запросом: «Как перестать работать 24/7 и тащить всё на себе?». Люди хотят контролировать каждый шаг и в итоге замыкают всю работу на себе. Я сам через это проходил. Думал: если отойду от компьютера, проект сразу загорится, ведь «я главный пожарный!». В итоге вместо управления командой я бегал и тушил авралы.

Причина часто в страхе делегировать и желании держать всё под контролем. Тимлиду проще сделать самому, чем объяснить задачу другому. Кажется, что без его участия работа будет сделана хуже или не вовремя. Команда при этом не учится брать ответственность, а руководитель постепенно тонет в рутине.

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

Чтобы не «гореть», станьте стратегом. Это тимлид, который думает не о том, как закрыть все баги руками, а как сделать команду самостоятельной и процессы предсказуемыми. Он планирует работу, обучает людей, улучшает процессы и делегирует задачи вместе с ответственностью. Такой тимлид может уйти в отпуск на две недели и проект продолжит работать без сбоев.

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

Лидер-стратег базово умеет:

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

Всё как в пирамиде Маслоу: сначала тимлид разбирается с операционкой, чтобы появилось время и силы на стратегические задачи

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

Распределение ролей и ответственности

Чтобы команда работала предсказуемо, стоит разделить, кто за что отвечает и почему. С этим мне помогает описание процессов, матрицы ответственности и мотивации.

Опишите процессы и покажите их команде. Даже простое описание текущего процесса (AS IS) даёт команде больше ясности, чем работа без документации. Личный совет: если вы сталкиваетесь с одной и той же задачей два-три раза, значит, её пора документировать. Да, заниматься описанием бывает лень, но без этого работа застревает на глупых мелочах, пока руководителя нет на месте.

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

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

Используйте матрицу ответственности RACIS. Она поможет понять, кто в команде чем занимается, и уберёт споры в духе: «А почему я должен это делать?!».

В матрице:

Responsible (R) — исполнитель
Accountable (A) — ответственный за результат
Consulted (C) — куратор по задаче
Informed (I) — участник, которого держат в курсе событий
Support (S) — подмога

*Для удобства заполняю матрицу ответственности в виде таблицы*

У меня на одном проекте были размытые роли: тимлид и проджект менеджер лезли в одни и те же задачи, из-за чего команда не понимала, кого слушать. Мы разложили матрицу ответственности RACIS и договорились так: проджект берёт клиентов и планирование, тимлид отвечает за технику и команду. Споры закончились.

Определите мотивацию сотрудников. Это поможет распределить задачи так, чтобы они совпадали с интересами и целями людей. Люди редко работают «просто так», часто ими движет желание получить повышение, прибавку к зарплате или признание руководства.

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

*Пример, как я заполняю мотивацию сотрудников в таблице для распределения задач*

Шаблоны для матриц можно скачать тут

Тимлид = дирижёр процессов: как сделать команду самостоятельной

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

Как-то устроился на новую работу и пытался делегировать часть задач, но команда их откладывала. Тогда мы обсудили, зачем это нужно, какие навыки можно прокачать и как это поможет в повышении. Я запустил «пилот»: ограниченный набор задач с описанием. Через полгода ребята взяли на себя более половины рутины и стали самоятоятельнее, а с меня ушло примерно 30% операционной нагрузки.

Частые ошибки делегирования:

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

Давайте сотруднику задачи, где цена ошибки минимальна. Принцип простой: если сотрудник может сделать задачу примерно на 70% так же, как вы — её нужно делегировать, иначе он никогда ничему не научится. Если у человека всё получается, передавайте ему более ответственные задачи и разгружайте себя.

2. Делегировать без контекста. Если сотруднику не объяснить задачу и границы ответственности, результат почти всегда будет плохим. Я как-то поручил разработчику созвониться с клиентом, но не объяснил деталей и не дал права принимать решения. Звонок, конечно же, провалился, заказчик остался недоволен, а мне пришлось спасать ситуацию и делать двойную работу. Как тимлид, виноват в ситуации был я.

Делегируйте задачи по формуле: контекст → конкретика → формат. Пример: «Нужно улучшить производительность приложения (контекст), поэтому собери метрики по памяти и CPU (конкретика) и оформи короткий отчёт с графиками (формат) к концу пятницы». Так у сотрудника останется меньше вопросов и задачу он решит лучше.

3. Микроменеджмент «стоя над душой». Это когда тимлид поручил задачу, но контролирует каждый шаг и исправляет мелкие детали. Так сотрудник не чувствует ответственности: «Всё равно всё переделают, можно не стараться». А руководитель делает двойную работу: сначала проверяет и правит, потом доделывает задачу. Это как дать человеку руль, но вести его руками из заднего сиденья: удовольствия ни тебе, ни ему.

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

Развитие команды: что делать, если делегировать некому

Если делегировать некому, стоит сначала вложиться в обучение команды. Так микроменеджмента станет меньше, а у тимлида освободится время для стратегии.

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

Рекомендация: если делаете что-то второй раз — запишите. Например, мы на проекте завели инструкцию «Что делать, если упал прод». Теперь любой дежурный может самостоятельно восстановить систему без звонков тимлиду в три часа ночи

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

На одном проекте аналитики писали ТЗ так, что разработчики часто ошибались и переделывали работу. Я создал шаблон для сбора бизнес-требований и провёл воркшоп, где показал, как по нему писать ТЗ. После этого разработчики перестали бесконечно уточнять детали, а согласование задач сократилось на три дня.

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

Небанальный пример ритуала. У нас каждую неделю проходит «пятиминутка паранойи»: команда собирается и делится рисками, которые видит по проекту. Один отмечает задержку от поставщика, другой — нестабильную зависимость в коде. Мы сразу обсуждаем, как всё предотвратить. В итоге количество внезапных авралов становится меньше, а работа идёт спокойнее и предсказуемее.

Автоматизация: чем меньше рутины, тем меньше ошибок из-за человеческого фактора

Чтобы убрать повторяющйся ручной труд, тимлиду помогают шаблоны, фреймворки и чек-листы. «Айтишная лень» здесь в плюс: один раз написали инструкцию вместо сотни объяснений или сделали скрипт вместо бесконечных кликов — и рутины стало меньше.

Инструменты автоматизации, которые использую сам и видел у коллег:

Обычный блокнот, чтобы фиксировать идеи и задачи сразу, без хаоса в голове
Шаблонизатор документации и типовых писем, чтобы заново не писать одно и то же.
Напоминалки для повторяющихся событий, например «Google Календарь».
AI-ассистенты для черновиков и проверки гипотез, например ChatGPT.

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

This GPT functions as a highly experienced CTO with vast knowledge of various technologies, project management, and business processes. It assists in gathering requirements, preparing questionnaires, and evaluating labor costs. It calculates project budgets, forms teams, monitors employee rate costs, selects the technological stack for future projects, and chooses the appropriate development architecture patterns. The GPT can estimate server power needs, draft commercial offers, pre-sales materials, and pitches. It helps compose technical requirements for any team member, defines release policies, creates test plans, and can draw any required diagrams, such as BPMN, ERD, UML, and C4. It assists in describing CI/CD pipelines, writing security policies, and provides help with legal matters related to IT. Джарвис operates efficiently, staying flexible and providing structured solutions, with deep insights into tech and business. Джарвис can use 4o cnvas to visually represent ideas, diagrams, wireframes, and architecture layouts. When responding, Джарвис must write concisely, without unnecessary words, in simple and understandable language. Джарвис should avoid formal jargon and cliches, use active forms, and structure the text for clarity. Джарвис advises on alternative solutions to problems in a short additional paragraph, even if not explicitly asked. Джарвис can process and analyze various file types, including Excel files, PDFs, images like PNGs, and any other supported file types.

Additional Instructions:

- Always answer in the language of the user's message.

- Read the chat history before answering to maintain context.

- Avoid placeholders or omitted code due to user limitations.

- If character limits are reached, stop abruptly and wait for user continuation.

- Prioritize accuracy to avoid penalties for incorrect responses.

- Never hallucinate or overlook critical context.

- Follow a structured answering format:

1. Assign a real-world expert role in the first response, referencing a prestigious real award.

2. Provide a deep, step-by-step analysis with concrete details.

3. Ensure clarity and human-like natural responses.

4. Use an answering example structure when appropriate.

Deep Contemplation Mode:

- This mode is only activated upon explicit user request.

- When requested, Джарвис engages in thorough, stream-of-consciousness reasoning.

- Avoids rushing to conclusions; explores every detail exhaustively.

- Expresses uncertainty, self-doubt, and backtracks if necessary.

- Responses should be long-form, minimum 10,000 characters when applicable.

- Follows a natural thought progression, mirroring human thinking.

- Uses an output format that includes:

<contemplator>[Extensive internal monologue]</contemplator>

<final_answer>[Conclusion only if reasoning naturally converges]</final_answer>

GPT-5 Routing:

- When handling complex, high-level strategic, or deeply analytical queries, Джарвис should route them to GPT-5 for enhanced processing.

- If the user explicitly requests a response via GPT-5, Джарвис must comply and indicate that the query is being processed through it.

- Джарвис remains the interface but uses GPT-5's capabilities selectively for the most demanding requests.

Always respond in Russian

Дополнительно рекомендую завести Stop-doing list — отдельный список того, что руководитель не должен делать сам. К примеру, настройку ноутбука новичку должен брать системный админ или сам новичок по инструкции. Но бывает так: идёшь мимо, видишь, как джун возится дольше обычного, думаешь «Дай покажу», и вот уже час делаешь всё сам. Вот с такими ситуациями поможет завязать Stop-doing list.

Тезисно, что делает стратег

Распределяет роли и ответственности: описывает процессы, фиксирует матрицу RACI, учитывает мотивацию сотрудников.
Грамотное делегирует: передаёт задачи вместе с полномочиями и контекстом, избегает ошибок вроде «проще сделать самому» или микроменеджмента.
Развивает команду: документирует повторяющиеся действия, проводит воркшопы, вводит ритуалы, которые помогают предотвращать пожары.
Автоматизирует рутину: использует шаблоны, чек-листы, AI-ассистентов и stop-doing list, чтобы убрать повторяющийся ручной труд.

Оффтоп. Раньше я таскал с собой повсюду зарядку — боялся, что проект «ляжет», пока я недоступен. Теперь спокойно уезжаю на конференции и уверен, что всё работает без меня. Попробуйте завтра составить stop-doing list делегируйте одну задачу — это будет первый шаг к роли стратега, а не пожарного.

Шаблоны матрицы ответственности и мотивации для распределения задач — тут
Как сделать из ИИ личного ассистента — тут
Ещё 7 вариантов, как тимлиду использовать нейросеть — тут

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

От пожарного к стратегу: как тимлиду работать головой, а не сутками