🎯 Как я перестал бояться давать развивающую обратную связь

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

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

Но это не работает.

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

Но реакция была разной.

Кто-то просто принимал обратную связь и говорил:
«Да, я и сам замечал такое».

А кто-то думал, что я жду от него совершенно другого поведения. Он менял стиль работы, считал, что делает всё правильно, но когда я снова давал развивающую обратную связь, он удивлялся:
«Я думал, ты как раз этого и хотел!»

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

И я понял: обратная связь – это не про обвинения, а про развитие. И воспринимать её нужно именно так. Если ты хочешь, чтобы команда становилась сильнее, ты не можешь замалчивать проблемные места. Люди не читают мысли, они не всегда видят свои слабые стороны. Но если ты честно и конструктивно указываешь на них – это шанс для роста.

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

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

@ctrlshiftboss

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

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

Но реальность быстро показала, что управление — это вообще другая профессия.

Код либо работает, либо нет. А с людьми так не бывает. Здесь нет чётких правил, нет линтера, который подсветит ошибку, и нет Stack Overflow, где можно найти готовый ответ. Информации вроде много, но что из неё реально работает — непонятно. Ты просто разбираешься методом проб и (больно полученных) ошибок.

Кто я?

Меня зовут Илья Царев, и я занимаюсь коммерческой разработкой больше 12 лет.
• Работал в стартапах. Делал первую в России connected car платформу Remoto, которая потом была успешно интегрирована в один из сервисов каршеринга (Делимобиль).
• Несколько лет работал в Альфа-Банке, где построил одну из сильнейших команд мобильной разработки на рынке в тот момент.
• В 2019 году присоединился к команде Яндекс Такси и помогаю создавать клиентский суперапп Яндекс Go, который хочу сделать самым удобным.
• Последние 8 лет управляю командами инженеров — от небольших групп в 10 человек в начале до больших подразделений в 250+ сотрудников сейчас.
• Иногда выступаю на конференциях (пример раз, пример два).
• Иногда пишу статьи, например, вот одна из них.

О чём этот канал?

Про реальные ошибки и выводы. Про то, что реально помогает руководителю в IT, а что — просто красивая теория.

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

@ctrlshiftboss

🔥 Что делать, если сотрудник хочет уволиться?

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

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

Есть два типа мотивации при увольнении:

1. Мотивация ОТ

Человек уходит от чего-то:
— Плохой руководитель или команда.
— Неинтересные задачи.
— Раздражающие процессы.
— Устаревшие технологии.

Здесь я задаю вопрос: «Могу ли я быстро починить ситуацию?» Если проблема решаемая, стоит ли увольняться? Иногда люди просто не видят, что решение есть.

2. Мотивация К

Человек уходит к чему-то:
— Повышение, которое давно хотел.
— Другая культура, где он чувствует себя комфортнее.
— Новый стек технологий.

Здесь вопрос другой: «Могу ли я дать это внутри компании?» Если нет — честный разговор. Если да — может, есть смысл обсудить альтернативные варианты?

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

@ctrlshiftboss

📵 «Я всегда на связи» — миф об идеальном руководителе

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

Поначалу это работает. Люди действительно чувствуют, что ты рядом, что ты «в теме». Но через какое-то время ты начинаешь замечать, что команда… перестаёт думать самостоятельно.

— Почему ты не принял решение сам?
— Я хотел сначала спросить тебя.

И вот ты уже точка, через которую проходят все вопросы. Всё начинает тормозить. И это не потому, что команда слабая — это потому, что ты стал зависимостью.

Научиться быть недоступным — тоже навык.

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

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

@ctrlshiftboss

⚙️ LLM и новая реальность инженерного труда

Я уже давно не пишу код каждый день. Последние лет пять — максимум что-то по мелочи: прототип, тулза для себя, небольшой эксперимент.

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

На днях я собрал рабочий прототип за день и пару часов между встречами. Как?
— Написал задание Cursor’у.
— Ушёл на встречу.
— Вернулся, посмотрел, что получилось.
— Подкорректировал, добавил новые вводные.
— И так по кругу.

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

И вот что интересно:
многие из тех, кто стал руководителями, делали это не потому, что хотели управлять, а потому что хотели делать больше. Но нельзя было «ускорить себя» как разработчика. Единственный способ масштабироваться — был через людей.

