Важность похвалы
Я уже давно работаю управленцем и чем выше поднимаюсь, тем больше вижу тенденцию к отсутствию похвалы в работе в принципе. Недавно у нас был тренинг, после которого мой руководитель говорил мне, что хвалить не видят смысла, когда рядом зрелая команда и управленцы, нужно фокусироваться на целях и проблемах, а достижение целей само по себе считается похвальным и правильным.
Не знаю правильно ли это в управлении руководителями, но с начинающими так точно нельзя. Да и с ребятами в команде это не приведет ни к чему хорошему. В роли начинающего я такой подход оценил какое-то время назад, сходив на пробные занятия в стрелковый клуб и на скалодром. Оба похода объединяли крайне вялые инструкторы, которые после каждого упражнения говорили “идем дальше” с каменными лицами. При этом не забывая указывать на ошибки, когда делаешь что-то неправильно. Не смотря на то, что я головой понимаю, как это работает, удовольствие от работы с такими инструкторами было крайне сомнительным. Сменив стрелковый клуб, кстати, и попав на позитивного, вовлекающего инструктора, умеющего подбадривать в процессе, я сходил просто прекрасно, получил кучу позитива и продолжу ходить именно к этим ребятам.
К чему это я все? А к тому, какой бы зрелой ни была ваша команда и собеседник, не забывайте хвалить человека за хорошую работу. Как минимум это будет позитивным подкреплением, что очень важно. Второе, человек поймет, что его работу ценят и видят. Забывая хвалить людей, вы ставите их в очень странное положение, когда нет достаточной обратной связи о их работе. Получается, что человека только все время ругают (потому что проблему нужно обсуждать и решать). Таким подходом вы легко можете демотивировать и человека, и команду. У людей сложится впечатление, что вы придираетесь к ним и не видите их работы, а главное не цените их. Джунам и стажерам вы вообще можете отбить желание заниматься данной профессией, сложив впечатление, что они только ошибаются и ничего не делают правильно.
Никогда не забывайте оценивать заслуги людей. Но и не тратьте похвалу, если человек ее не заслужил. Поставьте себя на место человека и вам будет проще понять его ощущения.
Максим Шаламов
#руководителю
Я уже давно работаю управленцем и чем выше поднимаюсь, тем больше вижу тенденцию к отсутствию похвалы в работе в принципе. Недавно у нас был тренинг, после которого мой руководитель говорил мне, что хвалить не видят смысла, когда рядом зрелая команда и управленцы, нужно фокусироваться на целях и проблемах, а достижение целей само по себе считается похвальным и правильным.
Не знаю правильно ли это в управлении руководителями, но с начинающими так точно нельзя. Да и с ребятами в команде это не приведет ни к чему хорошему. В роли начинающего я такой подход оценил какое-то время назад, сходив на пробные занятия в стрелковый клуб и на скалодром. Оба похода объединяли крайне вялые инструкторы, которые после каждого упражнения говорили “идем дальше” с каменными лицами. При этом не забывая указывать на ошибки, когда делаешь что-то неправильно. Не смотря на то, что я головой понимаю, как это работает, удовольствие от работы с такими инструкторами было крайне сомнительным. Сменив стрелковый клуб, кстати, и попав на позитивного, вовлекающего инструктора, умеющего подбадривать в процессе, я сходил просто прекрасно, получил кучу позитива и продолжу ходить именно к этим ребятам.
К чему это я все? А к тому, какой бы зрелой ни была ваша команда и собеседник, не забывайте хвалить человека за хорошую работу. Как минимум это будет позитивным подкреплением, что очень важно. Второе, человек поймет, что его работу ценят и видят. Забывая хвалить людей, вы ставите их в очень странное положение, когда нет достаточной обратной связи о их работе. Получается, что человека только все время ругают (потому что проблему нужно обсуждать и решать). Таким подходом вы легко можете демотивировать и человека, и команду. У людей сложится впечатление, что вы придираетесь к ним и не видите их работы, а главное не цените их. Джунам и стажерам вы вообще можете отбить желание заниматься данной профессией, сложив впечатление, что они только ошибаются и ничего не делают правильно.
Никогда не забывайте оценивать заслуги людей. Но и не тратьте похвалу, если человек ее не заслужил. Поставьте себя на место человека и вам будет проще понять его ощущения.
Максим Шаламов
#руководителю
Как использовать право вето для мотивации руководителей команд
Часто вижу вопрос, как повысить уверенность и вовлеченность своих сотрудников-руководителей. В нормальной структуре руководителей не должно быть слишком много, поэтому индивидуальный подход будет хорошим решением. Но если говорить о чем-то общем, то, на мой взгляд, очень важно дать человеку право принимать решения.
У меня очень простой подход: руководитель по определению может перекрыть любое решение своего подчиненного. На этом строится возможность выстраивания стратегии сверху и использование опыта (которого у руководителя в идеале должно быть много). И тут тем, кто это слышит в первый раз, начинает казаться, что я буду диктовать им по шагам каждый их рабочий день. На самом деле нет. У меня много работы и помимо этого, более того, я считаю, что человек на своем месте должен справляться с работой, либо покидать ее. Поэтому, если я диктую человеку что делать, то это либо новая ситуация для него или есть обстоятельства диктующие такое решение, либо ему пора задуматься над тем, как хорошо он делает свою работу.
Со своими ребятами я всегда стараюсь четко проговорить все детали, где я жду, что они будут решать проблему сами (сообщив мне результаты), а где они идут за согласованием (и даже тут идеально прийти с вариантами решения). Возможность принимать решения, самому решать проблемы и достигать результата очень мотивирует людей, ориентированных на результат и рост.
Тем, кто себя отлично проявляет, я даю право вето на ряд решений. Например, они могут сказать нет на найме кандидата, его переводе или увольнении, даже если я буду считать, что это стоит сделать. С правом вето надо быть очень аккуратным, это позволяет чувствовать себя максимально уверенно, но надо понимать, что не все ситуации подвластны нам и всегда требуется гибкость. Давайте такое только проверенным ребятам и очерчивайте границы. Тут есть важный момент - нельзя потом просто взять и проигнорировать вето своего сотрудника, вы обесцените это, как мотивацию и подорвете доверие к себе.
В заключении скажу, всегда делегируйте людям положенные им задачи, ищите тех, кто будет справляться, а не пытайтесь все проконтролировать сами. Помните, что в управление надо выдвигать тех, кто готов к ответственности и может давать результат.
Больше об управлении людьми, вы найдете в моем учебнике “Тимлид: базовый уровень”. В нем, помимо разбора всех основных умений руководителя команды, я добавил целую главу про делегирование полномочий.
Максим Шаламов
#руководителю
Часто вижу вопрос, как повысить уверенность и вовлеченность своих сотрудников-руководителей. В нормальной структуре руководителей не должно быть слишком много, поэтому индивидуальный подход будет хорошим решением. Но если говорить о чем-то общем, то, на мой взгляд, очень важно дать человеку право принимать решения.
У меня очень простой подход: руководитель по определению может перекрыть любое решение своего подчиненного. На этом строится возможность выстраивания стратегии сверху и использование опыта (которого у руководителя в идеале должно быть много). И тут тем, кто это слышит в первый раз, начинает казаться, что я буду диктовать им по шагам каждый их рабочий день. На самом деле нет. У меня много работы и помимо этого, более того, я считаю, что человек на своем месте должен справляться с работой, либо покидать ее. Поэтому, если я диктую человеку что делать, то это либо новая ситуация для него или есть обстоятельства диктующие такое решение, либо ему пора задуматься над тем, как хорошо он делает свою работу.
Со своими ребятами я всегда стараюсь четко проговорить все детали, где я жду, что они будут решать проблему сами (сообщив мне результаты), а где они идут за согласованием (и даже тут идеально прийти с вариантами решения). Возможность принимать решения, самому решать проблемы и достигать результата очень мотивирует людей, ориентированных на результат и рост.
Тем, кто себя отлично проявляет, я даю право вето на ряд решений. Например, они могут сказать нет на найме кандидата, его переводе или увольнении, даже если я буду считать, что это стоит сделать. С правом вето надо быть очень аккуратным, это позволяет чувствовать себя максимально уверенно, но надо понимать, что не все ситуации подвластны нам и всегда требуется гибкость. Давайте такое только проверенным ребятам и очерчивайте границы. Тут есть важный момент - нельзя потом просто взять и проигнорировать вето своего сотрудника, вы обесцените это, как мотивацию и подорвете доверие к себе.
В заключении скажу, всегда делегируйте людям положенные им задачи, ищите тех, кто будет справляться, а не пытайтесь все проконтролировать сами. Помните, что в управление надо выдвигать тех, кто готов к ответственности и может давать результат.
Больше об управлении людьми, вы найдете в моем учебнике “Тимлид: базовый уровень”. В нем, помимо разбора всех основных умений руководителя команды, я добавил целую главу про делегирование полномочий.
Максим Шаламов
#руководителю
Ловушка незаменимого
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Почему нельзя просто сорвать сроки? Какие могут быть последствия?
Бывают ситуации, когда невозможно уложиться в сроки. Правильное поведение в такой ситуации: выставить реальные сроки, всем озвучить и, пытаясь оптимизировать затраты, все же напоминать о реалиях на любых встречах. Так делать правильно хоть и часто сложно. Многие просто берут сроки, не споря (даже если можно было просто назвать реальные сроки без споров), и потом, по факту, говорят, что не укладываются в дедлайн. Меня часто спрашивают, понятно, что это не правильно, но как это воспринимаешь ты или более высокое руководство? Какие долгосрочные последствия?
Тут нужно понимать, что все зависит от ситуации. Чем крупнее компания, тем сильнее она опирается на метрики и цели, которые стоят у конкретных руководителей. Цели спускаются более мелкими кусками, на руководителей звена ниже. Каждая цель вашей команды / продукта в итоге влияет на большую цель. Многие цели нельзя закрыть частично. Например, происходит переход с легаси системы на новую, новую делает несколько команд. Обычно если одна не успевает, то это ведет к тому, что не засчитывается цель в целом, потому что, обычно, вывести из эксплуатации легаси нельзя. То, что вы подводите свое руководство это понятно, но пользователи продолжат работать на легаси (обычно переход затеян для улучшения работы пользователей), смежным командам свои цели тоже могут не засчитать (такое бывает чаще, чем кажется), могут быть не достигнуты бизнес показатели из-за этого ну и т. д. Соответственно, небольшой проваленный кусок может снежным комом потянуть за собой очень много вещей. Большинство людей не задумываются об этом и очень скептически относятся к своим целям. Ну казалось бы у нас не самый важный функционал, ничего страшного. Но на практике работает это не так. В двух системах скорее всего работать никто не будет по многим причинам и техническим и бизнесовым. Поэтому я всегда рассказываю своим ребятам о том, кто и что от них зависит и советую и вам такие вещи знать.
В итоге, самое плохое часто даже не срыв сроков, а то, что он произойдет неожиданно. Никто не сможет проработать варианты, обойти проблему или усилить вашу команду. Соответственно, это будет большим стрессом для всех. Но что же может случится конкретно для вас?
Тут все зависит от руководства и ситуации, может от ничего до увольнения. Чаще идут более мягкие наказания. Отмена премий (если они есть), отмена повышений для всей команды или определенных ее участников. Это быстрые эффекты. В отложенных эффектах я бы отметил отсутствие доверия к вам и вашей команде, то есть вам будут стараться не поручать ничего важного и интересного, а также будут заниматься вашим ростом и развитием в последнюю очередь.
В целом, не попадать в сроки, спущенные сверху, это нормально, ненормально, когда вы знаете и молчите об этом. Сказать прямо и честно, что не успеваете это часть работы (у меня есть много историй про это, если будет интерес к этому, то поделюсь).
Заранее понять, что вы не успеваете в сроки это тоже отдельная задача, которую мы будем разбирать на нашем марафоне по работе со сроками, стартующем 11 декабря. Там же разберем, что можно сделать, чтобы уложиться в сроки, если уже не успеваете. Зовите своих коллег и подчиненных присоединиться к марафону, информация будет очень полезная и важная для всех.
Максим Шаламов
#разработчику #руководителю
Бывают ситуации, когда невозможно уложиться в сроки. Правильное поведение в такой ситуации: выставить реальные сроки, всем озвучить и, пытаясь оптимизировать затраты, все же напоминать о реалиях на любых встречах. Так делать правильно хоть и часто сложно. Многие просто берут сроки, не споря (даже если можно было просто назвать реальные сроки без споров), и потом, по факту, говорят, что не укладываются в дедлайн. Меня часто спрашивают, понятно, что это не правильно, но как это воспринимаешь ты или более высокое руководство? Какие долгосрочные последствия?
Тут нужно понимать, что все зависит от ситуации. Чем крупнее компания, тем сильнее она опирается на метрики и цели, которые стоят у конкретных руководителей. Цели спускаются более мелкими кусками, на руководителей звена ниже. Каждая цель вашей команды / продукта в итоге влияет на большую цель. Многие цели нельзя закрыть частично. Например, происходит переход с легаси системы на новую, новую делает несколько команд. Обычно если одна не успевает, то это ведет к тому, что не засчитывается цель в целом, потому что, обычно, вывести из эксплуатации легаси нельзя. То, что вы подводите свое руководство это понятно, но пользователи продолжат работать на легаси (обычно переход затеян для улучшения работы пользователей), смежным командам свои цели тоже могут не засчитать (такое бывает чаще, чем кажется), могут быть не достигнуты бизнес показатели из-за этого ну и т. д. Соответственно, небольшой проваленный кусок может снежным комом потянуть за собой очень много вещей. Большинство людей не задумываются об этом и очень скептически относятся к своим целям. Ну казалось бы у нас не самый важный функционал, ничего страшного. Но на практике работает это не так. В двух системах скорее всего работать никто не будет по многим причинам и техническим и бизнесовым. Поэтому я всегда рассказываю своим ребятам о том, кто и что от них зависит и советую и вам такие вещи знать.
В итоге, самое плохое часто даже не срыв сроков, а то, что он произойдет неожиданно. Никто не сможет проработать варианты, обойти проблему или усилить вашу команду. Соответственно, это будет большим стрессом для всех. Но что же может случится конкретно для вас?
Тут все зависит от руководства и ситуации, может от ничего до увольнения. Чаще идут более мягкие наказания. Отмена премий (если они есть), отмена повышений для всей команды или определенных ее участников. Это быстрые эффекты. В отложенных эффектах я бы отметил отсутствие доверия к вам и вашей команде, то есть вам будут стараться не поручать ничего важного и интересного, а также будут заниматься вашим ростом и развитием в последнюю очередь.
В целом, не попадать в сроки, спущенные сверху, это нормально, ненормально, когда вы знаете и молчите об этом. Сказать прямо и честно, что не успеваете это часть работы (у меня есть много историй про это, если будет интерес к этому, то поделюсь).
Заранее понять, что вы не успеваете в сроки это тоже отдельная задача, которую мы будем разбирать на нашем марафоне по работе со сроками, стартующем 11 декабря. Там же разберем, что можно сделать, чтобы уложиться в сроки, если уже не успеваете. Зовите своих коллег и подчиненных присоединиться к марафону, информация будет очень полезная и важная для всех.
Максим Шаламов
#разработчику #руководителю
Почему люди уходят из компании
Текучка в команде - болезненная тема для руководителей, у многих этот показатель входит в KPI и влияет на показатели успеха собственной работы. Несомненно, она влияет и на успешность работы самой команды, поэтому игнорировать текучку ни в коем случае нельзя. Чтобы начать решать эту проблему, для начала нужно разобраться, в чем основные причины. Давайте пойдем от самых очевидных к менее очевидным пунктам.
Очевидные причины
Не подходящая компания или проект. Бывает, что обещали одно, а внутри все не так. Обман ожиданий конечно же ведет к оттоку сотрудников. Стоит уделять внимание тому, что обещаете на собеседовании, не обещайте больше, чем есть и не искажайте основные факты. Даже если вы так заманите человека в свою команду, велика вероятность, что он очень быстро уйдет, а ресурсы команды для его ввода в проект будут потрачены впустую.
Не сработались с командой или руководителем. Тоже нередкая проблема, когда не получается найти общий язык новому сотруднику и уже устоявшейся команде, что приводит к проблемам в коммуникациях и в достижении целей. Это периодически приводит к конфликтам. Конечно же люди часто не готовы продолжать в таких условиях. Я уже как-то писал о том, как собеседовать человека на совместимость с командой, старайтесь уделять этому внимание уже на собеседовании, чтобы уменьшить риски появления такой ситуации.
Проекты на поддержке. Многие разработчики не готовы работать на проектах, где нет развития. Основная часть проекта уже готова и не меняется, правятся только мелкие ошибки и делаются незначительные доработки. Конечно же людям, особенно имеющим какие-то амбиции, не хочется терять время на “мертвые” проекты, им скучно, они теряют квалификацию и, соответственно, свою цену на рынке.
Просто надоедает проект, все уже знакомо, хочется выйти за границы комфорта. Конечно, выход из зоны комфорта помогают росту и развитию разработчика.Конечно, выход из зоны комфорта помогают росту и развитию разработчика. Однако, можно продолжать развиваться и будучи на уже знакомом проекте, мы разбираем как это можно сделать в нашем продукте по борьбе с рутиной. Учитесь этому, если вы разработчик, реже придется менять работу и меньше будете терять время, пока находитесь на уже знакомом проекте. Мотивируйте к использованию этих подходов своих подчиненных, если вы руководитель, это поможет уменьшить текучку.
Менее однозначные проблемы
Дальше пойдем к менее однозначным пунктам.
В проекте все налажено включая процессы. Не смотря на то, что все будет идти понятно и предсказуемо, и удастся избежать многих проблем, части людей будет скучно или сложно встраиваться в такие системы.
Проекты на стадии активного роста и развития. На самом деле, многие говорят, что им такой опыт интересен, но, по факту, большинство не готово взять на себя ответственность за настройку даже малейших вещей, будь то выбор единой библиотеки (не просто мне нравится, а провести анализ и переработать какой-то кусок в пром по правилам команды и показать результаты), до запуска тестов в пайплайне и т.д. Люди буду говорить, что да, вот хочется, чтобы все росло и развивалось, но только чтоб нам ничего делать было не надо. В итоге, выгорание идет от того, что многое сделано не оптимально, но тут правильный настрой в том, чтобы участвовать в процессе самим.
Нет роста. В целом это реально может быть проблемой, и что не делаешь и не просишь, роста тебе не будет. Но нередки случаи, когда ты хочешь постоянные повышения за одну и туже работу (даже не индексации а именно повышения), так не бывает. Для повышений нужно делать что-то сверх своей работы и это надо согласовывать с руководством.
Максим Шаламов
#советы #руководителю #разработчику
Текучка в команде - болезненная тема для руководителей, у многих этот показатель входит в KPI и влияет на показатели успеха собственной работы. Несомненно, она влияет и на успешность работы самой команды, поэтому игнорировать текучку ни в коем случае нельзя. Чтобы начать решать эту проблему, для начала нужно разобраться, в чем основные причины. Давайте пойдем от самых очевидных к менее очевидным пунктам.
Очевидные причины
Не подходящая компания или проект. Бывает, что обещали одно, а внутри все не так. Обман ожиданий конечно же ведет к оттоку сотрудников. Стоит уделять внимание тому, что обещаете на собеседовании, не обещайте больше, чем есть и не искажайте основные факты. Даже если вы так заманите человека в свою команду, велика вероятность, что он очень быстро уйдет, а ресурсы команды для его ввода в проект будут потрачены впустую.
Не сработались с командой или руководителем. Тоже нередкая проблема, когда не получается найти общий язык новому сотруднику и уже устоявшейся команде, что приводит к проблемам в коммуникациях и в достижении целей. Это периодически приводит к конфликтам. Конечно же люди часто не готовы продолжать в таких условиях. Я уже как-то писал о том, как собеседовать человека на совместимость с командой, старайтесь уделять этому внимание уже на собеседовании, чтобы уменьшить риски появления такой ситуации.
Проекты на поддержке. Многие разработчики не готовы работать на проектах, где нет развития. Основная часть проекта уже готова и не меняется, правятся только мелкие ошибки и делаются незначительные доработки. Конечно же людям, особенно имеющим какие-то амбиции, не хочется терять время на “мертвые” проекты, им скучно, они теряют квалификацию и, соответственно, свою цену на рынке.
Просто надоедает проект, все уже знакомо, хочется выйти за границы комфорта. Конечно, выход из зоны комфорта помогают росту и развитию разработчика.Конечно, выход из зоны комфорта помогают росту и развитию разработчика. Однако, можно продолжать развиваться и будучи на уже знакомом проекте, мы разбираем как это можно сделать в нашем продукте по борьбе с рутиной. Учитесь этому, если вы разработчик, реже придется менять работу и меньше будете терять время, пока находитесь на уже знакомом проекте. Мотивируйте к использованию этих подходов своих подчиненных, если вы руководитель, это поможет уменьшить текучку.
Менее однозначные проблемы
Дальше пойдем к менее однозначным пунктам.
В проекте все налажено включая процессы. Не смотря на то, что все будет идти понятно и предсказуемо, и удастся избежать многих проблем, части людей будет скучно или сложно встраиваться в такие системы.
Проекты на стадии активного роста и развития. На самом деле, многие говорят, что им такой опыт интересен, но, по факту, большинство не готово взять на себя ответственность за настройку даже малейших вещей, будь то выбор единой библиотеки (не просто мне нравится, а провести анализ и переработать какой-то кусок в пром по правилам команды и показать результаты), до запуска тестов в пайплайне и т.д. Люди буду говорить, что да, вот хочется, чтобы все росло и развивалось, но только чтоб нам ничего делать было не надо. В итоге, выгорание идет от того, что многое сделано не оптимально, но тут правильный настрой в том, чтобы участвовать в процессе самим.
Нет роста. В целом это реально может быть проблемой, и что не делаешь и не просишь, роста тебе не будет. Но нередки случаи, когда ты хочешь постоянные повышения за одну и туже работу (даже не индексации а именно повышения), так не бывает. Для повышений нужно делать что-то сверх своей работы и это надо согласовывать с руководством.
Максим Шаламов
#советы #руководителю #разработчику
Что мешает хорошим технарям стать руководителями?
Не смотря на мой уже немалый опыт в росте лидов и руководителей более высокого уровня, получается далеко не всегда. Многие по тем или иным причинам не справляются. Причин на самом деле много (если статья зайдет, то сделаю обзор по основным), но хотел бы остановиться на одной, через которую проходят все инженеры, которых я знаю.
Начну с себя. Когда я развивался, как разработчик, для меня было очень важно умение погружаться в задачу и концентрироваться на ней. Это то, что многие называют состоянием “потока”. Одна из причин, по которой у меня хорошо получалось, это то, что я мог по 3-4 часа работать непрерывно, а в целом по дню выдавать до 7-8 часов именно написания кода. Делая отступление в сторону, не сильно рекомендую так делать, весьма выматываюший режим. Это была одной из причин, по которым я обычно успевал сделать очень много. И я привык так работать.
Но, когда я стал двигаться к руководящим позициям, оказалось, что у тебя много задач, требующих внимания. И, если ты сфокусируешься только на одной, да, ты сделаешь ее, но провалишь другие и, в целом, это будет провалом.
Теперь новой реальностью стало быстрое переключение между большим количеством задач. Да, многие ты передаешь кому-то, но нужно как минимум понять, что хотят и кому передать задачу, иначе дело может застопориться. И тебе нужно найти время на небольшое количество задач, где нужно погружение. Небольшое - это снова больше, чем один. В итоге моя сильная сторона, как разработчика, мешала мне в этом.
К чему все это я? С этим сталкиваются все мои ребята. Очень тяжело дается переход к такому формату задач. И людей прямо за уши приходится оттаскивать от погружения в конкретную задачу, к формату работы со всем пулом задач. Это дается через боль и люди очень тяжело выходят из зоны комфорта. Это и не хорошо и не плохо это надо пережить.
В итоге, многие просто предпочитают не менять подход и как лиды не раскрываются. У меня такие ребята возвращаются к своим привычным обязанностям. В целом, это говорит о том, что новая должность требует новых навыков и подходов.
Больше о конкретных навыках руководителя команды, вы можете найти в моем учебнике для руководителей “Тимлид: базовый уровень”. В нем, я разобрал еще одну из задач, с которой большинство даже опытных руководителей не справляется - делегирование. И конечно же все основные моменты, с которыми придется столкнуться на этой должности.
Максим Шаламов
#руководителю
Не смотря на мой уже немалый опыт в росте лидов и руководителей более высокого уровня, получается далеко не всегда. Многие по тем или иным причинам не справляются. Причин на самом деле много (если статья зайдет, то сделаю обзор по основным), но хотел бы остановиться на одной, через которую проходят все инженеры, которых я знаю.
Начну с себя. Когда я развивался, как разработчик, для меня было очень важно умение погружаться в задачу и концентрироваться на ней. Это то, что многие называют состоянием “потока”. Одна из причин, по которой у меня хорошо получалось, это то, что я мог по 3-4 часа работать непрерывно, а в целом по дню выдавать до 7-8 часов именно написания кода. Делая отступление в сторону, не сильно рекомендую так делать, весьма выматываюший режим. Это была одной из причин, по которым я обычно успевал сделать очень много. И я привык так работать.
Но, когда я стал двигаться к руководящим позициям, оказалось, что у тебя много задач, требующих внимания. И, если ты сфокусируешься только на одной, да, ты сделаешь ее, но провалишь другие и, в целом, это будет провалом.
Теперь новой реальностью стало быстрое переключение между большим количеством задач. Да, многие ты передаешь кому-то, но нужно как минимум понять, что хотят и кому передать задачу, иначе дело может застопориться. И тебе нужно найти время на небольшое количество задач, где нужно погружение. Небольшое - это снова больше, чем один. В итоге моя сильная сторона, как разработчика, мешала мне в этом.
К чему все это я? С этим сталкиваются все мои ребята. Очень тяжело дается переход к такому формату задач. И людей прямо за уши приходится оттаскивать от погружения в конкретную задачу, к формату работы со всем пулом задач. Это дается через боль и люди очень тяжело выходят из зоны комфорта. Это и не хорошо и не плохо это надо пережить.
В итоге, многие просто предпочитают не менять подход и как лиды не раскрываются. У меня такие ребята возвращаются к своим привычным обязанностям. В целом, это говорит о том, что новая должность требует новых навыков и подходов.
Больше о конкретных навыках руководителя команды, вы можете найти в моем учебнике для руководителей “Тимлид: базовый уровень”. В нем, я разобрал еще одну из задач, с которой большинство даже опытных руководителей не справляется - делегирование. И конечно же все основные моменты, с которыми придется столкнуться на этой должности.
Максим Шаламов
#руководителю
Допустим ли микроменеджмент? Какие последствия?
Начнем с определения, которое я возьму из Википедии, чтобы не было расхождений. В бизнесе микроменеджмент — это стиль управления персоналом, при котором руководство использует чрезмерный и постоянный контроль над сотрудниками, не допуская никакой самостоятельности в принятии решений.
Нужно ли такое бывает в реальности? Бывают ли ситуации, где это работает? Да. Приходя в новые команды/отделы/компании, которые работают неэффективно, пока идет процесс перестройки и обучения под новые требования, часто приходится влазить в проекты и процессы и диктовать, что делать, пока люди учатся. Такие меры могут давать положительный эффект только на короткой дистанции. По моему опыту, выведение из кризисов проектов и команд начинается с этого, но не должно на этом останавливаться.
Основной проблемой такого подхода, я вижу убийство мотивации и замыкание всего на себя. Убийство мотивации влечет за собой то, что вы будете окружены вялыми и безинициативными сотрудниками. Их производительность будет низкой, любые изменения и процессы будут внедряться из под палки. Ожидать, что они приложат усилие для улучшения компании или проекта довольно глупо. Более того, такие люди потеряют понимание возможностей к росту и мотивации, и те, кто чего-то хотят покинут компанию. Останутся самые слабые и пассивные. Сложные проекты и амбициозные цели с такой командой будут не для вас.
Замыкание всего на себя повлечет вашу перегрузку. Медленную реакцию на любые проблемы и изменения. И вы все должны будете придумывать и решать сами. Людям вы либо не доверите, либо уже ушли все, кто мог бы думать сам.
В целом, старайтесь избегать микроменеджмента, используйте его только в крайнем случае, как я писал в начале. В остальном, он принесет больше минусов, чем плюсов.
Максим Шаламов
#советы #руководителю
Начнем с определения, которое я возьму из Википедии, чтобы не было расхождений. В бизнесе микроменеджмент — это стиль управления персоналом, при котором руководство использует чрезмерный и постоянный контроль над сотрудниками, не допуская никакой самостоятельности в принятии решений.
Нужно ли такое бывает в реальности? Бывают ли ситуации, где это работает? Да. Приходя в новые команды/отделы/компании, которые работают неэффективно, пока идет процесс перестройки и обучения под новые требования, часто приходится влазить в проекты и процессы и диктовать, что делать, пока люди учатся. Такие меры могут давать положительный эффект только на короткой дистанции. По моему опыту, выведение из кризисов проектов и команд начинается с этого, но не должно на этом останавливаться.
Основной проблемой такого подхода, я вижу убийство мотивации и замыкание всего на себя. Убийство мотивации влечет за собой то, что вы будете окружены вялыми и безинициативными сотрудниками. Их производительность будет низкой, любые изменения и процессы будут внедряться из под палки. Ожидать, что они приложат усилие для улучшения компании или проекта довольно глупо. Более того, такие люди потеряют понимание возможностей к росту и мотивации, и те, кто чего-то хотят покинут компанию. Останутся самые слабые и пассивные. Сложные проекты и амбициозные цели с такой командой будут не для вас.
Замыкание всего на себя повлечет вашу перегрузку. Медленную реакцию на любые проблемы и изменения. И вы все должны будете придумывать и решать сами. Людям вы либо не доверите, либо уже ушли все, кто мог бы думать сам.
В целом, старайтесь избегать микроменеджмента, используйте его только в крайнем случае, как я писал в начале. В остальном, он принесет больше минусов, чем плюсов.
Максим Шаламов
#советы #руководителю
Как я выбираю руководителей
Я уже рассказывал, на что я смотрю на собеседовании. Но там не поднималась отдельно тема руководителей, которых тоже нужно нанимать. Для простоты я не буду особенно вдаваться в градацию и акценты в зависимости от этого. К руководителям, в данном контексте, относятся и тимлиды и лидеры компетенций отделов (например лидеры направления Python, Go, JS и т.д.).
Умение излагать мысли
Первое, на что я смотрю, это умение излагать свои мысли ясно и четко. Такие позиции подразумевают тесное общение с людьми и чем выше, тем больше. Поэтому, если человек не умеет внятно излагать свои мысли, это большой минус.
Прошлый опыт и причины решений
Дальше я смотрю на опыт человека, причем мы не просто зачитываем резюме, а человек рассказывает о своей работе. Меня интересуют решения, которые он принимал и мотивация, с который он это делал. Если человек не может объяснить зачем он делал или внедрял что-то, то для руководителя это огромный минус. Если какие-то вещи спускались сверху, но были неразумными, то обсуждаем, что он делал в этих ситуациях.
Умение себя подать
Дальше я смотрю насколько человек умеет себя подать и расположить к себе. С какой командой он сможет работать, а с какой нет. В идеале, человек должен мочь возглавить любую команду, но обычно это не так и это становится ограничением при выборе.
Какая мотивация
Очень важно для меня понять мотивацию человека. Причем не только по работе, но и по желанию быть руководителем. Если это то, что тебе нравится и в чем ты хочешь развиваться, то это хорошо. А если так вышло, получилось и денег чуть больше платят, то мне этой мотивации не достаточно.
Практические вопросы
После этого я прошу рассказать человека, как он хотел бы организовать работу своей команды / направления, что бы он делал, как бы проверял результат, что важно, а что нет. В основном я слушаю, после чего задаю вопросы для уточнения (например: “а как бы фиксировали цели?”, “какими шагами бы шли к ее выполнению?” и т.д.). На этом этапе мне важно увидеть, что человек понимает свою позицию. Что он расскажет и о целях и о работе с людьми, а главное о том, как все сделать прозрачно для руководства и подчиненных. Этот этап для меня самый важный, потому что предыдущих пунктов недостаточно. Если говорить о человеке на вырост, то я с большей вероятностью буду растить кого-то внутри. Нанимая руководителя, хочется получить усиление сразу, а не в перспективе. Хотя бывают и исключения.
В целом, как и в любом деле, опирайтесь на свои потребности и свое понимание задач и позиций. А идя на собеседование, помните, что главное это хороший и позитивный настрой.
Если хотите лучше подготовиться к подобному собеседованию, то советую посмотреть мой учебник для тимлидов. Там я разобрал все основы работы с командой, которым учу своих собственных подчиненных.
Максим Шаламов
#руководителю
Я уже рассказывал, на что я смотрю на собеседовании. Но там не поднималась отдельно тема руководителей, которых тоже нужно нанимать. Для простоты я не буду особенно вдаваться в градацию и акценты в зависимости от этого. К руководителям, в данном контексте, относятся и тимлиды и лидеры компетенций отделов (например лидеры направления Python, Go, JS и т.д.).
Умение излагать мысли
Первое, на что я смотрю, это умение излагать свои мысли ясно и четко. Такие позиции подразумевают тесное общение с людьми и чем выше, тем больше. Поэтому, если человек не умеет внятно излагать свои мысли, это большой минус.
Прошлый опыт и причины решений
Дальше я смотрю на опыт человека, причем мы не просто зачитываем резюме, а человек рассказывает о своей работе. Меня интересуют решения, которые он принимал и мотивация, с который он это делал. Если человек не может объяснить зачем он делал или внедрял что-то, то для руководителя это огромный минус. Если какие-то вещи спускались сверху, но были неразумными, то обсуждаем, что он делал в этих ситуациях.
Умение себя подать
Дальше я смотрю насколько человек умеет себя подать и расположить к себе. С какой командой он сможет работать, а с какой нет. В идеале, человек должен мочь возглавить любую команду, но обычно это не так и это становится ограничением при выборе.
Какая мотивация
Очень важно для меня понять мотивацию человека. Причем не только по работе, но и по желанию быть руководителем. Если это то, что тебе нравится и в чем ты хочешь развиваться, то это хорошо. А если так вышло, получилось и денег чуть больше платят, то мне этой мотивации не достаточно.
Практические вопросы
После этого я прошу рассказать человека, как он хотел бы организовать работу своей команды / направления, что бы он делал, как бы проверял результат, что важно, а что нет. В основном я слушаю, после чего задаю вопросы для уточнения (например: “а как бы фиксировали цели?”, “какими шагами бы шли к ее выполнению?” и т.д.). На этом этапе мне важно увидеть, что человек понимает свою позицию. Что он расскажет и о целях и о работе с людьми, а главное о том, как все сделать прозрачно для руководства и подчиненных. Этот этап для меня самый важный, потому что предыдущих пунктов недостаточно. Если говорить о человеке на вырост, то я с большей вероятностью буду растить кого-то внутри. Нанимая руководителя, хочется получить усиление сразу, а не в перспективе. Хотя бывают и исключения.
В целом, как и в любом деле, опирайтесь на свои потребности и свое понимание задач и позиций. А идя на собеседование, помните, что главное это хороший и позитивный настрой.
Если хотите лучше подготовиться к подобному собеседованию, то советую посмотреть мой учебник для тимлидов. Там я разобрал все основы работы с командой, которым учу своих собственных подчиненных.
Максим Шаламов
#руководителю
"Почему меня не уважают?"
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Недоступен - не решаешь
Сегодня поделюсь очень короткой, но от этого не менее важной мыслью. Много проблем у начинающих лидов бывает с ситуациями, когда они хотят стать точкой входа по изменениям в команде. Чтобы, если меняются требования, это не расползалась по людям, а собиралось и фильтровалось в них. Идея правильная и они даже могут убедить начать так делать. Но все ломается, если вы не будете доступны. То есть, если нужно обсудить изменения, а вы выпадаете на день, два, три, то конечно никто через вас работать не будет. Это касается любых коммуникаций. Хотите, чтобы работали через вас, в оговоренное время или по понятному сценарию (например по выставленным в свободные слоты встречам), - вы всегда доступны, подключаетесь и вовлечены в процесс. Иначе это работать не будет.
Максим Шаламов
#руководителю
Сегодня поделюсь очень короткой, но от этого не менее важной мыслью. Много проблем у начинающих лидов бывает с ситуациями, когда они хотят стать точкой входа по изменениям в команде. Чтобы, если меняются требования, это не расползалась по людям, а собиралось и фильтровалось в них. Идея правильная и они даже могут убедить начать так делать. Но все ломается, если вы не будете доступны. То есть, если нужно обсудить изменения, а вы выпадаете на день, два, три, то конечно никто через вас работать не будет. Это касается любых коммуникаций. Хотите, чтобы работали через вас, в оговоренное время или по понятному сценарию (например по выставленным в свободные слоты встречам), - вы всегда доступны, подключаетесь и вовлечены в процесс. Иначе это работать не будет.
Максим Шаламов
#руководителю
“Почему меня не слушают, я же начальник”
У ряда руководителей можно услышать о проблемах с тем, что их не слушаются и/или не воспринимают. Причем смена команд и работы им не сильно помогает. Не могу сказать, что обладаю большой выборкой, но есть один момент, на который я бы обращал внимание. И как сотруднику при оценке руководителя, и как руководителю для понимания, как тебя воспринимают.
В чем проблема
Смысл проблемы в том, что у большинства руководителей их жалоба звучит примерно как “он меня не послушал, а ведь я начальник”. Я конечно согласен, что субординация важна, но не всегда слов “я начальник” достаточно, чтобы что-то случилось или начало делаться, как вы хотите. Давайте разберемся по частям с этой проблемой.
Самое простое, часто люди не понимают, что и зачем вы хотите, поэтому они либо спорят, либо делают все, чтобы не брать в работу вашу задачу. Поэтому всегда найдите время объяснить, зачем вы что-то требуете. Например, “если мы не сделаем эту задачу, отложив текущие, то все лишимся премий”, лучше чем “бросайте фигню, которой занимаетесь, и все силы бросайте на эту задачу”. Если задача пришла сверху и вы сами не до конца понимаете ситуацию, я считаю, что лучше так и передать своим подчиненным. Это лучше, чем они будут думать, что вы просто не нашли времени для донесения информации или посчитали себя выше общения с ними.
Второе, подача авторитета с точки зрения должности работает не на всех, а у части людей вызывает отрицательные эмоции вплоть до неподвластной им необходимости мешать вам. Сама по себе должность не говорит о компетентности в целом, или по крайней мере в текущей ситуации.
Как лучше делать
Лично я всегда иду от другого и люди, которых я считаю хорошими руководителями, обычно делают также. Я иду либо от ответственности, либо от знания. И обычно, когда я слушаю подобные возмущения от руководителей, которых я считаю хорошими, они звучат примерно как “мне не важно, что он считает. Отвечать мне, поэтому мы сделали, как я сказал”. Сама по себе подача себя через ответственность лично у меня вызывает больше понимания. Я понимаю, что за каждый большой провал сначала ответит мой руководитель, а потом, если считает правильным он сам, вызовет отвечать меня. И он это понимает. Поэтому глобальных проблем с принятием права последнего слова у меня нет. Так же, как если ты признанный у себя в команде эксперт, то можно идти от того, что ты точно знаешь и берешь ответственность на себя. Знание и принятие ответственности тоже имеет вес, но это скорее хорошо работает в среде тех, кто вас давно знает.
В заключении, для упрощения взаимодействий, когда вы хотите единолично принять решение, идите от пояснения причин и фиксирования принятия ответственности за решения.
Максим Шаламов
#руководителю #советы
У ряда руководителей можно услышать о проблемах с тем, что их не слушаются и/или не воспринимают. Причем смена команд и работы им не сильно помогает. Не могу сказать, что обладаю большой выборкой, но есть один момент, на который я бы обращал внимание. И как сотруднику при оценке руководителя, и как руководителю для понимания, как тебя воспринимают.
В чем проблема
Смысл проблемы в том, что у большинства руководителей их жалоба звучит примерно как “он меня не послушал, а ведь я начальник”. Я конечно согласен, что субординация важна, но не всегда слов “я начальник” достаточно, чтобы что-то случилось или начало делаться, как вы хотите. Давайте разберемся по частям с этой проблемой.
Самое простое, часто люди не понимают, что и зачем вы хотите, поэтому они либо спорят, либо делают все, чтобы не брать в работу вашу задачу. Поэтому всегда найдите время объяснить, зачем вы что-то требуете. Например, “если мы не сделаем эту задачу, отложив текущие, то все лишимся премий”, лучше чем “бросайте фигню, которой занимаетесь, и все силы бросайте на эту задачу”. Если задача пришла сверху и вы сами не до конца понимаете ситуацию, я считаю, что лучше так и передать своим подчиненным. Это лучше, чем они будут думать, что вы просто не нашли времени для донесения информации или посчитали себя выше общения с ними.
Второе, подача авторитета с точки зрения должности работает не на всех, а у части людей вызывает отрицательные эмоции вплоть до неподвластной им необходимости мешать вам. Сама по себе должность не говорит о компетентности в целом, или по крайней мере в текущей ситуации.
Как лучше делать
Лично я всегда иду от другого и люди, которых я считаю хорошими руководителями, обычно делают также. Я иду либо от ответственности, либо от знания. И обычно, когда я слушаю подобные возмущения от руководителей, которых я считаю хорошими, они звучат примерно как “мне не важно, что он считает. Отвечать мне, поэтому мы сделали, как я сказал”. Сама по себе подача себя через ответственность лично у меня вызывает больше понимания. Я понимаю, что за каждый большой провал сначала ответит мой руководитель, а потом, если считает правильным он сам, вызовет отвечать меня. И он это понимает. Поэтому глобальных проблем с принятием права последнего слова у меня нет. Так же, как если ты признанный у себя в команде эксперт, то можно идти от того, что ты точно знаешь и берешь ответственность на себя. Знание и принятие ответственности тоже имеет вес, но это скорее хорошо работает в среде тех, кто вас давно знает.
В заключении, для упрощения взаимодействий, когда вы хотите единолично принять решение, идите от пояснения причин и фиксирования принятия ответственности за решения.
Максим Шаламов
#руководителю #советы
Да не заботитесь вы о команде!
Я часто слышу от ребят: “я забочусь о команде”, ”я переживаю о проекте” и тому подобное. А потом идет какое-то “но” или еще что-то, что человеку мешает. Сейчас я в разговорах концентрируюсь на первой части и всегда спрашиваю, а что ты сделал в рамках своей заботы / беспокойства / ответственности?
Заботишься о выгорании команды? А что сделано для улучшения планирования?
Заботишься о качестве проекта? А что сделано для улучшения этого качества?
И т.д. и т.п. Моя задача не утопить людей, а понять одну важную вещь: готовы ли они действовать или это просто слова и оправдание. Я могу им помочь, найти время, отстоять сроки и т.д. Но они сами должны этим заниматься и брать ответственность, иначе я просто вовремя не узнаю о проблеме.
Хотите разгрузить команду? Берите меньше задач, требуйте делать лучше постановку задач, работайте с ожиданиями - совершайте действия, чтобы исправить то, что вас беспокоит. Я готов помочь своим ребятам на каждом этапе, но только тогда, когда они заранее проанализировали, поняли, где проблемы, и тогда уже пришли за помощью, или они решают проблему, но их начали продавливать и им нужна помощь отстоять позиции. Сидеть и ждать, что за тебя все сделают, не сработает. Заботиться и команде, проекте и прочем, и ничего не делать для улучшения - не забота, это удобное оправдание для своей совести.
Максим Шаламов
#руководителю
Я часто слышу от ребят: “я забочусь о команде”, ”я переживаю о проекте” и тому подобное. А потом идет какое-то “но” или еще что-то, что человеку мешает. Сейчас я в разговорах концентрируюсь на первой части и всегда спрашиваю, а что ты сделал в рамках своей заботы / беспокойства / ответственности?
Заботишься о выгорании команды? А что сделано для улучшения планирования?
Заботишься о качестве проекта? А что сделано для улучшения этого качества?
И т.д. и т.п. Моя задача не утопить людей, а понять одну важную вещь: готовы ли они действовать или это просто слова и оправдание. Я могу им помочь, найти время, отстоять сроки и т.д. Но они сами должны этим заниматься и брать ответственность, иначе я просто вовремя не узнаю о проблеме.
Хотите разгрузить команду? Берите меньше задач, требуйте делать лучше постановку задач, работайте с ожиданиями - совершайте действия, чтобы исправить то, что вас беспокоит. Я готов помочь своим ребятам на каждом этапе, но только тогда, когда они заранее проанализировали, поняли, где проблемы, и тогда уже пришли за помощью, или они решают проблему, но их начали продавливать и им нужна помощь отстоять позиции. Сидеть и ждать, что за тебя все сделают, не сработает. Заботиться и команде, проекте и прочем, и ничего не делать для улучшения - не забота, это удобное оправдание для своей совести.
Максим Шаламов
#руководителю