🚀 Лидерство – это не титул, а твои действия
Когда-то давно я был обычным разработчиком в команде без формального лидера. Мы искали тимлида, но подходящего кандидата всё не находилось. Начальник у нас был, но он курировал сразу несколько направлений и в операционку не погружался. Команда варилась сама по себе.
В какой-то момент я задал себе вопрос: А почему лидом не могу быть я?
Я пришёл к начальнику и сказал, что хочу взять на себя эту роль. Он посмотрел на меня и ответил:
“Хочешь? Действуй. Если через 6 месяцев команда сама начнёт тебя воспринимать как лидера и ты реально улучшишь процесс разработки – тогда и поговорим.”
И вот я остался без титула, без формальной власти, но с пониманием, что мне нужно что-то менять.
📌 Я начал помогать команде не только с кодом, но и с процессами.
📌 Брал на себя самые сложные коммуникации.
📌 Решал проблемы, на которые никто не хотел тратить время.
📌 Вовлекал людей, искал решения, двигал нас вперёд.
Поначалу было сложно: у меня не было права “приказывать”, я не мог просто сказать “делаем так”. Но со временем я понял, что лидерство – это не про должность, а про то, насколько ты полезен команде.
Через 6 месяцев мой начальник сдержал слово, и меня официально назначили тимлидом. Но к тому моменту это уже мало что изменило – команда давно воспринимала меня таковым.
Этот урок я использовал снова и снова, и именно он помог мне расти дальше.
Лидерство – это не должность. Это стиль мышления и действий. Если хочешь стать лидером – начни им быть, а не жди назначения.
Когда-то давно я был обычным разработчиком в команде без формального лидера. Мы искали тимлида, но подходящего кандидата всё не находилось. Начальник у нас был, но он курировал сразу несколько направлений и в операционку не погружался. Команда варилась сама по себе.
В какой-то момент я задал себе вопрос: А почему лидом не могу быть я?
Я пришёл к начальнику и сказал, что хочу взять на себя эту роль. Он посмотрел на меня и ответил:
“Хочешь? Действуй. Если через 6 месяцев команда сама начнёт тебя воспринимать как лидера и ты реально улучшишь процесс разработки – тогда и поговорим.”
И вот я остался без титула, без формальной власти, но с пониманием, что мне нужно что-то менять.
📌 Я начал помогать команде не только с кодом, но и с процессами.
📌 Брал на себя самые сложные коммуникации.
📌 Решал проблемы, на которые никто не хотел тратить время.
📌 Вовлекал людей, искал решения, двигал нас вперёд.
Поначалу было сложно: у меня не было права “приказывать”, я не мог просто сказать “делаем так”. Но со временем я понял, что лидерство – это не про должность, а про то, насколько ты полезен команде.
Через 6 месяцев мой начальник сдержал слово, и меня официально назначили тимлидом. Но к тому моменту это уже мало что изменило – команда давно воспринимала меня таковым.
Этот урок я использовал снова и снова, и именно он помог мне расти дальше.
Лидерство – это не должность. Это стиль мышления и действий. Если хочешь стать лидером – начни им быть, а не жди назначения.
🔥2
🏗️ Управление командой — это не строительство дома, а садоводство
Когда я только начинал руководить, я представлял себе команду как дом:
• Нужно заложить прочный фундамент (процессы),
• Возвести стены (правила),
• Добавить крышу (структуру и иерархию).
Всё казалось логичным: чёткий план, прогнозируемый результат. Если всё правильно построить, то команда будет работать как часы, верно?
Нет.
Оказалось, что люди – не кирпичи. Они не укладываются в строгие схемы, не всегда ведут себя предсказуемо и уж точно не любят, когда их просто «встраивают» в систему.
И тогда я понял, что управление командой – это не строительство дома. Это садоводство.
• Ты не можешь заставить дерево расти быстрее, но можешь создать для него условия.
• У каждой культуры свой ритм: кто-то развивается мгновенно, а кому-то нужно время.
• Иногда приходится обрезать сухие ветви (даже если жалко).
• Иногда погода играет против тебя – и всё идёт не по плану.
Хороший садовод не «контролирует» каждую травинку – он наблюдает, экспериментирует и помогает всему цвести естественным образом.
Так же и с командой: твоя задача – не выстроить идеальную систему, а создать среду, где люди могут расти. И тогда они сами дадут результат, о котором ты даже не мечтал.
Когда я только начинал руководить, я представлял себе команду как дом:
• Нужно заложить прочный фундамент (процессы),
• Возвести стены (правила),
• Добавить крышу (структуру и иерархию).
Всё казалось логичным: чёткий план, прогнозируемый результат. Если всё правильно построить, то команда будет работать как часы, верно?
Нет.
Оказалось, что люди – не кирпичи. Они не укладываются в строгие схемы, не всегда ведут себя предсказуемо и уж точно не любят, когда их просто «встраивают» в систему.
И тогда я понял, что управление командой – это не строительство дома. Это садоводство.
• Ты не можешь заставить дерево расти быстрее, но можешь создать для него условия.
• У каждой культуры свой ритм: кто-то развивается мгновенно, а кому-то нужно время.
• Иногда приходится обрезать сухие ветви (даже если жалко).
• Иногда погода играет против тебя – и всё идёт не по плану.
Хороший садовод не «контролирует» каждую травинку – он наблюдает, экспериментирует и помогает всему цвести естественным образом.
Так же и с командой: твоя задача – не выстроить идеальную систему, а создать среду, где люди могут расти. И тогда они сами дадут результат, о котором ты даже не мечтал.
👍2🔥1
🚀 Найм – это не только про скиллы, а про людей, которые двигают команду вперёд
Можно набрать самых умных разработчиков, но если они работают без интереса, без вовлечённости, без желания разбираться в продукте – команда не взлетит.
Представьте себе экипаж корабля. У всех крутые навыки: один отлично управляет парусами, другой знает все звёзды, третий – мастер ремонта. Но если они не понимают, куда и зачем плывут, они будут просто механически выполнять задачи. Как только появится первая буря или изменится маршрут – всё развалится.
Настоящая сила команды – в людях, которым важно то, что они делают. Они не просто кодят, а понимают, почему это нужно. Они не ждут указаний, а предлагают решения. Они не только работают в команде – они её создают.
Как их найти?
🔥 Смотрите не только на навыки, но и на интерес. Человек, который хочет разобраться в вашем продукте и понимает его ценность, быстрее адаптируется и принесёт больше пользы, чем эксперт без мотивации.
🔥 Продавайте не только работу, но и идею. Почему именно ваш проект важен? Почему именно у вас интересно работать? Люди выбирают не только условия – они выбирают смысл.
🔥 Создавайте среду, в которую хочется попасть. Крутые специалисты идут туда, где уже есть сильная команда, интересные задачи и пространство для роста.
Найм – это не просто подбор по стеку. Это поиск тех, кто усилит команду не только скиллами, но и отношением к работе. Только с такими людьми можно строить что-то великое.
Можно набрать самых умных разработчиков, но если они работают без интереса, без вовлечённости, без желания разбираться в продукте – команда не взлетит.
Представьте себе экипаж корабля. У всех крутые навыки: один отлично управляет парусами, другой знает все звёзды, третий – мастер ремонта. Но если они не понимают, куда и зачем плывут, они будут просто механически выполнять задачи. Как только появится первая буря или изменится маршрут – всё развалится.
Настоящая сила команды – в людях, которым важно то, что они делают. Они не просто кодят, а понимают, почему это нужно. Они не ждут указаний, а предлагают решения. Они не только работают в команде – они её создают.
Как их найти?
🔥 Смотрите не только на навыки, но и на интерес. Человек, который хочет разобраться в вашем продукте и понимает его ценность, быстрее адаптируется и принесёт больше пользы, чем эксперт без мотивации.
🔥 Продавайте не только работу, но и идею. Почему именно ваш проект важен? Почему именно у вас интересно работать? Люди выбирают не только условия – они выбирают смысл.
🔥 Создавайте среду, в которую хочется попасть. Крутые специалисты идут туда, где уже есть сильная команда, интересные задачи и пространство для роста.
Найм – это не просто подбор по стеку. Это поиск тех, кто усилит команду не только скиллами, но и отношением к работе. Только с такими людьми можно строить что-то великое.
💯1
Как не превратиться в бюрократа и не потерять связь с реальностью
Чем выше ты поднимаешься, тем больше времени уходит на согласования, отчёты, обсуждения процессов. И вот в какой-то момент ты понимаешь, что больше не создаёшь ценность — ты просто координируешь чужую работу.
Ты всё реже участвуешь в реальных обсуждениях с командой, а больше решаешь административные вопросы. Ты уверен, что всё идёт нормально, но по-настоящему не понимаешь, как команда работает изнутри.
Как этого избежать?
1️⃣ Осознанно выделяй время на работу с реальными задачами
Календарь забит встречами? Запланируй слоты, где ты не в созвонах, а разбираешь реальные проблемы. Проводи время с командой, а не только с другими руководителями.
2️⃣ Спрашивай не «Как дела?», а «Что можно улучшить?»
Вместо контроля статусов – фокус на реальных вызовах. Общайся с разработчиками, дизайнерами, аналитиками напрямую, а не только с их лидами. Понимай реальные сложности, а не агрегированные отчёты.
3️⃣ Инициируй изменения, а не просто управляй текущим процессом
Если ты не думаешь о том, как сделать свою команду лучше – ты просто обслуживаешь существующую систему. Где у команды узкие места? Как вывести её на новый уровень? Какие новые инициативы помогут вам стать сильнее?
4️⃣ Режь ненужные процессы
Если что-то существует “потому что так принято”, спроси себя – реально ли это помогает команде, или это просто ещё одна бюрократическая нагрузка? Убирай лишние слои согласований и лишние точки контроля.
5️⃣ Ставь амбициозные цели, которые двигают команду вперёд
Хороший руководитель не просто контролирует, а даёт направление. Где ваша команда должна быть через полгода? Какие проекты позволят ей расти? Если ты сам не ставишь перед собой и командой таких целей, вы просто будете поддерживать статус-кво.
Бюрократия – это ловушка, в которую попадают многие. Если не хочешь оказаться в ней, держи фокус на реальных делах, а не на процессах ради процессов.
Чем выше ты поднимаешься, тем больше времени уходит на согласования, отчёты, обсуждения процессов. И вот в какой-то момент ты понимаешь, что больше не создаёшь ценность — ты просто координируешь чужую работу.
Ты всё реже участвуешь в реальных обсуждениях с командой, а больше решаешь административные вопросы. Ты уверен, что всё идёт нормально, но по-настоящему не понимаешь, как команда работает изнутри.
Как этого избежать?
1️⃣ Осознанно выделяй время на работу с реальными задачами
Календарь забит встречами? Запланируй слоты, где ты не в созвонах, а разбираешь реальные проблемы. Проводи время с командой, а не только с другими руководителями.
2️⃣ Спрашивай не «Как дела?», а «Что можно улучшить?»
Вместо контроля статусов – фокус на реальных вызовах. Общайся с разработчиками, дизайнерами, аналитиками напрямую, а не только с их лидами. Понимай реальные сложности, а не агрегированные отчёты.
3️⃣ Инициируй изменения, а не просто управляй текущим процессом
Если ты не думаешь о том, как сделать свою команду лучше – ты просто обслуживаешь существующую систему. Где у команды узкие места? Как вывести её на новый уровень? Какие новые инициативы помогут вам стать сильнее?
4️⃣ Режь ненужные процессы
Если что-то существует “потому что так принято”, спроси себя – реально ли это помогает команде, или это просто ещё одна бюрократическая нагрузка? Убирай лишние слои согласований и лишние точки контроля.
5️⃣ Ставь амбициозные цели, которые двигают команду вперёд
Хороший руководитель не просто контролирует, а даёт направление. Где ваша команда должна быть через полгода? Какие проекты позволят ей расти? Если ты сам не ставишь перед собой и командой таких целей, вы просто будете поддерживать статус-кво.
Бюрократия – это ловушка, в которую попадают многие. Если не хочешь оказаться в ней, держи фокус на реальных делах, а не на процессах ради процессов.
👍1
⚡ Почему отсутствие конфликтов в команде – тревожный сигнал
Многие руководители гордятся тем, что у них “здоровая атмосфера” и нет конфликтов. Кажется, что всё идеально: люди не спорят, не выясняют отношения, работа идёт спокойно.
Но если в команде никогда не бывает споров, значит, есть проблема.
Отсутствие конфликтов – это не всегда про взаимопонимание. Чаще это значит, что люди просто избегают сложных тем. Они не спорят не потому, что согласны, а потому что боятся высказываться, не хотят брать на себя ответственность или просто не верят, что их мнение что-то изменит.
Как отличить здоровую команду от пассивного соглашательства?
1️⃣ Люди задают неудобные вопросы?
Если обсуждения сводятся только к «окей, сделаем», это плохо. В сильных командах люди уточняют, сомневаются, предлагают альтернативы.
2️⃣ Решения принимаются быстро, но некачественно?
Если все всегда соглашаются без обсуждений, решения могут быть поверхностными. Споры помогают находить слабые места.
3️⃣ Есть культура открытого обсуждения?
В здоровой команде люди могут оспаривать даже мнения руководителя. В токсичной – все соглашаются с боссом, даже если понимают, что он не прав.
4️⃣ Как команда реагирует на критику?
Конструктивная критика – это нормально. Если все избегают любых конфликтных тем, значит, проблемы просто заметаются под ковёр.
Что делать?
🚀 Создавай культуру споров – показывай, что несогласие и обсуждения не только допустимы, но и полезны.
🚀 Сам оспаривай идеи – пусть люди видят, что здоровая дискуссия не наказуема.
🚀 Учись управлять конфликтами – цель не в том, чтобы их не было, а в том, чтобы они приводили к лучшим решениям.
Настоящая сильная команда – это не там, где тишина. Это там, где люди спорят, но не ради спора, а ради лучшего результата.
Многие руководители гордятся тем, что у них “здоровая атмосфера” и нет конфликтов. Кажется, что всё идеально: люди не спорят, не выясняют отношения, работа идёт спокойно.
Но если в команде никогда не бывает споров, значит, есть проблема.
Отсутствие конфликтов – это не всегда про взаимопонимание. Чаще это значит, что люди просто избегают сложных тем. Они не спорят не потому, что согласны, а потому что боятся высказываться, не хотят брать на себя ответственность или просто не верят, что их мнение что-то изменит.
Как отличить здоровую команду от пассивного соглашательства?
1️⃣ Люди задают неудобные вопросы?
Если обсуждения сводятся только к «окей, сделаем», это плохо. В сильных командах люди уточняют, сомневаются, предлагают альтернативы.
2️⃣ Решения принимаются быстро, но некачественно?
Если все всегда соглашаются без обсуждений, решения могут быть поверхностными. Споры помогают находить слабые места.
3️⃣ Есть культура открытого обсуждения?
В здоровой команде люди могут оспаривать даже мнения руководителя. В токсичной – все соглашаются с боссом, даже если понимают, что он не прав.
4️⃣ Как команда реагирует на критику?
Конструктивная критика – это нормально. Если все избегают любых конфликтных тем, значит, проблемы просто заметаются под ковёр.
Что делать?
🚀 Создавай культуру споров – показывай, что несогласие и обсуждения не только допустимы, но и полезны.
🚀 Сам оспаривай идеи – пусть люди видят, что здоровая дискуссия не наказуема.
🚀 Учись управлять конфликтами – цель не в том, чтобы их не было, а в том, чтобы они приводили к лучшим решениям.
Настоящая сильная команда – это не там, где тишина. Это там, где люди спорят, но не ради спора, а ради лучшего результата.
🔥1
⏳ Успеть всё – невозможно. И не нужно.
Кажется, что если правильно организовать своё время, прокачать эффективность, внедрить тайм-блокинг и научиться «концентрироваться на главном» – можно справиться со всеми задачами.
Но правда в том, что неважно, насколько ты эффективен – ты всегда будешь завален делами. Работы не станет меньше. Если просто оптимизировать работу, но не управлять своей энергией и не создавать зазоры для размышлений, ты выгоришь.
В книге Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency Tom DeMarco говорит об ошибочном восприятии эффективности. Многие считают, что максимальная загрузка человека или команды – это хорошо, что идеальный процесс тот, где нет простоев. На самом деле, это приводит к тому, что нет ресурса на изменения, адаптацию и рост.
Что такое Slack и почему это важно?
Slack в понимании DeMarco – это не про мессенджер, а про запас времени и энергии, который позволяет команде и человеку не просто механически выполнять работу, а думать, анализировать и улучшать.
Компании, которые забивают все 100% времени сотрудников, получают людей, которые не могут работать эффективнее – они просто делают больше однотипных задач, но не улучшают систему.
Руководитель, который тратит весь день на операционку, упускает будущее – у него нет времени задуматься, а куда вообще движется команда?
Когда нет Slack-а:
• Люди не успевают адаптироваться – если вся работа на 100% расписана, любое новое обстоятельство ломает процессы.
• Никто не думает о росте – все заняты тушением пожаров, а не поиском решений, как сделать работу проще, быстрее и эффективнее.
• Производительность падает – кажется, что загрузка выросла, но на деле люди просто замедляются из-за перегруза.
Как управлять этим в своей работе?
1️⃣ Закладывай время на размышления
Если твой календарь забит встречами и задачами, ты не управляешь – ты просто разруливаешь бесконечный поток задач. Выделяй время, чтобы подумать, что можно улучшить.
2️⃣ Оценивай не только «что я сделал», но и «что изменилось»
Много работы ≠ прогресс. Если ты каждый день закрываешь десятки задач, но ничего принципиально не меняется – значит, ты просто бежишь по кругу.
3️⃣ Оптимизируй не скорость работы, а систему
DeMarco пишет, что люди – не машины, их нельзя загрузить на 100%. Если команда всё время работает на пределе, она не развивается. Лучшие руководители думают не о том, как делать больше, а о том, как делать лучше.
4️⃣ Смотри шире своей роли
Если ты руководишь командой, твоя задача – не только раздавать задачи, а создавать среду, в которой люди могут работать эффективно. Если твои люди перегружены операционкой – у них тоже нет времени думать, а значит, роста не будет.
Настоящая эффективность – это не про заполненный календарь. Это про пространство, которое позволяет не просто работать, а двигаться вперёд.
Если ты работаешь без зазоров, без возможности остановиться и подумать – ты не управляешь, а просто тушишь пожары. Оставь себе место для размышлений. Это и есть настоящий Slack.
Кажется, что если правильно организовать своё время, прокачать эффективность, внедрить тайм-блокинг и научиться «концентрироваться на главном» – можно справиться со всеми задачами.
Но правда в том, что неважно, насколько ты эффективен – ты всегда будешь завален делами. Работы не станет меньше. Если просто оптимизировать работу, но не управлять своей энергией и не создавать зазоры для размышлений, ты выгоришь.
В книге Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency Tom DeMarco говорит об ошибочном восприятии эффективности. Многие считают, что максимальная загрузка человека или команды – это хорошо, что идеальный процесс тот, где нет простоев. На самом деле, это приводит к тому, что нет ресурса на изменения, адаптацию и рост.
Что такое Slack и почему это важно?
Slack в понимании DeMarco – это не про мессенджер, а про запас времени и энергии, который позволяет команде и человеку не просто механически выполнять работу, а думать, анализировать и улучшать.
Компании, которые забивают все 100% времени сотрудников, получают людей, которые не могут работать эффективнее – они просто делают больше однотипных задач, но не улучшают систему.
Руководитель, который тратит весь день на операционку, упускает будущее – у него нет времени задуматься, а куда вообще движется команда?
Когда нет Slack-а:
• Люди не успевают адаптироваться – если вся работа на 100% расписана, любое новое обстоятельство ломает процессы.
• Никто не думает о росте – все заняты тушением пожаров, а не поиском решений, как сделать работу проще, быстрее и эффективнее.
• Производительность падает – кажется, что загрузка выросла, но на деле люди просто замедляются из-за перегруза.
Как управлять этим в своей работе?
1️⃣ Закладывай время на размышления
Если твой календарь забит встречами и задачами, ты не управляешь – ты просто разруливаешь бесконечный поток задач. Выделяй время, чтобы подумать, что можно улучшить.
2️⃣ Оценивай не только «что я сделал», но и «что изменилось»
Много работы ≠ прогресс. Если ты каждый день закрываешь десятки задач, но ничего принципиально не меняется – значит, ты просто бежишь по кругу.
3️⃣ Оптимизируй не скорость работы, а систему
DeMarco пишет, что люди – не машины, их нельзя загрузить на 100%. Если команда всё время работает на пределе, она не развивается. Лучшие руководители думают не о том, как делать больше, а о том, как делать лучше.
4️⃣ Смотри шире своей роли
Если ты руководишь командой, твоя задача – не только раздавать задачи, а создавать среду, в которой люди могут работать эффективно. Если твои люди перегружены операционкой – у них тоже нет времени думать, а значит, роста не будет.
Настоящая эффективность – это не про заполненный календарь. Это про пространство, которое позволяет не просто работать, а двигаться вперёд.
Если ты работаешь без зазоров, без возможности остановиться и подумать – ты не управляешь, а просто тушишь пожары. Оставь себе место для размышлений. Это и есть настоящий Slack.
👍3
🔄 Саморефлексия руководителя – привычка, которая меняет всё
В самом начале своей карьеры тимлида я прочел простой, но мощный совет: каждый вечер спрашивать себя – что я сделал сегодня, чтобы продвинуть команду вперёд?
Со временем я усложнил этот инструмент. Теперь каждый вечер по пути домой я задаю себе три вопроса:
1️⃣ Что я сделал сегодня, что реально помогло команде?
2️⃣ Что я мог бы сделать лучше?
3️⃣ Что я изменю завтра, чтобы быть лучшим руководителем?
Иногда ответы неприятные. Бывает, осознаёшь, что день прошёл в операционке, но ничего ценного ты не добавил. Бывает, что понимаешь – где-то поторопился, где-то не дал человеку проявить себя, где-то избежал сложного разговора.
Но именно это позволяет не застревать в рутине, а постоянно расти.
Если вечером нечего ответить на вопрос «что я сделал для команды?», значит, завтра что-то нужно делать иначе.
В самом начале своей карьеры тимлида я прочел простой, но мощный совет: каждый вечер спрашивать себя – что я сделал сегодня, чтобы продвинуть команду вперёд?
Со временем я усложнил этот инструмент. Теперь каждый вечер по пути домой я задаю себе три вопроса:
1️⃣ Что я сделал сегодня, что реально помогло команде?
2️⃣ Что я мог бы сделать лучше?
3️⃣ Что я изменю завтра, чтобы быть лучшим руководителем?
Иногда ответы неприятные. Бывает, осознаёшь, что день прошёл в операционке, но ничего ценного ты не добавил. Бывает, что понимаешь – где-то поторопился, где-то не дал человеку проявить себя, где-то избежал сложного разговора.
Но именно это позволяет не застревать в рутине, а постоянно расти.
Если вечером нечего ответить на вопрос «что я сделал для команды?», значит, завтра что-то нужно делать иначе.
👍7
👨🏫 Если сомневаешься – не бери
Один из моих знакомых ТОП-менеджеров сказал:
“Я за первые пять минут принимаю решение, брать человека или нет, а оставшиеся 55 – пытаюсь переубедить себя в этом решении.”
Чем больше я занимаюсь наймом руководителей, тем больше понимаю, насколько это правда.
Когда ты нанимаешь тимлида, руководителя направления или даже CTO, ты нанимаешь не просто сотрудника – ты меняешь динамику всей команды. Ошибки здесь стоят дорого. Неправильный человек может замедлить процессы, убить мотивацию, спровоцировать уход сильных сотрудников. Я знаю это на своём опыте.
За годы управления я нанял много сотрудников. И каждый раз, когда я сомневался, но всё-таки решался взять человека, через несколько месяцев приходилось признавать: интуиция не подвела – я совершил ошибку.
Но всё равно часто после собеседования я пытаюсь себя переубедить:
👉 «Он не слишком вовлекался в обсуждение, но, может, в деле проявится…»
👉 «Есть вопросы по лидерским качествам, но зато у него неплохой бэкграунд…»
👉 «Команде он вряд ли понравится, но, может, привыкнут…»
В реальности таких «может быть» не существует. Если у тебя есть сомнения – их заметит и команда. Цена ошибки в найме руководителя огромна.
Как минимизировать риск?
1️⃣ Прими правило: если сомневаешься – не бери.
2️⃣ Оценивай влияние, а не просто скиллы. Хороший руководитель делает команду сильнее, а не просто управляет задачами.
3️⃣ Не соглашайся на «нормально» – ищи того, кто усилит команду.
Наём руководителя – это осознанный выбор человека, который поведёт команду вперёд. И если ты в этом не уверен – значит, это не тот человек.
P.S. Данное правило экстраполируется на наём любых сотрудников и является универсальным
Один из моих знакомых ТОП-менеджеров сказал:
“Я за первые пять минут принимаю решение, брать человека или нет, а оставшиеся 55 – пытаюсь переубедить себя в этом решении.”
Чем больше я занимаюсь наймом руководителей, тем больше понимаю, насколько это правда.
Когда ты нанимаешь тимлида, руководителя направления или даже CTO, ты нанимаешь не просто сотрудника – ты меняешь динамику всей команды. Ошибки здесь стоят дорого. Неправильный человек может замедлить процессы, убить мотивацию, спровоцировать уход сильных сотрудников. Я знаю это на своём опыте.
За годы управления я нанял много сотрудников. И каждый раз, когда я сомневался, но всё-таки решался взять человека, через несколько месяцев приходилось признавать: интуиция не подвела – я совершил ошибку.
Но всё равно часто после собеседования я пытаюсь себя переубедить:
👉 «Он не слишком вовлекался в обсуждение, но, может, в деле проявится…»
👉 «Есть вопросы по лидерским качествам, но зато у него неплохой бэкграунд…»
👉 «Команде он вряд ли понравится, но, может, привыкнут…»
В реальности таких «может быть» не существует. Если у тебя есть сомнения – их заметит и команда. Цена ошибки в найме руководителя огромна.
Как минимизировать риск?
1️⃣ Прими правило: если сомневаешься – не бери.
2️⃣ Оценивай влияние, а не просто скиллы. Хороший руководитель делает команду сильнее, а не просто управляет задачами.
3️⃣ Не соглашайся на «нормально» – ищи того, кто усилит команду.
Наём руководителя – это осознанный выбор человека, который поведёт команду вперёд. И если ты в этом не уверен – значит, это не тот человек.
P.S. Данное правило экстраполируется на наём любых сотрудников и является универсальным
👍5🔥2
🚀 Делегирование решений: как не стать главным тормозом в компании
Одна из ключевых задач руководителя – принимать решения. Но если всё завязано только на одном человеке, это неизбежно превращается в узкое горлышко: процессы тормозятся, сотрудники боятся проявлять инициативу, а организация теряет скорость и гибкость.
Два типа решений
Мне нравится как Джефф Безос предлагает это решить. Он делит все решения на два типа:
1️⃣ Необратимые решения («односторонние двери»)
Это серьёзные стратегические выборы, последствия которых сложно или невозможно исправить. Они требуют тщательного анализа, дискуссий и консенсуса. Здесь действительно важно остановиться и подумать.
2️⃣ Обратимые решения («двусторонние двери»)
Это решения, которые можно отменить, скорректировать или переработать. Ошиблись? Окей, потеряли немного времени или денег, но не критично. Можно быстро попробовать снова.
Распространенная ошибка – всё превращать в решения первого типа. В итоге даже мелкие вопросы зацикливаются на одном человеке, все ждут “одобрения сверху”, а организация становится медленной и неэффективной.
Как это исправить?
✅ Перед любым решением определяйте его тип. Если это обратимый выбор, не тормозите – принимайте быстро и двигайтесь дальше.
✅ Делегируйте решения второго типа. Руководитель не должен быть “центром вселенной”. Дайте людям право принимать решения, иначе они просто перестанут думать самостоятельно.
✅ Создавайте культуру экспериментов. Если за каждую ошибку карают, сотрудники будут избегать решений. А значит, компания перестанет развиваться.
✅ Не превращайтесь в “главного тормоза”. Чем выше ваша позиция, тем больше вас будут вовлекать в процессы. Учитесь отступать и давать команде больше автономии.
@ctrlshiftboss
Одна из ключевых задач руководителя – принимать решения. Но если всё завязано только на одном человеке, это неизбежно превращается в узкое горлышко: процессы тормозятся, сотрудники боятся проявлять инициативу, а организация теряет скорость и гибкость.
Два типа решений
Мне нравится как Джефф Безос предлагает это решить. Он делит все решения на два типа:
1️⃣ Необратимые решения («односторонние двери»)
Это серьёзные стратегические выборы, последствия которых сложно или невозможно исправить. Они требуют тщательного анализа, дискуссий и консенсуса. Здесь действительно важно остановиться и подумать.
2️⃣ Обратимые решения («двусторонние двери»)
Это решения, которые можно отменить, скорректировать или переработать. Ошиблись? Окей, потеряли немного времени или денег, но не критично. Можно быстро попробовать снова.
Распространенная ошибка – всё превращать в решения первого типа. В итоге даже мелкие вопросы зацикливаются на одном человеке, все ждут “одобрения сверху”, а организация становится медленной и неэффективной.
Как это исправить?
✅ Перед любым решением определяйте его тип. Если это обратимый выбор, не тормозите – принимайте быстро и двигайтесь дальше.
✅ Делегируйте решения второго типа. Руководитель не должен быть “центром вселенной”. Дайте людям право принимать решения, иначе они просто перестанут думать самостоятельно.
✅ Создавайте культуру экспериментов. Если за каждую ошибку карают, сотрудники будут избегать решений. А значит, компания перестанет развиваться.
✅ Не превращайтесь в “главного тормоза”. Чем выше ваша позиция, тем больше вас будут вовлекать в процессы. Учитесь отступать и давать команде больше автономии.
@ctrlshiftboss
🔥6👍3🫡2
🎯 Как я перестал бояться давать развивающую обратную связь
Я всегда боялся говорить людям, что они что-то делают не так. Позитивную обратную связь давать легко – похвалил, поддержал, и все довольны. Но как сказать человеку, что он работает недостаточно хорошо, не обидев его и не демотивировав?
Из-за этого я часто тянул с развивающей обратной связью или вообще её избегал, надеясь, что если я буду подсвечивать только сильные стороны, человек сам догадается, что можно улучшить.
Но это не работает.
Однажды я решил попробовать иначе. За короткий период я дал честную, прямую обратную связь нескольким людям. Мне было страшно – я ожидал обиды, сопротивления, возможно, даже конфликтов.
Но реакция была разной.
Кто-то просто принимал обратную связь и говорил:
«Да, я и сам замечал такое».
А кто-то думал, что я жду от него совершенно другого поведения. Он менял стиль работы, считал, что делает всё правильно, но когда я снова давал развивающую обратную связь, он удивлялся:
«Я думал, ты как раз этого и хотел!»
Здесь мы уже корректировали ожидания друг от друга: я стал чётче объяснять, что именно стоит изменить и в каком направлении двигаться, а не просто указывать на проблему.
И я понял: обратная связь – это не про обвинения, а про развитие. И воспринимать её нужно именно так. Если ты хочешь, чтобы команда становилась сильнее, ты не можешь замалчивать проблемные места. Люди не читают мысли, они не всегда видят свои слабые стороны. Но если ты честно и конструктивно указываешь на них – это шанс для роста.
С того момента мне стало намного легче. Я уже не боюсь давать развивающую обратную связь, потому что понимаю: если человек хочет развиваться, он её ценит. Я вижу, что команда становится сильнее, быстрее решает проблемы и лучше понимает, как расти.
Главный вывод: честная обратная связь – это не критика и не нужно её так воспринимать. Она помогает людям стать лучше. И если ты хочешь быть хорошим руководителем, избегать её нельзя.
@ctrlshiftboss
Я всегда боялся говорить людям, что они что-то делают не так. Позитивную обратную связь давать легко – похвалил, поддержал, и все довольны. Но как сказать человеку, что он работает недостаточно хорошо, не обидев его и не демотивировав?
Из-за этого я часто тянул с развивающей обратной связью или вообще её избегал, надеясь, что если я буду подсвечивать только сильные стороны, человек сам догадается, что можно улучшить.
Но это не работает.
Однажды я решил попробовать иначе. За короткий период я дал честную, прямую обратную связь нескольким людям. Мне было страшно – я ожидал обиды, сопротивления, возможно, даже конфликтов.
Но реакция была разной.
Кто-то просто принимал обратную связь и говорил:
«Да, я и сам замечал такое».
А кто-то думал, что я жду от него совершенно другого поведения. Он менял стиль работы, считал, что делает всё правильно, но когда я снова давал развивающую обратную связь, он удивлялся:
«Я думал, ты как раз этого и хотел!»
Здесь мы уже корректировали ожидания друг от друга: я стал чётче объяснять, что именно стоит изменить и в каком направлении двигаться, а не просто указывать на проблему.
И я понял: обратная связь – это не про обвинения, а про развитие. И воспринимать её нужно именно так. Если ты хочешь, чтобы команда становилась сильнее, ты не можешь замалчивать проблемные места. Люди не читают мысли, они не всегда видят свои слабые стороны. Но если ты честно и конструктивно указываешь на них – это шанс для роста.
С того момента мне стало намного легче. Я уже не боюсь давать развивающую обратную связь, потому что понимаю: если человек хочет развиваться, он её ценит. Я вижу, что команда становится сильнее, быстрее решает проблемы и лучше понимает, как расти.
Главный вывод: честная обратная связь – это не критика и не нужно её так воспринимать. Она помогает людям стать лучше. И если ты хочешь быть хорошим руководителем, избегать её нельзя.
@ctrlshiftboss
❤6🔥4👍3
На прошлой неделе за один (!) вечер собрал с нуля iOS-приложение, которое собирает все данные из HealthKit, готовит из них json (чтобы потом с помощью LLM его можно было проанализировать и получить конкретные рекомендации и обнаружить аномалии) и строит графики с уровнем стресса по дням.
Я сам написал 0 (ноль) строчек кода :) Всё сделал через claude 3.7. Есть небольшие погрешности, но они быстро чинятся еще одной итерацией.
Из крутого – я не давал никаких промптов для интерфейса, кроме как в формате: “хочу иметь возможность выбрать за сколько дней выгружать данные” или “хочу чтобы был график с уровнем стресса” и тд. LLM сама отрисовала экраны с прогрессом выгрузки данных, экраны с формулой для стресса и другие пояснения (я даже не просил этого). Из коробки работает темная тема и адаптивная верстка)
Будущее!
@ctrlshiftboss
Я сам написал 0 (ноль) строчек кода :) Всё сделал через claude 3.7. Есть небольшие погрешности, но они быстро чинятся еще одной итерацией.
Из крутого – я не давал никаких промптов для интерфейса, кроме как в формате: “хочу иметь возможность выбрать за сколько дней выгружать данные” или “хочу чтобы был график с уровнем стресса” и тд. LLM сама отрисовала экраны с прогрессом выгрузки данных, экраны с формулой для стресса и другие пояснения (я даже не просил этого). Из коробки работает темная тема и адаптивная верстка)
Будущее!
@ctrlshiftboss
🔥11👍1
🔥 Из разработчика в руководители: то, о чём не пишут в книгах, что проверено на опыте
Когда я перешёл из разработки в управление, мне казалось, что это просто следующий логичный шаг в карьере. Ну а что сложного? Ты же знаешь, как всё устроено, умеешь писать код, понимаешь архитектуру — значит, сможешь и команду организовать.
Но реальность быстро показала, что управление — это вообще другая профессия.
Код либо работает, либо нет. А с людьми так не бывает. Здесь нет чётких правил, нет линтера, который подсветит ошибку, и нет Stack Overflow, где можно найти готовый ответ. Информации вроде много, но что из неё реально работает — непонятно. Ты просто разбираешься методом проб и (больно полученных) ошибок.
Кто я?
Меня зовут Илья Царев, и я занимаюсь коммерческой разработкой больше 12 лет.
• Работал в стартапах. Делал первую в России connected car платформу Remoto, которая потом была успешно интегрирована в один из сервисов каршеринга (Делимобиль).
• Несколько лет работал в Альфа-Банке, где построил одну из сильнейших команд мобильной разработки на рынке в тот момент.
• В 2019 году присоединился к команде Яндекс Такси и помогаю создавать клиентский суперапп Яндекс Go, который хочу сделать самым удобным.
• Последние 8 лет управляю командами инженеров — от небольших групп в 10 человек в начале до больших подразделений в 250+ сотрудников сейчас.
• Иногда выступаю на конференциях (пример раз, пример два).
• Иногда пишу статьи, например, вот одна из них.
О чём этот канал?
Про реальные ошибки и выводы. Про то, что реально помогает руководителю в IT, а что — просто красивая теория.
Если вы уже управляете командой или только переходите в новую роль — оставайтесь. Здесь будет то, что мне самому когда-то сильно помогло бы.
@ctrlshiftboss
Когда я перешёл из разработки в управление, мне казалось, что это просто следующий логичный шаг в карьере. Ну а что сложного? Ты же знаешь, как всё устроено, умеешь писать код, понимаешь архитектуру — значит, сможешь и команду организовать.
Но реальность быстро показала, что управление — это вообще другая профессия.
Код либо работает, либо нет. А с людьми так не бывает. Здесь нет чётких правил, нет линтера, который подсветит ошибку, и нет Stack Overflow, где можно найти готовый ответ. Информации вроде много, но что из неё реально работает — непонятно. Ты просто разбираешься методом проб и (больно полученных) ошибок.
Кто я?
Меня зовут Илья Царев, и я занимаюсь коммерческой разработкой больше 12 лет.
• Работал в стартапах. Делал первую в России connected car платформу Remoto, которая потом была успешно интегрирована в один из сервисов каршеринга (Делимобиль).
• Несколько лет работал в Альфа-Банке, где построил одну из сильнейших команд мобильной разработки на рынке в тот момент.
• В 2019 году присоединился к команде Яндекс Такси и помогаю создавать клиентский суперапп Яндекс Go, который хочу сделать самым удобным.
• Последние 8 лет управляю командами инженеров — от небольших групп в 10 человек в начале до больших подразделений в 250+ сотрудников сейчас.
• Иногда выступаю на конференциях (пример раз, пример два).
• Иногда пишу статьи, например, вот одна из них.
О чём этот канал?
Про реальные ошибки и выводы. Про то, что реально помогает руководителю в IT, а что — просто красивая теория.
Если вы уже управляете командой или только переходите в новую роль — оставайтесь. Здесь будет то, что мне самому когда-то сильно помогло бы.
@ctrlshiftboss
🔥17👍4🤩4
🔥 Что делать, если сотрудник хочет уволиться?
Когда ко мне приходит человек и говорит: «Я ухожу», моя первая реакция — не пытаться его удержать любой ценой, а разобраться в мотивации.
Задача руководителя — помогать своим сотрудникам. Неважно, работаете вы ещё вместе или уже нет. Поэтому первое правило — быть честным. Не пытаться манипулировать, давить или обещать то, что невозможно. А объективно разобрать ситуацию. К таким руководителям сотрудники потом возвращаются, рекомендуют их, делятся знаниями даже спустя годы.
Есть два типа мотивации при увольнении:
1. Мотивация ОТ
Человек уходит от чего-то:
— Плохой руководитель или команда.
— Неинтересные задачи.
— Раздражающие процессы.
— Устаревшие технологии.
Здесь я задаю вопрос: «Могу ли я быстро починить ситуацию?» Если проблема решаемая, стоит ли увольняться? Иногда люди просто не видят, что решение есть.
2. Мотивация К
Человек уходит к чему-то:
— Повышение, которое давно хотел.
— Другая культура, где он чувствует себя комфортнее.
— Новый стек технологий.
Здесь вопрос другой: «Могу ли я дать это внутри компании?» Если нет — честный разговор. Если да — может, есть смысл обсудить альтернативные варианты?
После такого разговора человек либо осознанно остаётся, либо уходит без негатива. А для меня это ещё и важный сигнал: что исправить в команде, чтобы меньше людей уходило в будущем.
@ctrlshiftboss
Когда ко мне приходит человек и говорит: «Я ухожу», моя первая реакция — не пытаться его удержать любой ценой, а разобраться в мотивации.
Задача руководителя — помогать своим сотрудникам. Неважно, работаете вы ещё вместе или уже нет. Поэтому первое правило — быть честным. Не пытаться манипулировать, давить или обещать то, что невозможно. А объективно разобрать ситуацию. К таким руководителям сотрудники потом возвращаются, рекомендуют их, делятся знаниями даже спустя годы.
Есть два типа мотивации при увольнении:
1. Мотивация ОТ
Человек уходит от чего-то:
— Плохой руководитель или команда.
— Неинтересные задачи.
— Раздражающие процессы.
— Устаревшие технологии.
Здесь я задаю вопрос: «Могу ли я быстро починить ситуацию?» Если проблема решаемая, стоит ли увольняться? Иногда люди просто не видят, что решение есть.
2. Мотивация К
Человек уходит к чему-то:
— Повышение, которое давно хотел.
— Другая культура, где он чувствует себя комфортнее.
— Новый стек технологий.
Здесь вопрос другой: «Могу ли я дать это внутри компании?» Если нет — честный разговор. Если да — может, есть смысл обсудить альтернативные варианты?
После такого разговора человек либо осознанно остаётся, либо уходит без негатива. А для меня это ещё и важный сигнал: что исправить в команде, чтобы меньше людей уходило в будущем.
@ctrlshiftboss
👍8🔥4❤3
📵 «Я всегда на связи» — миф об идеальном руководителе
Когда я только начал управлять, мне казалось, что я обязан быть доступным всегда. У команды должна быть уверенность, что я рядом: пришёл в личку — ответил, позвал на созвон — подключился, попросил совет — сразу дал.
Поначалу это работает. Люди действительно чувствуют, что ты рядом, что ты «в теме». Но через какое-то время ты начинаешь замечать, что команда… перестаёт думать самостоятельно.
— Почему ты не принял решение сам?
— Я хотел сначала спросить тебя.
И вот ты уже точка, через которую проходят все вопросы. Всё начинает тормозить. И это не потому, что команда слабая — это потому, что ты стал зависимостью.
Научиться быть недоступным — тоже навык.
Не в смысле игнорировать людей. А в смысле создавать пространство, где они сами принимают решения. Где знают границы, чувствуют поддержку, но не висят у тебя на шее.
И чем выше ты поднимаешься, тем больше таких зон ты должен выстраивать. Потому что управление — это не про участие во всём, а про то, чтобы всё работало без твоего постоянного участия.
@ctrlshiftboss
Когда я только начал управлять, мне казалось, что я обязан быть доступным всегда. У команды должна быть уверенность, что я рядом: пришёл в личку — ответил, позвал на созвон — подключился, попросил совет — сразу дал.
Поначалу это работает. Люди действительно чувствуют, что ты рядом, что ты «в теме». Но через какое-то время ты начинаешь замечать, что команда… перестаёт думать самостоятельно.
— Почему ты не принял решение сам?
— Я хотел сначала спросить тебя.
И вот ты уже точка, через которую проходят все вопросы. Всё начинает тормозить. И это не потому, что команда слабая — это потому, что ты стал зависимостью.
Научиться быть недоступным — тоже навык.
Не в смысле игнорировать людей. А в смысле создавать пространство, где они сами принимают решения. Где знают границы, чувствуют поддержку, но не висят у тебя на шее.
И чем выше ты поднимаешься, тем больше таких зон ты должен выстраивать. Потому что управление — это не про участие во всём, а про то, чтобы всё работало без твоего постоянного участия.
@ctrlshiftboss
👍10🔥2💯2
⚙️ LLM и новая реальность инженерного труда
Я уже давно не пишу код каждый день. Последние лет пять — максимум что-то по мелочи: прототип, тулза для себя, небольшой эксперимент.
Но сейчас всё изменилось. С появлением LLM я снова могу быстро «писать» код — не руками, а головой.
На днях я собрал рабочий прототип за день и пару часов между встречами. Как?
— Написал задание Cursor’у.
— Ушёл на встречу.
— Вернулся, посмотрел, что получилось.
— Подкорректировал, добавил новые вводные.
— И так по кругу.
Это не магия. Это просто новая модель взаимодействия с инженерией. Я не сижу в редакторе по 8 часов, я формулирую проблему, корректирую подходы, проверяю результат.
И вот что интересно:
многие из тех, кто стал руководителями, делали это не потому, что хотели управлять, а потому что хотели делать больше. Но нельзя было «ускорить себя» как разработчика. Единственный способ масштабироваться — был через людей.
А теперь — появился другой путь. LLM — это не замена инженерам, это усиление. Это возможность снова масштабировать свои действия напрямую.
Как это повлияет на разработку? На команды? На руководителей?
Ответа пока нет. Но понятно одно — подход к инженерии уже меняется.
@ctrlshiftboss
Я уже давно не пишу код каждый день. Последние лет пять — максимум что-то по мелочи: прототип, тулза для себя, небольшой эксперимент.
Но сейчас всё изменилось. С появлением LLM я снова могу быстро «писать» код — не руками, а головой.
На днях я собрал рабочий прототип за день и пару часов между встречами. Как?
— Написал задание Cursor’у.
— Ушёл на встречу.
— Вернулся, посмотрел, что получилось.
— Подкорректировал, добавил новые вводные.
— И так по кругу.
Это не магия. Это просто новая модель взаимодействия с инженерией. Я не сижу в редакторе по 8 часов, я формулирую проблему, корректирую подходы, проверяю результат.
И вот что интересно:
многие из тех, кто стал руководителями, делали это не потому, что хотели управлять, а потому что хотели делать больше. Но нельзя было «ускорить себя» как разработчика. Единственный способ масштабироваться — был через людей.
А теперь — появился другой путь. LLM — это не замена инженерам, это усиление. Это возможность снова масштабировать свои действия напрямую.
Как это повлияет на разработку? На команды? На руководителей?
Ответа пока нет. Но понятно одно — подход к инженерии уже меняется.
@ctrlshiftboss
🔥4💯2❤1