А теперь — появился другой путь. LLM — это не замена инженерам, это усиление. Это возможность снова масштабировать свои действия напрямую.

Как это повлияет на разработку? На команды? На руководителей?
Ответа пока нет. Но понятно одно — подход к инженерии уже меняется.

@ctrlshiftboss

🙈 Про обезьянок, задачи и как не тащить всё на себе

Помните пост, где на руководителе висело куча обезьян? Это не просто забавная картинка — это метафора из книги «Одноминутный менеджер и его обезьяны». И, честно говоря, я долго не придавал этому значения, пока не начал замечать это в своей работе.

Когда кто-то из команды приходит с вопросом или задачей, и ты говоришь:
— «Давай, я уточню»
— «Я сам поговорю с ними»
— «Окей, разберусь вечером»

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

У меня тоже так бывало. К концу дня — куча задач, но большинство из них вообще не мои. Просто неудобно было не помочь, и вот ты уже вписался.

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

Теперь я чаще спрашиваю:
— «А что ты сам планируешь с этим делать?»
— «Какие у тебя есть идеи?»

И обезьянки остаются там, где им и место.

@ctrlshiftboss

📩 Письмо из пятницы в прошлый понедельник

Привет, понедельничный я.

Ты сейчас, скорее всего, на кураже — всё расписал, собрал встречи, в голове амбиции, цели, план на неделю. Это нормально.

Но вот тебе пара напоминаний от меня — пятничного:

— Не пытайся решить всё сразу.
Некоторые вопросы просто не имеют ответа на этой неделе. И это тоже ок.

— Люди — не задачи.
Если кто-то «не так сделал», это не значит, что он плохой. Поговори, пойми, помоги.

— Делегируй раньше, чем начнёт гореть.
Ты всё равно не потушишь всё один.

— Не забывай хвалить. Особенно когда кажется, что «и так понятно».

— И ещё: пятница всё равно наступит.
Даже если в среду кажется, что неделя будет вечной.

Береги фокус. Не забывай дышать.
Всё идёт нормально.

@ctrlshiftboss

👀 Хочешь изменить команду? Начни с себя.

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

Если ты не отвечаешь на сообщения — не жди быстрой реакции от других.
Если ты перебиваешь на встречах — команда перестанет слушать друг друга.
Если ты игнорируешь проблемы — они тоже будут молчать.

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

Управление — это не только про «говорить, как надо»,
это в первую очередь про демонстрировать, как надо.

Если хочешь, чтобы команда что-то изменила —
посмотри, не пора ли сначала поменяться самому.

@ctrlshiftboss

📭 Zero Inbox . Это про уважение

Много лет назад я понял, что без правила Zero Inbox — никуда.
Оно простое: в конце дня в мессенджерах и почте не должно оставаться висящих непрочитанных сообщений.

Зачем это нужно?

Во-первых — ради фокуса.
Когда у тебя 50 непрочитанных чатов, они лежат в голове грузом. Даже если ты занят другим — мозг всё равно возвращается к ним.

Во-вторых — ради других.
Если ты не отвечаешь — кто-то стоит на паузе. Его задача, проект или решение завязано на твой ответ.
Ты этого не замечаешь, а он тормозится.

Я стараюсь отвечать всем в течение нескольких часов, даже если не могу дать финальный ответ.
Если идёт встреча за встречей — откладываю. Но вечером всегда довожу всё до Zero Inbox.

Если нет финального решения, то:
— отвечаю, что подумаю,
— пишу, когда вернусь с ответом,
— и помечаю сообщение как непрочитанное — оно остаётся у меня как туду.

Мессенджеры для меня — это не просто чат. Это ещё и инбокс задач.

Кстати, про это круто писал Рома. У него отличный канал.

Правило простое. Очевидное.
Но пока ты его не внедрил — управлять вниманием и не тормозить других почти невозможно.

@ctrlshiftboss

🦸‍♂️ Роль, которую невозможно снять

На выходных мы проводили ежегодную конференцию Яндекс Dev Day&Night.
Между докладами я разговорился с коллегой Лешей. Он напомнил, как пару лет назад я выступал и говорил, что руководитель остаётся руководителем даже в баре.

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

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

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

