Почему нельзя просто сорвать сроки? Какие могут быть последствия?
Бывают ситуации, когда невозможно уложиться в сроки. Правильное поведение в такой ситуации: выставить реальные сроки, всем озвучить и, пытаясь оптимизировать затраты, все же напоминать о реалиях на любых встречах. Так делать правильно хоть и часто сложно. Многие просто берут сроки, не споря (даже если можно было просто назвать реальные сроки без споров), и потом, по факту, говорят, что не укладываются в дедлайн. Меня часто спрашивают, понятно, что это не правильно, но как это воспринимаешь ты или более высокое руководство? Какие долгосрочные последствия?
Тут нужно понимать, что все зависит от ситуации. Чем крупнее компания, тем сильнее она опирается на метрики и цели, которые стоят у конкретных руководителей. Цели спускаются более мелкими кусками, на руководителей звена ниже. Каждая цель вашей команды / продукта в итоге влияет на большую цель. Многие цели нельзя закрыть частично. Например, происходит переход с легаси системы на новую, новую делает несколько команд. Обычно если одна не успевает, то это ведет к тому, что не засчитывается цель в целом, потому что, обычно, вывести из эксплуатации легаси нельзя. То, что вы подводите свое руководство это понятно, но пользователи продолжат работать на легаси (обычно переход затеян для улучшения работы пользователей), смежным командам свои цели тоже могут не засчитать (такое бывает чаще, чем кажется), могут быть не достигнуты бизнес показатели из-за этого ну и т. д. Соответственно, небольшой проваленный кусок может снежным комом потянуть за собой очень много вещей. Большинство людей не задумываются об этом и очень скептически относятся к своим целям. Ну казалось бы у нас не самый важный функционал, ничего страшного. Но на практике работает это не так. В двух системах скорее всего работать никто не будет по многим причинам и техническим и бизнесовым. Поэтому я всегда рассказываю своим ребятам о том, кто и что от них зависит и советую и вам такие вещи знать.
В итоге, самое плохое часто даже не срыв сроков, а то, что он произойдет неожиданно. Никто не сможет проработать варианты, обойти проблему или усилить вашу команду. Соответственно, это будет большим стрессом для всех. Но что же может случится конкретно для вас?
Тут все зависит от руководства и ситуации, может от ничего до увольнения. Чаще идут более мягкие наказания. Отмена премий (если они есть), отмена повышений для всей команды или определенных ее участников. Это быстрые эффекты. В отложенных эффектах я бы отметил отсутствие доверия к вам и вашей команде, то есть вам будут стараться не поручать ничего важного и интересного, а также будут заниматься вашим ростом и развитием в последнюю очередь.
В целом, не попадать в сроки, спущенные сверху, это нормально, ненормально, когда вы знаете и молчите об этом. Сказать прямо и честно, что не успеваете это часть работы (у меня есть много историй про это, если будет интерес к этому, то поделюсь).
Заранее понять, что вы не успеваете в сроки это тоже отдельная задача, которую мы будем разбирать на нашем марафоне по работе со сроками, стартующем 11 декабря. Там же разберем, что можно сделать, чтобы уложиться в сроки, если уже не успеваете. Зовите своих коллег и подчиненных присоединиться к марафону, информация будет очень полезная и важная для всех.
Максим Шаламов
#разработчику #руководителю
Бывают ситуации, когда невозможно уложиться в сроки. Правильное поведение в такой ситуации: выставить реальные сроки, всем озвучить и, пытаясь оптимизировать затраты, все же напоминать о реалиях на любых встречах. Так делать правильно хоть и часто сложно. Многие просто берут сроки, не споря (даже если можно было просто назвать реальные сроки без споров), и потом, по факту, говорят, что не укладываются в дедлайн. Меня часто спрашивают, понятно, что это не правильно, но как это воспринимаешь ты или более высокое руководство? Какие долгосрочные последствия?
Тут нужно понимать, что все зависит от ситуации. Чем крупнее компания, тем сильнее она опирается на метрики и цели, которые стоят у конкретных руководителей. Цели спускаются более мелкими кусками, на руководителей звена ниже. Каждая цель вашей команды / продукта в итоге влияет на большую цель. Многие цели нельзя закрыть частично. Например, происходит переход с легаси системы на новую, новую делает несколько команд. Обычно если одна не успевает, то это ведет к тому, что не засчитывается цель в целом, потому что, обычно, вывести из эксплуатации легаси нельзя. То, что вы подводите свое руководство это понятно, но пользователи продолжат работать на легаси (обычно переход затеян для улучшения работы пользователей), смежным командам свои цели тоже могут не засчитать (такое бывает чаще, чем кажется), могут быть не достигнуты бизнес показатели из-за этого ну и т. д. Соответственно, небольшой проваленный кусок может снежным комом потянуть за собой очень много вещей. Большинство людей не задумываются об этом и очень скептически относятся к своим целям. Ну казалось бы у нас не самый важный функционал, ничего страшного. Но на практике работает это не так. В двух системах скорее всего работать никто не будет по многим причинам и техническим и бизнесовым. Поэтому я всегда рассказываю своим ребятам о том, кто и что от них зависит и советую и вам такие вещи знать.
В итоге, самое плохое часто даже не срыв сроков, а то, что он произойдет неожиданно. Никто не сможет проработать варианты, обойти проблему или усилить вашу команду. Соответственно, это будет большим стрессом для всех. Но что же может случится конкретно для вас?
Тут все зависит от руководства и ситуации, может от ничего до увольнения. Чаще идут более мягкие наказания. Отмена премий (если они есть), отмена повышений для всей команды или определенных ее участников. Это быстрые эффекты. В отложенных эффектах я бы отметил отсутствие доверия к вам и вашей команде, то есть вам будут стараться не поручать ничего важного и интересного, а также будут заниматься вашим ростом и развитием в последнюю очередь.
В целом, не попадать в сроки, спущенные сверху, это нормально, ненормально, когда вы знаете и молчите об этом. Сказать прямо и честно, что не успеваете это часть работы (у меня есть много историй про это, если будет интерес к этому, то поделюсь).
Заранее понять, что вы не успеваете в сроки это тоже отдельная задача, которую мы будем разбирать на нашем марафоне по работе со сроками, стартующем 11 декабря. Там же разберем, что можно сделать, чтобы уложиться в сроки, если уже не успеваете. Зовите своих коллег и подчиненных присоединиться к марафону, информация будет очень полезная и важная для всех.
Максим Шаламов
#разработчику #руководителю
Почему люди уходят из компании
Текучка в команде - болезненная тема для руководителей, у многих этот показатель входит в KPI и влияет на показатели успеха собственной работы. Несомненно, она влияет и на успешность работы самой команды, поэтому игнорировать текучку ни в коем случае нельзя. Чтобы начать решать эту проблему, для начала нужно разобраться, в чем основные причины. Давайте пойдем от самых очевидных к менее очевидным пунктам.
Очевидные причины
Не подходящая компания или проект. Бывает, что обещали одно, а внутри все не так. Обман ожиданий конечно же ведет к оттоку сотрудников. Стоит уделять внимание тому, что обещаете на собеседовании, не обещайте больше, чем есть и не искажайте основные факты. Даже если вы так заманите человека в свою команду, велика вероятность, что он очень быстро уйдет, а ресурсы команды для его ввода в проект будут потрачены впустую.
Не сработались с командой или руководителем. Тоже нередкая проблема, когда не получается найти общий язык новому сотруднику и уже устоявшейся команде, что приводит к проблемам в коммуникациях и в достижении целей. Это периодически приводит к конфликтам. Конечно же люди часто не готовы продолжать в таких условиях. Я уже как-то писал о том, как собеседовать человека на совместимость с командой, старайтесь уделять этому внимание уже на собеседовании, чтобы уменьшить риски появления такой ситуации.
Проекты на поддержке. Многие разработчики не готовы работать на проектах, где нет развития. Основная часть проекта уже готова и не меняется, правятся только мелкие ошибки и делаются незначительные доработки. Конечно же людям, особенно имеющим какие-то амбиции, не хочется терять время на “мертвые” проекты, им скучно, они теряют квалификацию и, соответственно, свою цену на рынке.
Просто надоедает проект, все уже знакомо, хочется выйти за границы комфорта. Конечно, выход из зоны комфорта помогают росту и развитию разработчика.Конечно, выход из зоны комфорта помогают росту и развитию разработчика. Однако, можно продолжать развиваться и будучи на уже знакомом проекте, мы разбираем как это можно сделать в нашем продукте по борьбе с рутиной. Учитесь этому, если вы разработчик, реже придется менять работу и меньше будете терять время, пока находитесь на уже знакомом проекте. Мотивируйте к использованию этих подходов своих подчиненных, если вы руководитель, это поможет уменьшить текучку.
Менее однозначные проблемы
Дальше пойдем к менее однозначным пунктам.
В проекте все налажено включая процессы. Не смотря на то, что все будет идти понятно и предсказуемо, и удастся избежать многих проблем, части людей будет скучно или сложно встраиваться в такие системы.
Проекты на стадии активного роста и развития. На самом деле, многие говорят, что им такой опыт интересен, но, по факту, большинство не готово взять на себя ответственность за настройку даже малейших вещей, будь то выбор единой библиотеки (не просто мне нравится, а провести анализ и переработать какой-то кусок в пром по правилам команды и показать результаты), до запуска тестов в пайплайне и т.д. Люди буду говорить, что да, вот хочется, чтобы все росло и развивалось, но только чтоб нам ничего делать было не надо. В итоге, выгорание идет от того, что многое сделано не оптимально, но тут правильный настрой в том, чтобы участвовать в процессе самим.
Нет роста. В целом это реально может быть проблемой, и что не делаешь и не просишь, роста тебе не будет. Но нередки случаи, когда ты хочешь постоянные повышения за одну и туже работу (даже не индексации а именно повышения), так не бывает. Для повышений нужно делать что-то сверх своей работы и это надо согласовывать с руководством.
Максим Шаламов
#советы #руководителю #разработчику
Текучка в команде - болезненная тема для руководителей, у многих этот показатель входит в KPI и влияет на показатели успеха собственной работы. Несомненно, она влияет и на успешность работы самой команды, поэтому игнорировать текучку ни в коем случае нельзя. Чтобы начать решать эту проблему, для начала нужно разобраться, в чем основные причины. Давайте пойдем от самых очевидных к менее очевидным пунктам.
Очевидные причины
Не подходящая компания или проект. Бывает, что обещали одно, а внутри все не так. Обман ожиданий конечно же ведет к оттоку сотрудников. Стоит уделять внимание тому, что обещаете на собеседовании, не обещайте больше, чем есть и не искажайте основные факты. Даже если вы так заманите человека в свою команду, велика вероятность, что он очень быстро уйдет, а ресурсы команды для его ввода в проект будут потрачены впустую.
Не сработались с командой или руководителем. Тоже нередкая проблема, когда не получается найти общий язык новому сотруднику и уже устоявшейся команде, что приводит к проблемам в коммуникациях и в достижении целей. Это периодически приводит к конфликтам. Конечно же люди часто не готовы продолжать в таких условиях. Я уже как-то писал о том, как собеседовать человека на совместимость с командой, старайтесь уделять этому внимание уже на собеседовании, чтобы уменьшить риски появления такой ситуации.
Проекты на поддержке. Многие разработчики не готовы работать на проектах, где нет развития. Основная часть проекта уже готова и не меняется, правятся только мелкие ошибки и делаются незначительные доработки. Конечно же людям, особенно имеющим какие-то амбиции, не хочется терять время на “мертвые” проекты, им скучно, они теряют квалификацию и, соответственно, свою цену на рынке.
Просто надоедает проект, все уже знакомо, хочется выйти за границы комфорта. Конечно, выход из зоны комфорта помогают росту и развитию разработчика.Конечно, выход из зоны комфорта помогают росту и развитию разработчика. Однако, можно продолжать развиваться и будучи на уже знакомом проекте, мы разбираем как это можно сделать в нашем продукте по борьбе с рутиной. Учитесь этому, если вы разработчик, реже придется менять работу и меньше будете терять время, пока находитесь на уже знакомом проекте. Мотивируйте к использованию этих подходов своих подчиненных, если вы руководитель, это поможет уменьшить текучку.
Менее однозначные проблемы
Дальше пойдем к менее однозначным пунктам.
В проекте все налажено включая процессы. Не смотря на то, что все будет идти понятно и предсказуемо, и удастся избежать многих проблем, части людей будет скучно или сложно встраиваться в такие системы.
Проекты на стадии активного роста и развития. На самом деле, многие говорят, что им такой опыт интересен, но, по факту, большинство не готово взять на себя ответственность за настройку даже малейших вещей, будь то выбор единой библиотеки (не просто мне нравится, а провести анализ и переработать какой-то кусок в пром по правилам команды и показать результаты), до запуска тестов в пайплайне и т.д. Люди буду говорить, что да, вот хочется, чтобы все росло и развивалось, но только чтоб нам ничего делать было не надо. В итоге, выгорание идет от того, что многое сделано не оптимально, но тут правильный настрой в том, чтобы участвовать в процессе самим.
Нет роста. В целом это реально может быть проблемой, и что не делаешь и не просишь, роста тебе не будет. Но нередки случаи, когда ты хочешь постоянные повышения за одну и туже работу (даже не индексации а именно повышения), так не бывает. Для повышений нужно делать что-то сверх своей работы и это надо согласовывать с руководством.
Максим Шаламов
#советы #руководителю #разработчику
Что мешает хорошим технарям стать руководителями?
Не смотря на мой уже немалый опыт в росте лидов и руководителей более высокого уровня, получается далеко не всегда. Многие по тем или иным причинам не справляются. Причин на самом деле много (если статья зайдет, то сделаю обзор по основным), но хотел бы остановиться на одной, через которую проходят все инженеры, которых я знаю.
Начну с себя. Когда я развивался, как разработчик, для меня было очень важно умение погружаться в задачу и концентрироваться на ней. Это то, что многие называют состоянием “потока”. Одна из причин, по которой у меня хорошо получалось, это то, что я мог по 3-4 часа работать непрерывно, а в целом по дню выдавать до 7-8 часов именно написания кода. Делая отступление в сторону, не сильно рекомендую так делать, весьма выматываюший режим. Это была одной из причин, по которым я обычно успевал сделать очень много. И я привык так работать.
Но, когда я стал двигаться к руководящим позициям, оказалось, что у тебя много задач, требующих внимания. И, если ты сфокусируешься только на одной, да, ты сделаешь ее, но провалишь другие и, в целом, это будет провалом.
Теперь новой реальностью стало быстрое переключение между большим количеством задач. Да, многие ты передаешь кому-то, но нужно как минимум понять, что хотят и кому передать задачу, иначе дело может застопориться. И тебе нужно найти время на небольшое количество задач, где нужно погружение. Небольшое - это снова больше, чем один. В итоге моя сильная сторона, как разработчика, мешала мне в этом.
К чему все это я? С этим сталкиваются все мои ребята. Очень тяжело дается переход к такому формату задач. И людей прямо за уши приходится оттаскивать от погружения в конкретную задачу, к формату работы со всем пулом задач. Это дается через боль и люди очень тяжело выходят из зоны комфорта. Это и не хорошо и не плохо это надо пережить.
В итоге, многие просто предпочитают не менять подход и как лиды не раскрываются. У меня такие ребята возвращаются к своим привычным обязанностям. В целом, это говорит о том, что новая должность требует новых навыков и подходов.
Больше о конкретных навыках руководителя команды, вы можете найти в моем учебнике для руководителей “Тимлид: базовый уровень”. В нем, я разобрал еще одну из задач, с которой большинство даже опытных руководителей не справляется - делегирование. И конечно же все основные моменты, с которыми придется столкнуться на этой должности.
Максим Шаламов
#руководителю
Не смотря на мой уже немалый опыт в росте лидов и руководителей более высокого уровня, получается далеко не всегда. Многие по тем или иным причинам не справляются. Причин на самом деле много (если статья зайдет, то сделаю обзор по основным), но хотел бы остановиться на одной, через которую проходят все инженеры, которых я знаю.
Начну с себя. Когда я развивался, как разработчик, для меня было очень важно умение погружаться в задачу и концентрироваться на ней. Это то, что многие называют состоянием “потока”. Одна из причин, по которой у меня хорошо получалось, это то, что я мог по 3-4 часа работать непрерывно, а в целом по дню выдавать до 7-8 часов именно написания кода. Делая отступление в сторону, не сильно рекомендую так делать, весьма выматываюший режим. Это была одной из причин, по которым я обычно успевал сделать очень много. И я привык так работать.
Но, когда я стал двигаться к руководящим позициям, оказалось, что у тебя много задач, требующих внимания. И, если ты сфокусируешься только на одной, да, ты сделаешь ее, но провалишь другие и, в целом, это будет провалом.
Теперь новой реальностью стало быстрое переключение между большим количеством задач. Да, многие ты передаешь кому-то, но нужно как минимум понять, что хотят и кому передать задачу, иначе дело может застопориться. И тебе нужно найти время на небольшое количество задач, где нужно погружение. Небольшое - это снова больше, чем один. В итоге моя сильная сторона, как разработчика, мешала мне в этом.
К чему все это я? С этим сталкиваются все мои ребята. Очень тяжело дается переход к такому формату задач. И людей прямо за уши приходится оттаскивать от погружения в конкретную задачу, к формату работы со всем пулом задач. Это дается через боль и люди очень тяжело выходят из зоны комфорта. Это и не хорошо и не плохо это надо пережить.
В итоге, многие просто предпочитают не менять подход и как лиды не раскрываются. У меня такие ребята возвращаются к своим привычным обязанностям. В целом, это говорит о том, что новая должность требует новых навыков и подходов.
Больше о конкретных навыках руководителя команды, вы можете найти в моем учебнике для руководителей “Тимлид: базовый уровень”. В нем, я разобрал еще одну из задач, с которой большинство даже опытных руководителей не справляется - делегирование. И конечно же все основные моменты, с которыми придется столкнуться на этой должности.
Максим Шаламов
#руководителю
Допустим ли микроменеджмент? Какие последствия?
Начнем с определения, которое я возьму из Википедии, чтобы не было расхождений. В бизнесе микроменеджмент — это стиль управления персоналом, при котором руководство использует чрезмерный и постоянный контроль над сотрудниками, не допуская никакой самостоятельности в принятии решений.
Нужно ли такое бывает в реальности? Бывают ли ситуации, где это работает? Да. Приходя в новые команды/отделы/компании, которые работают неэффективно, пока идет процесс перестройки и обучения под новые требования, часто приходится влазить в проекты и процессы и диктовать, что делать, пока люди учатся. Такие меры могут давать положительный эффект только на короткой дистанции. По моему опыту, выведение из кризисов проектов и команд начинается с этого, но не должно на этом останавливаться.
Основной проблемой такого подхода, я вижу убийство мотивации и замыкание всего на себя. Убийство мотивации влечет за собой то, что вы будете окружены вялыми и безинициативными сотрудниками. Их производительность будет низкой, любые изменения и процессы будут внедряться из под палки. Ожидать, что они приложат усилие для улучшения компании или проекта довольно глупо. Более того, такие люди потеряют понимание возможностей к росту и мотивации, и те, кто чего-то хотят покинут компанию. Останутся самые слабые и пассивные. Сложные проекты и амбициозные цели с такой командой будут не для вас.
Замыкание всего на себя повлечет вашу перегрузку. Медленную реакцию на любые проблемы и изменения. И вы все должны будете придумывать и решать сами. Людям вы либо не доверите, либо уже ушли все, кто мог бы думать сам.
В целом, старайтесь избегать микроменеджмента, используйте его только в крайнем случае, как я писал в начале. В остальном, он принесет больше минусов, чем плюсов.
Максим Шаламов
#советы #руководителю
Начнем с определения, которое я возьму из Википедии, чтобы не было расхождений. В бизнесе микроменеджмент — это стиль управления персоналом, при котором руководство использует чрезмерный и постоянный контроль над сотрудниками, не допуская никакой самостоятельности в принятии решений.
Нужно ли такое бывает в реальности? Бывают ли ситуации, где это работает? Да. Приходя в новые команды/отделы/компании, которые работают неэффективно, пока идет процесс перестройки и обучения под новые требования, часто приходится влазить в проекты и процессы и диктовать, что делать, пока люди учатся. Такие меры могут давать положительный эффект только на короткой дистанции. По моему опыту, выведение из кризисов проектов и команд начинается с этого, но не должно на этом останавливаться.
Основной проблемой такого подхода, я вижу убийство мотивации и замыкание всего на себя. Убийство мотивации влечет за собой то, что вы будете окружены вялыми и безинициативными сотрудниками. Их производительность будет низкой, любые изменения и процессы будут внедряться из под палки. Ожидать, что они приложат усилие для улучшения компании или проекта довольно глупо. Более того, такие люди потеряют понимание возможностей к росту и мотивации, и те, кто чего-то хотят покинут компанию. Останутся самые слабые и пассивные. Сложные проекты и амбициозные цели с такой командой будут не для вас.
Замыкание всего на себя повлечет вашу перегрузку. Медленную реакцию на любые проблемы и изменения. И вы все должны будете придумывать и решать сами. Людям вы либо не доверите, либо уже ушли все, кто мог бы думать сам.
В целом, старайтесь избегать микроменеджмента, используйте его только в крайнем случае, как я писал в начале. В остальном, он принесет больше минусов, чем плюсов.
Максим Шаламов
#советы #руководителю
Как я выбираю руководителей
Я уже рассказывал, на что я смотрю на собеседовании. Но там не поднималась отдельно тема руководителей, которых тоже нужно нанимать. Для простоты я не буду особенно вдаваться в градацию и акценты в зависимости от этого. К руководителям, в данном контексте, относятся и тимлиды и лидеры компетенций отделов (например лидеры направления Python, Go, JS и т.д.).
Умение излагать мысли
Первое, на что я смотрю, это умение излагать свои мысли ясно и четко. Такие позиции подразумевают тесное общение с людьми и чем выше, тем больше. Поэтому, если человек не умеет внятно излагать свои мысли, это большой минус.
Прошлый опыт и причины решений
Дальше я смотрю на опыт человека, причем мы не просто зачитываем резюме, а человек рассказывает о своей работе. Меня интересуют решения, которые он принимал и мотивация, с который он это делал. Если человек не может объяснить зачем он делал или внедрял что-то, то для руководителя это огромный минус. Если какие-то вещи спускались сверху, но были неразумными, то обсуждаем, что он делал в этих ситуациях.
Умение себя подать
Дальше я смотрю насколько человек умеет себя подать и расположить к себе. С какой командой он сможет работать, а с какой нет. В идеале, человек должен мочь возглавить любую команду, но обычно это не так и это становится ограничением при выборе.
Какая мотивация
Очень важно для меня понять мотивацию человека. Причем не только по работе, но и по желанию быть руководителем. Если это то, что тебе нравится и в чем ты хочешь развиваться, то это хорошо. А если так вышло, получилось и денег чуть больше платят, то мне этой мотивации не достаточно.
Практические вопросы
После этого я прошу рассказать человека, как он хотел бы организовать работу своей команды / направления, что бы он делал, как бы проверял результат, что важно, а что нет. В основном я слушаю, после чего задаю вопросы для уточнения (например: “а как бы фиксировали цели?”, “какими шагами бы шли к ее выполнению?” и т.д.). На этом этапе мне важно увидеть, что человек понимает свою позицию. Что он расскажет и о целях и о работе с людьми, а главное о том, как все сделать прозрачно для руководства и подчиненных. Этот этап для меня самый важный, потому что предыдущих пунктов недостаточно. Если говорить о человеке на вырост, то я с большей вероятностью буду растить кого-то внутри. Нанимая руководителя, хочется получить усиление сразу, а не в перспективе. Хотя бывают и исключения.
В целом, как и в любом деле, опирайтесь на свои потребности и свое понимание задач и позиций. А идя на собеседование, помните, что главное это хороший и позитивный настрой.
Если хотите лучше подготовиться к подобному собеседованию, то советую посмотреть мой учебник для тимлидов. Там я разобрал все основы работы с командой, которым учу своих собственных подчиненных.
Максим Шаламов
#руководителю
Я уже рассказывал, на что я смотрю на собеседовании. Но там не поднималась отдельно тема руководителей, которых тоже нужно нанимать. Для простоты я не буду особенно вдаваться в градацию и акценты в зависимости от этого. К руководителям, в данном контексте, относятся и тимлиды и лидеры компетенций отделов (например лидеры направления Python, Go, JS и т.д.).
Умение излагать мысли
Первое, на что я смотрю, это умение излагать свои мысли ясно и четко. Такие позиции подразумевают тесное общение с людьми и чем выше, тем больше. Поэтому, если человек не умеет внятно излагать свои мысли, это большой минус.
Прошлый опыт и причины решений
Дальше я смотрю на опыт человека, причем мы не просто зачитываем резюме, а человек рассказывает о своей работе. Меня интересуют решения, которые он принимал и мотивация, с который он это делал. Если человек не может объяснить зачем он делал или внедрял что-то, то для руководителя это огромный минус. Если какие-то вещи спускались сверху, но были неразумными, то обсуждаем, что он делал в этих ситуациях.
Умение себя подать
Дальше я смотрю насколько человек умеет себя подать и расположить к себе. С какой командой он сможет работать, а с какой нет. В идеале, человек должен мочь возглавить любую команду, но обычно это не так и это становится ограничением при выборе.
Какая мотивация
Очень важно для меня понять мотивацию человека. Причем не только по работе, но и по желанию быть руководителем. Если это то, что тебе нравится и в чем ты хочешь развиваться, то это хорошо. А если так вышло, получилось и денег чуть больше платят, то мне этой мотивации не достаточно.
Практические вопросы
После этого я прошу рассказать человека, как он хотел бы организовать работу своей команды / направления, что бы он делал, как бы проверял результат, что важно, а что нет. В основном я слушаю, после чего задаю вопросы для уточнения (например: “а как бы фиксировали цели?”, “какими шагами бы шли к ее выполнению?” и т.д.). На этом этапе мне важно увидеть, что человек понимает свою позицию. Что он расскажет и о целях и о работе с людьми, а главное о том, как все сделать прозрачно для руководства и подчиненных. Этот этап для меня самый важный, потому что предыдущих пунктов недостаточно. Если говорить о человеке на вырост, то я с большей вероятностью буду растить кого-то внутри. Нанимая руководителя, хочется получить усиление сразу, а не в перспективе. Хотя бывают и исключения.
В целом, как и в любом деле, опирайтесь на свои потребности и свое понимание задач и позиций. А идя на собеседование, помните, что главное это хороший и позитивный настрой.
Если хотите лучше подготовиться к подобному собеседованию, то советую посмотреть мой учебник для тимлидов. Там я разобрал все основы работы с командой, которым учу своих собственных подчиненных.
Максим Шаламов
#руководителю
"Почему меня не уважают?"
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Недоступен - не решаешь
Сегодня поделюсь очень короткой, но от этого не менее важной мыслью. Много проблем у начинающих лидов бывает с ситуациями, когда они хотят стать точкой входа по изменениям в команде. Чтобы, если меняются требования, это не расползалась по людям, а собиралось и фильтровалось в них. Идея правильная и они даже могут убедить начать так делать. Но все ломается, если вы не будете доступны. То есть, если нужно обсудить изменения, а вы выпадаете на день, два, три, то конечно никто через вас работать не будет. Это касается любых коммуникаций. Хотите, чтобы работали через вас, в оговоренное время или по понятному сценарию (например по выставленным в свободные слоты встречам), - вы всегда доступны, подключаетесь и вовлечены в процесс. Иначе это работать не будет.
Максим Шаламов
#руководителю
Сегодня поделюсь очень короткой, но от этого не менее важной мыслью. Много проблем у начинающих лидов бывает с ситуациями, когда они хотят стать точкой входа по изменениям в команде. Чтобы, если меняются требования, это не расползалась по людям, а собиралось и фильтровалось в них. Идея правильная и они даже могут убедить начать так делать. Но все ломается, если вы не будете доступны. То есть, если нужно обсудить изменения, а вы выпадаете на день, два, три, то конечно никто через вас работать не будет. Это касается любых коммуникаций. Хотите, чтобы работали через вас, в оговоренное время или по понятному сценарию (например по выставленным в свободные слоты встречам), - вы всегда доступны, подключаетесь и вовлечены в процесс. Иначе это работать не будет.
Максим Шаламов
#руководителю
“Почему меня не слушают, я же начальник”
У ряда руководителей можно услышать о проблемах с тем, что их не слушаются и/или не воспринимают. Причем смена команд и работы им не сильно помогает. Не могу сказать, что обладаю большой выборкой, но есть один момент, на который я бы обращал внимание. И как сотруднику при оценке руководителя, и как руководителю для понимания, как тебя воспринимают.
В чем проблема
Смысл проблемы в том, что у большинства руководителей их жалоба звучит примерно как “он меня не послушал, а ведь я начальник”. Я конечно согласен, что субординация важна, но не всегда слов “я начальник” достаточно, чтобы что-то случилось или начало делаться, как вы хотите. Давайте разберемся по частям с этой проблемой.
Самое простое, часто люди не понимают, что и зачем вы хотите, поэтому они либо спорят, либо делают все, чтобы не брать в работу вашу задачу. Поэтому всегда найдите время объяснить, зачем вы что-то требуете. Например, “если мы не сделаем эту задачу, отложив текущие, то все лишимся премий”, лучше чем “бросайте фигню, которой занимаетесь, и все силы бросайте на эту задачу”. Если задача пришла сверху и вы сами не до конца понимаете ситуацию, я считаю, что лучше так и передать своим подчиненным. Это лучше, чем они будут думать, что вы просто не нашли времени для донесения информации или посчитали себя выше общения с ними.
Второе, подача авторитета с точки зрения должности работает не на всех, а у части людей вызывает отрицательные эмоции вплоть до неподвластной им необходимости мешать вам. Сама по себе должность не говорит о компетентности в целом, или по крайней мере в текущей ситуации.
Как лучше делать
Лично я всегда иду от другого и люди, которых я считаю хорошими руководителями, обычно делают также. Я иду либо от ответственности, либо от знания. И обычно, когда я слушаю подобные возмущения от руководителей, которых я считаю хорошими, они звучат примерно как “мне не важно, что он считает. Отвечать мне, поэтому мы сделали, как я сказал”. Сама по себе подача себя через ответственность лично у меня вызывает больше понимания. Я понимаю, что за каждый большой провал сначала ответит мой руководитель, а потом, если считает правильным он сам, вызовет отвечать меня. И он это понимает. Поэтому глобальных проблем с принятием права последнего слова у меня нет. Так же, как если ты признанный у себя в команде эксперт, то можно идти от того, что ты точно знаешь и берешь ответственность на себя. Знание и принятие ответственности тоже имеет вес, но это скорее хорошо работает в среде тех, кто вас давно знает.
В заключении, для упрощения взаимодействий, когда вы хотите единолично принять решение, идите от пояснения причин и фиксирования принятия ответственности за решения.
Максим Шаламов
#руководителю #советы
У ряда руководителей можно услышать о проблемах с тем, что их не слушаются и/или не воспринимают. Причем смена команд и работы им не сильно помогает. Не могу сказать, что обладаю большой выборкой, но есть один момент, на который я бы обращал внимание. И как сотруднику при оценке руководителя, и как руководителю для понимания, как тебя воспринимают.
В чем проблема
Смысл проблемы в том, что у большинства руководителей их жалоба звучит примерно как “он меня не послушал, а ведь я начальник”. Я конечно согласен, что субординация важна, но не всегда слов “я начальник” достаточно, чтобы что-то случилось или начало делаться, как вы хотите. Давайте разберемся по частям с этой проблемой.
Самое простое, часто люди не понимают, что и зачем вы хотите, поэтому они либо спорят, либо делают все, чтобы не брать в работу вашу задачу. Поэтому всегда найдите время объяснить, зачем вы что-то требуете. Например, “если мы не сделаем эту задачу, отложив текущие, то все лишимся премий”, лучше чем “бросайте фигню, которой занимаетесь, и все силы бросайте на эту задачу”. Если задача пришла сверху и вы сами не до конца понимаете ситуацию, я считаю, что лучше так и передать своим подчиненным. Это лучше, чем они будут думать, что вы просто не нашли времени для донесения информации или посчитали себя выше общения с ними.
Второе, подача авторитета с точки зрения должности работает не на всех, а у части людей вызывает отрицательные эмоции вплоть до неподвластной им необходимости мешать вам. Сама по себе должность не говорит о компетентности в целом, или по крайней мере в текущей ситуации.
Как лучше делать
Лично я всегда иду от другого и люди, которых я считаю хорошими руководителями, обычно делают также. Я иду либо от ответственности, либо от знания. И обычно, когда я слушаю подобные возмущения от руководителей, которых я считаю хорошими, они звучат примерно как “мне не важно, что он считает. Отвечать мне, поэтому мы сделали, как я сказал”. Сама по себе подача себя через ответственность лично у меня вызывает больше понимания. Я понимаю, что за каждый большой провал сначала ответит мой руководитель, а потом, если считает правильным он сам, вызовет отвечать меня. И он это понимает. Поэтому глобальных проблем с принятием права последнего слова у меня нет. Так же, как если ты признанный у себя в команде эксперт, то можно идти от того, что ты точно знаешь и берешь ответственность на себя. Знание и принятие ответственности тоже имеет вес, но это скорее хорошо работает в среде тех, кто вас давно знает.
В заключении, для упрощения взаимодействий, когда вы хотите единолично принять решение, идите от пояснения причин и фиксирования принятия ответственности за решения.
Максим Шаламов
#руководителю #советы
Да не заботитесь вы о команде!
Я часто слышу от ребят: “я забочусь о команде”, ”я переживаю о проекте” и тому подобное. А потом идет какое-то “но” или еще что-то, что человеку мешает. Сейчас я в разговорах концентрируюсь на первой части и всегда спрашиваю, а что ты сделал в рамках своей заботы / беспокойства / ответственности?
Заботишься о выгорании команды? А что сделано для улучшения планирования?
Заботишься о качестве проекта? А что сделано для улучшения этого качества?
И т.д. и т.п. Моя задача не утопить людей, а понять одну важную вещь: готовы ли они действовать или это просто слова и оправдание. Я могу им помочь, найти время, отстоять сроки и т.д. Но они сами должны этим заниматься и брать ответственность, иначе я просто вовремя не узнаю о проблеме.
Хотите разгрузить команду? Берите меньше задач, требуйте делать лучше постановку задач, работайте с ожиданиями - совершайте действия, чтобы исправить то, что вас беспокоит. Я готов помочь своим ребятам на каждом этапе, но только тогда, когда они заранее проанализировали, поняли, где проблемы, и тогда уже пришли за помощью, или они решают проблему, но их начали продавливать и им нужна помощь отстоять позиции. Сидеть и ждать, что за тебя все сделают, не сработает. Заботиться и команде, проекте и прочем, и ничего не делать для улучшения - не забота, это удобное оправдание для своей совести.
Максим Шаламов
#руководителю
Я часто слышу от ребят: “я забочусь о команде”, ”я переживаю о проекте” и тому подобное. А потом идет какое-то “но” или еще что-то, что человеку мешает. Сейчас я в разговорах концентрируюсь на первой части и всегда спрашиваю, а что ты сделал в рамках своей заботы / беспокойства / ответственности?
Заботишься о выгорании команды? А что сделано для улучшения планирования?
Заботишься о качестве проекта? А что сделано для улучшения этого качества?
И т.д. и т.п. Моя задача не утопить людей, а понять одну важную вещь: готовы ли они действовать или это просто слова и оправдание. Я могу им помочь, найти время, отстоять сроки и т.д. Но они сами должны этим заниматься и брать ответственность, иначе я просто вовремя не узнаю о проблеме.
Хотите разгрузить команду? Берите меньше задач, требуйте делать лучше постановку задач, работайте с ожиданиями - совершайте действия, чтобы исправить то, что вас беспокоит. Я готов помочь своим ребятам на каждом этапе, но только тогда, когда они заранее проанализировали, поняли, где проблемы, и тогда уже пришли за помощью, или они решают проблему, но их начали продавливать и им нужна помощь отстоять позиции. Сидеть и ждать, что за тебя все сделают, не сработает. Заботиться и команде, проекте и прочем, и ничего не делать для улучшения - не забота, это удобное оправдание для своей совести.
Максим Шаламов
#руководителю
4 признака, что тебе не стать руководителем
Мы тут с Максимом разговорились и подсчитали, что примерно 40% ребят в его команде, которые пробуют стать руководителями, не справляются с новой позицией и возвращаются к разработке. Я попросила Максима назвать главные причины, которые мешают его подчиненным перестроится на работу управленцем. Четыре самых главных из них вы найдете в видео:
https://youtu.be/fiq26llSdyQ
#руководителю
Мы тут с Максимом разговорились и подсчитали, что примерно 40% ребят в его команде, которые пробуют стать руководителями, не справляются с новой позицией и возвращаются к разработке. Я попросила Максима назвать главные причины, которые мешают его подчиненным перестроится на работу управленцем. Четыре самых главных из них вы найдете в видео:
https://youtu.be/fiq26llSdyQ
#руководителю
YouTube
Топ-4 признака, что тебе никогда не стать руководителем
Плюшки в описании ниже ↓
Мы с нашим экспертом СТО Максимом Шаламовым собрали топ-4 признаков, что человеку не суждено стать руководителем.
Инструкция, как получить должность тимлида: https://t.me/ITbesedka/69
Учебник "Тимлид: базовый уровень": https://oros…
Мы с нашим экспертом СТО Максимом Шаламовым собрали топ-4 признаков, что человеку не суждено стать руководителем.
Инструкция, как получить должность тимлида: https://t.me/ITbesedka/69
Учебник "Тимлид: базовый уровень": https://oros…
Как я понял, что необходимо растить людей
Есть немало споров нужно или нет растить людей, окупается это или нет. Давайте я расскажу о своем опыте и потом сделаю вывод. Мне очень повезло и я нашел людей, с которыми мы на одной волне и работаем уже лет 8 вместе. Это очень помогает браться за самые сложные задачи и решать их.
Было время, когда мы втроем запускали проекты, делая все руками с минимальной помощью от остальных участников команды. Проекты росли и становились сложнее и интереснее. Стало понятно, что мы не можем сделать все, а с рынка взять много готовых мотивированных профессионалов не получится. Так мы начали инвестировать в людей и получили отличные результаты.
С дальнейшим ростом развития под собой только исполнителей стало недостаточно, все управление в себя тоже не завернешь и ты начинаешь растить руководителей. Кто искал лидов и позиции выше понимает насколько мало готовых людей ищет работу, учить точно придется.
Поэтому я считаю, что вопроса нужно ли учить людей даже не стоит, учить людей придется в любом случае. Помимо понятной пользы для вас, есть еще немаловажные аспекты. Вы получите более низкую текучку и более мотивированных людей. Потому что все любят, когда их ценят, в них верят и в них инвестируют. Конечно люди будут уходить, но в целом вы будете закрывать свои потребности, плюс есть большая вероятность, что эти люди позже снова захотят с вами поработать.
Больше о росте под собой людей, я писал в своем учебнике для тимлидов. Также, как и о делегировании полномочий, без которого при росте команды тоже не обойтись.
Максим Шаламов
#руководителю
Есть немало споров нужно или нет растить людей, окупается это или нет. Давайте я расскажу о своем опыте и потом сделаю вывод. Мне очень повезло и я нашел людей, с которыми мы на одной волне и работаем уже лет 8 вместе. Это очень помогает браться за самые сложные задачи и решать их.
Было время, когда мы втроем запускали проекты, делая все руками с минимальной помощью от остальных участников команды. Проекты росли и становились сложнее и интереснее. Стало понятно, что мы не можем сделать все, а с рынка взять много готовых мотивированных профессионалов не получится. Так мы начали инвестировать в людей и получили отличные результаты.
С дальнейшим ростом развития под собой только исполнителей стало недостаточно, все управление в себя тоже не завернешь и ты начинаешь растить руководителей. Кто искал лидов и позиции выше понимает насколько мало готовых людей ищет работу, учить точно придется.
Поэтому я считаю, что вопроса нужно ли учить людей даже не стоит, учить людей придется в любом случае. Помимо понятной пользы для вас, есть еще немаловажные аспекты. Вы получите более низкую текучку и более мотивированных людей. Потому что все любят, когда их ценят, в них верят и в них инвестируют. Конечно люди будут уходить, но в целом вы будете закрывать свои потребности, плюс есть большая вероятность, что эти люди позже снова захотят с вами поработать.
Больше о росте под собой людей, я писал в своем учебнике для тимлидов. Также, как и о делегировании полномочий, без которого при росте команды тоже не обойтись.
Максим Шаламов
#руководителю
Сменить работу не значит решить проблему
До первого места работы, где я проработал долго и плодотворно, я сменил 9 компаний, нигде не проработав и года. Везде, в целом, были одни и те же проблемы: сложности с бизнесом, сложности с ростом, мало интересных задач, повышения происходят не так, как ты хочешь и ждешь. В какой-то момент я понял, что как специалист я за счет этого расширил кругозор, но я не расту вглубь, как по технике, так и по софт части. И в целом я понял, что работы меняются, а я нет. Это понимание дало мне огромный толчок, позволило получить интересные проекты, рост, собрать команду, с которой мне было интересно работать и главное теперь это воспроизводится на новых местах, потому что проблемы везде похожие, а адаптироваться и расти нужно именно тебе. Тогда ты сможешь решить многое из проблем.
Собственно к чему это все? Многие бегают с работы на работу и каждый раз попадают в одни и те же проблемы. В итоге, удовлетворенность от работы на любом месте низкая, карьера идет не так, как хочется. Виноваты все вокруг, пойду вон к тем, там все по-другому. На самом деле, чтобы прийти к чему-то другому, нужно поменять себя. Тогда вы будете выбирать коллег и компании по-другому, смотреть на другие вещи и сможете решать типовые проблемы. А решать проблемы придется всегда, на любой позиции. Повышения, интересные задачи, новые вызовы, зоны роста - все это нужно уметь стабильно получать, уметь где-то подождать, а где-то с опытом понимать, что твоих сил изменить компанию недостаточно и тогда действительно идти дальше.
Главное не заниматься самообманом, а начинать поиск проблемы с себя, тогда ты будешь и расти, и лучше понимать, как получить желаемое. Если вы решили для себя, что расти и развиваться самому это ваш вариант, то посмотрите наш небольшой курс по борьбе с рутиной. Мы там как раз описали подходы, которые вырабатывают привычку к постоянному самосовершенствованию.
Максим Шаламов
#советы #разработчику #руководителю
До первого места работы, где я проработал долго и плодотворно, я сменил 9 компаний, нигде не проработав и года. Везде, в целом, были одни и те же проблемы: сложности с бизнесом, сложности с ростом, мало интересных задач, повышения происходят не так, как ты хочешь и ждешь. В какой-то момент я понял, что как специалист я за счет этого расширил кругозор, но я не расту вглубь, как по технике, так и по софт части. И в целом я понял, что работы меняются, а я нет. Это понимание дало мне огромный толчок, позволило получить интересные проекты, рост, собрать команду, с которой мне было интересно работать и главное теперь это воспроизводится на новых местах, потому что проблемы везде похожие, а адаптироваться и расти нужно именно тебе. Тогда ты сможешь решить многое из проблем.
Собственно к чему это все? Многие бегают с работы на работу и каждый раз попадают в одни и те же проблемы. В итоге, удовлетворенность от работы на любом месте низкая, карьера идет не так, как хочется. Виноваты все вокруг, пойду вон к тем, там все по-другому. На самом деле, чтобы прийти к чему-то другому, нужно поменять себя. Тогда вы будете выбирать коллег и компании по-другому, смотреть на другие вещи и сможете решать типовые проблемы. А решать проблемы придется всегда, на любой позиции. Повышения, интересные задачи, новые вызовы, зоны роста - все это нужно уметь стабильно получать, уметь где-то подождать, а где-то с опытом понимать, что твоих сил изменить компанию недостаточно и тогда действительно идти дальше.
Главное не заниматься самообманом, а начинать поиск проблемы с себя, тогда ты будешь и расти, и лучше понимать, как получить желаемое. Если вы решили для себя, что расти и развиваться самому это ваш вариант, то посмотрите наш небольшой курс по борьбе с рутиной. Мы там как раз описали подходы, которые вырабатывают привычку к постоянному самосовершенствованию.
Максим Шаламов
#советы #разработчику #руководителю
Почему не надо 10 лет работать разработчиком, чтобы стать руководителем разработки?
Есть популярное мнение, что для того, чтобы стать руководителем в команде разработчиков, нужно стать мега спецом в своей области, потратив не менее 10 лет. И только тогда уже думать об управлении. В общем случае это полный бред.
Погружение в специфику нужно
Давайте сделаю отступление, что в любом случае, став руководителем команды, нужно какое-то погружение в специфику работы и проекта, понимать общие вещи и способы решать проблемы. Есть места, где просто не выделяют отдельно такую роль / позицию, и там вариантов вообще нет. Это полезно, но не будет критичным.
Управление – другая профессия
Давайте я объясню, что не так в целом с мнением, что сначала нужно отработать 10 лет в разработке. Первое, управление командой это просто другая работа. Руководить кем-то или чем-то это не тоже самое, что выполнять задачи в этой же сфере. Поэтому хоть 50 лет проведи разработчиком, руководить ты от этого не научишься.
Все технологии отдела выучить невозможно
У нас сейчас тенденция к полнофункциональным командам, то есть там будут специалисты разных областей знаний. Никакой жизни не хватит все учить по 10 лет, да и остальное уже будет не актуально через 10 лет.
Продолжая прошлый пункт, часть знаний быстро теряет актуальность, а будучи лидом постоянно держать контекст и обновлять знания у вас не получится.
Углубление в технологии мешает раскрываться управленческим навыкам
Глубокое знание предмета, часто мешает людям раскрыться, как руководителям. Это кажется странным, но такое происходит постоянно. Это приводит к завышенным ожиданиям от подчиненных, постоянным попыткам сделать все самому (ну так же быстрее), постоянной печали, что накопленные навыки теряются (на первых этапах есть у всех).
Конечно знания не бывают лишними и то, что я пришел из разработки в управление мне очень помогает. Но я давно уже понял, что хороший инженер и хороший руководитель могут как сочетаться в одном человеке, так и быть взаимоисключающими. Поэтому надо понимать, что ваши технические знания вам пригодятся, но не настолько, чтобы это было ключевым. И да, под специфику вашей команды и проекта вам придется подтянуть знания, но не на уровне топ специалиста в любой отрасли нужной для проекта.
А что учить вместо 10 лет разработки?
Если хотите стать руководителем, то нужно набираться именно управленческих знаний. Как раз для таких случаев я писал свой учебник для начинающих руководителей технических команд, чтобы дать всю нужную начальную информацию разработчику, который решил перейти в управление, но еще не знает, как это сделать. Если задумываетесь об управлении, то берите учебник – не пожалеете.
Максим Шаламов
#разработчику #руководителю
Есть популярное мнение, что для того, чтобы стать руководителем в команде разработчиков, нужно стать мега спецом в своей области, потратив не менее 10 лет. И только тогда уже думать об управлении. В общем случае это полный бред.
Погружение в специфику нужно
Давайте сделаю отступление, что в любом случае, став руководителем команды, нужно какое-то погружение в специфику работы и проекта, понимать общие вещи и способы решать проблемы. Есть места, где просто не выделяют отдельно такую роль / позицию, и там вариантов вообще нет. Это полезно, но не будет критичным.
Управление – другая профессия
Давайте я объясню, что не так в целом с мнением, что сначала нужно отработать 10 лет в разработке. Первое, управление командой это просто другая работа. Руководить кем-то или чем-то это не тоже самое, что выполнять задачи в этой же сфере. Поэтому хоть 50 лет проведи разработчиком, руководить ты от этого не научишься.
Все технологии отдела выучить невозможно
У нас сейчас тенденция к полнофункциональным командам, то есть там будут специалисты разных областей знаний. Никакой жизни не хватит все учить по 10 лет, да и остальное уже будет не актуально через 10 лет.
Продолжая прошлый пункт, часть знаний быстро теряет актуальность, а будучи лидом постоянно держать контекст и обновлять знания у вас не получится.
Углубление в технологии мешает раскрываться управленческим навыкам
Глубокое знание предмета, часто мешает людям раскрыться, как руководителям. Это кажется странным, но такое происходит постоянно. Это приводит к завышенным ожиданиям от подчиненных, постоянным попыткам сделать все самому (ну так же быстрее), постоянной печали, что накопленные навыки теряются (на первых этапах есть у всех).
Конечно знания не бывают лишними и то, что я пришел из разработки в управление мне очень помогает. Но я давно уже понял, что хороший инженер и хороший руководитель могут как сочетаться в одном человеке, так и быть взаимоисключающими. Поэтому надо понимать, что ваши технические знания вам пригодятся, но не настолько, чтобы это было ключевым. И да, под специфику вашей команды и проекта вам придется подтянуть знания, но не на уровне топ специалиста в любой отрасли нужной для проекта.
А что учить вместо 10 лет разработки?
Если хотите стать руководителем, то нужно набираться именно управленческих знаний. Как раз для таких случаев я писал свой учебник для начинающих руководителей технических команд, чтобы дать всю нужную начальную информацию разработчику, который решил перейти в управление, но еще не знает, как это сделать. Если задумываетесь об управлении, то берите учебник – не пожалеете.
Максим Шаламов
#разработчику #руководителю
Стрессоустойчивость правда так важна для руководителя?
Часто встречаю истории, что руководитель, получая негативную обратную связь, проблемы на проекте, проблемы с сотрудниками или какие-то подковерные игры, теряет аппетит, сон и настроение. В итоге: потеря мотивации, выгорание, увольнение. Такая ситуация большая проблема и большой вызов для любого руководителя. Всегда что-то идет не так, всегда кто-то не доволен, что-то ломается (можно дойти до состояния, когда работает как положено и все равно исключений будет много).
Любой руководитель должен учиться спокойно воспринимать проблемы и не закапывать в них себя и других. Вариться в негативе не решит проблем, принимать все слишком близко к сердцу не решит ваших проблем. Вы потратите много сил на нервы и не нужные конфликты, а ваш проект и команда нуждаются в вашей энергии, позитиве, времени и силах.
Нужно учиться не обращать внимания на проблемы и двигаться к своим целям. Это не значит, что вам плевать на проект или что вы не будете ничего делать. Это значит, что вы направите силы туда, где они нужны.
Направляйте силы в нужное русло, не пытайтесь винить себя за все проблемы, не изводите себя. Наметьте план и идите по нему, смотрите, что не получается и адаптируйтесь к ситуации.
Максима Шаламов
#руководителю
Часто встречаю истории, что руководитель, получая негативную обратную связь, проблемы на проекте, проблемы с сотрудниками или какие-то подковерные игры, теряет аппетит, сон и настроение. В итоге: потеря мотивации, выгорание, увольнение. Такая ситуация большая проблема и большой вызов для любого руководителя. Всегда что-то идет не так, всегда кто-то не доволен, что-то ломается (можно дойти до состояния, когда работает как положено и все равно исключений будет много).
Любой руководитель должен учиться спокойно воспринимать проблемы и не закапывать в них себя и других. Вариться в негативе не решит проблем, принимать все слишком близко к сердцу не решит ваших проблем. Вы потратите много сил на нервы и не нужные конфликты, а ваш проект и команда нуждаются в вашей энергии, позитиве, времени и силах.
Нужно учиться не обращать внимания на проблемы и двигаться к своим целям. Это не значит, что вам плевать на проект или что вы не будете ничего делать. Это значит, что вы направите силы туда, где они нужны.
Направляйте силы в нужное русло, не пытайтесь винить себя за все проблемы, не изводите себя. Наметьте план и идите по нему, смотрите, что не получается и адаптируйтесь к ситуации.
Максима Шаламов
#руководителю
Как правильно увольнять людей
Тема увольнений для большинства из нас сложна и болезненна. Я сам в первые разы испытывал большой дискомфорт и чувство вины. Это нормально. И даже спустя годы работы, этот процесс приносит только осадок, но по-другому и быть не может. Давайте поговорим о том, что важно при увольнениях на любой позиции. Если будет много реакций к посту, рассмотрим как определить, что человека надо увольнять.
Не тяните, сделаете только хуже
Первое и самое главное: увольнение нельзя затягивать. Если уж вы поняли, что с человеком нужно расстаться, то надо заниматься этим незамедлительно. Пока у вас не начились проблемы с другими сотрудниками и/или вашими целями. Многие пытаются бегать от этого как можно дольше, вдруг сам уйдет. Это неправильно, если время пришло, то займитесь этим.
Поймите в чем была ошибка
Второе, если человека нанимали вы или при вас, то увольнение человека это ошибка в найме или процесса адаптации и развития человека (если это не сокращение по финансовым причинам, когда просто уменьшается численность). Не нужно сильно загонять себя, нужно сесть и понять в чем была ошибка, что можно было сделать по-другому. Прийти к решению и начать делать по-другому. Ведите историю по причинам увольнений, чтобы убедится, что у вас идет работа над ошибками, что проблема не сохраняется.
Готовьтесь к конфликту заранее
Третье, увольнение это всегда неприятно, часто конфликтно. Примите это. Если только человек не собирался уже сам уходить, то приятного в этом ничего быть не может. Готовьтесь соответственно.
Объясните причины
Четвертое, готовьте обратную связь для человека. Уделите время, чтобы обьяснить свою мотивацию, разобрать проблемы. Вполне возможно расстаться с человеком нормально, чтобы он понял в чем проблема, даже если и не до конца принял.
Поговорите с командой
Пятое, помните о команде. Человек, которого вы увольняете, общается с кем-то еще из ваших сотрудников. Поэтому, по возможности, обсудите причины расставания и с командой, объясните, что было не так и как можно были избежать этого. Еще раз выровняйтесь по правилам и принципам, по которым вы работаете. Это очень важно и полезно, чтобы вам не внесли смуту и хаос в работу.
Расставайтесь нормально
Шестое, старайтесь расстаться нормально (если человек не перешел черту). Если решение принято и мотивация понятна, то надо точно расставаться, но, по возможности, это надо сделать без обид и конфликтов. Старайтесь быть конструктивным, терпеливым и внимательным. Это полезно для вас, репутации вашей команды и компании.
При увольнениях главное помнить, что нельзя тянуть и что люди не работают в вакууме, они работают в коллективе и при увольнении с коллективом тоже надо работать.
Больше о моих подходах в управлении командой, я рассказываю в своем учебнике для руководителей.
Максим Шаламов
#руководителю
Тема увольнений для большинства из нас сложна и болезненна. Я сам в первые разы испытывал большой дискомфорт и чувство вины. Это нормально. И даже спустя годы работы, этот процесс приносит только осадок, но по-другому и быть не может. Давайте поговорим о том, что важно при увольнениях на любой позиции. Если будет много реакций к посту, рассмотрим как определить, что человека надо увольнять.
Не тяните, сделаете только хуже
Первое и самое главное: увольнение нельзя затягивать. Если уж вы поняли, что с человеком нужно расстаться, то надо заниматься этим незамедлительно. Пока у вас не начились проблемы с другими сотрудниками и/или вашими целями. Многие пытаются бегать от этого как можно дольше, вдруг сам уйдет. Это неправильно, если время пришло, то займитесь этим.
Поймите в чем была ошибка
Второе, если человека нанимали вы или при вас, то увольнение человека это ошибка в найме или процесса адаптации и развития человека (если это не сокращение по финансовым причинам, когда просто уменьшается численность). Не нужно сильно загонять себя, нужно сесть и понять в чем была ошибка, что можно было сделать по-другому. Прийти к решению и начать делать по-другому. Ведите историю по причинам увольнений, чтобы убедится, что у вас идет работа над ошибками, что проблема не сохраняется.
Готовьтесь к конфликту заранее
Третье, увольнение это всегда неприятно, часто конфликтно. Примите это. Если только человек не собирался уже сам уходить, то приятного в этом ничего быть не может. Готовьтесь соответственно.
Объясните причины
Четвертое, готовьте обратную связь для человека. Уделите время, чтобы обьяснить свою мотивацию, разобрать проблемы. Вполне возможно расстаться с человеком нормально, чтобы он понял в чем проблема, даже если и не до конца принял.
Поговорите с командой
Пятое, помните о команде. Человек, которого вы увольняете, общается с кем-то еще из ваших сотрудников. Поэтому, по возможности, обсудите причины расставания и с командой, объясните, что было не так и как можно были избежать этого. Еще раз выровняйтесь по правилам и принципам, по которым вы работаете. Это очень важно и полезно, чтобы вам не внесли смуту и хаос в работу.
Расставайтесь нормально
Шестое, старайтесь расстаться нормально (если человек не перешел черту). Если решение принято и мотивация понятна, то надо точно расставаться, но, по возможности, это надо сделать без обид и конфликтов. Старайтесь быть конструктивным, терпеливым и внимательным. Это полезно для вас, репутации вашей команды и компании.
При увольнениях главное помнить, что нельзя тянуть и что люди не работают в вакууме, они работают в коллективе и при увольнении с коллективом тоже надо работать.
Больше о моих подходах в управлении командой, я рассказываю в своем учебнике для руководителей.
Максим Шаламов
#руководителю