Когда команда работает удалённо, одна из ключевых задач менеджера - не требовать от людей мгновенных ответов на каждое сообщение.
Удалённый формат подразумевает, что сотрудник на связи. Но "на связи" - это не про реакцию в течение пары минут в чате. Это про другое: ты ставишь задачу и понимаешь, что она будет выполнена в срок. Назначаешь встречу - и человек на ней присутствует. Просишь что-то сделать - и это делается вовремя.
Доступность - это про надёжность и предсказуемость, а не про скорость ответа в мессенджере.
Некоторые руководители начинают нервничать, если сообщение висит непрочитанным несколько минут. В голове сразу появляются тревожные сценарии: чем вообще сейчас занимается команда? Не отвлеклись ли куда-то не туда?
В офлайне всё проще: если сотрудника нет на месте, понятно - отошёл на обед, за кофе, на звонок. А в удалёнке возникает ощущение потери контроля, будто работа начинает расползаться.
Важно принять простую вещь: мгновенной реакции не будет. И это нормально.
Тогда возникает вопрос - как контролировать работу? Ответ неочевидный: напрямую - никак. Работа - это не место, куда приходят, а результат, который получают. Вот результат и стоит отслеживать. А людей лишний раз дёргать не нужно.
Выстроить работу команды на удалёнке - правильная цель. Но начинается она не с команды, а с самого менеджера: с его подхода, ожиданий и умения доверять.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤4❤🔥3🔥3
Please open Telegram to view this post
VIEW IN TELEGRAM
😁9🔥3❤1🤯1
Управление проектами - это не всегда про сертификаты PMBoK. Иногда самые сильные уроки нам оставляет история, где проекты реализовывались в условиях жестких ограничений и высочайшей ставки. Пример советской системы ПВО "Беркут" показывает, что фундаментальные принципы инициации проекта работают вне зависимости от эпохи.
Постановление Совмина 1950 года содержало четкую бизнес-потребность (угроза ядерного удара), формулировало SMART-цели, определяло границы и стейкхолдеров. По сути, это был идеальный устав проекта, который запустил сложнейший наукоемкий процесс.
Но главное отличие этого исторического кейса от современных реалий - в подходе к мотивации. В документе отсутствовал раздел "анализ рисков" (вариант не сделать - даже не рассматривался), зато был прописан мощнейший блок финансового стимулирования. Размер премий для руководителей и исполнителей составлял около 1000 средних окладов, что в пересчете на сегодняшние реалии исчисляется десятками и сотнями миллионов рублей.
Предлагаем обратить на это внимание: при инициации сложных проектов стоит возвращать практику однозначной и кратной мотивации ключевых участников, а не пропускать этот раздел.
Результат такого подхода говорит сам за себя. Проект колоссальной сложности - создание системы радиолокации и противоракет, был выполнен менее чем за три года. Это позволило нейтрализовать критическую угрозу и изменить ход истории.
Современным проектным менеджерам стоит задуматься: возможно, проблема не в сложности методологий, а в том, что мы упускаем из виду фундаментальные вещи - четкое понимание неизбежности результата и адекватную оценку вклада команды.
LinkedIn: Илья Соломадин, Старший руководитель проектов - T8 Infinite Technologies
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍3🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁11❤2🔥2
Сегодняшний рынок разработки парадоксален: кандидатов много, но инженеров, способных довести задачу до работающего результата, по-прежнему мало. В эпоху AI, где код генерируется легко, главная ценность разработчика сместилась из плоскости технических знаний в плоскость ответственности. Два простых вопроса на собеседовании помогают выявить эту ценность быстрее, чем сложные технические интервью.
Первый вопрос - "Кто отвечает за задачу?". Ответ "Я" раскрывает владельца результата, который не останавливается на коммите, а доводит задачу до пользователя, уточняет требования и думает о работе системы после релиза. Если же кандидат начинает делить ответственность по ролям ("я за код, QA - за тесты"), это сигнал, что реальная ценность такого сотрудника ниже - ему нужен постоянный организационный контроль.
Для тимлида этот вопрос трансформируется: важно не то, возьмет ли он задачу на себя, а умеет ли он строить систему, где ответственность распределена внутри команды, не превращая лидера в узкое место.
Второй вопрос - "Пишете ли вы unit-тесты?". Это демонстрирует зрелость. Разработчик, который пишет тесты, демонстрирует иное отношение к качеству: он проектирует код так, чтобы его можно было тестировать (модульность, слабая связность), не боится рефакторинга и думает о долгосрочной жизни системы.
Для тимлида этот вопрос проверяет не количество тестов, а понимание архитектурных рисков и способность оценивать техническую реальность, а не только управлять процессами.
Эти вопросы работают, потому что они проверяют не знание синтаксиса, а отношение к ответственности и качеству - качества, которые меняются медленнее технологий. Если вы ищете сильного инженера, ищите того, кто берет ответственность за результат и понимает, как код живет в продакшене.
Если вы сами разработчик - смещайте фокус резюме с технологий на решенные бизнес-задачи, учитесь писать тесты и будьте готовы подтвердить свою роль владельца результата реальными историями.
LinkedIn: Виктор Демин, Tech Adviser & CTO - Self-employed
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2❤1
Please open Telegram to view this post
VIEW IN TELEGRAM
💯9😁5❤3
Please open Telegram to view this post
VIEW IN TELEGRAM
😁19💯4❤3
Возьмём любой стартап, небольшую компанию или даже отдельный проект внутри крупной организации. Чем живёт команда? В первую очередь - эмоциями.
Энтузиазм зашкаливает. Радость от того, что создаётся что-то новое. Затем приходят разочарования из-за неудач, раздражение из-за проблем, сожаление о том, что не получилось. Потом - всплеск: "Взлетело! Пошли деньги!". И снова качели: злость, тревога, паника. Затем очередной подъём - достигли цели, впереди новая вершина. Постоянные эмоциональные всплески. Команда не горит - она пылает.
Но где здесь место для спокойствия? Где рутина, где скука? Её почти нет. Потому что скука появляется тогда, когда исчезает неопределённость. Когда ты уже не бродишь вслепую по рынку, не метаешься в поисках модели, а понимаешь, что именно нужно делать - и просто делаешь это.
Скука приходит в тот момент, когда начинается системная работа: улучшение процессов, прокачка навыков, настройка инструментов, развитие людей. Это уже не про хаос и не про героизм, а про методичное движение вперёд - шаг за шагом, без лишней спешки.
Хаос всегда яркий и эмоциональный. А там, где появляется порядок, возникают процессы - вместе с ними приходит и скука. Потому что системность вытесняет постоянные всплески. Исчезают неожиданные провалы, авралы и нервное напряжение. Появляется предсказуемость и повторяемость. И вот это - нормальная рабочая скука.
Эмоции, конечно, нужны. Без них нельзя. Но они должны быть дозированными, а не задавать ритм всей работе. Управлять этим ритмом должен ты сам.
Стало слишком спокойно - можно добавить немного драйва: запустить новый проект, попробовать рискованную гипотезу, поставить команде сложную задачу, взять непростого клиента. Но важно не перегнуть. Основа всё равно должна оставаться стабильной.
Потому что скука в работе - это признак того, что всё работает как надо.
Да, подниматься по лестнице может быть не слишком увлекательно. Зато это куда надёжнее, чем с эмоциями лететь вниз.
Иногда лучшая цель для команды - это чуть больше скуки в работе.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2🔥2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁18❤2🔥2
Переход из технического специалиста в техлида - это не просто смена должности, а полная перестройка мышления. Главная ловушка, в которую попадает большинство, - это микроменеджмент и попытка удержать контроль над всеми задачами.
Бывает страшно отпустить, но только доверив команде и перестав оценивать задачи через призму своего опыта, можно выиграть время для действительно важных вещей. Планинг покер с участием лидера часто искажает оценки: авторитет давит, а команда теряет право на собственное погружение в задачу.
Синдром самозванца в новой роли неизбежен, особенно когда случаются факапы. Спасает здесь не волшебная таблетка, а смена фокуса: если рассматривать провалы не как личную трагедию, а как системную задачу или вызов, от паники не остается и следа. Важно помнить, что ответственность за результат не равна личной ответственности за написание всего кода. Перестав грести всё на себя и начав поднимать экспертизу команды, можно найти решения, которые раньше были недоступны.
Люди - не роботы, и любой процесс, будь то код-ревью или работа с приоритетами, требует постоянного возврата к договоренностям. Если правило не зафиксировано в доступном месте и о нем не напоминают раз в неделю, оно перестает работать. Управление командой - это постоянные эксперименты: фича-лиды по желанию, ответственные за модули, утренние напоминания о фокусе.
Только через пробы, ошибки и регулярное обсуждение того, что зашло, а что нет, можно найти подход к разным людям.
Конструктивный конфликт - это не скандал, а инструмент. В момент недопонимания главное - выяснить мотивацию сотрудника и предложить варианты, которые приведут к win-win. А самое главное открытие на этом пути - перестать стыдиться того, что день прошел в созвонах, а не в написании кода.
Польза техлида измеряется не его собственными коммитами, а тем, насколько быстро и эффективно команда решает задачи без его прямого участия.
LinkedIn: Виктор Чижеков, TechLead - CDEK
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁8🔥4❤1
Годовое ревью - это не формальный отчет о проделанной работе и не повод просто похвалить за хорошую работу. Это стратегический инструмент, который позволяет найти точку пересечения между амбициями сотрудника и целями бизнеса.
Главная ценность встречи - выявить узкие места до того, как человек выгорит или уйдет к конкурентам. Даже если сотрудник не жалуется, это не значит, что его всё устраивает: возможно, ему не хватает прозрачности, поддержки или амбициозных задач.
Чтобы ревью принесло пользу, важно выйти за рамки оценки "хорошо/плохо". Если сотрудник показывает низкие результаты, это не всегда повод для замены: часто так обнаруживаются слабые места в процессах, скорректировав которые, вы укрепляете команду без затрат на найм. Если же сотрудник успешен, ваша задача - не ограничиваться общей похвалой, а зафиксировать, что именно получилось лучше всего и наметить шаги для дальнейшего роста.
Избегайте типичных ошибок: формального подхода ("всё хорошо"), ухода в операционку (обсуждение текучки вместо годовой динамики) и переходов на личности. Говорите на языке фактов, цифр и конкретных действий. Если сотрудник не согласен с обратной связью, важно опираться на заранее оговоренные критерии и снять страх последствий, объяснив, что цель встречи - скорректировать ситуацию, а не наказать.
Главный результат ревью - это не заполненный опросник, а четкий план действий на следующий период с конкретными шагами и сроками. Для этого нужно заранее готовить базу: собирать самооценку сотрудника, обратную связь от коллег и метрики. Чтобы разговор был честным, а не формальным, культуру обратной связи нужно выстраивать системно - встречаться чаще одного раза в год, формировать чувство безопасности и обязательно предлагать решения на основе услышанных проблем.
LinkedIn: Анастасия Лиходиевская, L&D Program Developer - Garage Eight
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁8🔥3❤1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁13🔥2❤1
Гибкость, умение перестраиваться и подстраиваться под новые условия - это основа. Любой хороший менеджер это понимает. Но вот насколько это тяжело и местами пугающе - осознают далеко не все. А тут ещё и ИИ добавляет напряжения.
Когда долго работаешь в привычной среде, с понятными задачами и инструментами, возникает ощущение стабильности. Всё отлажено, методы проверены, процессы понятны. И вдруг то, что казалось надёжным, перестаёт работать. Первая реакция - сделать вид, что ничего не происходит, и продолжать как раньше. Но именно в этот момент теряется время. А те, кто быстрее адаптируется, уже вырываются вперёд.
Допустим, ты управлял проектами в госкорпорации: строгие планы, минимум изменений, жёсткая архитектура, роли закреплены, любое решение проходит через длинную цепочку согласований. А потом оказываешься в коммерческой среде: релизы каждую неделю, постоянные эксперименты, распределённая команда в разных часовых поясах. Возникает ощущение, что всё разваливается, и ты не справляешься.
Но у тебя остаётся важное - базовые управленческие навыки. Ты умеешь видеть структуру там, где другим кажется хаос. Можешь разобраться в требованиях, разложить их на конкретные задачи, выстроить работу и вовлечь людей, даже если они не горят проектом.
В продуктовой работе - похожая картина. Да, сегодня ИИ способен за секунды генерировать десятки идей. Но именно человек решает, какие из них имеют смысл, а какие приведут к потере ресурсов. Не ИИ, а ты говоришь команде: "Это не будет работать, давайте думать дальше"
В аналитике ситуация такая же. Не так важно, в каком инструменте строятся отчёты. Гораздо важнее - подход. Хватает ли тебе терпения разбираться в данных, когда цифры не сходятся. Есть ли привычка последовательно проверять гипотезы, искать отклонения и докапываться до причин, даже если проще закрыть задачу и забыть. Умеешь ли видеть причинно-следственные связи и принимать здравые решения.
Инструменты могут устареть. Мир может измениться, AI заберёт часть работы. Но остаются фундаментальные навыки - то, что формировалось годами и отличает профессионала от тех, кто просто пользуется новыми технологиями.
Правила игры меняются, но ты по-прежнему в ней.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥3👍2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁14🔥3❤2
Менторинг - это инструмент, который начинает работать там, где курсы и чек-листы бессильны: на этапе, когда вы уже принимаете решения в условиях неопределенности, а цена ошибки становится слишком высокой. Это не про советы и готовые ответы, и уж точно не терапия. Это профессиональная рефлексия, которая позволяет увидеть со стороны собственные паттерны, границы ответственности и точки выбора.
Для опытного руководителя менторинг становится редким местом, где можно получить честную обратную связь без политики и ролей, когда привычная обратная связь исчезает, а уровень ответственности уже не предполагает постоянных комментариев.
На практике это не формализованный процесс с анкетами, а работа с конкретными ситуациями. Вместо абстрактного "как стать лучше" разбираются реальные конфликты со стейкхолдерами, невозможность делегировать или ощущение, что ты не управляешь, а реагируешь.
Ментор не дает рецептов, но с помощью честных вопросов помогает распаковать автоматизмы: почему решение было принято именно так, какие альтернативы игнорировались, какие последствия мы не замечаем. Результат выглядит не как резкий карьерный скачок, а как постепенные сдвиги - выстроенные границы, ясность в приоритетах и способность выдерживать неопределенность.
Особенно интересно, что менторинг полезен обеим сторонам. Для самого ментора это способ структурировать собственный опыт, распаковать управленческий автоматизм и не застыть в истории "я всё знаю". Простые и неудобные вопросы менти работают как зеркало, не давая застрять в собственных паттернах.
В итоге это возвращает ощущение смысла и энергии - влияние не только через KPI, но и через развитие других людей. Взросление в профессии начинается с момента, когда тебе уже не важно, кто прав, а гораздо важнее понимать, почему ты выбираешь именно этот путь.
LinkedIn: Наталья Пеккер, CPO - Альфа-Банк
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3❤2👍2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁8🔥5❤3👀2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁9❤2👍1💯1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁10💯4❤3
Please open Telegram to view this post
VIEW IN TELEGRAM
😁5❤4🔥3