Это не значит, что нужно ходить с серьёзным лицом и ни с кем не пить пиво. Веселиться можно. И нужно. Но при этом важно помнить: твои слова, реакции и поведение по‑прежнему влияют на команду.

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

— Пошутил неудачно? Кто-то замкнётся.
— Промолчал, когда кто-то грубо высказался? Остальные решат, что это норма.
— Ушёл в телефон, когда тебе рассказывают о проблеме? Значит, это никому не важно.

Ты не просто один из. Ты — ориентир. Даже вне офиса, даже вне рабочего контекста.

Это не про пафос. Это про ответственность. Осознанную и не навязанную извне.

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

@ctrlshiftboss

🔕 Тишина в чате

Праздники в разгаре. Кто-то работает, кто-то отдыхает, но активность в чатах заметно снижается.

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

Когда нет постоянного потока сообщений и встреч, проще взглянуть на процессы со стороны.

— Как чувствует себя команда?
— Что требует внимания, но обычно остаётся на втором плане?
— Где можно упростить, убрать лишнее, пересобрать?

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

Используйте эту паузу с пользой. Она не выпадет из календаря — но может многое изменить.

@ctrlshiftboss

🔧 Микроменеджмент — не зло. Это инструмент

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

Но со временем понял: микроменеджмент — это не признак слабости, а управленческий инструмент. И иногда он необходим.

Представьте, у вас ломается машина. Вы отвозите её в автосервис.
Вам говорят: «Починим за 20 тысяч и два дня».
Через четыре дня вам выставляют счёт на 40, машина вроде работает, вы отъезжаете на три километра — и она снова ломается.

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

С командами то же самое.
Если что-то системно идёт не так — погрузиться в детали и начать управлять плотнее — это ваша работа.

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

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

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

@ctrlshiftboss

⚙️ Всё на процессах? Или всё на людях?
Часть 1 — когда команда строится на процессах

В какой-то момент каждый руководитель сталкивается с этим выбором — делать ставку на процессы или на людей.

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

И то, и другое работает — но по-разному.

В этой мини-серии разберём оба подхода: когда они полезны, чем опасны и как найти баланс.

⸻⸻⸻

Начнём с процесса.

Есть команды и целые компании, в которых всё держится на чётких процессах.
Задачи подробно описаны, роли формализованы, каждый шаг зафиксирован в Notion или Confluence. Человека можно поменять — система останется.

Плюсы такого подхода:
• высокая предсказуемость и управляемость
• новым людям проще влиться
• масштабируемость — процессы можно копировать
• снижается риск, что что-то завязано на одного

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

Процессы — это хорошо. Но они не решают проблемы — это делают люди.

Если построить всё только на процессах, система может казаться надёжной, но окажется хрупкой при первом сбое.

В следующем посте разберём обратную крайность — когда всё держится на людях.

@ctrlshiftboss

🧠 Всё на процессах? Или всё на людях?
Часть 2 — когда команда держится на людях (начало тут)

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

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

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

Но есть и минусы:
• система нестабильна — если кто-то уходит, многое рушится
• новичкам тяжело влиться — слишком много негласного
• многое держится на устных договорённостях и личных отношениях
• в условиях роста такой подход плохо масштабируется

Это работает — но только до определённого размера и при очень высоком уровне команды.

Подход «всё на людях» хорош для стартапов, кросс-функциональных групп, RnD-команд. Но в долгую — он требует поддержки структурой.

Рано или поздно команда вырастает. Уходят ключевые люди. Приходит неопытный новичок. И тут выясняется, что «всё и так понятно» — только для старожилов.

⸻

Истина — как обычно — где-то между. И в следующем посте попробуем поговорить о балансе.

@ctrlshiftboss

Технотекст‑7: неожиданная победа 🏆

Отправил свою статью на конкурс Хабра просто чтобы попробовать. Подумал: а вдруг?
В итоге — из ~800 публикаций — жюри выбрало мой текст победителем в номинации.

Вот она, та самая статья:
Может ли мобильный-разработчик стать CTO?

Спасибо всем, кто читал, вдохновлял и предлагал правки — без вас такого финала бы не было.

@ctrlshiftboss