Здесь приветственный пост
Хотите верьте, хотите нет - в инете практически нет инфы о том, из чего состоит реальная работа руководителя в разработке. То, что вы можете найти в 99% статей, презентаций и книг - "за все хорошее, против всего плохого". Делегируйте, следуйте целям бизнеса, agile, софт-скиллы, метрики, спринты, бла-бла. Даже PMBoK советуют.
Любой, кто занимал руководящую позицию (особенно выше, чем руководство небольшой командой) - сталкивается с совершенно другими вопросами, связанными главным образом с кадрами и выстраиванием отношений в компании. Корпоративные игры, отношение членов команды к работе, что делать с проблемными коллегами из других отделов, отношение с руководителем, столкновения разных подходов к менеджменту, репутация личная, репутация команды, полномочия, управление зарплатами сотрудников, борьба за ресурсы, риторика на совещаниях. И настроение команды.
Собственно, я увидел нишу - похоже, будет неплохо поговорить об этих вещах. О внутреннем устройстве менеджмента в разработке, без цензуры.
Думаю, здесь будет 3 типа контента - истории из работы, практические рекомендации и теоретические рассуждения. Плюс общение в комментах
Кому это может быть интересно? На мой взгляд, Вам, если:
1. Вы на лидерской позиции в разработке
2. Вы хотите занять лидерскую позицию, но пока еще не знаете как и что
3. Вы на соло позиции, но вам интересно заглянуть за кулисы, что там внутри происходит
4. Вы сам не из разработки, но вам интересна честная инфа об этой сфере
Располагайтесь, и посмотрим, куда нас это приведет. Поехали )
Хотите верьте, хотите нет - в инете практически нет инфы о том, из чего состоит реальная работа руководителя в разработке. То, что вы можете найти в 99% статей, презентаций и книг - "за все хорошее, против всего плохого". Делегируйте, следуйте целям бизнеса, agile, софт-скиллы, метрики, спринты, бла-бла. Даже PMBoK советуют.
Любой, кто занимал руководящую позицию (особенно выше, чем руководство небольшой командой) - сталкивается с совершенно другими вопросами, связанными главным образом с кадрами и выстраиванием отношений в компании. Корпоративные игры, отношение членов команды к работе, что делать с проблемными коллегами из других отделов, отношение с руководителем, столкновения разных подходов к менеджменту, репутация личная, репутация команды, полномочия, управление зарплатами сотрудников, борьба за ресурсы, риторика на совещаниях. И настроение команды.
Собственно, я увидел нишу - похоже, будет неплохо поговорить об этих вещах. О внутреннем устройстве менеджмента в разработке, без цензуры.
Думаю, здесь будет 3 типа контента - истории из работы, практические рекомендации и теоретические рассуждения. Плюс общение в комментах
Кому это может быть интересно? На мой взгляд, Вам, если:
1. Вы на лидерской позиции в разработке
2. Вы хотите занять лидерскую позицию, но пока еще не знаете как и что
3. Вы на соло позиции, но вам интересно заглянуть за кулисы, что там внутри происходит
4. Вы сам не из разработки, но вам интересна честная инфа об этой сфере
Располагайтесь, и посмотрим, куда нас это приведет. Поехали )
🔥23❤6👍4
Первая история - довольно веселая. Про доверие
В одной компании работал вместе с другом, я тогда был разрабом, а он тимлидом, я его постоянно подменял, мы всё обсуждали как есть.
Там был харизматичный, жадный и при этом вообще ничего не смыслящий в разработке гендир, который немного напоминал своими глупостями сэра Джона Франклина из "Террора" Дэна Симмонса.
Он периодически (достаточно рандомно) приходил с внезапным: "давайте сокращать расходы на Галамент!". У нас команда разработки состояла примерно наполовину из аутстафф сотрудников из другой компании, и вот это было ее название. Это был прям локальный мем. Обычно мы отбивались, это была такая игра "на слабо", если мы сопротивляемся отчаянно - он отстает. Если нет - прожимает уволить кого-то. Но иногда от стоял до последнего несмотря на любые аргументы.
И в команде работала девушка, достаточно давно, у нее была хорошая экспертиза, но в определенный момент ее производительность стала резко проседать, вплоть до того, что она могла недели три сидеть с какой-то одной средненькой задачей.
И вот мы начинаем с другом обсуждать, что с ней делать - она уже особо пользы не приносит в отделе, уговоры не работают. По хорошему - нужно разрывать с ней контракт. С другой стороны - вот сейчас ее уволим, а завтра гендир придет и потребует сокращать расходы, а все остальные прям круто работают и решают кучу проблем. Наша мотивация - сугубо конструктивная, чтобы дела делались, у нас есть фронт работ, полно срочных задач от других отделов, толковых людей и так в обрез. Вот так мы пообсуждали, и остановились на том, что сейчас увольнять ее не будем, а будет она у нас просто тусоваться в качестве "балласта", чтобы когда надо будет сокращать расходы - мы немного посопротивляемся (как обычно, для порядка), а потом скажем - хорошо, так и быть, давайте вот ее уволим (а топовых ребят сохраним).
Чему меня учит эта история - в первую очередь тому, что доверие это база, вокруг которой строятся оптимальные стратегии управления. Очевидно, что если бы гендир умел ставить нормальные цели заранее, доверял аргументации нанятых профессионалов и не пытался "брать на понт", таких субоптимальных решений принимать (страдать херней, прямо скажем) не приходилось бы.
А еще - что не надо думать, что ты дофига умный и хитрее всех других )
В одной компании работал вместе с другом, я тогда был разрабом, а он тимлидом, я его постоянно подменял, мы всё обсуждали как есть.
Там был харизматичный, жадный и при этом вообще ничего не смыслящий в разработке гендир, который немного напоминал своими глупостями сэра Джона Франклина из "Террора" Дэна Симмонса.
Он периодически (достаточно рандомно) приходил с внезапным: "давайте сокращать расходы на Галамент!". У нас команда разработки состояла примерно наполовину из аутстафф сотрудников из другой компании, и вот это было ее название. Это был прям локальный мем. Обычно мы отбивались, это была такая игра "на слабо", если мы сопротивляемся отчаянно - он отстает. Если нет - прожимает уволить кого-то. Но иногда от стоял до последнего несмотря на любые аргументы.
И в команде работала девушка, достаточно давно, у нее была хорошая экспертиза, но в определенный момент ее производительность стала резко проседать, вплоть до того, что она могла недели три сидеть с какой-то одной средненькой задачей.
И вот мы начинаем с другом обсуждать, что с ней делать - она уже особо пользы не приносит в отделе, уговоры не работают. По хорошему - нужно разрывать с ней контракт. С другой стороны - вот сейчас ее уволим, а завтра гендир придет и потребует сокращать расходы, а все остальные прям круто работают и решают кучу проблем. Наша мотивация - сугубо конструктивная, чтобы дела делались, у нас есть фронт работ, полно срочных задач от других отделов, толковых людей и так в обрез. Вот так мы пообсуждали, и остановились на том, что сейчас увольнять ее не будем, а будет она у нас просто тусоваться в качестве "балласта", чтобы когда надо будет сокращать расходы - мы немного посопротивляемся (как обычно, для порядка), а потом скажем - хорошо, так и быть, давайте вот ее уволим (а топовых ребят сохраним).
Чему меня учит эта история - в первую очередь тому, что доверие это база, вокруг которой строятся оптимальные стратегии управления. Очевидно, что если бы гендир умел ставить нормальные цели заранее, доверял аргументации нанятых профессионалов и не пытался "брать на понт", таких субоптимальных решений принимать (страдать херней, прямо скажем) не приходилось бы.
А еще - что не надо думать, что ты дофига умный и хитрее всех других )
👍15❤2🔥1
Следующая история - "Сэкономили на KPI".
Дело было в 2019, компания - средний бизнес, ~200 человек, разработка - 3 команды, человек 25 суммарно.
Главный герой истории - тимлид, устроился за несколько месяцев до этого, зп на тот год по тому стеку неплохая - 220 + 40, которые выходят за счет квартальной премии ("KPI"). Изначально он хотел 250 фикс, но согласился на премию под заверения, что он без проблем ее получит, если будет успешно выполнять свою работу (ну и он подумал - я-то крут, с чего вруг я работу не смогу выполнить).
Думаю, те, кто имеет минимальный опыт с этими ситуациями, уже понимают, куда клонит рассказ %)
К слову, это была его первая руководящая позиция, но это тянет на отдельный пост.
Начинается работа, он выкладывается по полной - разгребает накопившиеся проблемы (несколько месяцев команда была без тимлида). Его личный челлендж - в том числе доказать себе, что он может отлично выполнять работу тимлида. Этакое "сейчас я покажу всем и себе, что я реально могу это". В целом такой человек, которому очень по кайфу кодить плюс хороший от природы лидер, хотя и с довольно хаотичным подходом.
В принципе, всем вокруг, кто более или менее шарит, было очевидно, что выполняется выдающаяся работа (х2 минимум от того, что можно ожидать от рандомного чувака с рынка, даже если просто брать объем, не говоря уже о том, что качество было выше среднего).
Наступает время KPI - барабанная дробь - он получает 70%, а члены его команды, у которых есть KPI - и того меньше.
И тут прикол: казалось бы, сумма смешная, 120*0,3 = 36к. Но это производит эффект плевка в лицо.
Реакция - "это я-то 70%? Ну нихера себе... Отлично, больше никаких переработок, никаких релизов ночью, никаких покодить в выходные, да и вообще чет я слишком много работаю..." А на это еще у него наложились споры с гендиром насчет KPI своих ребят, что тоже добавило негатива к ситуации.
Это был самый идиотски сэкономленный полтинник (если с налогами) - потерянный объем работы на следующий квартал примерно соразмерен наличию дополнительного разраба в команде. Он потом через время немного отошел, так как ему в принципе было самому интересно, но так, как на старте - уже никогда в этой компании не работал.
Лично меня эта история учит многому, весь перечень не поместится в это пост, но давайте основное:
1. Когда в зарплатных переговорах вам зашивают KPI в ваши фикс ожидания - это ред флаг. Есть очень большой риск что не будет так, как вы думаете, в среднем проще устроиться на фикс и не беспокоиться. Воспринимайте в своих расчетах при выборе работы премию как то, чего может не быть.
2. Если цель - эффективная работа и высокое соотношение работы к затратам, то не давать людям то, что они ожидают - практически всегда провальная стратегия.
3. Ощущение справедливости и основанная на ней демотивация - ключевая вещь в понимании того, как обеспечивается производительность в разработке, если речь про топовых людей. Про это еще будет в отдельном посте.
Дело было в 2019, компания - средний бизнес, ~200 человек, разработка - 3 команды, человек 25 суммарно.
Главный герой истории - тимлид, устроился за несколько месяцев до этого, зп на тот год по тому стеку неплохая - 220 + 40, которые выходят за счет квартальной премии ("KPI"). Изначально он хотел 250 фикс, но согласился на премию под заверения, что он без проблем ее получит, если будет успешно выполнять свою работу (ну и он подумал - я-то крут, с чего вруг я работу не смогу выполнить).
Думаю, те, кто имеет минимальный опыт с этими ситуациями, уже понимают, куда клонит рассказ %)
К слову, это была его первая руководящая позиция, но это тянет на отдельный пост.
Начинается работа, он выкладывается по полной - разгребает накопившиеся проблемы (несколько месяцев команда была без тимлида). Его личный челлендж - в том числе доказать себе, что он может отлично выполнять работу тимлида. Этакое "сейчас я покажу всем и себе, что я реально могу это". В целом такой человек, которому очень по кайфу кодить плюс хороший от природы лидер, хотя и с довольно хаотичным подходом.
В принципе, всем вокруг, кто более или менее шарит, было очевидно, что выполняется выдающаяся работа (х2 минимум от того, что можно ожидать от рандомного чувака с рынка, даже если просто брать объем, не говоря уже о том, что качество было выше среднего).
Наступает время KPI - барабанная дробь - он получает 70%, а члены его команды, у которых есть KPI - и того меньше.
И тут прикол: казалось бы, сумма смешная, 120*0,3 = 36к. Но это производит эффект плевка в лицо.
Реакция - "это я-то 70%? Ну нихера себе... Отлично, больше никаких переработок, никаких релизов ночью, никаких покодить в выходные, да и вообще чет я слишком много работаю..." А на это еще у него наложились споры с гендиром насчет KPI своих ребят, что тоже добавило негатива к ситуации.
Это был самый идиотски сэкономленный полтинник (если с налогами) - потерянный объем работы на следующий квартал примерно соразмерен наличию дополнительного разраба в команде. Он потом через время немного отошел, так как ему в принципе было самому интересно, но так, как на старте - уже никогда в этой компании не работал.
Лично меня эта история учит многому, весь перечень не поместится в это пост, но давайте основное:
1. Когда в зарплатных переговорах вам зашивают KPI в ваши фикс ожидания - это ред флаг. Есть очень большой риск что не будет так, как вы думаете, в среднем проще устроиться на фикс и не беспокоиться. Воспринимайте в своих расчетах при выборе работы премию как то, чего может не быть.
2. Если цель - эффективная работа и высокое соотношение работы к затратам, то не давать людям то, что они ожидают - практически всегда провальная стратегия.
3. Ощущение справедливости и основанная на ней демотивация - ключевая вещь в понимании того, как обеспечивается производительность в разработке, если речь про топовых людей. Про это еще будет в отдельном посте.
👍20🔥3
Отстаивать твои границы - это часть твоей роли.
Попадали когда-нибудь в такую ситуацию, что вы уже перегружены, а вам еще наваливают работы? Что чувствовали в этот момент?
У меня была история: я впервые занимал менеджерскую позицию, мне нужно было заниматься 3 отделами разработки, организовывать процессы и т.п. Было довольно много работы, по сути заведомо больше, чем можно сделать, когнитивное напряжение было достаточно сильным, часто было так, что я приходя с работы сразу засыпал на 1-2 часа.
И вот я нахожусь в этих обстоятельствах, все время что-то надо делать, что-то выходит из внимания, много разных контекстов одновременно, и тут пишет техдир (мой руководитель) - прислать какой-то отчет.
Мои ощущения в тот момент:
1. "Дурацкий отчет"
2. "Я и так перегружен, а теперь еще и этим заниматься"
3. Неприязнь к этому запросу
4. Сильное раздражение
И я как-то резко ответил, что явно видно было, что я недоволен и не хочу этого делать.
И вот вопрос - кто в этой ситуации дурак?
Варианты ответов:
1. Тот, кто придумал "дурацкий отчет"
2. Техдир, который у меня его запрашивает
3. Мой менеджер, потому что на мне слишком много работы
4. Я сам, потому что на мне слишком много работы
Правильный ответ - номер 4.
Реальность такова, что никто не сможет отстаивать ваши границы за вас, если только вы не работаете "винтиком", а работаете на сложной комплексной позиции, которой часто является работа менеджера или разработчика.
- У вас есть смежные области знаний
- Рядом всегда "валяются" ничьи зоны ответственности
- Всегда можно сделать что-то лучше
Более того - ты не делаешь этим лучше окружающим!
Но остается вопрос - а почему, если это важно, то это не зона ответственности менеджера - организовать работу так, чтобы на тебе не было перегрузки?
Во-первых, менеджер может бытьмудак из тех людей, которые не особо рефлексируют и просто накидывают до тех пор, пока не встретят сопротивление.
Во-вторых, вообще-то никто кроме тебя не знает в точности весь объем того, чем ты занимаешься. В работе, опирающейся на знания - никогда.
Ну и в третьих, если сам не сделаешь - никто не гарантирует, что это будет сделано или будет сделано хорошо. Полагаться на себя в этом вопросе - просто более эффективный способ достижения результата.
Итак:
Если ты менеджер, то отстаивать твои границы - это часть твоей роли
Попадали когда-нибудь в такую ситуацию, что вы уже перегружены, а вам еще наваливают работы? Что чувствовали в этот момент?
У меня была история: я впервые занимал менеджерскую позицию, мне нужно было заниматься 3 отделами разработки, организовывать процессы и т.п. Было довольно много работы, по сути заведомо больше, чем можно сделать, когнитивное напряжение было достаточно сильным, часто было так, что я приходя с работы сразу засыпал на 1-2 часа.
И вот я нахожусь в этих обстоятельствах, все время что-то надо делать, что-то выходит из внимания, много разных контекстов одновременно, и тут пишет техдир (мой руководитель) - прислать какой-то отчет.
Мои ощущения в тот момент:
1. "Дурацкий отчет"
2. "Я и так перегружен, а теперь еще и этим заниматься"
3. Неприязнь к этому запросу
4. Сильное раздражение
И я как-то резко ответил, что явно видно было, что я недоволен и не хочу этого делать.
И вот вопрос - кто в этой ситуации дурак?
Варианты ответов:
1. Тот, кто придумал "дурацкий отчет"
2. Техдир, который у меня его запрашивает
3. Мой менеджер, потому что на мне слишком много работы
4. Я сам, потому что на мне слишком много работы
Правильный ответ - номер 4.
Реальность такова, что никто не сможет отстаивать ваши границы за вас, если только вы не работаете "винтиком", а работаете на сложной комплексной позиции, которой часто является работа менеджера или разработчика.
- У вас есть смежные области знаний
- Рядом всегда "валяются" ничьи зоны ответственности
- Всегда можно сделать что-то лучше
Более того - ты не делаешь этим лучше окружающим!
Но остается вопрос - а почему, если это важно, то это не зона ответственности менеджера - организовать работу так, чтобы на тебе не было перегрузки?
Во-первых, менеджер может быть
Во-вторых, вообще-то никто кроме тебя не знает в точности весь объем того, чем ты занимаешься. В работе, опирающейся на знания - никогда.
Ну и в третьих, если сам не сделаешь - никто не гарантирует, что это будет сделано или будет сделано хорошо. Полагаться на себя в этом вопросе - просто более эффективный способ достижения результата.
Итак:
Если ты менеджер, то отстаивать твои границы - это часть твоей роли
👍15🔥2🤔2🤡1🥱1
Сегодня мы пробили первую сотку подписчиков - респект всем, кто присоединился. Отмечаем это событие дополнительным постом )
Стряхнул пыль со статьи 2020 года, которую тогда написал "в стол". Настал ее день, предлагаю вашему вниманию: ссылка
Стряхнул пыль со статьи 2020 года, которую тогда написал "в стол". Настал ее день, предлагаю вашему вниманию: ссылка
Pavel Palagin
Пришел на новое место, "всё плохо". С чего начать?
Тема статьи - как в обстановке хаоса выбрать перечень организационных работ и расставить приоритеты.
👍10🔥2👏2
Эволюция разработчика.
Слыхали такое, что разработчики должны быть инициативными, увлеченными, продуктивными, а еще желательно лояльными?
Много кому нужны такие. А что-то их мало. Почему вдруг?
Давайте я расскажу вам стандартный путь эволюции сознания, который проходят очень многие разрабы.
Возьмем человека, который обладает всеми этими качествами - инициативный, вовлеченный, крутой и продуктивный, при этом очень скромный и лояльный. На своем карьерном пути этот человек проходит, назовем это так, Испытания.
Испытание вовлеченности
Приходит наш герой на первую работу. Немного поработав, видит - это не так, это можно улучшить, вот это сделать можно эффективнее. Начинает говорить об этом другим, пишет предложения, выходит далеко за рамки своей зоны ответственности. А его предложения игнорят, например. Или спрашивают - у тебя что, работы нет? А бывает - просто повесят на него одного решение найденной общей проблемы. И вот так он помыкается немного, да и перестанет. Теперь он делает то, что сказано.
Испытание скромности
Приходит наш герой на вторую работу (пока еще не одновременно). Трудится, показывает класс, пилит фичи, приносит пользу, качает харды. Думает: буду хорошо работать - меня оценят. Про повышения не спрашивает. Что нужно сделать, чтобы получить больше денег - тоже. И как-то так странно выходит, что через время его зарплата уже сильно ниже рынка. Он думает - так, ну я тут уже имею экспертизу, работаю неплохо, всем всё нравится. Очевидно, я имею ценность гораздо выше для компании, чем какой-то новый человек с рынка. Получается, мне должны даже больше рынка платить? А у меня меньше. Пойду спрошу... А ответ - "давай подождем перформанс ревью, думаю на 20% получится поднять". И вот наш герой понимает, что оптимальный способ держаться в рынке - менять работу. Теперь он джоб-хоппер.
Испытание силы
Приходит наш герой на третью работу. Еще немного поработав, видит - да я же хорош. Я делаю в три раза больше соседа, шарю в продукте лучше, самые сложные задачи дают мне. А ну-ка я узнаю, какая у этого соседа зарплата. Такая же (или на 20% ниже). Опа... Возникают мысли - если я делаю х3, то почему я получаю не х3? Пообщаешься с руководителем - х3 или даже х2 не дадут. От силы процентов 30 накинут. И что-то как-то уже не очень хочется х3 выдавать. Зачем? Буду делать х1,5 - один фиг буду топ в команде, и еще хвалить будут. А куда половину времени девать - можно отдохнуть, поделать пет-проекты, заняться саморазвитием или фрилансом. Или найти вторую работу. Теперь он средний сеньор с рынка. Эволюция завершена.
А теперь, как говорится, кто в этой ситуации дурак? Что-то мне подсказывает, что не наш герой.
Слыхали такое, что разработчики должны быть инициативными, увлеченными, продуктивными, а еще желательно лояльными?
Много кому нужны такие. А что-то их мало. Почему вдруг?
Давайте я расскажу вам стандартный путь эволюции сознания, который проходят очень многие разрабы.
Возьмем человека, который обладает всеми этими качествами - инициативный, вовлеченный, крутой и продуктивный, при этом очень скромный и лояльный. На своем карьерном пути этот человек проходит, назовем это так, Испытания.
Испытание вовлеченности
Приходит наш герой на первую работу. Немного поработав, видит - это не так, это можно улучшить, вот это сделать можно эффективнее. Начинает говорить об этом другим, пишет предложения, выходит далеко за рамки своей зоны ответственности. А его предложения игнорят, например. Или спрашивают - у тебя что, работы нет? А бывает - просто повесят на него одного решение найденной общей проблемы. И вот так он помыкается немного, да и перестанет. Теперь он делает то, что сказано.
Испытание скромности
Приходит наш герой на вторую работу (пока еще не одновременно). Трудится, показывает класс, пилит фичи, приносит пользу, качает харды. Думает: буду хорошо работать - меня оценят. Про повышения не спрашивает. Что нужно сделать, чтобы получить больше денег - тоже. И как-то так странно выходит, что через время его зарплата уже сильно ниже рынка. Он думает - так, ну я тут уже имею экспертизу, работаю неплохо, всем всё нравится. Очевидно, я имею ценность гораздо выше для компании, чем какой-то новый человек с рынка. Получается, мне должны даже больше рынка платить? А у меня меньше. Пойду спрошу... А ответ - "давай подождем перформанс ревью, думаю на 20% получится поднять". И вот наш герой понимает, что оптимальный способ держаться в рынке - менять работу. Теперь он джоб-хоппер.
Испытание силы
Приходит наш герой на третью работу. Еще немного поработав, видит - да я же хорош. Я делаю в три раза больше соседа, шарю в продукте лучше, самые сложные задачи дают мне. А ну-ка я узнаю, какая у этого соседа зарплата. Такая же (или на 20% ниже). Опа... Возникают мысли - если я делаю х3, то почему я получаю не х3? Пообщаешься с руководителем - х3 или даже х2 не дадут. От силы процентов 30 накинут. И что-то как-то уже не очень хочется х3 выдавать. Зачем? Буду делать х1,5 - один фиг буду топ в команде, и еще хвалить будут. А куда половину времени девать - можно отдохнуть, поделать пет-проекты, заняться саморазвитием или фрилансом. Или найти вторую работу. Теперь он средний сеньор с рынка. Эволюция завершена.
А теперь, как говорится, кто в этой ситуации дурак? Что-то мне подсказывает, что не наш герой.
🔥12💯9👍7
История о коррупции внутри коммерческих компаний
Коррупция начинается с чьего-то Желания. Страстишки.
В этом случае желание было - отказаться от 1С как части бэкенд-системы.
Если в норме ты нанимаешь профессионала, чтобы он использовал свою экспертизу для предложения лучшего решения, то в случае Желания - всё может быть ровно наоборот.
Собственник нанимает одного технического директора - тот оценивает ситуацию и говорит - так делать нельзя, будет хуже. Собственник ругается с ним, техдир уходит. Нанимается следующий. Тот оценивает ситуацию, находит через свои связи подрядчика, подрядчик говорит ему "слушай, ну мы можем вас ограбить, но ты меня знаешь, и я тебе говорю - вам это не нужно". Второй техдир уходит, приходит следующий.
Так происходит, пока не появляется некий человек, который скажет ровно то, что владелец компании хочет услышать, даже если это неправда.
Появляется команда "трансформации", под нее нанимается еще несколько дорогих челиков с зп х1.5 от сеньор разраба, они рисуют схемы, строят roadmap на год, очень оптимистичный. Шарящие разрабы и лиды компании, глянув на этот план, уже через 5 минут понимают, что это всё чушь и профанация. Что так не будет. И тем более не будет в эти сроки.
Что с этим можно сделать? Как правило - ничего. На собственника прямого выхода нет, для него ты просто ноунейм исполнитель. Будет твое слово против слова "архитектора", который уже присел на уши и имеет вес в глазах владельца компании, потому что реализует его Желание. А "слово против слова" это обычно плохой план. Репортишь своему руководителю, и на этом обычно всё.
Ситуация обрастает локальными мемами и превращается в шоу. Между собой мы следим за неизбежным провалом инициативы и шутим над ее прогрессом. Мы понимаем, что модные челы просто говорят красивые слова, тянут из компании бабки, продавая надежду.
Год идет, все планы ожидаемо едут. Год заканчивается - по факту не сделано практически ничего. Ближе к сроку челы из команды трансформации просто уходят в другие компании.
Новый год - угадайте что? Делается новый roadmap, почти такой же, как старый. Находятся другие люди, которые готовы начать эту песню с начала.
Спустя несколько лет мне стало любопытно, завершился ли проект "трансформации" в той компании - нет, его потом просто закрыли. Спалили пару сотен k баксов и норм.
Чему это учит? Давайте попробуем накинуть несколько вариантов:
➖владелец компании - не всевидящий бог, который верной рукой ведет компанию к успеху сквозь айсберги провалов. Это обычный человек, который может ошибаться, которого могут обманывать и разводить
➖единственная реальная характеристика, которая определяет, будет ли кто-то топ-менеджером - умение понравиться руководителю. Делается это за счет красивых слов или высокой компетенции - это уже ситуативно. Посудите сами, если ты классный, но руководитель не считает, что ты классный - очевидно он тебя и не возьмет
➖коррупция и паразитизм есть не только в госухе. На 99% уверен, что челы прекрасно понимали, что они делают, что проект не взлетит, и не имели цели профессионально решать проблемы компании
➖надо понимать, что за вывеской "мы делаем общее дело" и "всё ради результатов" среди менеджмента кроется полно людей, которые играют в win-lose pvp игру, борются за ресурсы для себя (или себя и своей "бригады") в ущерб остальным, прикрываясь красивой риторикой
Вообще тема обширная, я думаю мы к ней еще не раз вернемся.
Коррупция начинается с чьего-то Желания. Страстишки.
В этом случае желание было - отказаться от 1С как части бэкенд-системы.
Если в норме ты нанимаешь профессионала, чтобы он использовал свою экспертизу для предложения лучшего решения, то в случае Желания - всё может быть ровно наоборот.
Собственник нанимает одного технического директора - тот оценивает ситуацию и говорит - так делать нельзя, будет хуже. Собственник ругается с ним, техдир уходит. Нанимается следующий. Тот оценивает ситуацию, находит через свои связи подрядчика, подрядчик говорит ему "слушай, ну мы можем вас ограбить, но ты меня знаешь, и я тебе говорю - вам это не нужно". Второй техдир уходит, приходит следующий.
Так происходит, пока не появляется некий человек, который скажет ровно то, что владелец компании хочет услышать, даже если это неправда.
Появляется команда "трансформации", под нее нанимается еще несколько дорогих челиков с зп х1.5 от сеньор разраба, они рисуют схемы, строят roadmap на год, очень оптимистичный. Шарящие разрабы и лиды компании, глянув на этот план, уже через 5 минут понимают, что это всё чушь и профанация. Что так не будет. И тем более не будет в эти сроки.
Что с этим можно сделать? Как правило - ничего. На собственника прямого выхода нет, для него ты просто ноунейм исполнитель. Будет твое слово против слова "архитектора", который уже присел на уши и имеет вес в глазах владельца компании, потому что реализует его Желание. А "слово против слова" это обычно плохой план. Репортишь своему руководителю, и на этом обычно всё.
Ситуация обрастает локальными мемами и превращается в шоу. Между собой мы следим за неизбежным провалом инициативы и шутим над ее прогрессом. Мы понимаем, что модные челы просто говорят красивые слова, тянут из компании бабки, продавая надежду.
Год идет, все планы ожидаемо едут. Год заканчивается - по факту не сделано практически ничего. Ближе к сроку челы из команды трансформации просто уходят в другие компании.
Новый год - угадайте что? Делается новый roadmap, почти такой же, как старый. Находятся другие люди, которые готовы начать эту песню с начала.
Спустя несколько лет мне стало любопытно, завершился ли проект "трансформации" в той компании - нет, его потом просто закрыли. Спалили пару сотен k баксов и норм.
Чему это учит? Давайте попробуем накинуть несколько вариантов:
➖владелец компании - не всевидящий бог, который верной рукой ведет компанию к успеху сквозь айсберги провалов. Это обычный человек, который может ошибаться, которого могут обманывать и разводить
➖единственная реальная характеристика, которая определяет, будет ли кто-то топ-менеджером - умение понравиться руководителю. Делается это за счет красивых слов или высокой компетенции - это уже ситуативно. Посудите сами, если ты классный, но руководитель не считает, что ты классный - очевидно он тебя и не возьмет
➖коррупция и паразитизм есть не только в госухе. На 99% уверен, что челы прекрасно понимали, что они делают, что проект не взлетит, и не имели цели профессионально решать проблемы компании
➖надо понимать, что за вывеской "мы делаем общее дело" и "всё ради результатов" среди менеджмента кроется полно людей, которые играют в win-lose pvp игру, борются за ресурсы для себя (или себя и своей "бригады") в ущерб остальным, прикрываясь красивой риторикой
Вообще тема обширная, я думаю мы к ней еще не раз вернемся.
👍22❤4🔥3🤔1🤝1
Выбор правильного решения на простом кейсе
Собесили тимлида backend. Только открыли найм - сразу попался один хороший кандидат (что редкость).
Прошел поведенческое интервью, прошел техническое, дополнительно провели архитектурное. Всё хорошо, его фидбек - тоже всё нравится. Согласовал деньги. Жду пока HR сделает оффер, уже радуюсь, что повезло долго не возиться.
И тут бах - кандидат отлетает. Узнаю причину. После интервью в процессе найма идет этап сбора и проверки рекомендаций. Ждал просто завершения формальностей. Парень дал рекомендации без вопросов, рекомендации были проверены, всё хорошо. И на этапе оффера - минус. Причина - не хочу начинать отношения с компанией с недоверия.
Я сначала такой "что?..". Сначала просто удивился. Думаю - странная фигня какая-то. Поговорил сам с человеком. Потом немного подумал и первый вывод - "странный тип какой-то, может и лучше, что не взяли, вылезло бы что-то еще". Несколько чел внутри компании отреагировали так же. Думаю для большинства история здесь бы и закончилась %) Но я стал думать дальше.
Во-первых, по себе судить нельзя (по крайней мере в менеджменте). Мне стало интересно - вот если хотя бы для одного человека в этом есть что-то плохое, то надо понять вообще масштаб явления. Что думают разные люди?
Для этого мне нужен кто-то непредвзятый. В следующие дней десять было несколько встреч в рамках нетворкинга. Рассказывал этот кейс и смотрел, как люди оценивают ситуацию и примеряют ее на себя.
Получил 2-3 ответа, из них один информативный - человек сказал, что он бы рекомендации сделал, но в целом он воспринимает это как тупость (потому что можно дать контакты друзей) и неуважение (потому что проверяйте мои скиллы, а не что какой-то левый чел про меня скажет). Я посомневался (опять же, потому что я сам ощущаю это иначе), но в итоге - звучит легитимно.
Окей, допустим, есть какая-то часть народу, для которых сбор рекомендаций - минус. Тогда надо проанализировать - а зачем этот этап вообще существует?
Я прикинул и сделал вывод, что процесс собеседования существует ради всего двух целей:
1. отсеивание неподходящих людей
2. конкуренция с другими компаниями
Если этап не делает существенный вклад ни в одну из этих целей, значит этого этапа не должно быть.
Со вторым пунктом понятно - никакого вклада в конкуренцию с другими за кандидатов это не дает, скорее мешает.
Как это работает на отсев?
1. Сначала возьмем людей c хорошими намерениями - мы тут ничего не выясняем нового
2. Люди с плохими намерениями - если они не тупые - поймут что надо дать телефоны тех, кто не скажет про них что-то плохое. Например, контакты друзей
3. Что остается: люди с плохими намерениями и которым при этом либо вообще настолько пофиг на эту работу, что даже лень заморачиваться, либо они слишком тупые, чтобы дать контакты тех, кто скажет про них что-то критично плохое
Звучит как будто в 3 случае мы так и так на других этапах это должны заметить )
В сухом остатке - пользы нет или она мизерная, издержки есть. Вывод - надо это выкинуть на мусорку.
Встретились с Head of HR и рекрутером, единогласно решили убрать этап.
Строго говоря, мне мои аргументы и анализ не понадобились, чтобы решить этот кейс )) HR оказался достаточно компетентным, чтобы сделать тот же вывод исходя просто из своего опыта и экспертизы. Но бывает по разному, на мой взгляд - лучше быть всегда готовым аргументированно отстоять правильную позицию. Тогда даже если будет принято нерациональное решение - по крайней мере ты отработал профессионально.
Несколько выводов:
➖не нужно судить поведение других людей по себе и слепо доверять своим ощущениям
➖сталкиваясь с непонятными ситуациями, можно сделать ресерч, в том числе за пределами компании
➖критично выкидывать что-то неэффективное из работы может быть важнее, чем в нее что-то добавлять
➖(дело вкуса, но) лучше лишний раз подготовиться к дискуссии, которая не состоится, чем прийти на дебаты голым
Собесили тимлида backend. Только открыли найм - сразу попался один хороший кандидат (что редкость).
Прошел поведенческое интервью, прошел техническое, дополнительно провели архитектурное. Всё хорошо, его фидбек - тоже всё нравится. Согласовал деньги. Жду пока HR сделает оффер, уже радуюсь, что повезло долго не возиться.
И тут бах - кандидат отлетает. Узнаю причину. После интервью в процессе найма идет этап сбора и проверки рекомендаций. Ждал просто завершения формальностей. Парень дал рекомендации без вопросов, рекомендации были проверены, всё хорошо. И на этапе оффера - минус. Причина - не хочу начинать отношения с компанией с недоверия.
Я сначала такой "что?..". Сначала просто удивился. Думаю - странная фигня какая-то. Поговорил сам с человеком. Потом немного подумал и первый вывод - "странный тип какой-то, может и лучше, что не взяли, вылезло бы что-то еще". Несколько чел внутри компании отреагировали так же. Думаю для большинства история здесь бы и закончилась %) Но я стал думать дальше.
Во-первых, по себе судить нельзя (по крайней мере в менеджменте). Мне стало интересно - вот если хотя бы для одного человека в этом есть что-то плохое, то надо понять вообще масштаб явления. Что думают разные люди?
Для этого мне нужен кто-то непредвзятый. В следующие дней десять было несколько встреч в рамках нетворкинга. Рассказывал этот кейс и смотрел, как люди оценивают ситуацию и примеряют ее на себя.
Получил 2-3 ответа, из них один информативный - человек сказал, что он бы рекомендации сделал, но в целом он воспринимает это как тупость (потому что можно дать контакты друзей) и неуважение (потому что проверяйте мои скиллы, а не что какой-то левый чел про меня скажет). Я посомневался (опять же, потому что я сам ощущаю это иначе), но в итоге - звучит легитимно.
Окей, допустим, есть какая-то часть народу, для которых сбор рекомендаций - минус. Тогда надо проанализировать - а зачем этот этап вообще существует?
Я прикинул и сделал вывод, что процесс собеседования существует ради всего двух целей:
1. отсеивание неподходящих людей
2. конкуренция с другими компаниями
Если этап не делает существенный вклад ни в одну из этих целей, значит этого этапа не должно быть.
Со вторым пунктом понятно - никакого вклада в конкуренцию с другими за кандидатов это не дает, скорее мешает.
Как это работает на отсев?
1. Сначала возьмем людей c хорошими намерениями - мы тут ничего не выясняем нового
2. Люди с плохими намерениями - если они не тупые - поймут что надо дать телефоны тех, кто не скажет про них что-то плохое. Например, контакты друзей
3. Что остается: люди с плохими намерениями и которым при этом либо вообще настолько пофиг на эту работу, что даже лень заморачиваться, либо они слишком тупые, чтобы дать контакты тех, кто скажет про них что-то критично плохое
Звучит как будто в 3 случае мы так и так на других этапах это должны заметить )
В сухом остатке - пользы нет или она мизерная, издержки есть. Вывод - надо это выкинуть на мусорку.
Встретились с Head of HR и рекрутером, единогласно решили убрать этап.
Строго говоря, мне мои аргументы и анализ не понадобились, чтобы решить этот кейс )) HR оказался достаточно компетентным, чтобы сделать тот же вывод исходя просто из своего опыта и экспертизы. Но бывает по разному, на мой взгляд - лучше быть всегда готовым аргументированно отстоять правильную позицию. Тогда даже если будет принято нерациональное решение - по крайней мере ты отработал профессионально.
Несколько выводов:
➖не нужно судить поведение других людей по себе и слепо доверять своим ощущениям
➖сталкиваясь с непонятными ситуациями, можно сделать ресерч, в том числе за пределами компании
➖критично выкидывать что-то неэффективное из работы может быть важнее, чем в нее что-то добавлять
➖(дело вкуса, но) лучше лишний раз подготовиться к дискуссии, которая не состоится, чем прийти на дебаты голым
👍19🔥4
Почему делегирование - фундаментально всратая концепция
Почти каждый наверно слышал - "нужно делегировать". Этот банальный тейк гуляет везде много лет, но как будто бы не очень помогает людям. Куда ни посмотришь - везде легко найдешь кучу перегруженых лидов и других руководителей. Они что, не слышали, что нужно/можно делегировать? %))
Наверно, проблема тогда в чем-то другом. Да и вообще, тезис про "нужно делегировать" существует не последние несколько лет, он существовал и 50 лет назад, и больше.
Суть в том, что делегирование - это фундаментально всратая концепция. Это, что называется, костыль. И он направляет тебя изначально в другом направлении.
Делегирование, если упрощенно - это когда ты передаешь часть своей работы другому. В чем проблема при такой постановке, что может пойти не так? Например:
➖ты продолжишь чувствовать за эту работу ответственность. Будешь нервничать, что сделано хуже, чем сам бы сделал, перепроверять, возможно даже переделывать
➖будешь чувствовать себя неловко, аморально, передавая человеку, у которого уже своя работа есть, еще и свою работу. Тогда будешь чувствовать себя неправым и закончится тем, что "лучше сам сделаю"
➖перфекционизм помешает. Чаще всего будет так (либо казаться, либо реально), что другой не так поймет, сделает хуже - опять "лучше сам сделаю"
Ну а кроме того, делегировать - это тоже довольно приличный объем микроменеджмента - выбирать что делегировать, кому, объяснять, потом проверять результат.
Так и получается, что можно 50 лет говорить, что "нужно делегировать", а воз и ныне там. Думаете, что 50 лет назад меньше делегировали, чем сегодня? )
Ну а какая альтернатива тогда, типа как правильно?
Изи. Нужно наоборот ставить вопрос: пишешь все, что делаешь на своей роли (список), смотришь на него и задаешь себе вопрос: "что из этого могу делать не я?".
Получается какой-то список функций. И все это раздаешь в другие роли внутри своей команды.
Еще раз - если ты чувствуешь перегрузку, то все, что можешь делать не ты, должен делать не ты. И так будет лучше для всех в команде.
То есть, вместо управления потоками работы и полномочий, мы проектируем сбалансированные зоны ответственности, после чего нам не нужно постоянно делегировать.
Зафиксируем: частое делегирование - признак неверно спроектированных ролей в команде.
Давай на примере теперь.
Ты тимлид. Администрируешь команду, делаешь ревью всех задач, делаешь техническую валидацию всех влетающих задач, собираешь релизы и делаешь деплой, проводишь 1-1, собесы, проектируешь архитектуру, пишешь отчеты для руководства, проводишь дейлики, сидишь на встречах, смотришь за перформансом членов своей команды, мониторишь доску, разруливаешь инциденты на проде... все, приехали. Классика.
Заканчивается тем, что ты что-то упускаешь, членам твоей команды становится сложнее тебя дозваться, когда ты реально нужен, начинают деградировать какие-то из твоих ключевых функций (те, которые кроме тебя реально никто не может сделать). А еще к этому всему жестко выгораешь. Копится стресс, слетает колпак.
Садишься, выписываешь все, что делаешь.
Ревью - распределяешь по команде, теперь каждый сколько-нибудь опытный разработчик делает ревью другим, а на тебя эскалируют только если возникают спорные вопросы.
Подготовку релиза (а может и сам релиз) отдаешь любым разрабам, хоть с небольшим опытом.
Дейлики отменяешь или делаешь их автономными от тебя.
Контроль статусов своих задач на доске включаешь в роль разработчика.
Отменяешь все встречи типа "синк" без ясной повестки.
Проектирование включаешь в роль миддл+ разработчика, а сам только делаешь ревью того, что получается.
Если надо - идешь пробиваешь плюшки для тех, кто берет это на себя. Опционально вводишь тайтлы типа техлида для тех, кто особо отличается.
Если для коллеги это что-то совершенно новое, менторишь по стандарту:
1. Делаешь сам, коллега смотрит, ты объясняешь логику своих действий
2. Коллега делает и объясняет, ты смотришь
3. Коллега делает без тебя, сообщает тебе о результате
4. Коллега делает сам автономно, сообщает только в случае возникновения проблем
Почти каждый наверно слышал - "нужно делегировать". Этот банальный тейк гуляет везде много лет, но как будто бы не очень помогает людям. Куда ни посмотришь - везде легко найдешь кучу перегруженых лидов и других руководителей. Они что, не слышали, что нужно/можно делегировать? %))
Наверно, проблема тогда в чем-то другом. Да и вообще, тезис про "нужно делегировать" существует не последние несколько лет, он существовал и 50 лет назад, и больше.
Суть в том, что делегирование - это фундаментально всратая концепция. Это, что называется, костыль. И он направляет тебя изначально в другом направлении.
Делегирование, если упрощенно - это когда ты передаешь часть своей работы другому. В чем проблема при такой постановке, что может пойти не так? Например:
➖ты продолжишь чувствовать за эту работу ответственность. Будешь нервничать, что сделано хуже, чем сам бы сделал, перепроверять, возможно даже переделывать
➖будешь чувствовать себя неловко, аморально, передавая человеку, у которого уже своя работа есть, еще и свою работу. Тогда будешь чувствовать себя неправым и закончится тем, что "лучше сам сделаю"
➖перфекционизм помешает. Чаще всего будет так (либо казаться, либо реально), что другой не так поймет, сделает хуже - опять "лучше сам сделаю"
Ну а кроме того, делегировать - это тоже довольно приличный объем микроменеджмента - выбирать что делегировать, кому, объяснять, потом проверять результат.
Так и получается, что можно 50 лет говорить, что "нужно делегировать", а воз и ныне там. Думаете, что 50 лет назад меньше делегировали, чем сегодня? )
Ну а какая альтернатива тогда, типа как правильно?
Изи. Нужно наоборот ставить вопрос: пишешь все, что делаешь на своей роли (список), смотришь на него и задаешь себе вопрос: "что из этого могу делать не я?".
Получается какой-то список функций. И все это раздаешь в другие роли внутри своей команды.
Еще раз - если ты чувствуешь перегрузку, то все, что можешь делать не ты, должен делать не ты. И так будет лучше для всех в команде.
То есть, вместо управления потоками работы и полномочий, мы проектируем сбалансированные зоны ответственности, после чего нам не нужно постоянно делегировать.
Зафиксируем: частое делегирование - признак неверно спроектированных ролей в команде.
Давай на примере теперь.
Ты тимлид. Администрируешь команду, делаешь ревью всех задач, делаешь техническую валидацию всех влетающих задач, собираешь релизы и делаешь деплой, проводишь 1-1, собесы, проектируешь архитектуру, пишешь отчеты для руководства, проводишь дейлики, сидишь на встречах, смотришь за перформансом членов своей команды, мониторишь доску, разруливаешь инциденты на проде... все, приехали. Классика.
Заканчивается тем, что ты что-то упускаешь, членам твоей команды становится сложнее тебя дозваться, когда ты реально нужен, начинают деградировать какие-то из твоих ключевых функций (те, которые кроме тебя реально никто не может сделать). А еще к этому всему жестко выгораешь. Копится стресс, слетает колпак.
Садишься, выписываешь все, что делаешь.
Ревью - распределяешь по команде, теперь каждый сколько-нибудь опытный разработчик делает ревью другим, а на тебя эскалируют только если возникают спорные вопросы.
Подготовку релиза (а может и сам релиз) отдаешь любым разрабам, хоть с небольшим опытом.
Дейлики отменяешь или делаешь их автономными от тебя.
Контроль статусов своих задач на доске включаешь в роль разработчика.
Отменяешь все встречи типа "синк" без ясной повестки.
Проектирование включаешь в роль миддл+ разработчика, а сам только делаешь ревью того, что получается.
Если надо - идешь пробиваешь плюшки для тех, кто берет это на себя. Опционально вводишь тайтлы типа техлида для тех, кто особо отличается.
Если для коллеги это что-то совершенно новое, менторишь по стандарту:
1. Делаешь сам, коллега смотрит, ты объясняешь логику своих действий
2. Коллега делает и объясняет, ты смотришь
3. Коллега делает без тебя, сообщает тебе о результате
4. Коллега делает сам автономно, сообщает только в случае возникновения проблем
👍17🔥4❤3👏2
(продолжение)
Для каких случаев остается делегирование:
1. Проверка гипотезы. Думая над изменением роли, 1-2 раза делегируешь кому-то какую-то работу для проверки.
2. Уходишь в отпуск - делегируешь на время своего отсутствия свою работу.
3. Разовые крупные активности (условно какой-то квартальный отчет), которые стоит сделать коллективно, но которые не стоят перекраивания ролей.
В инструкциях по безопасности самолета написано следующее:
"В случае разгерметизации салона наденьте кислородную маску сначала на себя, затем помогите надеть её ребёнку или тем, кто нуждается в помощи."
Кислород здесь - это время для внимания, размышления, концентрации и выполнения работы. Если вы несете ответственность за команду - сначала спасите себя, потом помогайте другим. Если себя спасти не можете - то и другим не поможете.
Для каких случаев остается делегирование:
1. Проверка гипотезы. Думая над изменением роли, 1-2 раза делегируешь кому-то какую-то работу для проверки.
2. Уходишь в отпуск - делегируешь на время своего отсутствия свою работу.
3. Разовые крупные активности (условно какой-то квартальный отчет), которые стоит сделать коллективно, но которые не стоят перекраивания ролей.
В инструкциях по безопасности самолета написано следующее:
"В случае разгерметизации салона наденьте кислородную маску сначала на себя, затем помогите надеть её ребёнку или тем, кто нуждается в помощи."
Кислород здесь - это время для внимания, размышления, концентрации и выполнения работы. Если вы несете ответственность за команду - сначала спасите себя, потом помогайте другим. Если себя спасти не можете - то и другим не поможете.
👍14🔥5❤1
Мотивация... или демотивация?
Есть много инфы про мотивацию сотрудников для менеджеров. У людей на местах, с другой стороны, сложился стереотип о мотивации как о морковке, подвешенной перед ослом. Среди специалистов словосочетание "замотивировать сотрудников" имеет скорее нагативную коннотацию - из-за корпоративной пропаганды, пустых обещаний и манипуляций.
Если отбросить мусор, то в сухом остатке "мотивация" это психологическое состояние человека и его желание/нежелание делать что-либо.
Здесь есть фокус - пока мейнстрим сконцентрирован на обсуждении как "замотивировать" кого-то, по факту основное влияние на мотивацию команды оказывают демотивирующие действия.
Давайте представим что есть некие условные единицы мотивации. Максимально заряженный человек - 100 единиц, "не хочу ничего делать" - 0 единиц.
Сравните стоимость в единицах мотивации:
➖Похвалили vs. оскорбили
➖Дали денег сверху vs. не дали то что обещали
➖Оказали уважение vs. выразили неуважение
➖Внимательно выслушали предложение vs. не стали слушать
➖Получаю сверх ожиданий vs. не получаю того что заслуживаю
➖Хорошее отношение ко мне vs. несправедливое отношение
Можно заметить (можно же?), что практически в каждом примере "стоимость" будет выше у демотивирующих действий в несколько раз.
Далее, есть мотивация внутренняя (основанная на ценностях человека и его собственных представлениях) и внешняя (обусловленная факторами среды).
Например, если человек считает правильным профессионально выполнить задачу - это внутренняя мотивация. Если ему безразлично, и сделает он это только из под палки или за пряник - это внешняя.
Есть некоторое условное "естественное" состояние, в котором человек не демотивирован ничем, и находится на уровне своей внутренней мотивации. От этого состояния вверх что-то вытянуть крайне сложно. От него опуститься вниз - очень легко.
Исходя из этого, самая верная стратегия построения сильной команды - искать людей с высокой внутренней мотивацией и - не демотивировать их.
Альтернатива может быть крайне печальной - вы сами выгорите от того, что надо стоять над душой у других людей, "подпинывая" их, чтобы сделали то, что надо, и задаваясь вопросом "мне что, одному здесь что-то надо?"
Дальше возникает вопрос - а как понять, что демотивирует людей? Об этом будет в продолжении, в следующем посте.
Есть много инфы про мотивацию сотрудников для менеджеров. У людей на местах, с другой стороны, сложился стереотип о мотивации как о морковке, подвешенной перед ослом. Среди специалистов словосочетание "замотивировать сотрудников" имеет скорее нагативную коннотацию - из-за корпоративной пропаганды, пустых обещаний и манипуляций.
Если отбросить мусор, то в сухом остатке "мотивация" это психологическое состояние человека и его желание/нежелание делать что-либо.
Здесь есть фокус - пока мейнстрим сконцентрирован на обсуждении как "замотивировать" кого-то, по факту основное влияние на мотивацию команды оказывают демотивирующие действия.
Давайте представим что есть некие условные единицы мотивации. Максимально заряженный человек - 100 единиц, "не хочу ничего делать" - 0 единиц.
Сравните стоимость в единицах мотивации:
➖Похвалили vs. оскорбили
➖Дали денег сверху vs. не дали то что обещали
➖Оказали уважение vs. выразили неуважение
➖Внимательно выслушали предложение vs. не стали слушать
➖Получаю сверх ожиданий vs. не получаю того что заслуживаю
➖Хорошее отношение ко мне vs. несправедливое отношение
Можно заметить (можно же?), что практически в каждом примере "стоимость" будет выше у демотивирующих действий в несколько раз.
Далее, есть мотивация внутренняя (основанная на ценностях человека и его собственных представлениях) и внешняя (обусловленная факторами среды).
Например, если человек считает правильным профессионально выполнить задачу - это внутренняя мотивация. Если ему безразлично, и сделает он это только из под палки или за пряник - это внешняя.
Есть некоторое условное "естественное" состояние, в котором человек не демотивирован ничем, и находится на уровне своей внутренней мотивации. От этого состояния вверх что-то вытянуть крайне сложно. От него опуститься вниз - очень легко.
Исходя из этого, самая верная стратегия построения сильной команды - искать людей с высокой внутренней мотивацией и - не демотивировать их.
Альтернатива может быть крайне печальной - вы сами выгорите от того, что надо стоять над душой у других людей, "подпинывая" их, чтобы сделали то, что надо, и задаваясь вопросом "мне что, одному здесь что-то надо?"
Дальше возникает вопрос - а как понять, что демотивирует людей? Об этом будет в продолжении, в следующем посте.
👍10🔥3❤2
Итак, допустим мы не хотим демотивировать людей, и пытаемся лучше понять, что их демотивирует.
Сразу отбросим рабочие, но не очень доступные варианты:
➖Можно обладать выдающимся талантом к эмпатии и быть способным интуитивно понимать и прогнозировать чувства людей. У большинства этого нет
➖Можно прожить всевозможные ситуации с разными людьми, приобрести опытным путем и отрефлексировать эту информацию. Так как люди попадаются разные и ситуаций много, приобретение достаточного опыта займет десятилетия - слишком долго
Реальный вариант (помимо "забить") - для начала взять доступный опыт, проанализировать его, обнаружить общие закономерности, и на основании них - предсказывать исход ситуаций.
Вслепую анализировать крайне сложно - нужна теоретическая база. В этом поможет ознакомление с этикой - наукой и философской дисциплиной, исследующей нравственное поведение и моральные принципы. Например, можно прочитать одну или несколько книг по этике. Мне из тех, которые я читал, зашла больше всего "Этика" Кропоткина, можно выбрать другую на свой вкус.
Подавляющее большинство (90%+) ситуаций, которые демотивируют людей - связаны с ощущением несправедливости. Справедливость, в свою очередь, тесно связана с пониманием равенства. Хоть эти понятия люди трактуют по своему, но обычно очень похоже.
Вот, например, несколько общих принципов:
➖все заслуживают равного отношения за равные деяния
➖разные деяния заслуживают разного отношения
Звучит достаточно абстрактно, вот приземленные примеры:
1️⃣ Вася и Петя делают работу мидла, но Вася джун, а Петя мидл. Вася чувствует несправедливость, основанную на неравенстве. Это его демотивирует
2️⃣ Коля и Женя делают одинаковую работу, но Колю уважают и хвалят, а Женю нет. Неравенство, несправедливость
3️⃣ Сергей и Антон находятся на одинаковой должности, но Сергей проявляет инициативу достигает выдающегося результата. За этим ничего не следует. Сергей чувствует несправедливость, так как разные деяния заслуживают разного отношения
4️⃣ Эдуард считает, что за свою работу он может рассчитывать на определенный уровень уважения от руководителя и коллег, но он его не получает. Он чувствует неравенство и, соответственно, несправедливость
В общем, думаю, идея понятна.
Здесь неравенство может быть как между разными субъектами (это обычно проще измеримо), так и между ожиданием и реальностью (здесь требуется получше знать людей, например, выяснять ожидания на one-to-one).
"Отношение" в данном контексте включают в себя и эмоциональную (почет, социальный статус, уважение, неуважение и т.п.) сторону, и материальную (деньги, рабочие условия, должности, полномочия и прочие плюшки)
Что часто попадается в оставшихся условных 10%?
➖Бессмысленность. Людей угнетает бессмысленность деятельности. Здесь два варианта - если на самом деле это не бессмысленно, человека можно обеспечить информацией об истинных целях. Если действительно бессмысленно - нужно перестать это делать (порой это требует некоторой смелости и настойчивости от менеджера, например, чтобы преодолеть консерватизм системы)
➖Нарушение принципов. Людей угнетает, когда им приходится поступаться своими идеалами, нравственными принципами, мировоззрением. Здесь сложнее - иногда просто нет совпадения. Иногда можно договориться или уступить, иногда лучше найти другую компанию/другого сотрудника.
Есть и другое, но это уже более редкие кейсы, и если хотя бы с выше описанными вещами менеджер умеет работать, я бы сказал он легко войдет в топ 5% лучших в этом отношении, на любом уровне вплоть до топ-менеджмента.
P.S. А можете накинуть в комменты историй, которые демотивировали вас или ваших друзей/знакомых? Заодно и проверим, укладываются ли они в схему )
Сразу отбросим рабочие, но не очень доступные варианты:
➖Можно обладать выдающимся талантом к эмпатии и быть способным интуитивно понимать и прогнозировать чувства людей. У большинства этого нет
➖Можно прожить всевозможные ситуации с разными людьми, приобрести опытным путем и отрефлексировать эту информацию. Так как люди попадаются разные и ситуаций много, приобретение достаточного опыта займет десятилетия - слишком долго
Реальный вариант (помимо "забить") - для начала взять доступный опыт, проанализировать его, обнаружить общие закономерности, и на основании них - предсказывать исход ситуаций.
Вслепую анализировать крайне сложно - нужна теоретическая база. В этом поможет ознакомление с этикой - наукой и философской дисциплиной, исследующей нравственное поведение и моральные принципы. Например, можно прочитать одну или несколько книг по этике. Мне из тех, которые я читал, зашла больше всего "Этика" Кропоткина, можно выбрать другую на свой вкус.
Подавляющее большинство (90%+) ситуаций, которые демотивируют людей - связаны с ощущением несправедливости. Справедливость, в свою очередь, тесно связана с пониманием равенства. Хоть эти понятия люди трактуют по своему, но обычно очень похоже.
Вот, например, несколько общих принципов:
➖все заслуживают равного отношения за равные деяния
➖разные деяния заслуживают разного отношения
Звучит достаточно абстрактно, вот приземленные примеры:
В общем, думаю, идея понятна.
Здесь неравенство может быть как между разными субъектами (это обычно проще измеримо), так и между ожиданием и реальностью (здесь требуется получше знать людей, например, выяснять ожидания на one-to-one).
"Отношение" в данном контексте включают в себя и эмоциональную (почет, социальный статус, уважение, неуважение и т.п.) сторону, и материальную (деньги, рабочие условия, должности, полномочия и прочие плюшки)
Что часто попадается в оставшихся условных 10%?
➖Бессмысленность. Людей угнетает бессмысленность деятельности. Здесь два варианта - если на самом деле это не бессмысленно, человека можно обеспечить информацией об истинных целях. Если действительно бессмысленно - нужно перестать это делать (порой это требует некоторой смелости и настойчивости от менеджера, например, чтобы преодолеть консерватизм системы)
➖Нарушение принципов. Людей угнетает, когда им приходится поступаться своими идеалами, нравственными принципами, мировоззрением. Здесь сложнее - иногда просто нет совпадения. Иногда можно договориться или уступить, иногда лучше найти другую компанию/другого сотрудника.
Есть и другое, но это уже более редкие кейсы, и если хотя бы с выше описанными вещами менеджер умеет работать, я бы сказал он легко войдет в топ 5% лучших в этом отношении, на любом уровне вплоть до топ-менеджмента.
P.S. А можете накинуть в комменты историй, которые демотивировали вас или ваших друзей/знакомых? Заодно и проверим, укладываются ли они в схему )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤4🔥2
Профессионалы или любители?
Руководство людьми часто сравнивают с шахматами. Я сегодня тоже хочу сравнить.
Вы наверно слышали, что практически все профессионалы в шахматах - это люди, которые начали играть с детства. Да и не каждый, кто начал с детства - может стать профессионалом.
Теперь давайте предположим, что руководство людьми - не проще, чем шахматы. Значит, на каком уровне будет находиться человек, который, скажем, 3-5 лет этим занимается? На любительском.
Это может быть крепкий любительский, если он хорошо учится, и слабый любительский, если он просто двигает фигурки, не особо углубляясь. Мастерами становятся за 10-15 лет, и то при упорных тренировках, изучении теории и некотором таланте.
А что важно, чтобы побеждать на любительском уровне? Две вещи:
1. Для начала изучить основы и общую идею, зачем тут что-то делается - правила, цель, стадии, борьба за центр, развитие фигур, атака на короля, вот это всё. Это придает твоим действиям осмысленность.
2. Не совершать грубых ошибок (blunder, он же "зевок")
К чему это я - да в общем к тому, что аналогия здесь полная. "Хороший менеджер" в коммерции - это "крепкий любитель" в шахматах. Человек, который понимает базу и редко лажает.
А много ли таких? Да в общем, достаточно мало. На любом уровне, вплоть до топ-менеджмента.
Кто-то может сказать - "ну-ну, он слишком критичен". Давайте я вам расскажу одну историю.
Дело было в одной компании, классного разработчика повысили до тимлида. Произошла классика - он продолжал решать проблемы как разработчик, и с руководством у него не клеилось. Кадровые вопросы такого уровня решал технический директор (10+ лет руководства, сильная карьера, из тех, интервью с кем можно найти в поисковике).
Через несколько месяцев техдир обсудил это с парой менеджеров внутри своей команды и решил перевести тимлида обратно в разрабы, в другую команду.
Как это делается правильно: назначается встреча 1 на 1, сразу обозначается решение, без хождения вокруг до около. Потом в ходе разговора оказывается моральная поддержка, без обвинения и конструктивно обсуждаются причины, строятся дальнейшие планы совместной работы.
Как это было сделано: а никак, тимлид узнал, что он идет в другую команду на дейлике, в разговоре между другими людьми как о сбывшемся факте.
Это реально анекдот) Является ли такое редкостью? Нет. Это сплошь и рядом, и если у вас наметан глаз, скорее всего вы это уже видите. Все вокруг лажают, вопрос частоты.
Какой можно сделать вывод? Заняв руководящую позицию - считать себя джуном. Разобраться в базовой теории. Учиться. Относиться к себе критично. Подумать где лажаешь. И не лажать)
Руководство людьми часто сравнивают с шахматами. Я сегодня тоже хочу сравнить.
Вы наверно слышали, что практически все профессионалы в шахматах - это люди, которые начали играть с детства. Да и не каждый, кто начал с детства - может стать профессионалом.
Теперь давайте предположим, что руководство людьми - не проще, чем шахматы. Значит, на каком уровне будет находиться человек, который, скажем, 3-5 лет этим занимается? На любительском.
Это может быть крепкий любительский, если он хорошо учится, и слабый любительский, если он просто двигает фигурки, не особо углубляясь. Мастерами становятся за 10-15 лет, и то при упорных тренировках, изучении теории и некотором таланте.
А что важно, чтобы побеждать на любительском уровне? Две вещи:
1. Для начала изучить основы и общую идею, зачем тут что-то делается - правила, цель, стадии, борьба за центр, развитие фигур, атака на короля, вот это всё. Это придает твоим действиям осмысленность.
2. Не совершать грубых ошибок (blunder, он же "зевок")
К чему это я - да в общем к тому, что аналогия здесь полная. "Хороший менеджер" в коммерции - это "крепкий любитель" в шахматах. Человек, который понимает базу и редко лажает.
А много ли таких? Да в общем, достаточно мало. На любом уровне, вплоть до топ-менеджмента.
Кто-то может сказать - "ну-ну, он слишком критичен". Давайте я вам расскажу одну историю.
Дело было в одной компании, классного разработчика повысили до тимлида. Произошла классика - он продолжал решать проблемы как разработчик, и с руководством у него не клеилось. Кадровые вопросы такого уровня решал технический директор (10+ лет руководства, сильная карьера, из тех, интервью с кем можно найти в поисковике).
Через несколько месяцев техдир обсудил это с парой менеджеров внутри своей команды и решил перевести тимлида обратно в разрабы, в другую команду.
Как это делается правильно: назначается встреча 1 на 1, сразу обозначается решение, без хождения вокруг до около. Потом в ходе разговора оказывается моральная поддержка, без обвинения и конструктивно обсуждаются причины, строятся дальнейшие планы совместной работы.
Как это было сделано: а никак, тимлид узнал, что он идет в другую команду на дейлике, в разговоре между другими людьми как о сбывшемся факте.
Это реально анекдот) Является ли такое редкостью? Нет. Это сплошь и рядом, и если у вас наметан глаз, скорее всего вы это уже видите. Все вокруг лажают, вопрос частоты.
Какой можно сделать вывод? Заняв руководящую позицию - считать себя джуном. Разобраться в базовой теории. Учиться. Относиться к себе критично. Подумать где лажаешь. И не лажать)
❤9👍7🔥3
Как неправильно ставить задачи?
Любой, кто ставит кому-то задачи - в какой-то степени руководит. Мы через коммуникацию призываем кого-то другого что-то сделать, это и есть руководство. Это может быть на словах, или в форме текста (обычно это более надежно).
Есть огромное количество вариантов и методов постановки задач, всякие там user story, SMART и т.д. В основном это не очень универсально, не ко всем задачам подходит. Для каких-то избыточно.
Из того, что я вижу на практике - большинство людей не умеют ставить другим людям задачи. Это данность. Когда я работал прогером на поддержке, у нас был мем "сделайте все хорошо!", так примерно ставились задачи - вот там где-то проблема. Это в рамках ожиданий от бухгалтеров, пользователей, сотрудников колл-центра, для них в общем норм этого не уметь. Для менеджеров, у которых это ключевой элемент работы - это признак непрофессионализма.
Более продвинутый, но всё еще неправильный способ ставить задачу - ограничиться указанием, что нужно сделать, но не обозначив контекст и ожидаемый в итоге результат. Это часто приводит к тому, что делается не то, что преследует оригинальные цели задачи. Просто потому что исполнителя используют "втемную", а он может быть и сделал бы правильно, но не хватило информации. Из-за этого несколько недель может решаться задача, которую можно выполнить за пару часов. Кроме того, это имеет и моральный аспект - не предоставляя информацию о назначении задачи, ты, желая того или нет, не уважаешь человека и низводишь его до винтика или живого робота.
Значит ли, что если слабо поставить задачу, то она не будет сделана? Нет, не значит. Это просто возлагает на систему дополнительные издержки и риски, которые будут незаметны - просто у всех людей вокруг работа незаметно станет тяжелее.
Есть два супер-минимальных критерия, которые есть в любой правильно поставленной задаче, и отсутствие которых делает любую задачу плохой. "Плохой" в данном контексте - это такой, которая добавляет риски неверного решения, дополнительных трудозатрат на это решение и т.п.
➖Первый - это контекст. Это обстоятельства возникновения и постановки этой задачи, отвечает на вопросы: зачем/почему?
➖Второй - это ожидаемый результат. По каким критериям заказчик поймет, что всё в порядке? Это еще называется acceptance criteria (критерии приемки).
(В комментах пример постановки от chatgpt)
Тестировщикам это хорошо известно - описывая баг, они пишут:
Зашел туда-то (контекст), тыкнул туда-то (контекст)
Ожидаемое поведение: (критерии приемки)
Фактическое поведение: (контекст)
Тут та же универсальная идея заложена, это не случайно.
Самое время открыть свой таск-трекер и посмотреть как там пишутся задачи😁
Любой, кто ставит кому-то задачи - в какой-то степени руководит. Мы через коммуникацию призываем кого-то другого что-то сделать, это и есть руководство. Это может быть на словах, или в форме текста (обычно это более надежно).
Есть огромное количество вариантов и методов постановки задач, всякие там user story, SMART и т.д. В основном это не очень универсально, не ко всем задачам подходит. Для каких-то избыточно.
Из того, что я вижу на практике - большинство людей не умеют ставить другим людям задачи. Это данность. Когда я работал прогером на поддержке, у нас был мем "сделайте все хорошо!", так примерно ставились задачи - вот там где-то проблема. Это в рамках ожиданий от бухгалтеров, пользователей, сотрудников колл-центра, для них в общем норм этого не уметь. Для менеджеров, у которых это ключевой элемент работы - это признак непрофессионализма.
Более продвинутый, но всё еще неправильный способ ставить задачу - ограничиться указанием, что нужно сделать, но не обозначив контекст и ожидаемый в итоге результат. Это часто приводит к тому, что делается не то, что преследует оригинальные цели задачи. Просто потому что исполнителя используют "втемную", а он может быть и сделал бы правильно, но не хватило информации. Из-за этого несколько недель может решаться задача, которую можно выполнить за пару часов. Кроме того, это имеет и моральный аспект - не предоставляя информацию о назначении задачи, ты, желая того или нет, не уважаешь человека и низводишь его до винтика или живого робота.
Значит ли, что если слабо поставить задачу, то она не будет сделана? Нет, не значит. Это просто возлагает на систему дополнительные издержки и риски, которые будут незаметны - просто у всех людей вокруг работа незаметно станет тяжелее.
Есть два супер-минимальных критерия, которые есть в любой правильно поставленной задаче, и отсутствие которых делает любую задачу плохой. "Плохой" в данном контексте - это такой, которая добавляет риски неверного решения, дополнительных трудозатрат на это решение и т.п.
➖Первый - это контекст. Это обстоятельства возникновения и постановки этой задачи, отвечает на вопросы: зачем/почему?
➖Второй - это ожидаемый результат. По каким критериям заказчик поймет, что всё в порядке? Это еще называется acceptance criteria (критерии приемки).
(В комментах пример постановки от chatgpt)
Тестировщикам это хорошо известно - описывая баг, они пишут:
Зашел туда-то (контекст), тыкнул туда-то (контекст)
Ожидаемое поведение: (критерии приемки)
Фактическое поведение: (контекст)
Тут та же универсальная идея заложена, это не случайно.
Самое время открыть свой таск-трекер и посмотреть как там пишутся задачи😁
👍11🔥3❤1
Забавный эпизод был на днях - ЧатГПТ внезапно начал задавать вопросы без спроса. В итоге получился довольно интересный диалог, которым захотелось поделиться.
Началось всё так - я посмотрел несколько кусков из мок-собеса (тренировочное собеседование) на проектного менеджера, ну и оставил такое сообщение про один из вопросов:
"Команда факапит 4 спринта, что будешь делать?"
я конечно понимаю, что на собесе ожидают услышать другое - а есть варик отменить спринты, если они все равно не работают? ) Такой вариант кто-то рассматривает?
Фреймворки разработки - это старая любимая мной тема, и я вечно сталкивался с проблемами очень кратко объяснить свой метод организации разработки: хотя он в целом достаточно популярен и эффективен, но для него нет какого-то общепринятого названия. Стало любопытно - пошел спросить у чатгпт как он назовет.
И всё бы наверно закончилось на втором сообщении, если бы он не начал внезапно задавать вопросы. У меня километры общения с чатгпт и в общем для него это не было раньше типичным поведением (чтобы он задавал вопросы - обычно его надо было прямо к этому подтолкнуть), поэтому удивило и вызвало любопытство. Как по мне, это отличный пример насыщенного полезными деталями обсуждения организации разработки. Еще и с довольно толковым, полезным для меня советом в конце. Предлагаю вашему вниманию:
https://chatgpt.com/share/67af8f17-6388-8013-b6e3-9f4ce6cfc0b3
Началось всё так - я посмотрел несколько кусков из мок-собеса (тренировочное собеседование) на проектного менеджера, ну и оставил такое сообщение про один из вопросов:
"Команда факапит 4 спринта, что будешь делать?"
я конечно понимаю, что на собесе ожидают услышать другое - а есть варик отменить спринты, если они все равно не работают? ) Такой вариант кто-то рассматривает?
Фреймворки разработки - это старая любимая мной тема, и я вечно сталкивался с проблемами очень кратко объяснить свой метод организации разработки: хотя он в целом достаточно популярен и эффективен, но для него нет какого-то общепринятого названия. Стало любопытно - пошел спросить у чатгпт как он назовет.
И всё бы наверно закончилось на втором сообщении, если бы он не начал внезапно задавать вопросы. У меня километры общения с чатгпт и в общем для него это не было раньше типичным поведением (чтобы он задавал вопросы - обычно его надо было прямо к этому подтолкнуть), поэтому удивило и вызвало любопытство. Как по мне, это отличный пример насыщенного полезными деталями обсуждения организации разработки. Еще и с довольно толковым, полезным для меня советом в конце. Предлагаю вашему вниманию:
https://chatgpt.com/share/67af8f17-6388-8013-b6e3-9f4ce6cfc0b3
ChatGPT
ChatGPT - Разработка без спринтов
ChatGPT helps you get answers, find inspiration, and be more productive.
👍6🔥5
Easy to learn, hard to master.
Это популярное выражение, применяется в частности к играм, в которых легко освоить правила, но вариативность и глубина делают мастерство в них очень тяжело достижимым. Например, шахматы или покер - правила можно освоить за день, а чтобы научиться круто играть - требуются годы, упорные тренировки, изучение теории и т.п.
Помню, как меня удивило, как мало хард-скиллов лежат в основе айти-менеджмента. Буквально, вот весь список:
1. Почитать про Agile (манифест + пару статей, раскрывающих смысл)
2. Прочитать scrum guide (~30 страниц)
3. Посмотреть пару лекций Пименова про Канбан-метод
4. Прочитать курс Селиховкина про проектный менеджмент (2-3 десятка коротких статей)
Это осваивается за 1-2 недели. Это не шутка, это всё, что используется как основа для организации командной разработки. Вся остальная информация - на 95% производная из этой, а 100% вам никогда не понадобится. В дополнение еще некоторые общие вещи:
➖какие бывают должности, роли, отделы
➖иметь общее представление о структуре коммерческой компании
➖что такое вообще разработка и из каких она состоит этапов (идея, бизнес-анализ, системный анализ, проектирование, разработка, тестирование и т.п.)
Пусть еще ~2 недели.
Если база такая маленькая, возникает вопрос: а почему менеджмент - это сложно? Например, почему так много плохих менеджеров. Или почему у многих не получаются какие-то, казалось бы, базовые вещи.
Ответ (моя версия) кроется в том, что это очень плохо формализуемая сфера деятельности. Инструкция "как быть хорошим менеджером" выглядела бы слишком противоречиво. Например так:
1. Будь исполнительным. (но) Постоянно подвергай сомнению задачи руководства
2. Будь дружелюбным. (но) Будь жестким
3. Будь терпимым к недостаткам. (но) Будь требовательным
4. Иди навстречу коллегам. (но) Не соглашайся на всё подряд
5. Ориентируйся на лучшие практики. (но) Придумывай свои решения, которые подходят в конкретной ситуации
6. Применяй системные решения. (но) Эффективно используй "костыли" (workarounds)
7. Наводи порядок. (но) Не закручивай гайки
И так далее, еще несколько десятков пунктов. Для неподготовленного человека это может выглядеть (или ощущаться) как шиза. "Действуй по ситуации" и "ориентируйся на здравый смысл" - это так себе инструкция, но это единственный универсальный совет.
Мы, прокачиваясь, по сути тренируем нашу "нейросетку" лучше понимать границу между полярными составляющими тех или иных решений. Здесь пойти навстречу или выставить границы? Здесь быть дипломатичным или резко сказать нет? Здесь делать самому или отдать другому? Это не сводится к административной инструкции.
You can learn it, but you can't teach it - еще одна поговорка, она означает, что некоторые вещи можно понять через опыт (анализ своих и чужих кейсов), но их невозможно передать другому человеку, просто объяснив.
Менеджмент - это как раз такая область. Причем софт-скиллы достаточно универсальные, они приобретаются при любом руководстве - хоть дворовой футбольной командой, хоть гильдией в mmorpg, хоть группой в походе.
Если вынести за скобки софты не эксклюзивно менеджерского характера (коммуникации, аналитика и т.д.), то вся прокачка, которая выходит за рамки описанных выше 2-3 недель на харды - это анализ бесконечного потока частных случаев, чтобы в будущем субъективно выбрать из альтернативных решений наиболее уместное в конкретном случае.
Это популярное выражение, применяется в частности к играм, в которых легко освоить правила, но вариативность и глубина делают мастерство в них очень тяжело достижимым. Например, шахматы или покер - правила можно освоить за день, а чтобы научиться круто играть - требуются годы, упорные тренировки, изучение теории и т.п.
Помню, как меня удивило, как мало хард-скиллов лежат в основе айти-менеджмента. Буквально, вот весь список:
1. Почитать про Agile (манифест + пару статей, раскрывающих смысл)
2. Прочитать scrum guide (~30 страниц)
3. Посмотреть пару лекций Пименова про Канбан-метод
4. Прочитать курс Селиховкина про проектный менеджмент (2-3 десятка коротких статей)
Это осваивается за 1-2 недели. Это не шутка, это всё, что используется как основа для организации командной разработки. Вся остальная информация - на 95% производная из этой, а 100% вам никогда не понадобится. В дополнение еще некоторые общие вещи:
➖какие бывают должности, роли, отделы
➖иметь общее представление о структуре коммерческой компании
➖что такое вообще разработка и из каких она состоит этапов (идея, бизнес-анализ, системный анализ, проектирование, разработка, тестирование и т.п.)
Пусть еще ~2 недели.
Если база такая маленькая, возникает вопрос: а почему менеджмент - это сложно? Например, почему так много плохих менеджеров. Или почему у многих не получаются какие-то, казалось бы, базовые вещи.
Ответ (моя версия) кроется в том, что это очень плохо формализуемая сфера деятельности. Инструкция "как быть хорошим менеджером" выглядела бы слишком противоречиво. Например так:
1. Будь исполнительным. (но) Постоянно подвергай сомнению задачи руководства
2. Будь дружелюбным. (но) Будь жестким
3. Будь терпимым к недостаткам. (но) Будь требовательным
4. Иди навстречу коллегам. (но) Не соглашайся на всё подряд
5. Ориентируйся на лучшие практики. (но) Придумывай свои решения, которые подходят в конкретной ситуации
6. Применяй системные решения. (но) Эффективно используй "костыли" (workarounds)
7. Наводи порядок. (но) Не закручивай гайки
И так далее, еще несколько десятков пунктов. Для неподготовленного человека это может выглядеть (или ощущаться) как шиза. "Действуй по ситуации" и "ориентируйся на здравый смысл" - это так себе инструкция, но это единственный универсальный совет.
Мы, прокачиваясь, по сути тренируем нашу "нейросетку" лучше понимать границу между полярными составляющими тех или иных решений. Здесь пойти навстречу или выставить границы? Здесь быть дипломатичным или резко сказать нет? Здесь делать самому или отдать другому? Это не сводится к административной инструкции.
You can learn it, but you can't teach it - еще одна поговорка, она означает, что некоторые вещи можно понять через опыт (анализ своих и чужих кейсов), но их невозможно передать другому человеку, просто объяснив.
Менеджмент - это как раз такая область. Причем софт-скиллы достаточно универсальные, они приобретаются при любом руководстве - хоть дворовой футбольной командой, хоть гильдией в mmorpg, хоть группой в походе.
Если вынести за скобки софты не эксклюзивно менеджерского характера (коммуникации, аналитика и т.д.), то вся прокачка, которая выходит за рамки описанных выше 2-3 недель на харды - это анализ бесконечного потока частных случаев, чтобы в будущем субъективно выбрать из альтернативных решений наиболее уместное в конкретном случае.
👍12🔥8❤4
Негативный фидбек - давать/не давать, как давать?
Был у меня как-то разговор на кухне с коллегами, как помню это были руководитель отдела разработки и директор по разработке. На тему фидбека, в частности негативного.
Позиции были примерно следующие:
1. Всегда надо давать
2. Не всегда надо давать
Вторую отстаивал я.
Ну и неявным образом существует третья позиция, являющаяся индустриальным стандартом - лениться и забивать на фидбек.
Чтобы продемонстрировать смысл своей позиции, могу привести один пример - это когда претензии взаимные.
Фидбек (негативный) - это в конечном счете оформленная претензия к тому, как человек что-то делает. Это как отзыв. Он может содержать в себе совет, но это не совет.
Бывают ситуации встречных претензий. Например:
➖Разработчик хочет просто делать задачи и у него есть претензия, что от него требуют много коммуникаций с продактами. А его менеджер - хочет дать ему негативный фидбек, что он недостаточно активно коммуницирует с продактами при анализе требований.
Это сработает плохо, скорее всего вообще в минус - обострит противоречия и увеличит недовольство. Для того, чтобы негативный фидбек был эффективен, нужно несколько условий:
1. Человек должен быть готов к обратной связи, в том числе эмоционально.
2. Это должно в теории принести какую-то пользу.
У многих людей есть какие-то особенности, различные черты характера, слабости. Давать фидбек по поводу них бывает контрпродуктивно - это может быть неотъемлемая черта личности.
Кто-то менее организованный, чем другие. У кого-то плохо с коммуникациями. Для кого-то не свойственно находиться в центре движухи и часто проявлять инициативу. Не всегда речь идет о прокачиваемом навыке. Кому-то просто сложно освоить какие-то вещи, которые легко даются другим.
Я примерно следующий алгоритм использую при принятии решений о критике в форме негативного фидбека:
❓запрашивал ли человек фидбек прямо?
Если да - я в любом случае отвечу как есть.
Если не запрашивал, то я в первую очередь задаю себе вопрос:
❓по совокупности плюсов и минусов, приносит ли человек пользу команде?
Если нет - то фидбек имеет смысл только как часть процесса увольнения. Например, чтобы подготовить человека морально к увольнению, или чтобы дать ему возможность исправить что-то в своей работе.
❓является ли решаемая проблема действительно деструктивной для команды?
Это такие кейсы как токсичное общение, конфликты, некомпетентные действия, ведущие к инцидентам и т.п. Тут в любом случае стоит дать фидбек и сразу решить проблему.
Допустим, нам по совокупности нравится, как кто-то делает работу. Тогда функция фидбека - сделать его работу лучше. Отсюда следующий вопрос:
❓похоже ли, что человек готов улучшать свою работу и ему нужна эта информация?
Если нет - скорее всего не стоит. Если да:
❓могу ли я помимо негативного фидбека еще дать конструктивные советы, как именно достичь улучшения в названной ситуации?
Если да - это хороший вариант дать фидбек. Если нет - скорее всего я буду думать дальше и возьму во внимание другие факторы.
В упрощенном виде как-то так. Естественно, имеет значение еще как складываются личные отношения, обстоятельства. А еще имеет значение - это член вашей команды, или нет (тогда в случае сомнений лучше дать фидбек менеджеру, а не напрямую)
Если же взглянуть на вопрос шире, то как правило работу с человеком надо строить вокруг его сильных сторон, а не вокруг слабых. Это значит, что на вопрос "давать ли негативный фидбек? Да/нет" ответ может быть - давать позитивный. Но это уже тянет на отдельный пост.
Справедливости ради, нужны аргументы и в пользу того, чтобы всегда давать негативную обратную связь. Поставлю себя на место оппонента:
1. Эта концепция проще. Действуешь по алгоритму - не ошибешься в неоднозначных ситуациях (корнер-кейсах)
2. Она готовит субъективное восприятие людей к реальным решениям (повышения, увольнения и т.п.)
3. Она дисциплинирует. Если лень - то нет отговорок типа "а может быть не надо".
4. Это более честно. Сокрытие информации и выбор что сообщать, а что нет - похожи на манипуляции.
Выводы на ваше усмотрение )
Был у меня как-то разговор на кухне с коллегами, как помню это были руководитель отдела разработки и директор по разработке. На тему фидбека, в частности негативного.
Позиции были примерно следующие:
1. Всегда надо давать
2. Не всегда надо давать
Вторую отстаивал я.
Ну и неявным образом существует третья позиция, являющаяся индустриальным стандартом - лениться и забивать на фидбек.
Чтобы продемонстрировать смысл своей позиции, могу привести один пример - это когда претензии взаимные.
Фидбек (негативный) - это в конечном счете оформленная претензия к тому, как человек что-то делает. Это как отзыв. Он может содержать в себе совет, но это не совет.
Бывают ситуации встречных претензий. Например:
➖Разработчик хочет просто делать задачи и у него есть претензия, что от него требуют много коммуникаций с продактами. А его менеджер - хочет дать ему негативный фидбек, что он недостаточно активно коммуницирует с продактами при анализе требований.
Это сработает плохо, скорее всего вообще в минус - обострит противоречия и увеличит недовольство. Для того, чтобы негативный фидбек был эффективен, нужно несколько условий:
1. Человек должен быть готов к обратной связи, в том числе эмоционально.
2. Это должно в теории принести какую-то пользу.
У многих людей есть какие-то особенности, различные черты характера, слабости. Давать фидбек по поводу них бывает контрпродуктивно - это может быть неотъемлемая черта личности.
Кто-то менее организованный, чем другие. У кого-то плохо с коммуникациями. Для кого-то не свойственно находиться в центре движухи и часто проявлять инициативу. Не всегда речь идет о прокачиваемом навыке. Кому-то просто сложно освоить какие-то вещи, которые легко даются другим.
Я примерно следующий алгоритм использую при принятии решений о критике в форме негативного фидбека:
❓запрашивал ли человек фидбек прямо?
Если да - я в любом случае отвечу как есть.
Если не запрашивал, то я в первую очередь задаю себе вопрос:
❓по совокупности плюсов и минусов, приносит ли человек пользу команде?
Если нет - то фидбек имеет смысл только как часть процесса увольнения. Например, чтобы подготовить человека морально к увольнению, или чтобы дать ему возможность исправить что-то в своей работе.
❓является ли решаемая проблема действительно деструктивной для команды?
Это такие кейсы как токсичное общение, конфликты, некомпетентные действия, ведущие к инцидентам и т.п. Тут в любом случае стоит дать фидбек и сразу решить проблему.
Допустим, нам по совокупности нравится, как кто-то делает работу. Тогда функция фидбека - сделать его работу лучше. Отсюда следующий вопрос:
❓похоже ли, что человек готов улучшать свою работу и ему нужна эта информация?
Если нет - скорее всего не стоит. Если да:
❓могу ли я помимо негативного фидбека еще дать конструктивные советы, как именно достичь улучшения в названной ситуации?
Если да - это хороший вариант дать фидбек. Если нет - скорее всего я буду думать дальше и возьму во внимание другие факторы.
В упрощенном виде как-то так. Естественно, имеет значение еще как складываются личные отношения, обстоятельства. А еще имеет значение - это член вашей команды, или нет (тогда в случае сомнений лучше дать фидбек менеджеру, а не напрямую)
Если же взглянуть на вопрос шире, то как правило работу с человеком надо строить вокруг его сильных сторон, а не вокруг слабых. Это значит, что на вопрос "давать ли негативный фидбек? Да/нет" ответ может быть - давать позитивный. Но это уже тянет на отдельный пост.
Справедливости ради, нужны аргументы и в пользу того, чтобы всегда давать негативную обратную связь. Поставлю себя на место оппонента:
1. Эта концепция проще. Действуешь по алгоритму - не ошибешься в неоднозначных ситуациях (корнер-кейсах)
2. Она готовит субъективное восприятие людей к реальным решениям (повышения, увольнения и т.п.)
3. Она дисциплинирует. Если лень - то нет отговорок типа "а может быть не надо".
4. Это более честно. Сокрытие информации и выбор что сообщать, а что нет - похожи на манипуляции.
Выводы на ваше усмотрение )
👍6❤3🔥1
Зачем быть менеджером?
Вопрос не праздный на самом деле.
Обычно это первое, что я спрашиваю, если речь про собес, менторство или смену позиции - почему хочешь быть менеджером.
Тимлидами, например, часто становятся просто в силу обстоятельств - есть какой-то хороший ответственный разраб, не хватает тимлида (кто-то уволился или появилась новая команда), и разрабу предлагают - давай будешь тимлидом. Многие думают - ну буду так же прогером, только еще буду говорить другим что делать. А это принципиально другая работа, на которой ты опять джун и нужно учиться совершенно другим вещам.
Разумных причин занимать позицию менеджера среднего звена (тимлида или проектного менеджера, например), как по мне, очень мало. Две, если быть точным. Ну, может быть, две с половиной:
1. "Мне это нужно как промежуточный этап на пути к другой цели" (свой бизнес или топ-позиции)
2. "Мне это нравится"
За 0,5 сойдет что-то типа "я хочу попробовать и понять, нравится ли мне это". Лучше, конечно, понимать заранее.
Теперь попробую описать то, что я считаю "плохими" причинами, и расскажу, почему:
1. "Мне предложили и я согласился(лась)"
2. "Было некуда расти дальше по грейдам, только на тимлида"
3. "Хочу доказать, что я это могу" (себе или другим)
4. "Хочу власти/говорить другим что делать"
5. "Хочу, чтобы меня больше ценили/хочу признания"
И так далее.
Эти "плохие" варианты, как и хорошие, можно сгруппировать на 2 типа - ради выгоды (первые два), и ради эмоций (3-5).
От "хороших" они отличаются тем, что варианты выгоды не взвешенные, а эмоциональные направлены не на себя, а наружу. Не говоря о том, что многие эмоциональные варианты могут стать токсичными еще и для окружающих.
Если мы говорим про амбициозного человека, то ради выгоды в смысле прибавки в деньгах не стоит целиться в позицию тимлида (да и вообще менеджера среднего звена) как конечную. Она с точки зрения затрат/профита не сбалансированная. Ответственности и усилий требуется больше намного, а прирост в зарплате - примерно 20-30% по рынку, на конкретном месте может быть и меньше. Если цель - деньги, или деньги в пересчете на час работы или единицу стресса - чаще всего есть какой-то другой, более выгодный вариант потратить усилия (например, дальнейшая прокачка в ветке технологий и работа на международном рынке - для разраба, в отличие от менеджера, достаточно среднего английского)
Если мы говорим про людей родом из нашего региона (страны бывшего СССР), то выйти на какие-нибудь $6-8k net разрабом, на мой взгляд, куда проще, чем сделать то же самое менеджером. По той информации, что у меня в наличии, я могу судить, что менеджеров с такими зп очень мало, а разрабов достаточно:
➖разрабам не нужен свободный английский для работы в англоязычных командах, достаточно B1-B2
➖как следствие, зп разрабов в разных регионах сильнее коррелируют (это как сообщающиеся сосуды) - для менеджеров преград намного больше
➖разрабов количественно нужно больше
➖как следствие, конкуренция среди менеджеров за высокооплачиваемые позиции намного выше
В конце концов, если сильно нужны будут деньги - останется вариант попробовать две fulltime работы совместить или фуллтайм с контрактом/фрилансом, что возможно разрабом, но намного сложнее менеджером.
А еще бывают такие ситуации - человек стал тимлидом, тратил время и усилия на руководство, просел по техскиллам, потом вышел на рынок, тоже на позицию тимлида - а его собеседуют в основном на технические хардскиллы.
Остается вопрос - а почему менеджером быть не особо выгодно, если это такая важная роль в любой организации? Как раз из-за того, что большому количество людей это просто нравится - это создает предложение и меняет динамику спроса/предложения.
Ну а если вам нравится, то это вполне хороший вариант: делая то, что нравится (а может быть, еще и хорошо получается), можно уехать дальше в долгосрочной перспективе, чем если делать то, что выгодно, но не доставляет удовольствия.
В конце концов, у большинства людей на Земле нет такой роскоши - не тянуть лямку, а заниматься тем, что действительно нравится.
Вопрос не праздный на самом деле.
Обычно это первое, что я спрашиваю, если речь про собес, менторство или смену позиции - почему хочешь быть менеджером.
Тимлидами, например, часто становятся просто в силу обстоятельств - есть какой-то хороший ответственный разраб, не хватает тимлида (кто-то уволился или появилась новая команда), и разрабу предлагают - давай будешь тимлидом. Многие думают - ну буду так же прогером, только еще буду говорить другим что делать. А это принципиально другая работа, на которой ты опять джун и нужно учиться совершенно другим вещам.
Разумных причин занимать позицию менеджера среднего звена (тимлида или проектного менеджера, например), как по мне, очень мало. Две, если быть точным. Ну, может быть, две с половиной:
1. "Мне это нужно как промежуточный этап на пути к другой цели" (свой бизнес или топ-позиции)
2. "Мне это нравится"
За 0,5 сойдет что-то типа "я хочу попробовать и понять, нравится ли мне это". Лучше, конечно, понимать заранее.
Теперь попробую описать то, что я считаю "плохими" причинами, и расскажу, почему:
1. "Мне предложили и я согласился(лась)"
2. "Было некуда расти дальше по грейдам, только на тимлида"
3. "Хочу доказать, что я это могу" (себе или другим)
4. "Хочу власти/говорить другим что делать"
5. "Хочу, чтобы меня больше ценили/хочу признания"
И так далее.
Эти "плохие" варианты, как и хорошие, можно сгруппировать на 2 типа - ради выгоды (первые два), и ради эмоций (3-5).
От "хороших" они отличаются тем, что варианты выгоды не взвешенные, а эмоциональные направлены не на себя, а наружу. Не говоря о том, что многие эмоциональные варианты могут стать токсичными еще и для окружающих.
Если мы говорим про амбициозного человека, то ради выгоды в смысле прибавки в деньгах не стоит целиться в позицию тимлида (да и вообще менеджера среднего звена) как конечную. Она с точки зрения затрат/профита не сбалансированная. Ответственности и усилий требуется больше намного, а прирост в зарплате - примерно 20-30% по рынку, на конкретном месте может быть и меньше. Если цель - деньги, или деньги в пересчете на час работы или единицу стресса - чаще всего есть какой-то другой, более выгодный вариант потратить усилия (например, дальнейшая прокачка в ветке технологий и работа на международном рынке - для разраба, в отличие от менеджера, достаточно среднего английского)
Если мы говорим про людей родом из нашего региона (страны бывшего СССР), то выйти на какие-нибудь $6-8k net разрабом, на мой взгляд, куда проще, чем сделать то же самое менеджером. По той информации, что у меня в наличии, я могу судить, что менеджеров с такими зп очень мало, а разрабов достаточно:
➖разрабам не нужен свободный английский для работы в англоязычных командах, достаточно B1-B2
➖как следствие, зп разрабов в разных регионах сильнее коррелируют (это как сообщающиеся сосуды) - для менеджеров преград намного больше
➖разрабов количественно нужно больше
➖как следствие, конкуренция среди менеджеров за высокооплачиваемые позиции намного выше
В конце концов, если сильно нужны будут деньги - останется вариант попробовать две fulltime работы совместить или фуллтайм с контрактом/фрилансом, что возможно разрабом, но намного сложнее менеджером.
А еще бывают такие ситуации - человек стал тимлидом, тратил время и усилия на руководство, просел по техскиллам, потом вышел на рынок, тоже на позицию тимлида - а его собеседуют в основном на технические хардскиллы.
Остается вопрос - а почему менеджером быть не особо выгодно, если это такая важная роль в любой организации? Как раз из-за того, что большому количество людей это просто нравится - это создает предложение и меняет динамику спроса/предложения.
Ну а если вам нравится, то это вполне хороший вариант: делая то, что нравится (а может быть, еще и хорошо получается), можно уехать дальше в долгосрочной перспективе, чем если делать то, что выгодно, но не доставляет удовольствия.
В конце концов, у большинства людей на Земле нет такой роскоши - не тянуть лямку, а заниматься тем, что действительно нравится.
🔥7👍5❤2
Оверстафф
Это интересное явление, которому редко придают значение. Сперва определение:
Оверстафф (overstaffing) — это ситуация, когда в команде слишком много специалистов по сравнению с объемом работы, который необходимо выполнить. Это может приводить к снижению эффективности, росту издержек и ухудшению взаимодействия в команде.
В основном люди думают только в одну сторону - получить больше ресурсов (людей, бюджетов и т.п.). Часто потому что "а потом не дадут, когда надо будет". Многие подгребают под себя просто из своих личных целей (большим количеством людей руководил - лучше послужной список).
В обратную сторону смотрят редко, и в основном только если сверху дают команду сокращать расходы.
А тем временем, это явление достаточно распространенное, вот три типичных примера в контексте команды разработки:
1️⃣ Слишком много разработчиков, и они предоставлены сами себе. Признаки - регулярно приходится самим себе выдумывать задачи (задач от бизнеса не хватает), и нередко эти задачи не доводятся до конца.
2️⃣ Слишком много продактов (или аналогов). Признак - бэклог неумолимо разрастается с каждым месяцем, в нем полно задач, которые никогда не будут сделаны. Как следствие - начинают использоваться более тяжелые организационные методы, начинаются дополнительные встречи ради приоритезации, груминга бэклога, издержки растут экспоненциально. Чтобы это решить (задачи застревают и не делаются) - могут нанять еще менеджеров. Вместо того, чтобы просто начать генерить меньше задач с низкой ценностью.
3️⃣ Слишком много специалистов одного типа в кросс-функциональной команде. Допустим, бэкенд разработчиков. Задачи начинают блокироваться на фронтэндерах. Кроме того - куча задач, застрявших на QA. Задачи начинают "протухать", требуют дополнительной работы и смены контекста - дополнительные издержки на обслуживание блокеров и очереди на QA.
Как избежать - нормально планировать найм, следить за динамикой (например, на досках команд).
Если уже случилось, то:
1. Попробовать выправить за счет стратегии дальнейшего найма (обычно это не так просто - масштабировать всех остальных кроме тех, кого слишком много)
2. Прикинуть насчет увольнений, может кого-то давно пора
3. Если все норм (не всё) - придумать чем глобально и надолго занять оверстафф роль (звездный час документации)
4. И если это всё не помогло - нужно просто начать ограничивать их скорость работы, пока не появятся опции получше. Пусть лучше просто отдохнут.
4 пункт может звучать странно, но бесполезная работа хуже ее отсутствия - она создает рост издержек не только на ее выполняющих, но и на всех окружающих.
Есть достаточно наивное представление, что каждый трудящийся приносит какой-то профит компании, иначе его бы в ней не было. Это не так, часто цели есть стратегические, например на рост компании, люди могут наниматься впрок и сидеть на скамейке запасных, делать задачи низкой ценности (если это разрабы), задачи "в стол" (если это аналитики или продакты).
Или может не быть управленческих ресурсов на направление в нужное русло работы людей или целых отделов, чтобы они делали что-то полезное для бизнеса. Конечно, самим этим людям часто так не кажется, они даже могут быть перегружены работой и зашиваться.
Так или иначе, (для менеджера) лучше разбираться в таких вещах и быть к ним готовым.
Это интересное явление, которому редко придают значение. Сперва определение:
Оверстафф (overstaffing) — это ситуация, когда в команде слишком много специалистов по сравнению с объемом работы, который необходимо выполнить. Это может приводить к снижению эффективности, росту издержек и ухудшению взаимодействия в команде.
В основном люди думают только в одну сторону - получить больше ресурсов (людей, бюджетов и т.п.). Часто потому что "а потом не дадут, когда надо будет". Многие подгребают под себя просто из своих личных целей (большим количеством людей руководил - лучше послужной список).
В обратную сторону смотрят редко, и в основном только если сверху дают команду сокращать расходы.
А тем временем, это явление достаточно распространенное, вот три типичных примера в контексте команды разработки:
Как избежать - нормально планировать найм, следить за динамикой (например, на досках команд).
Если уже случилось, то:
1. Попробовать выправить за счет стратегии дальнейшего найма (обычно это не так просто - масштабировать всех остальных кроме тех, кого слишком много)
2. Прикинуть насчет увольнений, может кого-то давно пора
3. Если все норм (не всё) - придумать чем глобально и надолго занять оверстафф роль (звездный час документации)
4. И если это всё не помогло - нужно просто начать ограничивать их скорость работы, пока не появятся опции получше. Пусть лучше просто отдохнут.
4 пункт может звучать странно, но бесполезная работа хуже ее отсутствия - она создает рост издержек не только на ее выполняющих, но и на всех окружающих.
Есть достаточно наивное представление, что каждый трудящийся приносит какой-то профит компании, иначе его бы в ней не было. Это не так, часто цели есть стратегические, например на рост компании, люди могут наниматься впрок и сидеть на скамейке запасных, делать задачи низкой ценности (если это разрабы), задачи "в стол" (если это аналитики или продакты).
Или может не быть управленческих ресурсов на направление в нужное русло работы людей или целых отделов, чтобы они делали что-то полезное для бизнеса. Конечно, самим этим людям часто так не кажется, они даже могут быть перегружены работой и зашиваться.
Так или иначе, (для менеджера) лучше разбираться в таких вещах и быть к ним готовым.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤1