Смелость как качество менеджера
Помните Страшилу, Железного Дровосека и Льва? Мы как-то на работе между собой проводили опрос, какой персонаж кому ближе )
Это может быть не очевидно, но смелость - очень важное качество именно для менеджера.
Для чего нужна смелость?
➖Говорить неприятную правду, особенно другим менеджерам, владельцу компании
➖Признавать свои ошибки, в том числе публично
➖Признавать, что чего-то не знаешь
➖Менять позицию, встретив более компетентное мнение
➖Защищать людей, за которых несешь ответственность
➖Выбрасывать или менять устоявшиеся процессы или практики, которые не работают
➖Увольнять неподходящих людей
➖Действовать решительно в ситуации неопределенности
➖Просто быть честным, наконец
Я видел бесконечное количество ситуаций, когда все решили промолчать, и выбрали делать неправильно.
Выступать с открытым забралом перед трудностями еще тем сложнее, чем ближе позиция к руководству компании, потому что там обычно и обитают различные интриги, борьба за власть, ресурсы и расположение руководства. Ну и, конечно, постоянно быть Дон Кихотом может быть утомительным.
Но если человек будет переступать через себя вместо того, чтобы делать то, что считает правильным - это будет медленно, но верно разрушать его собственную личность.
С другой стороны - любая компания, которая хочет быть эффективной и динамичной в изменяющихся условиях рынка, нуждается в достаточном количестве смелости в ее руководстве.
А менеджер без смелости — это администратор, который может лишь некритично передавать решения руководства и следить за их исполнением.
Помните Страшилу, Железного Дровосека и Льва? Мы как-то на работе между собой проводили опрос, какой персонаж кому ближе )
Это может быть не очевидно, но смелость - очень важное качество именно для менеджера.
Для чего нужна смелость?
➖Говорить неприятную правду, особенно другим менеджерам, владельцу компании
➖Признавать свои ошибки, в том числе публично
➖Признавать, что чего-то не знаешь
➖Менять позицию, встретив более компетентное мнение
➖Защищать людей, за которых несешь ответственность
➖Выбрасывать или менять устоявшиеся процессы или практики, которые не работают
➖Увольнять неподходящих людей
➖Действовать решительно в ситуации неопределенности
➖Просто быть честным, наконец
Я видел бесконечное количество ситуаций, когда все решили промолчать, и выбрали делать неправильно.
Выступать с открытым забралом перед трудностями еще тем сложнее, чем ближе позиция к руководству компании, потому что там обычно и обитают различные интриги, борьба за власть, ресурсы и расположение руководства. Ну и, конечно, постоянно быть Дон Кихотом может быть утомительным.
Но если человек будет переступать через себя вместо того, чтобы делать то, что считает правильным - это будет медленно, но верно разрушать его собственную личность.
С другой стороны - любая компания, которая хочет быть эффективной и динамичной в изменяющихся условиях рынка, нуждается в достаточном количестве смелости в ее руководстве.
А менеджер без смелости — это администратор, который может лишь некритично передавать решения руководства и следить за их исполнением.
❤🔥7🔥4❤3👍2
Аномалия в топ-менеджменте
Наблюдение: когда речь идет про коллег-специалистов, мы их воспринимаем так:
➖Если человек неприятный, мы подумаем - вот неприятный тип (мудак)
➖Если нормальный - обычный чел
➖Если приятный - значит, классный
Но эта шкала сдвигается на один, если речь про топ-менеджмент
➖Если человек неприятный - ну, обычный чел
➖Если просто нормальный - значит, классный
➖А если приятный - ну это что-то вообще уникальное
Не знаю, смешно вам или нет, но это реально у многих так работает )
Ну и не случайно. Давайте попробую привести несколько возможных объяснений.
Во-первых, среди различных топ-менеджеров в несколько раз больше, чем в среднем по популяции, людей с "плохими" расстройствами личности (если по простому - это те, кто вредят в основном не себе, а окружающим). Психопаты, люди с нарциссическим расстройством, социопаты и так далее - если вы зарядите глубокий поиск в ChatGPT, он вам накидает исследований, статей и статистики. У таких людей, соответственно, снижена эмпатия.
Во-вторых, это связано с тем, что на высоких позициях люди начинают вести себя более непосредственно - то есть более свободно проявлять свои истинные качества. На рядовых позициях люди чаще склонны вести себя более скрытно и сдержанно, и когда говорят, что кого-то "испортила власть" - по сути, человек просто в меньшей степени перестал скрываться.
В-третьих, если мы говорим не про предпринимателей, а про наемных топов, стоит задуматься - а какова механика, с помощью которой двигаются наверх по корпоративной иерархии? Кто-то может подумать, что это профессионализм - кто круче выполняет свои функции, того двигают наверх. Но среди топов можно выстретить как крутейших профи, так и полных долбаков, которые вообще ничего не умеют.
И может казаться реально странным с непривычки, пока не станет понятно, что профессионализм вторичен, а первично умение понравиться тому, кто принимает решение о назначении.
То есть вы можете запросто встретить полнейшего кретина, который с вашей точки зрения творит совершенную дичь (или просто ничего не делает толкового), но практически абсолютно исключено, что вы встретите человека, которого другой топ нанял вопреки личной неприязни. А вот если понравился - то наймет.
Потому что профессионализм еще надо уметь оценить, и на это часто нужно время, а вот если человек гладко стелет - это влияет сразу.
Наблюдение: когда речь идет про коллег-специалистов, мы их воспринимаем так:
➖Если человек неприятный, мы подумаем - вот неприятный тип (мудак)
➖Если нормальный - обычный чел
➖Если приятный - значит, классный
Но эта шкала сдвигается на один, если речь про топ-менеджмент
➖Если человек неприятный - ну, обычный чел
➖Если просто нормальный - значит, классный
➖А если приятный - ну это что-то вообще уникальное
Не знаю, смешно вам или нет, но это реально у многих так работает )
Ну и не случайно. Давайте попробую привести несколько возможных объяснений.
Во-первых, среди различных топ-менеджеров в несколько раз больше, чем в среднем по популяции, людей с "плохими" расстройствами личности (если по простому - это те, кто вредят в основном не себе, а окружающим). Психопаты, люди с нарциссическим расстройством, социопаты и так далее - если вы зарядите глубокий поиск в ChatGPT, он вам накидает исследований, статей и статистики. У таких людей, соответственно, снижена эмпатия.
Во-вторых, это связано с тем, что на высоких позициях люди начинают вести себя более непосредственно - то есть более свободно проявлять свои истинные качества. На рядовых позициях люди чаще склонны вести себя более скрытно и сдержанно, и когда говорят, что кого-то "испортила власть" - по сути, человек просто в меньшей степени перестал скрываться.
В-третьих, если мы говорим не про предпринимателей, а про наемных топов, стоит задуматься - а какова механика, с помощью которой двигаются наверх по корпоративной иерархии? Кто-то может подумать, что это профессионализм - кто круче выполняет свои функции, того двигают наверх. Но среди топов можно выстретить как крутейших профи, так и полных долбаков, которые вообще ничего не умеют.
И может казаться реально странным с непривычки, пока не станет понятно, что профессионализм вторичен, а первично умение понравиться тому, кто принимает решение о назначении.
То есть вы можете запросто встретить полнейшего кретина, который с вашей точки зрения творит совершенную дичь (или просто ничего не делает толкового), но практически абсолютно исключено, что вы встретите человека, которого другой топ нанял вопреки личной неприязни. А вот если понравился - то наймет.
Потому что профессионализм еще надо уметь оценить, и на это часто нужно время, а вот если человек гладко стелет - это влияет сразу.
👍12🔥5❤4
Чтобы дополнить предыдущий пост, хочу открыть рубрику #рекомендации
В основном я здесь выдаю какую-то концентрированную выжимку из своего опыта, но в пост все равно очень много не вложишь, а вот если сослаться на какой-то топового качества ресурс, из которого я сам черпал знания - тут концентрация ценности может быть намного выше.
Ну так вот, я прошлом посте я упоминал различные расстройства личности, которые часто встречаются среди руководства компаний. На самом деле, если Вы сами менеджер, то Вам точно стоит в этом хотя бы базово разбираться.
Да и по большому счету, любому человеку стоит - потому что это может касаться и выбора партнера (в смысле мужчины/женщины), и партнера по бизнесу, и окружения. А большинство людей даже не знает, что такое "психопат", хотя и употребляют это слово. Есть канал, где отлично и кратко разобраны эти темы - канал Мурада Султанова. Содержимое, формат, манера изложения - моё почтение.
Нас в первую очередь интересуют:
➖Асоциальное расстройство личности (психопаты и социопаты)
➖Нарциссическое расстройство личности
Всё это сможете найти там на ютуб-канале.
Если будете хотя бы минимально подготовлены по этим темам, у вас будет шанс избежать серьезных проблем в профессиональной и личной жизни.
https://youtu.be/smGrxDOeeK0
В основном я здесь выдаю какую-то концентрированную выжимку из своего опыта, но в пост все равно очень много не вложишь, а вот если сослаться на какой-то топового качества ресурс, из которого я сам черпал знания - тут концентрация ценности может быть намного выше.
Ну так вот, я прошлом посте я упоминал различные расстройства личности, которые часто встречаются среди руководства компаний. На самом деле, если Вы сами менеджер, то Вам точно стоит в этом хотя бы базово разбираться.
Да и по большому счету, любому человеку стоит - потому что это может касаться и выбора партнера (в смысле мужчины/женщины), и партнера по бизнесу, и окружения. А большинство людей даже не знает, что такое "психопат", хотя и употребляют это слово. Есть канал, где отлично и кратко разобраны эти темы - канал Мурада Султанова. Содержимое, формат, манера изложения - моё почтение.
Нас в первую очередь интересуют:
➖Асоциальное расстройство личности (психопаты и социопаты)
➖Нарциссическое расстройство личности
Всё это сможете найти там на ютуб-канале.
Если будете хотя бы минимально подготовлены по этим темам, у вас будет шанс избежать серьезных проблем в профессиональной и личной жизни.
https://youtu.be/smGrxDOeeK0
YouTube
ПСИХОПАТЫ и СОЦИОПАТЫ (1) чем отличаются два подтипа асоциального расстройства личности
Подписывайтесь на канал https://www.youtube.com/channel/UCE8bKtnV6h9gCqSWsTQ0h6g?sub_confirmation=1
2:27 Социопат или психопат – наглядная разница - персонажи из Место встречи изменить нельзя
3:37 Основные признаки асоциального расстройства личности
8:13…
2:27 Социопат или психопат – наглядная разница - персонажи из Место встречи изменить нельзя
3:37 Основные признаки асоциального расстройства личности
8:13…
❤6🔥3👍2
Как продакт может увеличить эффективность разработки на десятки процентов?
Часто в B2B SaaS компаниях команда разработки - основная статья расходов. Это подразумевает, что эффективное ее применение напрямую влияет на успешность бизнеса или его крах.
Мысль, что эффективность разработки зависит от того, как менеджмент организует ее работу - довольно тривиальна. Причинно-следственная связь между эффективностью команды разработки и качеством работы продакта менее очевидна.
Что нужно команде разработки от продакта, чтобы увеличить эффективность работы если не кратно, то на десятки процентов? Не так уж много на самом деле:
1. Нужно, чтобы фронт работы был четко коммуницирован в форме элементов бэклога
2. Все задачи должны сопровождаться освещением контекста
3. Приоритеты должны быть четко обозначены в системе
4. Должен проводиться регулярный груминг бэклога
5. После завершения задач должны быть освещены их результаты
Каждый пункт отвечает на свой критично важный для работы вопрос:
1. Что делаем?
2. Зачем и для каких целей?
3. В каком порядке и с какой интенсивностью?
4. Не устарела ли информация из п.1-3?
5. Что получилось в результате?
С одной стороны - эти вещи могут казаться очень базовыми. С другой стороны - как ни странно - они практически никогда не выполняются.
В среднем это выглядит так:
1. Что делаем - доносится частично, не четко, часто на словах и без критериев приемки. Результат эффективность утекает из-за потери информации от "испорченного телефона" и "имелось в виду другое", что вызывает переделки на поздних этапах разработки. Растет lead time, разработка становится дороже.
2. Почему мы это делаем - чаще всего никак не объясняется. Результат:
- не знаешь зачем нужна твоя работа - падает вовлеченность и мотивация
- не знаешь цель - не можешь выбрать лучшее решение из своих знаний о системе. Делаешь как сказано
В итоге падает производительность и реже выбираются оптимальные решения
3. Типовые ситуации с приоритетами - они либо вообще не используются по назначению, либо "всё срочно", что делает такую коммуникацию бесполезным шумом. Итог - путаница, стресс команды, неправильное распределение усилий для поставки ценности.
4. Груминг просто не делается. В итоге бэклог перестает соответствовать потребностям продукта и бизнеса, и усилия команды утекают на выполнение того, что уже потеряло ценность.
5. Задача после попадания в релиз улетает куда-то в небытие. Не происходит ни приемки, ни фидбека, ни освещения результатов. В итоге - падение интереса к работе, продукту, как следствие - снижение вовлеченности и мотивации что-то делать.
По последнему пункту просто представьте, что вы делаете красивые игрушки, и в одном случае просто кидаете их в темный ящик, а в другом - видите счастливые лица покупателей того, что вы сделали. В каком случае вы выгорите от бессмысленности своей работы, а в каком будете довольны и заинтересованы?
Из моей практики хорошим продактом можно считать того, кто нормально выполняет первый пункт и хоть как-то - третий. Из пяти.
Простой экономический расчет: бюджет команды разработки - десятки тысяч долларов (для небольшой) и более сотни тысяч в месяц для среднего размера. Пусть роль продакта стоит 10 тысяч в месяц. Пусть их несколько. Стоит ли треть времени этой позиции (несколько тысяч) потратить, чтобы увеличить приозводительность команды стоимостью в 100 тысяч на десятки процентов?
А для читателя остается загадка - то ли всё, что я написал выше - полная чепуха, то ли... почему же так происходит?
P.S. а если вы случайно оказались продактом, который это всё делает - я хочу с Вами дружить! )
Часто в B2B SaaS компаниях команда разработки - основная статья расходов. Это подразумевает, что эффективное ее применение напрямую влияет на успешность бизнеса или его крах.
Мысль, что эффективность разработки зависит от того, как менеджмент организует ее работу - довольно тривиальна. Причинно-следственная связь между эффективностью команды разработки и качеством работы продакта менее очевидна.
Что нужно команде разработки от продакта, чтобы увеличить эффективность работы если не кратно, то на десятки процентов? Не так уж много на самом деле:
1. Нужно, чтобы фронт работы был четко коммуницирован в форме элементов бэклога
2. Все задачи должны сопровождаться освещением контекста
3. Приоритеты должны быть четко обозначены в системе
4. Должен проводиться регулярный груминг бэклога
5. После завершения задач должны быть освещены их результаты
Каждый пункт отвечает на свой критично важный для работы вопрос:
1. Что делаем?
2. Зачем и для каких целей?
3. В каком порядке и с какой интенсивностью?
4. Не устарела ли информация из п.1-3?
5. Что получилось в результате?
С одной стороны - эти вещи могут казаться очень базовыми. С другой стороны - как ни странно - они практически никогда не выполняются.
В среднем это выглядит так:
1. Что делаем - доносится частично, не четко, часто на словах и без критериев приемки. Результат эффективность утекает из-за потери информации от "испорченного телефона" и "имелось в виду другое", что вызывает переделки на поздних этапах разработки. Растет lead time, разработка становится дороже.
2. Почему мы это делаем - чаще всего никак не объясняется. Результат:
- не знаешь зачем нужна твоя работа - падает вовлеченность и мотивация
- не знаешь цель - не можешь выбрать лучшее решение из своих знаний о системе. Делаешь как сказано
В итоге падает производительность и реже выбираются оптимальные решения
3. Типовые ситуации с приоритетами - они либо вообще не используются по назначению, либо "всё срочно", что делает такую коммуникацию бесполезным шумом. Итог - путаница, стресс команды, неправильное распределение усилий для поставки ценности.
4. Груминг просто не делается. В итоге бэклог перестает соответствовать потребностям продукта и бизнеса, и усилия команды утекают на выполнение того, что уже потеряло ценность.
5. Задача после попадания в релиз улетает куда-то в небытие. Не происходит ни приемки, ни фидбека, ни освещения результатов. В итоге - падение интереса к работе, продукту, как следствие - снижение вовлеченности и мотивации что-то делать.
По последнему пункту просто представьте, что вы делаете красивые игрушки, и в одном случае просто кидаете их в темный ящик, а в другом - видите счастливые лица покупателей того, что вы сделали. В каком случае вы выгорите от бессмысленности своей работы, а в каком будете довольны и заинтересованы?
Из моей практики хорошим продактом можно считать того, кто нормально выполняет первый пункт и хоть как-то - третий. Из пяти.
Простой экономический расчет: бюджет команды разработки - десятки тысяч долларов (для небольшой) и более сотни тысяч в месяц для среднего размера. Пусть роль продакта стоит 10 тысяч в месяц. Пусть их несколько. Стоит ли треть времени этой позиции (несколько тысяч) потратить, чтобы увеличить приозводительность команды стоимостью в 100 тысяч на десятки процентов?
А для читателя остается загадка - то ли всё, что я написал выше - полная чепуха, то ли... почему же так происходит?
P.S. а если вы случайно оказались продактом, который это всё делает - я хочу с Вами дружить! )
❤6👍4
Внедрение инноваций в команде/организации на примере
Каким бы ни было существенное изменение в работе, которое вы хотите внедрить, даже если оно будет очевидно прогрессивным и полезным, коллектив почти всегда разделится примерно на три группы по отношению к этому изменению:
1️⃣ Энтузиасты и радикалы, открытые к изменениям и улучшениям, либо прямо инициирующие их
2️⃣ Консерваторы, сопротивляющиеся изменениям (пассивно или активно - "я привык так делать и буду так делать дальше")
3️⃣ Нейтралы, которые не будут проявлять активность в ту или иную сторону, но могут присоединиться со временем к той позиции, которая доминирует
Это неискоренимо в силу природы людей, которые дифференцируются по радикализму/консерватизму, конформизму/нонконформизму, и ряду других признаков.
Это означает, что есть универсальные методы внедрения инноваций в коллективе. Хочу поделиться несколькими закономерностями из своего опыта, а потом добавить конкретный пример из последнего.
Допустим, речь об изменениях, которые требуют адаптации и больших усилий, растянутых во времени. Не то, что можно поменять 1 днем.
➖Вам никогда не нужно пытаться раскатывать изменения сразу на всех. Обратите внимание на группу энтузиастов, которые примут участие исходя из внутреннего интереса, начните с формирования из них передовой/экспериментальной группы. Это может быть одно подразделение в отделе или виртуальная группа людей из разных команд (гильдия).
➖Проводите пиар изменений, как внутри команды, так и за ее пределами (другие отделы, руководство компании). Это поднимает привлекательность изменений и репутацию команды.
➖Позаботьтесь о финансовой стороне вопроса, если речь про изменения, которые требуют существенных усилий от участников. Повышения, "плюсы" на перформанс ревью, премии, бюджет на инструменты или на то, чтобы отпраздновать успехи - в зависимости от того, что вам доступно.
➖При этом избегайте транзакционных отношений на начальном этапе ("ты мне, я тебе"). Берите на первом этапе на борт только тех, кого интересуют сами изменения как таковые. Если наберете людей, которым не интересен сам процесс - рискуете завалить всё дело.
И конкретный пример про внедрение AI инструментов в разработке:
1️⃣ Собираем инфу кто пользуется ИИ в команде, узнаем минимальные детали
(идентифицируем энтузиастов, консерваторов и нейтралов)
2️⃣ Организуем встречу по обмену опытом, где несколько спикеров делятся своим опытом использования ИИ в разработке (не обязательно быть крутым)
(продолжаем анализ кто есть кто + начинаем пиар)
3️⃣ Анализируем результаты 1 и 2, собираем группу энтузиастов использования ИИ в разработке, которые хотят быть на передовой
4️⃣ Согласуем бюджет на подписки на ИИ инструменты для этой группы
5️⃣ Ставим задачу активно использовать, делиться в группе опытом, инсайтами, собирать примеры использования
6️⃣ Ждем накопления опыта
(за это время какая-то часть нейтрально настроенных людей будет присоединяться к инициативе самостоятельно)
7️⃣ Анализируем и презентуем результат (внутри команды, в компании)
8️⃣ Распространяем успешное использование на остальную команду
Каким бы ни было существенное изменение в работе, которое вы хотите внедрить, даже если оно будет очевидно прогрессивным и полезным, коллектив почти всегда разделится примерно на три группы по отношению к этому изменению:
Это неискоренимо в силу природы людей, которые дифференцируются по радикализму/консерватизму, конформизму/нонконформизму, и ряду других признаков.
Это означает, что есть универсальные методы внедрения инноваций в коллективе. Хочу поделиться несколькими закономерностями из своего опыта, а потом добавить конкретный пример из последнего.
Допустим, речь об изменениях, которые требуют адаптации и больших усилий, растянутых во времени. Не то, что можно поменять 1 днем.
➖Вам никогда не нужно пытаться раскатывать изменения сразу на всех. Обратите внимание на группу энтузиастов, которые примут участие исходя из внутреннего интереса, начните с формирования из них передовой/экспериментальной группы. Это может быть одно подразделение в отделе или виртуальная группа людей из разных команд (гильдия).
➖Проводите пиар изменений, как внутри команды, так и за ее пределами (другие отделы, руководство компании). Это поднимает привлекательность изменений и репутацию команды.
➖Позаботьтесь о финансовой стороне вопроса, если речь про изменения, которые требуют существенных усилий от участников. Повышения, "плюсы" на перформанс ревью, премии, бюджет на инструменты или на то, чтобы отпраздновать успехи - в зависимости от того, что вам доступно.
➖При этом избегайте транзакционных отношений на начальном этапе ("ты мне, я тебе"). Берите на первом этапе на борт только тех, кого интересуют сами изменения как таковые. Если наберете людей, которым не интересен сам процесс - рискуете завалить всё дело.
И конкретный пример про внедрение AI инструментов в разработке:
(идентифицируем энтузиастов, консерваторов и нейтралов)
(продолжаем анализ кто есть кто + начинаем пиар)
(за это время какая-то часть нейтрально настроенных людей будет присоединяться к инициативе самостоятельно)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍6❤2
Что такое "хороший менеджер"?
Готовился тут писать один из следующих постов с названием "Нельзя стать хорошим менеджером, учась на своих ошибках", и логично встал вопрос пояснения термина "хороший менеджер".
Давайте расскажу, как я это понимаю, основываясь на личном опыте. И то, как лично я оцениваю себя и других.
При этом я не буду писать всякие первичные свойства, типа интеллекта, особенностей характера, харизмы и т.п., а только наблюдаемые проявления.
Без вариантов должное:
1️⃣ Умение соблюдать договоренности. Держать слово, или, в просторечии, "отвечать за базар".
2️⃣ Отсутствие гибрис-синдрома. Проще говоря, серьезных проблем с эго, связанных с наличием руководящей позиции. Жажда власти, обидчивость, высокомерие, чрезмерная щепетильность по поводу своего "авторитета" - всё сюда.
3️⃣ Win-win майндсет. Менеджер находится (мы тут говорим о наемнике) между предпринимателем или другим менеджером и своей командой. Этот пункт означает, что он действует, балансируя интересы обеих сторон, не выбирая явным образом одну в ущерб другой.
4️⃣ Отсутствие, что называется, проявлений insecurity (неуверенность, уязвимость, ощущение собственной недостаточности). Если не смелость, то по крайней мере отсутствие подавляющих страхов, чтобы отстоять то, что считаешь правильным.
(примечание: повторюсь, я пишу про наблюдаемые проявления. Внутри человек может чувствовать себя как угодно, но если он может со своими комплексами справиться и не проявлять их с коллегами - это ок)
5️⃣ Самокритичность. Способность сомневаться, выслушивать альтернативные мнения, признавать свои ошибки публично.
6️⃣ Кооперативность. Способность не вести себя как территориальное животное или герой Игры Престолов/Борджиа, а сотрудничать с другими менеджерами для достижения общих целей.
7️⃣ Здравый смысл. Наиболее сложно формализуемая характеристика, но почти все, кто имеют дело с менеджерами, часто видят, что это огромное преимущество, и это полный ахтунг, когда этого нет. Можно назвать по другому - способность принимать рациональные взвешенные решения.
8️⃣ Профессионализм. Понимание (теория, предпосылки, ситуация), применение (принятие решений и организация работы) и способность объяснить (свои решения, явления и т.п.).
Есть еще много важных свойств, без которых, тем не менее, могу представить хорошего менеджера, например получение удовольствия от своей работы, честность/открытость, справедливость и другие. Стратегическое мышление или умение воодушевлять людей, которые обычно не совмещаются в одном человеке.
Много ли людей, которые укладываются в эти критерии? На мой взгляд, не очень. Но все, кто укладывались - очень запоминающиеся личности и очень многим вокруг было очевидно, что это выдающиеся менеджеры.
Готовился тут писать один из следующих постов с названием "Нельзя стать хорошим менеджером, учась на своих ошибках", и логично встал вопрос пояснения термина "хороший менеджер".
Давайте расскажу, как я это понимаю, основываясь на личном опыте. И то, как лично я оцениваю себя и других.
При этом я не буду писать всякие первичные свойства, типа интеллекта, особенностей характера, харизмы и т.п., а только наблюдаемые проявления.
Без вариантов должное:
(примечание: повторюсь, я пишу про наблюдаемые проявления. Внутри человек может чувствовать себя как угодно, но если он может со своими комплексами справиться и не проявлять их с коллегами - это ок)
Есть еще много важных свойств, без которых, тем не менее, могу представить хорошего менеджера, например получение удовольствия от своей работы, честность/открытость, справедливость и другие. Стратегическое мышление или умение воодушевлять людей, которые обычно не совмещаются в одном человеке.
Много ли людей, которые укладываются в эти критерии? На мой взгляд, не очень. Но все, кто укладывались - очень запоминающиеся личности и очень многим вокруг было очевидно, что это выдающиеся менеджеры.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍7❤3
Закон вытеснения инициативы формализацией
Думаю, мы достаточно познакомились и размялись, чтобы иногда переходить к более глубокой и неочевидной теории)
И первая из сложных неочевидных механик - то, как формализация и правила влияют на общий результат работы.
Какое у людей обычно базовое, интуитивное представление:
➖Должны быть четко определены роли и прописаны зоны ответственности
➖Процессы должны быть понятно прописаны
➖Лучше больше ясности, чтобы понятно было кому и что делать
И в некоторых, особенно запущенных случаях:
➖Менеджеры должны описать, что нужно делать, а остальные должны делать это
Мы к этому еще сейчас вернемся, но сначала я сформулирую закон:
📖 "Для выбранной деятельности и команды существует такой минимальный набор правил, после которого добавление правила снижает полезный результат работы"
Или упрощенная версия: "делая X обязанностью, ты можешь потерять 2X от результата".
Очень простой и многим понятный пример:
➖В компании свободный график - когда хочешь приходишь, когда хочешь уходишь. При этом иногда надо сделать релиз утром или "потушить пожар" вечером/на выходных. Всем ок, люди по своей инициативе закрывают много вопросов.
➖Очередной менеджер приходит и решает вводить правила по поводу рабочего времени, например, что оно должно быть фиксированным.
➖Результат: когда кончается окно рабочего времени, все дружно отключаются и недоступны в случае каких-то проблем. В итоге все в минусе.
➖Другой пример, более сложный - с формализацией ролей и зон ответственности. Напомню ключевую механику - люди разные. У одного что-то одно хорошо получается, а другое совсем плохо. Эффективная команда строится вокруг сильных сторон составляющих ее личностей, а не вокруг погони за устранением слабостей.
➖Формализуя универсальную роль с точным перечнем навыков и выполняемых функций (например, middle backend developer), вы почти всегда получите "прокрустово ложе" - одни не будут в него вписываться, другие будут до него недотягивать.
Потом смотришь на такие описания и спрашиваешь: "это реально используется в работе?" - нет.
❗️Важно еще понимать, что наличие неработающих правил - это не ноль, это минус. Это:
1. Ухудшает отношение к нормальным правилам
2. Тратит время
3. Раздражает людей
И третий пример:
➖Есть команда, в ней 8 человек. 6 хорошо работают и имеют внутреннюю мотивацию. 1 работает нормально, но слишком часто оставшись без внимания впадает в прокрастинацию. И еще 1 работает отвратительно и ищет все возможности минимизировать продуктивность, то есть работает только, что называется, "из-под палки".
➖Есть менеджер, который делает типичный вывод, что нужен контроль, чтобы решить эту проблему. И он вводит правило - теперь каждый день делаем дейлики, где все отчитываются о том, что сделали за день и планируют делать завтра.
➖Результат: 6 человек, у которых все было норм, нагружены ненужным ритуалом. Седьмой вынужден периодически придумывать, что он "сделал", пока прокрастинировал, так как очень сложно сказать честно что не смог работать вчера. Он еще больше замыкается в себе от этой лжи. Восьмого же это совершенно не смущает и он легко выдумывает варианты типа "разбирался" или "продолжал заниматься задачей". Итог: все в минусе.
Тема на самом деле потянула бы минимум на часовую беседу, но если краткий вывод сделать, какие можно из этого выделить ориентиры:
✅ Думая о введении правила, думать не только о целях, но и минусах его введения.
✅ Периодически надо задумываться о том, чтобы отменять имеющиеся правила. Ставить под сомнение их целесообразность и эффективность.
✅ Важно разбираться в психологии того, как формируется инициатива на местах, и как обязательства ее снижают
✅ Если вы хотите от кого-то инициативы, вы должны его меньше контролировать или вообще не контролировать
✅ Не используйте правила как инструмент формирования результата. Вместо этого рассказывайте коллегам о целях и ожиданиях от результата их работы
✅ Вы не сделаете универсальную систему, в которой понравится вместе работать и людям со внутренней мотивацией, и тем, кому нужен "начальник" с палкой над душой
Думаю, мы достаточно познакомились и размялись, чтобы иногда переходить к более глубокой и неочевидной теории)
И первая из сложных неочевидных механик - то, как формализация и правила влияют на общий результат работы.
Какое у людей обычно базовое, интуитивное представление:
➖Должны быть четко определены роли и прописаны зоны ответственности
➖Процессы должны быть понятно прописаны
➖Лучше больше ясности, чтобы понятно было кому и что делать
И в некоторых, особенно запущенных случаях:
➖Менеджеры должны описать, что нужно делать, а остальные должны делать это
Мы к этому еще сейчас вернемся, но сначала я сформулирую закон:
📖 "Для выбранной деятельности и команды существует такой минимальный набор правил, после которого добавление правила снижает полезный результат работы"
Или упрощенная версия: "делая X обязанностью, ты можешь потерять 2X от результата".
Очень простой и многим понятный пример:
➖В компании свободный график - когда хочешь приходишь, когда хочешь уходишь. При этом иногда надо сделать релиз утром или "потушить пожар" вечером/на выходных. Всем ок, люди по своей инициативе закрывают много вопросов.
➖Очередной менеджер приходит и решает вводить правила по поводу рабочего времени, например, что оно должно быть фиксированным.
➖Результат: когда кончается окно рабочего времени, все дружно отключаются и недоступны в случае каких-то проблем. В итоге все в минусе.
➖Другой пример, более сложный - с формализацией ролей и зон ответственности. Напомню ключевую механику - люди разные. У одного что-то одно хорошо получается, а другое совсем плохо. Эффективная команда строится вокруг сильных сторон составляющих ее личностей, а не вокруг погони за устранением слабостей.
➖Формализуя универсальную роль с точным перечнем навыков и выполняемых функций (например, middle backend developer), вы почти всегда получите "прокрустово ложе" - одни не будут в него вписываться, другие будут до него недотягивать.
Потом смотришь на такие описания и спрашиваешь: "это реально используется в работе?" - нет.
❗️Важно еще понимать, что наличие неработающих правил - это не ноль, это минус. Это:
1. Ухудшает отношение к нормальным правилам
2. Тратит время
3. Раздражает людей
И третий пример:
➖Есть команда, в ней 8 человек. 6 хорошо работают и имеют внутреннюю мотивацию. 1 работает нормально, но слишком часто оставшись без внимания впадает в прокрастинацию. И еще 1 работает отвратительно и ищет все возможности минимизировать продуктивность, то есть работает только, что называется, "из-под палки".
➖Есть менеджер, который делает типичный вывод, что нужен контроль, чтобы решить эту проблему. И он вводит правило - теперь каждый день делаем дейлики, где все отчитываются о том, что сделали за день и планируют делать завтра.
➖Результат: 6 человек, у которых все было норм, нагружены ненужным ритуалом. Седьмой вынужден периодически придумывать, что он "сделал", пока прокрастинировал, так как очень сложно сказать честно что не смог работать вчера. Он еще больше замыкается в себе от этой лжи. Восьмого же это совершенно не смущает и он легко выдумывает варианты типа "разбирался" или "продолжал заниматься задачей". Итог: все в минусе.
Тема на самом деле потянула бы минимум на часовую беседу, но если краткий вывод сделать, какие можно из этого выделить ориентиры:
✅ Думая о введении правила, думать не только о целях, но и минусах его введения.
✅ Периодически надо задумываться о том, чтобы отменять имеющиеся правила. Ставить под сомнение их целесообразность и эффективность.
✅ Важно разбираться в психологии того, как формируется инициатива на местах, и как обязательства ее снижают
✅ Если вы хотите от кого-то инициативы, вы должны его меньше контролировать или вообще не контролировать
✅ Не используйте правила как инструмент формирования результата. Вместо этого рассказывайте коллегам о целях и ожиданиях от результата их работы
✅ Вы не сделаете универсальную систему, в которой понравится вместе работать и людям со внутренней мотивацией, и тем, кому нужен "начальник" с палкой над душой
👍9❤2
"Что такое плохо" на примере историй из жизни
Иногда можно лучше понять, что такое "хорошо", узнав, что такое "плохо".
Я расскажу несколько из запомнившихся мне историй.
Всего будет 8 историй, я их расскажу в порядке от довольно безобидных до критичных.
Ну и, наверно, стоит добавить, что по 1 ситуации (кроме самых долбанутых) не стоит делать совсем уж поспешные выводы целиком о человеке )
1️⃣ Итак, первая история - "Плюрализм споткнулся о размер столов".
Руководитель департамента разработки решил проявить плюрализм и вынести на обсуждение команды новый дизайн офиса. Сложно сказать, на что он рассчитывал, но пошел довольно серьезный и увлеченный разбор полетов с критикой, в особенности критика пришлась на слишком маленький размер столов. В итоге начался, что называется, срач.
Итог - руководитель департамента рассердился/обиделся, сказал, что больше не будет мнение команды спрашивать )
Мораль:
➖Нужно заранее думать о хороших и плохих сценариях развития событий. Если не уверен - вообще не начинай
➖Нужно уметь воспринимать критику, быть к ней готовым
➖Можно что-то почитать про фасилитацию обсуждений, как это правильно делается
➖Не надо обижаться ) это смешно и глупо
2️⃣ "Ну это, конечно, неправда".
В компанию приходит новый технический директор. Создает образ демократичного человека, который открыто общается с сотрудниками, интересуется их мнением.
И вот, обсуждается какой-то серьезный вопрос на тему как правильно организовать работу с тимлидом одной из команд разработки и разработчиком (это я).
Техдир задает вопрос, получает очень обстоятельный и глубокий ответ (разрабы с таким настроением - вот наконец-то есть кому рассказать о реальных проблемах, и с этим челом мы их устраним).
Ответ техдира - цитата - "ну, это, конечно, неправда", и как ни в чем ни бывало продолжает разговор.
Мы выпали ) Всё, с этого момента, можно сказать, что интерес к его персоне и доверие падает практически до нуля )
Мораль:
➖Надо уважительно общаться с коллегами
➖Свои комплексы надо держать при себе
➖Если даже вы кому-то не доверяете - особенно если это только начало общения и по сути знакомство - не надо "ляпать языком" всякую чушь
3️⃣ "Ты подрываешь мой авторитет"
Начинающий тимлид ведет дейлик. Отчитывается разработчик, затрагивается какая-то фича. Тимлид поясняет разрабу как она работает. Другой разработчик (это был я) высказывается, что работает по другому. Тимлид настаивает на своей версии, и получает ответ - "да нет, я вот только сегодня смотрел это". Дискуссия на этом заканчивается. Но не история )
После дейлика тимлид подходит ко мне и начинает раздраженно докапываться по какому-то другому рабочему вопросу. Раньше такого не было (да и вообще у нас дружеские отношения), поэтому сразу становится понятно, что дело не в этом вопросе. Я предлагаю сходить на обед пообщаться.
Через 10 минут посторонних разговоров тимлида прорывает, и он наконец сообщает, что я подрываю его авторитет и что я не должен оспаривать его решения. Мой ответ "это обычный рабочий вопрос, конечно нужно просто спокойно обсуждать лучшее решение и всё" - его не устраивает, разговор накаляется, доходит практически до ссоры.
Мораль:
➖Нужно внимательно следить за своим эго, своими комплексами, особенно это касается новичков, которые впервые стали руководителями
➖Не нужно путать критику идей, выборов и решений с критикой личности. Публичное обсуждение решений - норм, личности - плохо
➖Если вам что-то сильно не нравится - нужно набраться смелости, предложить встречу 1-1 и высказать это
Иногда можно лучше понять, что такое "хорошо", узнав, что такое "плохо".
Я расскажу несколько из запомнившихся мне историй.
Всего будет 8 историй, я их расскажу в порядке от довольно безобидных до критичных.
Ну и, наверно, стоит добавить, что по 1 ситуации (кроме самых долбанутых) не стоит делать совсем уж поспешные выводы целиком о человеке )
Руководитель департамента разработки решил проявить плюрализм и вынести на обсуждение команды новый дизайн офиса. Сложно сказать, на что он рассчитывал, но пошел довольно серьезный и увлеченный разбор полетов с критикой, в особенности критика пришлась на слишком маленький размер столов. В итоге начался, что называется, срач.
Итог - руководитель департамента рассердился/обиделся, сказал, что больше не будет мнение команды спрашивать )
Мораль:
➖Нужно заранее думать о хороших и плохих сценариях развития событий. Если не уверен - вообще не начинай
➖Нужно уметь воспринимать критику, быть к ней готовым
➖Можно что-то почитать про фасилитацию обсуждений, как это правильно делается
➖Не надо обижаться ) это смешно и глупо
В компанию приходит новый технический директор. Создает образ демократичного человека, который открыто общается с сотрудниками, интересуется их мнением.
И вот, обсуждается какой-то серьезный вопрос на тему как правильно организовать работу с тимлидом одной из команд разработки и разработчиком (это я).
Техдир задает вопрос, получает очень обстоятельный и глубокий ответ (разрабы с таким настроением - вот наконец-то есть кому рассказать о реальных проблемах, и с этим челом мы их устраним).
Ответ техдира - цитата - "ну, это, конечно, неправда", и как ни в чем ни бывало продолжает разговор.
Мы выпали ) Всё, с этого момента, можно сказать, что интерес к его персоне и доверие падает практически до нуля )
Мораль:
➖Надо уважительно общаться с коллегами
➖Свои комплексы надо держать при себе
➖Если даже вы кому-то не доверяете - особенно если это только начало общения и по сути знакомство - не надо "ляпать языком" всякую чушь
Начинающий тимлид ведет дейлик. Отчитывается разработчик, затрагивается какая-то фича. Тимлид поясняет разрабу как она работает. Другой разработчик (это был я) высказывается, что работает по другому. Тимлид настаивает на своей версии, и получает ответ - "да нет, я вот только сегодня смотрел это". Дискуссия на этом заканчивается. Но не история )
После дейлика тимлид подходит ко мне и начинает раздраженно докапываться по какому-то другому рабочему вопросу. Раньше такого не было (да и вообще у нас дружеские отношения), поэтому сразу становится понятно, что дело не в этом вопросе. Я предлагаю сходить на обед пообщаться.
Через 10 минут посторонних разговоров тимлида прорывает, и он наконец сообщает, что я подрываю его авторитет и что я не должен оспаривать его решения. Мой ответ "это обычный рабочий вопрос, конечно нужно просто спокойно обсуждать лучшее решение и всё" - его не устраивает, разговор накаляется, доходит практически до ссоры.
Мораль:
➖Нужно внимательно следить за своим эго, своими комплексами, особенно это касается новичков, которые впервые стали руководителями
➖Не нужно путать критику идей, выборов и решений с критикой личности. Публичное обсуждение решений - норм, личности - плохо
➖Если вам что-то сильно не нравится - нужно набраться смелости, предложить встречу 1-1 и высказать это
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥5❤3
Продолжение прошлого поста, истории про "что такое плохо"
4️⃣ "В Ставрополе за эти деньги..."
Еще давно, на первой работе я был стажером в аутсорсинговой разработке. Там классно был организован конвейер по отбору, обучению и онбордингу высококлассных стажеров. Но после окончания стажировки люди переходили на сдельную зарплату и перспективы были довольно плачевные. Все стажеры в "курилке" обсуждали свои сомнительные перспективы в компании, когда они перейдут из стажеров в специалисты. Некоторые даже специально оттягивали этот момент, хотя зарплата стажера была больше похожа на стипендию.
И вот, встреча с руководством компании, где можно открыто поговорить и задать вопросы. Я освещаю выше описанную ситуацию и предложение пересмотреть условия, на которых люди начинают работать как специалисты, гендиректор триггерится на фразу про стипендию, со словами "да в в Ставрополе люди за эти деньги" рады работать и так далее. Всё, далее уже никакие рациональные аргументы не имеют смысла. Больше я в этой компании руководству ничего не предлагал. Пара человек при мне ушли на х2 зп в другие компании. Потом и я ушел.
Это очень частая ситуация, когда человек воспринимает ситуацию, требующую менеджерского решения, не рационально, а эмоционально, причем эмоции часто основаны на воспринимаемом близко к сердцу личном (опыте или переживании).
Мораль:
➖Решая ситуацию как менеджер, нельзя полагаться на эмоции, на свою личную жизнь и опыт, прошлую карьеру. Только на объективный анализ текущей ситуации
➖"Мне/кому-то было тяжело, теперь вам должно быть тяжело" - это токсичная, неэффективная, а потому еще и глупая установка
5️⃣ "Как правильно или как лучше?"
В этой истории я уже достаточно опытный разработчик с навыками аналитика, решающий весь цикл задачи от общения с пользователем до реализации и тестирования. Наша команда занимается разработкой биллинга и различных внутренних продуктов, которыми пользуется бухгалтерия и т.п.
Возникает типовая задача - из-за рассинхрона финансовых данных между разными сервисами нужен какой-то механизм сверок. Есть несколько частей системы, за каждую отвечают разные отделы. И вот есть заказчик - главный бухгалтер, и есть менеджер, принимающий решение - директор по разработке.
У нас возникли разногласия - я предлагал сделать сверку на стороне моей команды, потому что тогда это будет сделано быстро и качественно. Директор предлагал сделать в на стороне команды, которая отвечает за данные (DWH), потому что это "правильно", и по правильному сверки должны быть на их стороне. Технически сделать можно было и так и так - в обеих системах были все возможности.
В общем мы немного поспорили, потому что я понимал, что если это отдать им - это либо вообще не будет сделано, либо будет сделано через несколько месяцев против наших 1-2 недель. Но Head of Dev твердо остался на своем.
Это типичный выбор между "как правильно" (теоретически) и "как лучше" (в реальности). И это довольно типичная ошибка людей с майндсетом разработчика.
Я на тот момент еще достаточно горячо, скажем так, воспринимал такие ситуации, поэтому на этом я не остановился, и решил слегка поинтриговать, чтобы было таки выбрано мое решение. Я отдельно встретился и обсудил ситуацию с заказчиком (главным бухгалтером) и описал просто - "либо мы делаем как хочет Стас, либо это будет нормально и быстро сделано". Она всё поняла, не знаю что там было сделано за кулисами, но через пару дней нам отдали эту задачу )
Мораль:
➖Реальные условия на земле всегда важнее "теоретически правильного" решения
➖При оценке ситуации надо учитывать качество и надежность кадров, а не только технологии и организационную структуру
➖Порой можно добиться своего решения, даже если ты разработчик, а оппонент - директор по разработке. Если уметь и хотеть. Другой вопрос - нужно ли вам это?
Еще давно, на первой работе я был стажером в аутсорсинговой разработке. Там классно был организован конвейер по отбору, обучению и онбордингу высококлассных стажеров. Но после окончания стажировки люди переходили на сдельную зарплату и перспективы были довольно плачевные. Все стажеры в "курилке" обсуждали свои сомнительные перспективы в компании, когда они перейдут из стажеров в специалисты. Некоторые даже специально оттягивали этот момент, хотя зарплата стажера была больше похожа на стипендию.
И вот, встреча с руководством компании, где можно открыто поговорить и задать вопросы. Я освещаю выше описанную ситуацию и предложение пересмотреть условия, на которых люди начинают работать как специалисты, гендиректор триггерится на фразу про стипендию, со словами "да в в Ставрополе люди за эти деньги" рады работать и так далее. Всё, далее уже никакие рациональные аргументы не имеют смысла. Больше я в этой компании руководству ничего не предлагал. Пара человек при мне ушли на х2 зп в другие компании. Потом и я ушел.
Это очень частая ситуация, когда человек воспринимает ситуацию, требующую менеджерского решения, не рационально, а эмоционально, причем эмоции часто основаны на воспринимаемом близко к сердцу личном (опыте или переживании).
Мораль:
➖Решая ситуацию как менеджер, нельзя полагаться на эмоции, на свою личную жизнь и опыт, прошлую карьеру. Только на объективный анализ текущей ситуации
➖"Мне/кому-то было тяжело, теперь вам должно быть тяжело" - это токсичная, неэффективная, а потому еще и глупая установка
В этой истории я уже достаточно опытный разработчик с навыками аналитика, решающий весь цикл задачи от общения с пользователем до реализации и тестирования. Наша команда занимается разработкой биллинга и различных внутренних продуктов, которыми пользуется бухгалтерия и т.п.
Возникает типовая задача - из-за рассинхрона финансовых данных между разными сервисами нужен какой-то механизм сверок. Есть несколько частей системы, за каждую отвечают разные отделы. И вот есть заказчик - главный бухгалтер, и есть менеджер, принимающий решение - директор по разработке.
У нас возникли разногласия - я предлагал сделать сверку на стороне моей команды, потому что тогда это будет сделано быстро и качественно. Директор предлагал сделать в на стороне команды, которая отвечает за данные (DWH), потому что это "правильно", и по правильному сверки должны быть на их стороне. Технически сделать можно было и так и так - в обеих системах были все возможности.
В общем мы немного поспорили, потому что я понимал, что если это отдать им - это либо вообще не будет сделано, либо будет сделано через несколько месяцев против наших 1-2 недель. Но Head of Dev твердо остался на своем.
Это типичный выбор между "как правильно" (теоретически) и "как лучше" (в реальности). И это довольно типичная ошибка людей с майндсетом разработчика.
Я на тот момент еще достаточно горячо, скажем так, воспринимал такие ситуации, поэтому на этом я не остановился, и решил слегка поинтриговать, чтобы было таки выбрано мое решение. Я отдельно встретился и обсудил ситуацию с заказчиком (главным бухгалтером) и описал просто - "либо мы делаем как хочет Стас, либо это будет нормально и быстро сделано". Она всё поняла, не знаю что там было сделано за кулисами, но через пару дней нам отдали эту задачу )
Мораль:
➖Реальные условия на земле всегда важнее "теоретически правильного" решения
➖При оценке ситуации надо учитывать качество и надежность кадров, а не только технологии и организационную структуру
➖Порой можно добиться своего решения, даже если ты разработчик, а оппонент - директор по разработке. Если уметь и хотеть. Другой вопрос - нужно ли вам это?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4❤2
#рекомендации
В перерывах между историями хочу поделиться рассказом Ивана Селиховкина "Черная книга скрам". Это тот чел, набором статей про проектный менеджмент которого я делился в одном из постов.
Вообще я не знаю, что он за человек и чем занимается, но он пишет очень умно и с глубоким знанием вопроса.
По сути, здесь он в форме рассказа иронически пересматривает очень распространенную не критичную точку зрения на Agile в форме карго-культа. Я бы даже сказал, что прочитать рассказ и тщательно его обдумать - это хорошее упражнение, чтобы подняться на ступеньку выше как менеджер, умеющий выбирать правильные организационные инструменты.
Ссылка: https://pmjournal.ru/articles/keysy/chernaya-kniga-skram/
В перерывах между историями хочу поделиться рассказом Ивана Селиховкина "Черная книга скрам". Это тот чел, набором статей про проектный менеджмент которого я делился в одном из постов.
Вообще я не знаю, что он за человек и чем занимается, но он пишет очень умно и с глубоким знанием вопроса.
По сути, здесь он в форме рассказа иронически пересматривает очень распространенную не критичную точку зрения на Agile в форме карго-культа. Я бы даже сказал, что прочитать рассказ и тщательно его обдумать - это хорошее упражнение, чтобы подняться на ступеньку выше как менеджер, умеющий выбирать правильные организационные инструменты.
Ссылка: https://pmjournal.ru/articles/keysy/chernaya-kniga-skram/
👍3🔥2🤔1
Продолжаем истории "что такое плохо".
6️⃣ "Удали, пожалуйста, свое сообщение"
Я тогда работал разрабом, где-то 2,5 года опыта примерно было. 50%+ моей работы это была поддержка, в основном колл-центра, оформления заказов, логистики и т.п. в приложении. Короче, много общался с пользователями и консультировал их, так как часто какие-то проблемы были из недопонимания и решались на словах. А если надо было кодить - то либо решал сам, либо передавал другим разрабам по зонам ответственности. И я был, соответственно, единой точкой входа в команду разработки по любым проблемам.
При этом у нас были трое парней на саппорте, которые по сути просто перенаправляли запросы ко мне, даже с типовыми вопросами. У меня закономерно возникла идея реорганизовать саппорт по нормальному, чтобы консультационные вопросы по работе приложения решались поддержкой, а не разрабами, типовые так точно.
Я придумал и предложил руководителю департамента улучшенную схему работы саппорта, предложил сделать внутреннюю базу знаний по решению типовых кейсов поддержкой и т.п., с обоснованием, в том числе экономическим (саппорт в несколько раз дешевле разрабов).
На это предложение отреагировали положительно, но с классической оговоркой - что организация, внедрение и обучение полностью на мне.
И вот, ближе к концу обсуждения этой идеи, идет переписка на корпоративном портале в комментах между мной, руководителем нашего департамента разработки, и техническим директором, который руководит этими чувачками на саппорте. У меня возникает резонный вопрос - а какая мотивация у этих ребят браться за это и усложнять себе работу - сейчас они с отключенным мозгом могут просто раскидывать тикеты, а в этой схеме они должны стать специалистами как минимум 2 линии. И там же спрашиваю, будет ли у них какое-то повышение зарплаты или какой у них мотив этим заниматься. В общем веду себя как нормальный человек, который конструктивно решает рабочую проблему.
Через несколько минут мне звонит техдир, их руководитель, и говорит "Удали, пожалуйста, свое сообщение". Я, помню, даже опешил от такого прикола. Говорю: "эээ, хорошо, а какая-все таки у них будет мотивация этим заниматься?". И он отвечает: "то что их не уволят" %)) В общем молодо-зелено, сообщение я удалил (сегодняшний я бы не удалил), но сразу сделал вывод, что, во-первых, техдир идиот, и во-вторых, что шансов у этого проекта примерно 0%.
При этом проект уже был повешен на меня. Я потратил какое-то время, пытаясь понять, можно ли с него съехать, и когда понял, что нельзя - просто договорился со своим руководителем, что мы попробуем, может получится, а может нет (я знал, что точно нет), и не стал особо вкладывать усилия в это, отработал чисто формально (естественно, у чуваков не было никакой мотивации), и всё это потихоньку сошло на нет за несколько месяцев и тихо было прикопано без каких-то дальнейших обсуждений.
Мораль:
➖Если вы имеете дело с каким-то среднего уровня менеджментом (а средний уровень - слабый), то скорее всего ваши предложения по улучшению работы, требующие чего-то от кого-то кроме вас - не взлетят. Бывает сложно оценить уровень менеджера, особенно по неопытности, но просто знать об этом уже неплохо.
➖Переход на принципиально более сложную и ответственную работу всегда должен сопровождаться промоушеном (повышением с изменением роли и зарплаты). Он может быть отложенным (по достижению результата), но из этого правила нет исключений. Альтернатива - почти гарантированно отсутствие мотивации этим заниматься.
➖Если на человека вешают невыполнимую или крайне неприятную задачу - отказываться и ругаться это не всегда единственная выход, который у него есть. Тихий и неприметный слив - это вторая опция. Это знает любой опытный менеджер как применительно к себе, так и к членам своей команды )
Я тогда работал разрабом, где-то 2,5 года опыта примерно было. 50%+ моей работы это была поддержка, в основном колл-центра, оформления заказов, логистики и т.п. в приложении. Короче, много общался с пользователями и консультировал их, так как часто какие-то проблемы были из недопонимания и решались на словах. А если надо было кодить - то либо решал сам, либо передавал другим разрабам по зонам ответственности. И я был, соответственно, единой точкой входа в команду разработки по любым проблемам.
При этом у нас были трое парней на саппорте, которые по сути просто перенаправляли запросы ко мне, даже с типовыми вопросами. У меня закономерно возникла идея реорганизовать саппорт по нормальному, чтобы консультационные вопросы по работе приложения решались поддержкой, а не разрабами, типовые так точно.
Я придумал и предложил руководителю департамента улучшенную схему работы саппорта, предложил сделать внутреннюю базу знаний по решению типовых кейсов поддержкой и т.п., с обоснованием, в том числе экономическим (саппорт в несколько раз дешевле разрабов).
На это предложение отреагировали положительно, но с классической оговоркой - что организация, внедрение и обучение полностью на мне.
И вот, ближе к концу обсуждения этой идеи, идет переписка на корпоративном портале в комментах между мной, руководителем нашего департамента разработки, и техническим директором, который руководит этими чувачками на саппорте. У меня возникает резонный вопрос - а какая мотивация у этих ребят браться за это и усложнять себе работу - сейчас они с отключенным мозгом могут просто раскидывать тикеты, а в этой схеме они должны стать специалистами как минимум 2 линии. И там же спрашиваю, будет ли у них какое-то повышение зарплаты или какой у них мотив этим заниматься. В общем веду себя как нормальный человек, который конструктивно решает рабочую проблему.
Через несколько минут мне звонит техдир, их руководитель, и говорит "Удали, пожалуйста, свое сообщение". Я, помню, даже опешил от такого прикола. Говорю: "эээ, хорошо, а какая-все таки у них будет мотивация этим заниматься?". И он отвечает: "то что их не уволят" %)) В общем молодо-зелено, сообщение я удалил (сегодняшний я бы не удалил), но сразу сделал вывод, что, во-первых, техдир идиот, и во-вторых, что шансов у этого проекта примерно 0%.
При этом проект уже был повешен на меня. Я потратил какое-то время, пытаясь понять, можно ли с него съехать, и когда понял, что нельзя - просто договорился со своим руководителем, что мы попробуем, может получится, а может нет (я знал, что точно нет), и не стал особо вкладывать усилия в это, отработал чисто формально (естественно, у чуваков не было никакой мотивации), и всё это потихоньку сошло на нет за несколько месяцев и тихо было прикопано без каких-то дальнейших обсуждений.
Мораль:
➖Если вы имеете дело с каким-то среднего уровня менеджментом (а средний уровень - слабый), то скорее всего ваши предложения по улучшению работы, требующие чего-то от кого-то кроме вас - не взлетят. Бывает сложно оценить уровень менеджера, особенно по неопытности, но просто знать об этом уже неплохо.
➖Переход на принципиально более сложную и ответственную работу всегда должен сопровождаться промоушеном (повышением с изменением роли и зарплаты). Он может быть отложенным (по достижению результата), но из этого правила нет исключений. Альтернатива - почти гарантированно отсутствие мотивации этим заниматься.
➖Если на человека вешают невыполнимую или крайне неприятную задачу - отказываться и ругаться это не всегда единственная выход, который у него есть. Тихий и неприметный слив - это вторая опция. Это знает любой опытный менеджер как применительно к себе, так и к членам своей команды )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤4🔥3
Предпоследняя история про плохой менеджмент.
7️⃣ "вам самим-то не надоело в говне сидеть?"
Эта история из восьми - моя любимая. Сама ситуация очень короткая, но чтобы была понятна вся ее глубина - придется рассказать предысторию.
Мы работали с другом в одной компании, оба программистами. У него были амбиции тимлида, и он нашел подходящую вакансию. Позвал меня с собой - поставил там условие, что ему нужен свой аналитик-прогер.
Это была финтех компания, в ней долгое время не могли найти руководителя в одну из команд разработки. Всё, начиная от процессов и заканчивая состоянием системы, было в относительно плачевном состоянии (было вообще в ужасном, но часть уже успели наладить при предыдущем тимлиде, который ушел за несколько месяцев до этого).
Онбординг был из серии "вот держите доступы". При трудоустройстве я общался с Head of HR и CTO, когда я через месяц пришел на работу - оба они уже уволились. По некоторым конкретным вопросам мог проконсультировать бывший тимлид (с ним был контракт на поддержку), но в целом он не сильно горел желанием сотрудничать и это было заметно.
Так что по большому счету нас просто закинули туда и предоставили самим себе. На доске в Jira - все как обычно, какие-то задачи зависшие на много месяцев в in development, непонятно что на самом деле в работе, задачи с описанием в две строки или вообще без описания и куча проблем в системе. И с командой тоже не все гладко - например, там был чувак, который вообще ничего не делал и его пришлось сразу уволить.
По сути у нас не было никакого руководителя, никто нам не ставил никакие цели, был какой-то поток бизнесовых задач, но в целом мы были просто предоставлены сами себе. Друг занялся больше технической частью и командой, я занялся процессами, ходил вместо него на часть совещаний с руководителями других отделов и заказчиками, реверс-инжинирингом проанализировал имеющийся API и описал его, ну и так далее. Я разобрался в Jira, стал ее админить, сделал новую нормальную доску, сделал рабочий процесс, внедрил его. Ну и при этом мы оба еще параллельно прогали задачи, которые влетали к нам - на разработку или какую-то аналитику собрать.
Так прошло первых несколько месяцев. Наняли нам нового руководителя - техдира. Чувак из тех, про которых сразу мелькает мысль, что физиогномика работает. Мы познакомились, он там начал какой-то свой онбординг проходить, вникать в дела.
(мы подошли к самой ситуации категории "что такое плохо") И вот, где-то пару недель наверно он работает, подходит он к нам с моим другом в опенспейсе с каким-то очередным вопросом о том, как всё устроено, и говорит: "слушайте, вам самим-то не надоело в говне сидеть?"
Вот так вот. %)
Мораль:
➖Ну, во-первых это очень смешно )
➖ Недостаток эмпатии и эгоцентричность для менеджера - это очень большая проблема, исключающая возможность наладить доверительные отношения с сотрудниками (если это не какие-то попадающие в зависимость жертвы)
➖Надо думать, что говоришь. Можно ляпнуть какую-то глупость при знакомстве с людьми, и потом исправить это впечатление будет крайне тяжело или невозможно
➖Другие люди - это не NPC, они тоже что-то делают осмысленное. Придя на новую работу - стоит начать с интервью членов команды и сбора информации о том, что происходило до тебя
➖Ситуацию в менеджменте надо всегда понимать не в статике, а в динамике - "было/стало", отдельные факты имеют малое значение. И лишь на таком уровне стоит давать какую-то оценку работе других людей.
➖И если эта оценка плохая - порой лучше промолчать и подумать еще.
Эта история из восьми - моя любимая. Сама ситуация очень короткая, но чтобы была понятна вся ее глубина - придется рассказать предысторию.
Мы работали с другом в одной компании, оба программистами. У него были амбиции тимлида, и он нашел подходящую вакансию. Позвал меня с собой - поставил там условие, что ему нужен свой аналитик-прогер.
Это была финтех компания, в ней долгое время не могли найти руководителя в одну из команд разработки. Всё, начиная от процессов и заканчивая состоянием системы, было в относительно плачевном состоянии (было вообще в ужасном, но часть уже успели наладить при предыдущем тимлиде, который ушел за несколько месяцев до этого).
Онбординг был из серии "вот держите доступы". При трудоустройстве я общался с Head of HR и CTO, когда я через месяц пришел на работу - оба они уже уволились. По некоторым конкретным вопросам мог проконсультировать бывший тимлид (с ним был контракт на поддержку), но в целом он не сильно горел желанием сотрудничать и это было заметно.
Так что по большому счету нас просто закинули туда и предоставили самим себе. На доске в Jira - все как обычно, какие-то задачи зависшие на много месяцев в in development, непонятно что на самом деле в работе, задачи с описанием в две строки или вообще без описания и куча проблем в системе. И с командой тоже не все гладко - например, там был чувак, который вообще ничего не делал и его пришлось сразу уволить.
По сути у нас не было никакого руководителя, никто нам не ставил никакие цели, был какой-то поток бизнесовых задач, но в целом мы были просто предоставлены сами себе. Друг занялся больше технической частью и командой, я занялся процессами, ходил вместо него на часть совещаний с руководителями других отделов и заказчиками, реверс-инжинирингом проанализировал имеющийся API и описал его, ну и так далее. Я разобрался в Jira, стал ее админить, сделал новую нормальную доску, сделал рабочий процесс, внедрил его. Ну и при этом мы оба еще параллельно прогали задачи, которые влетали к нам - на разработку или какую-то аналитику собрать.
Так прошло первых несколько месяцев. Наняли нам нового руководителя - техдира. Чувак из тех, про которых сразу мелькает мысль, что физиогномика работает. Мы познакомились, он там начал какой-то свой онбординг проходить, вникать в дела.
(мы подошли к самой ситуации категории "что такое плохо") И вот, где-то пару недель наверно он работает, подходит он к нам с моим другом в опенспейсе с каким-то очередным вопросом о том, как всё устроено, и говорит: "слушайте, вам самим-то не надоело в говне сидеть?"
Вот так вот. %)
Мораль:
➖Ну, во-первых это очень смешно )
➖ Недостаток эмпатии и эгоцентричность для менеджера - это очень большая проблема, исключающая возможность наладить доверительные отношения с сотрудниками (если это не какие-то попадающие в зависимость жертвы)
➖Надо думать, что говоришь. Можно ляпнуть какую-то глупость при знакомстве с людьми, и потом исправить это впечатление будет крайне тяжело или невозможно
➖Другие люди - это не NPC, они тоже что-то делают осмысленное. Придя на новую работу - стоит начать с интервью членов команды и сбора информации о том, что происходило до тебя
➖Ситуацию в менеджменте надо всегда понимать не в статике, а в динамике - "было/стало", отдельные факты имеют малое значение. И лишь на таком уровне стоит давать какую-то оценку работе других людей.
➖И если эта оценка плохая - порой лучше промолчать и подумать еще.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤5🔥4
Человек для роли или роль для человека?
Пару раз у меня стояла задача составить или применять "матрицу грейдов" для команды разработки. У думающих людей эти матрицы всегда вызывают процесс критического осмысления содержимого.
❓Действительно ли мы это используем в работе?
❓Правда ли мы именно так определяем рост на следующий грейд?
❓Действительно ли те, кого мы нанимаем и кто у нас уже работают - одинаково соответствуют описанным характеристикам?
❓Действительно ли мы именно на эти вещи смотрим, когда оцениваем сотрудников?
Ну и так далее. Обычно ответ на все или часть этих вопросов - нет.
Другой вопрос - дело ли в конкретной матрице (плохая матрица) или вообще под вопросом целесообразность ее наличия.
Хорошая сторона этой затеи - людям действительно порой не хватает ориентиров по каким критериям им можно улучшить свою работу и как двинуться дальше. Но это в принципе можно решать личным карьерным треком, сделанным на пару с менеджером.
Такие "хорошие" стороны как формализация причин отказа в повышении или принижения чьих-то заслуг я не рассматриваю как хорошие ) Стандартизацию с натяжкой можно отнести к положительным, но стандартизация не имеет самоценности и не может быть целью самой себя.
Плохих сторон, как мне видится, гораздо больше.
Они проистекают из идеи, что люди разные, и у всех разные сильные и слабые стороны. Есть такое выражение - "прокрустово ложе". Строгое и последовательное соблюдение стандартов грейдов, на мой взгляд, имеет именно этот эффект.
Во-первых, кто-то круче, а кто-то слабее. Стандарт подгонять под слабых или под сильных? Если его сделать средним - одни не будут до него дотягивать, другие будут заведомо его превышать. Придется лукавить.
Во-вторых, всегда (почти) это сводится к "на бумаге так, а на практике мы наши субъективные оценки работы человека подгоняем под шаблон". То есть, если нам чья-то работа нравится - мы склонны таким образом зафреймить его работу, чтобы она подходила под предлагаемые компетенции. А если нет - то всегда без труда можно найти в списке отсутствующие или слабые пункты.
То есть фактически это не алгоритмизируется и не автоматизируется, поэтому поверх субъективного мнения менеджера мы просто накладываем формальный слой, который добавляет издержки поверх субъективного решения. То есть решение будет ровно то же самое, просто потребуется дополнительный труд для его принятия.
Но вообще пост не про матрицу компетенций и грейды. Пост про то, вокруг чего строить команду - вокруг сильных сторон или вокруг слабостей. Это не такой очевидный вопрос, и хоть я в такой формулировке его не слышал от других менеджеров, а только в книгах, но по факту люди этот выбор совершают.
Когда мы говорим, что для определенной роли нужен такой-то минимальный набор компетенций, фактически мы легитимизируем фокусировку на слабых сторонах. То есть надо каждую свою компетенцию довести до какого-то приемлемого уровня.
В реальности мы часто имеем команду, в которой люди очень разные, причем чем команда сильнее - тем она более разнообразна и вариативна. В такой команде один будет энтузиастом, другой надежным и ему можно доверить ответственные вещи делать в соло, третий хаотичным и забывчивым, но решающим намного более сложные задачи, четвертый - очень трудоспособным, но с проблемами когда надо делать что-то сложное, а пятый - добряком, с которым всем приятно работать и из-за этого в команде отличная атмосфера.
Представьте, что для этих людей нужно сделать единый стандарт. Это я упомянул (в очень утрированном поверхностном виде) только про личные качества. А еще есть зоны ответственности, которые тоже распределены совершенно неравномерно. Кто-то только делает задачи, а кто-то еще их создает. Кто-то делает деплой. Кто-то следит за ошибками в логах, а кто-то нет.
Надо ли, чтобы все делали весь перечень работ? Сколько-то пунктов из этого списка? А что, если кто-то будет очень хорошо и стабильно делать сложные задачи, но ничего дополнительно на себя не берет?
Здесь есть над чем подумать, и, пожалуй, тема стоит еще одного поста, раскрывающего мою точку зрения на то, "как надо".
Пару раз у меня стояла задача составить или применять "матрицу грейдов" для команды разработки. У думающих людей эти матрицы всегда вызывают процесс критического осмысления содержимого.
❓Действительно ли мы это используем в работе?
❓Правда ли мы именно так определяем рост на следующий грейд?
❓Действительно ли те, кого мы нанимаем и кто у нас уже работают - одинаково соответствуют описанным характеристикам?
❓Действительно ли мы именно на эти вещи смотрим, когда оцениваем сотрудников?
Ну и так далее. Обычно ответ на все или часть этих вопросов - нет.
Другой вопрос - дело ли в конкретной матрице (плохая матрица) или вообще под вопросом целесообразность ее наличия.
Хорошая сторона этой затеи - людям действительно порой не хватает ориентиров по каким критериям им можно улучшить свою работу и как двинуться дальше. Но это в принципе можно решать личным карьерным треком, сделанным на пару с менеджером.
Такие "хорошие" стороны как формализация причин отказа в повышении или принижения чьих-то заслуг я не рассматриваю как хорошие ) Стандартизацию с натяжкой можно отнести к положительным, но стандартизация не имеет самоценности и не может быть целью самой себя.
Плохих сторон, как мне видится, гораздо больше.
Они проистекают из идеи, что люди разные, и у всех разные сильные и слабые стороны. Есть такое выражение - "прокрустово ложе". Строгое и последовательное соблюдение стандартов грейдов, на мой взгляд, имеет именно этот эффект.
Во-первых, кто-то круче, а кто-то слабее. Стандарт подгонять под слабых или под сильных? Если его сделать средним - одни не будут до него дотягивать, другие будут заведомо его превышать. Придется лукавить.
Во-вторых, всегда (почти) это сводится к "на бумаге так, а на практике мы наши субъективные оценки работы человека подгоняем под шаблон". То есть, если нам чья-то работа нравится - мы склонны таким образом зафреймить его работу, чтобы она подходила под предлагаемые компетенции. А если нет - то всегда без труда можно найти в списке отсутствующие или слабые пункты.
То есть фактически это не алгоритмизируется и не автоматизируется, поэтому поверх субъективного мнения менеджера мы просто накладываем формальный слой, который добавляет издержки поверх субъективного решения. То есть решение будет ровно то же самое, просто потребуется дополнительный труд для его принятия.
Но вообще пост не про матрицу компетенций и грейды. Пост про то, вокруг чего строить команду - вокруг сильных сторон или вокруг слабостей. Это не такой очевидный вопрос, и хоть я в такой формулировке его не слышал от других менеджеров, а только в книгах, но по факту люди этот выбор совершают.
Когда мы говорим, что для определенной роли нужен такой-то минимальный набор компетенций, фактически мы легитимизируем фокусировку на слабых сторонах. То есть надо каждую свою компетенцию довести до какого-то приемлемого уровня.
В реальности мы часто имеем команду, в которой люди очень разные, причем чем команда сильнее - тем она более разнообразна и вариативна. В такой команде один будет энтузиастом, другой надежным и ему можно доверить ответственные вещи делать в соло, третий хаотичным и забывчивым, но решающим намного более сложные задачи, четвертый - очень трудоспособным, но с проблемами когда надо делать что-то сложное, а пятый - добряком, с которым всем приятно работать и из-за этого в команде отличная атмосфера.
Представьте, что для этих людей нужно сделать единый стандарт. Это я упомянул (в очень утрированном поверхностном виде) только про личные качества. А еще есть зоны ответственности, которые тоже распределены совершенно неравномерно. Кто-то только делает задачи, а кто-то еще их создает. Кто-то делает деплой. Кто-то следит за ошибками в логах, а кто-то нет.
Надо ли, чтобы все делали весь перечень работ? Сколько-то пунктов из этого списка? А что, если кто-то будет очень хорошо и стабильно делать сложные задачи, но ничего дополнительно на себя не берет?
Здесь есть над чем подумать, и, пожалуй, тема стоит еще одного поста, раскрывающего мою точку зрения на то, "как надо".
👍8🔥5
Мысли о рекрутинге.
В последнее время все больше стал об этом думать. Хочу поделиться с вами.
Для начала, что меня наводило на размышления:
1️⃣ Когда начинаешь работать менеджером, начинаешь видеть насколько сложно найти хотя бы просто нормально работающих людей. Это совершенно непонятно, когда сам куда-то устраиваешься, или просто работаешь с норм коллегами, часть которых еще и круче тебя намного. Это было 5 лет назад, тогда я просто обратил внимание на это, но не придал особо значения.
2️⃣ Я сделал наблюдение, что практически все топовые ребята в команде - это либо пришедшие по стажерской программе, либо по рефералкам. За редким исключением те, кто просто приходил по холодному найму из рынка - исполняли работу при прочих равных на грейд ниже остальных, и чаще всего это была работа в формате исполнения базовых функций. Ну, или наоборот - рефералы и бывшие стажеры выполняли работу на один грейд выше, чем те, кого наняли с рынка.
3️⃣ Потом я начал в подробностях смотреть как изнутри выглядит найм. Например, как разработчик, проводящий собесы, предлагает фильтр по 5 годам опыта. Или как проходит собес чел, который в итоге не умеет делать практически ничего из того, что обсуждалось на собеседовании. Или как приходит чел с хорошими хардами и по рефералке, а в итоге ничего не делает.
4️⃣ Я смотрел одно из видео с Антоном Гладковым, где он рассказал, как нанимает людей. Во-первых, критерии отбора были там гораздо более серьезными. Во-вторых, сроки найма там были порядка недели ("3 дня") вместо возни по несколько месяцев как у всех. То есть в 10+ раз меньше срок при более высоком качестве.
На тот момент я сделал вывод, что холодный найм это крайне унылое и бесперспективное занятие, и наверно по хорошему проще вложить аналогичное количество средств и усилий в формирование способов поиска теплых или горячих кандидатов, чем строить эти конвейеры холодного найма. По крайней мере если речь идет про средний бизнес без HR-бренда с потребностями в единицах людей, ну максимум 1-2 десятках.
5️⃣ Как и все остальные, я наслышан о форматах собеседований в бигтехе. Например, когда мидлом устроиться на порядок проще, чем стажером. Про все эти академические вопросы. Рисования кода на доске. Алгоритмические секции, в том числе для QA. Тесты кубернетеса и кафки для джуна QA. Запрет на использование ИИ ассистента во время собеса. Когда сначала не проходит собес человек, которого потом в этой же компании отрывают в руками и он работает топ-перформером. И ровно обратные ситуации.
6️⃣ Когда я сам питчил работу в моей команде людям, я начал понимать, что рекрутеры не могут так же, по крайней мере если не сформируют тщательно уникальное предложение, скрупулезно изучив особенности команды и компании, куда нанимают. Я рассказывал про типовые задачи, реально важные фичи типа что нет дейликов и кучи дебильных встреч и можно просто работать, и прочие вещи. Отталкиваясь от своего понимания, что у нас особенно по кайфу, если поставить себя на место разработчика. А у всех по дефолту печеньки, интересный коллектив и дружный проект. А, еще продукт, который 10 или 20 лет на рынке! Это как продавать машину, уникальное предложение которой сводится к тому, что она ездит.
7️⃣ Ну и наконец, одно из последних наблюдений, как проходят технические собесы кандидаты, в которых я заведомо знаю, что они отлично работают и являются топ-перформерами. По обоим был фидбек что-то типа 5-6 из 10 и отрицательный вердикт - "не подходит". В основном потому, что не имел опыта работы с конкретными инструментами, технологиями и ситуациями )
То есть я выяснил, что мало того, что есть проблема, что берут тех, кто потом не работает (или не увольняют таких), так еще и режут тех, кто потом бы работал отлично.
(не влезло в 1 пост, продолжение вторым постом ниже)
В последнее время все больше стал об этом думать. Хочу поделиться с вами.
Для начала, что меня наводило на размышления:
На тот момент я сделал вывод, что холодный найм это крайне унылое и бесперспективное занятие, и наверно по хорошему проще вложить аналогичное количество средств и усилий в формирование способов поиска теплых или горячих кандидатов, чем строить эти конвейеры холодного найма. По крайней мере если речь идет про средний бизнес без HR-бренда с потребностями в единицах людей, ну максимум 1-2 десятках.
То есть я выяснил, что мало того, что есть проблема, что берут тех, кто потом не работает (или не увольняют таких), так еще и режут тех, кто потом бы работал отлично.
(не влезло в 1 пост, продолжение вторым постом ниже)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍8
Итого, у нас складывается довольно интересная картина:
➖Поле холодного найма очень слабое, найти даже просто норм работающих людей очень сложно
➖На вакухи летят тысячи отзывов, в том числе большинство нерелевантных, копаться в них без фильтрации уже никто не может. Начинаются какие-то взаимные войны автоматизаций
➖Холодный найм перестает работать - все больше найма сводится к другим способам (например, через прямые приглашения)
➖Есть куча вакансий, которые месяцами не могут закрыть
➖При этом есть топовые люди, которые не могут найти либо вообще ничего толкового, либо достойное их место для раскрытия своего потенциала
➖Есть просто "программисты из подвала", которые работают за 0,5 ценника от вакансий тех, кто не может месяцами найти никого толкового. Они не участвуют в рынке по ряду причин, включая выше озвученные
➖Есть собесы, которые плохо сделаны и их отвратительно проходить
➖Навык прохождения собеседований всё меньше коррелирует с реальным выхлопом от работы
➖Уволить после неудачного найма очень сложно
➖При этом для сотрудников практически отсутствует институт репутации (про компании еще хоть что-то можно узнать из открытых источников) - то есть всякие токсики, отморозки и паразиты просто дрейфуют по разным компаниям, еще больше ухудшая выборку холодного найма
➖Ценник рекрутинга айтишника через агентства достигает 20-25% его годовой зарплаты
➖При этом даже в результате относительно неплохо сделанных собесов бывают ложноположительные и ложноотрицательные заключения
Список неполный.
Выглядит так, как будто здесь закопаны какие-то новые еще не реализованные возможности )
➖Поле холодного найма очень слабое, найти даже просто норм работающих людей очень сложно
➖На вакухи летят тысячи отзывов, в том числе большинство нерелевантных, копаться в них без фильтрации уже никто не может. Начинаются какие-то взаимные войны автоматизаций
➖Холодный найм перестает работать - все больше найма сводится к другим способам (например, через прямые приглашения)
➖Есть куча вакансий, которые месяцами не могут закрыть
➖При этом есть топовые люди, которые не могут найти либо вообще ничего толкового, либо достойное их место для раскрытия своего потенциала
➖Есть просто "программисты из подвала", которые работают за 0,5 ценника от вакансий тех, кто не может месяцами найти никого толкового. Они не участвуют в рынке по ряду причин, включая выше озвученные
➖Есть собесы, которые плохо сделаны и их отвратительно проходить
➖Навык прохождения собеседований всё меньше коррелирует с реальным выхлопом от работы
➖Уволить после неудачного найма очень сложно
➖При этом для сотрудников практически отсутствует институт репутации (про компании еще хоть что-то можно узнать из открытых источников) - то есть всякие токсики, отморозки и паразиты просто дрейфуют по разным компаниям, еще больше ухудшая выборку холодного найма
➖Ценник рекрутинга айтишника через агентства достигает 20-25% его годовой зарплаты
➖При этом даже в результате относительно неплохо сделанных собесов бывают ложноположительные и ложноотрицательные заключения
Список неполный.
Выглядит так, как будто здесь закопаны какие-то новые еще не реализованные возможности )
👍16❤6
image_2025-11-07_21-13-35.png
62.4 KB
Индивидуальная ответственность или коллективная?
Я наткнулся на эту картинку, которую рисовал полтора года назад, чтобы пояснить коллеге, почему нельзя применять подход коллективной ответственности за результат, пока у тебя нет индивидуальной.
В принципе, наверно это была культурная дискуссия (в смысле, что о культуре).
Его посыл, как я его понял, был такой, что не нужно (и даже плохо) обсуждать кто и что конкретно должен делать или плохо делает, а важно, чтобы все (включая людей из разных структурных единиц, например, разработчиков и продактов) работали вместе и добивались результата.
Мой посыл был такой, что есть уровни зрелости, набросал схему как я это понимаю, и что нельзя "перепрыгнуть", а нужно последовательно по ним идти. А если попытаться применить сразу последнюю модель - то будет контрпродуктивно.
То есть:
1️⃣ Сначала нужно добиться/убедиться, что каждый член команды хорошо понимает и делает свою работу. Индивидуально.
2️⃣ Потом нужно убедиться, что команда умеет действовать сообща и интересуется результатом своей работы.
3️⃣ Потом необходимо создать прозрачную систему, через которую принимается работа и транслируется результат этой слаженной команды.
4️⃣ И лишь потом можно говорить о том, чтобы эффективно объединять разные команды для успешной совместной работы, где нет ничего "чужого".
То есть: индивидуальная работа -> тимбилдинг -> прозрачность и системность -> коллективный результат
Почему так?
Потому что если у вас есть проблемы с предыдущими этапами, а вы используете более продвинутую модель - у вас все незакрытые издержки будут вынесены на системный уровень.
Например:
➖у вас есть несколько людей, которые не делают что от них требуется? Другие будут работать за них, потому что "нам важен только командный результат". Со временем люди начнут раздражаться - почему они должны выполнять больше работы за других. Раздражение проявится по разному - кто-то уйдет, кто-то снизит производительность.
Или так:
➖вы не создали прозрачную систему, в которой понятен результат конкретной команды - и вот есть проект, который делают несколько команд. Все вокруг общее, все вокруг ничье. Зоны ответственности и результаты перемешаны. Система не позволяет качественно на большом масштабе распределить работу и так же прозрачно получить результат. Понять, кто справляется, а кто нет. Типичный итог - слабые команды заваливают проект, который пытаются потом судорожно пытаются вытянуть более сильные команды.
Люди (по крайней мере люди моей и близких западных культур) хотят хорошо работать, если результат их работы ассоциируется с их индивидуальностью и личными качествами. Когда они могут себя проявить. И не хотят хорошо работать, если плохая работа не порицается и не устраняется, а издержки от нее просто ложатся на тех, кто лучше работает.
Я наткнулся на эту картинку, которую рисовал полтора года назад, чтобы пояснить коллеге, почему нельзя применять подход коллективной ответственности за результат, пока у тебя нет индивидуальной.
В принципе, наверно это была культурная дискуссия (в смысле, что о культуре).
Его посыл, как я его понял, был такой, что не нужно (и даже плохо) обсуждать кто и что конкретно должен делать или плохо делает, а важно, чтобы все (включая людей из разных структурных единиц, например, разработчиков и продактов) работали вместе и добивались результата.
Мой посыл был такой, что есть уровни зрелости, набросал схему как я это понимаю, и что нельзя "перепрыгнуть", а нужно последовательно по ним идти. А если попытаться применить сразу последнюю модель - то будет контрпродуктивно.
То есть:
То есть: индивидуальная работа -> тимбилдинг -> прозрачность и системность -> коллективный результат
Почему так?
Потому что если у вас есть проблемы с предыдущими этапами, а вы используете более продвинутую модель - у вас все незакрытые издержки будут вынесены на системный уровень.
Например:
➖у вас есть несколько людей, которые не делают что от них требуется? Другие будут работать за них, потому что "нам важен только командный результат". Со временем люди начнут раздражаться - почему они должны выполнять больше работы за других. Раздражение проявится по разному - кто-то уйдет, кто-то снизит производительность.
Или так:
➖вы не создали прозрачную систему, в которой понятен результат конкретной команды - и вот есть проект, который делают несколько команд. Все вокруг общее, все вокруг ничье. Зоны ответственности и результаты перемешаны. Система не позволяет качественно на большом масштабе распределить работу и так же прозрачно получить результат. Понять, кто справляется, а кто нет. Типичный итог - слабые команды заваливают проект, который пытаются потом судорожно пытаются вытянуть более сильные команды.
Люди (по крайней мере люди моей и близких западных культур) хотят хорошо работать, если результат их работы ассоциируется с их индивидуальностью и личными качествами. Когда они могут себя проявить. И не хотят хорошо работать, если плохая работа не порицается и не устраняется, а издержки от нее просто ложатся на тех, кто лучше работает.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6💯3👍1
Наконец, последняя из 8 историй про плохой менеджмент.
8️⃣ Кидалово обыкновенное
Действующие лица: снова тот же чел, техдир из прошлой истории + тимлид и сеньор разраб из его команды.
Ситуация - канун нового года, это было еще в России - поэтому длинные праздники впереди. Если что-то навернется - никого не будет на работе. Обсуждаются дежурства - быть на подхвате, если что-то сломается - быстро подключиться и разрулить.
Техдир договаривается с тимлидом, что тот с еще одним опытным разрабом, чередуясь, подежурят на январские праздники. Техдир недавно пришел, поэтому он не особо в теме, как это делалось раньше, просто спрашивает как было раньше.
Тимлид совершает неточность, не проговорив до конца условия дежурства (компенсацию), потому что предполагает, что условия будут полностью те же, что и в прошлый раз.
Проходят январские праздники, люди отдежурили, но ничего не сломалось. И когда поднимается вопрос компенсации - это были то ли отгулы, то ли небольшая премия - техдир такой: а ничего же не сломалось, за что?
Я эту историю поставил последней, потому что эта ошибка в менеджменте - самая грубая: жадность и экономия на мелочах - проигрыш по крупному. Абсолютно никакой мотивации, кроме скверного характера, за таким решением стоять не может.
В чем проигрыш? Естественно, люди это запомнили. Тимлид и самый опытный разработчик. И в любой последующей ситуации взаимодействия с этим техдиром - перешли исключительно к транзакционному взаимодействию (я даю что-то тебе только после того, как ты даешь что-то мне) и урезали очень много своей добровольной инициативы, причем незаметно для этого руководителя.
Мораль:
➖личная порядочность имеет большое значение. Ее стоит брать в расчет, когда нанимаешь руководителя. Если человек чмо - для менеджера это вылезет быстрее и повлияет намного сильнее
➖глупо жадничать в мелочах - больше потеряешь по крупному
➖обычно стоит сохранять позитивные традиции. Если было принято поощрять людей за что-то определенным образом ранее - лучше сделать так же, если нет каких-то серьезных оснований сделать по другому
Итого, у нас есть 8 историй:
Плюрализм споткнулся о размер столов
Ну это, конечно, неправда
Ты подрываешь мой авторитет
В Ставрополе за эти деньги...
Как правильно или как лучше?
Удали, пожалуйста, свое сообщение
Вам самим-то не надоело в говне сидеть?
И сегодняшняя, Кидалово обыкновенное
Что из них можно почерпнуть? Думаю, каждый найдет что-то свое. Я думаю примерно следующее:
➖Все ошибаются, на любой позиции, причем достаточно часто. Не всегда "руководству виднее" (довольно популярный стереотип). Отрицать это глупо. Другой вопрос - как часто, насколько критично, как себя в этом случае ведут и учатся ли на своих ошибках
➖Можно учиться на чужих ошибках. Если Вы - человек наблюдательный и анализирующий, то работая на соло позиции и планируя стать менеджером, можно смотреть по сторонам, находить ошибки, и думать, как было бы можно сделать лучше. А еще лучше обсуждать или анализировать вместе с кем-то
➖Часто мы действуем интуитивно, когда ошибаемся. Это значит, что поглощая информацию о разных ситуациях, оптимальных или плохих решениях, впитывая такой опыт (для этого, в моем понимании, и полезны такие истории), мы прокачиваем нашу внутреннюю "нейросетку", проживая ситуации во внутреннем симуляторе, и это позволяет в будущем поступить правильнее. Чего я вам и желаю )
Действующие лица: снова тот же чел, техдир из прошлой истории + тимлид и сеньор разраб из его команды.
Ситуация - канун нового года, это было еще в России - поэтому длинные праздники впереди. Если что-то навернется - никого не будет на работе. Обсуждаются дежурства - быть на подхвате, если что-то сломается - быстро подключиться и разрулить.
Техдир договаривается с тимлидом, что тот с еще одним опытным разрабом, чередуясь, подежурят на январские праздники. Техдир недавно пришел, поэтому он не особо в теме, как это делалось раньше, просто спрашивает как было раньше.
Тимлид совершает неточность, не проговорив до конца условия дежурства (компенсацию), потому что предполагает, что условия будут полностью те же, что и в прошлый раз.
Проходят январские праздники, люди отдежурили, но ничего не сломалось. И когда поднимается вопрос компенсации - это были то ли отгулы, то ли небольшая премия - техдир такой: а ничего же не сломалось, за что?
Я эту историю поставил последней, потому что эта ошибка в менеджменте - самая грубая: жадность и экономия на мелочах - проигрыш по крупному. Абсолютно никакой мотивации, кроме скверного характера, за таким решением стоять не может.
В чем проигрыш? Естественно, люди это запомнили. Тимлид и самый опытный разработчик. И в любой последующей ситуации взаимодействия с этим техдиром - перешли исключительно к транзакционному взаимодействию (я даю что-то тебе только после того, как ты даешь что-то мне) и урезали очень много своей добровольной инициативы, причем незаметно для этого руководителя.
Мораль:
➖личная порядочность имеет большое значение. Ее стоит брать в расчет, когда нанимаешь руководителя. Если человек чмо - для менеджера это вылезет быстрее и повлияет намного сильнее
➖глупо жадничать в мелочах - больше потеряешь по крупному
➖обычно стоит сохранять позитивные традиции. Если было принято поощрять людей за что-то определенным образом ранее - лучше сделать так же, если нет каких-то серьезных оснований сделать по другому
Итого, у нас есть 8 историй:
Плюрализм споткнулся о размер столов
Ну это, конечно, неправда
Ты подрываешь мой авторитет
В Ставрополе за эти деньги...
Как правильно или как лучше?
Удали, пожалуйста, свое сообщение
Вам самим-то не надоело в говне сидеть?
И сегодняшняя, Кидалово обыкновенное
Что из них можно почерпнуть? Думаю, каждый найдет что-то свое. Я думаю примерно следующее:
➖Все ошибаются, на любой позиции, причем достаточно часто. Не всегда "руководству виднее" (довольно популярный стереотип). Отрицать это глупо. Другой вопрос - как часто, насколько критично, как себя в этом случае ведут и учатся ли на своих ошибках
➖Можно учиться на чужих ошибках. Если Вы - человек наблюдательный и анализирующий, то работая на соло позиции и планируя стать менеджером, можно смотреть по сторонам, находить ошибки, и думать, как было бы можно сделать лучше. А еще лучше обсуждать или анализировать вместе с кем-то
➖Часто мы действуем интуитивно, когда ошибаемся. Это значит, что поглощая информацию о разных ситуациях, оптимальных или плохих решениях, впитывая такой опыт (для этого, в моем понимании, и полезны такие истории), мы прокачиваем нашу внутреннюю "нейросетку", проживая ситуации во внутреннем симуляторе, и это позволяет в будущем поступить правильнее. Чего я вам и желаю )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥6❤2
Как увеличить свою удачу?
Для менеджеров в некотором смысле важнее задумываться о карьере, так как их движение на желаемую позицию занимает несколько шагов. Недостаточно просто получать опыт и дождаться, пока ты начнешь считаться сеньором.
У кого-то это особенно актуально для первой менеджерской позиции. Кто-то задумывается - вот я разработчик, как стать тимлидом? Или: я тимлид, как вырасти до engineering manager или CTO?
Успех данного мероприятия складывается из двух частей - личных усилий и удачи.
По всевозможным исследованиям, люди склонны недооценивать удачу (внешние обстоятельства, которые привели к положительным или отрицательным результатам) и склонны приписывать успехи своим личным качествам. У вас есть возможность не быть как все )
Возникает закономерный вопрос: если удача - это внешние обстоятельства, то как на нее можно повлиять?
Представим, что Вы разработчик и хотите занять позицию тимлида. Для упрощения представим, что устроиться с улицы на эту позицию нельзя. Предположим, по личным качествам Вы - достойный кандидат. Вы работаете в какой-то команде разработки. Возьмем шанс, что среди всех команд тимлидов не хватает в 30%.
Базово, это означает, что с вероятностью 30% Вы станете тимлидом, просто продолжая работать в своей компании. В таком упрощенном варианте - с нулевой вероятностью, если Вы оказались не там, где надо, и с 100% если там, где надо.
Так вот, если Вы поработаете в 4 разных компаниях, такой шанс уже вырастает до 76%.
Это значит, что надо никогда не забывать, что если вы что-то делаете, и у Вас не получается - возможно вы просто делаете это не в том месте, и не в то время.
Во всех компаниях, начиная с первой, я предлагал различные вполне разумные улучшения. Только в третьей это кому-то действительно понадобилось, и только в четвертой это реально принесло пользу мне и компании.
Короче, удачу можно увеличить просто чаще перебирая варианты.
Конкретно касательно менеджмента - это в первую очередь смена компании и развитие нетворка. Если Вы - классный, то чем больше людей Вас будет оценивать, тем большая вероятность, что Вы кому-то приглянетесь на желаемой позиции.
Усилить этот эффект можно, если перебирать не случайно, а анализируя. Хорошие руководители чаще нужны, например, в компаниях, которые недавно переросли из одной управленческой структуры в другую (например, из стартапа в средний бизнес. Или из среднего бизнеса в корпорацию), потому что при масштабировании нужно организовывать работу по новому. И гораздо реже они нужны там, где ничего не меняется. Даже в компании, где все отвратительно организовано - у вас будет гораздо больше шансов, чем в той, где все стабильно, все позиции уже заняты и нет текучки.
В одних компаниях любой ответственный достойный кандидат почти автоматически будет приглашен на руководящую позицию. В других - сидят люди, которые бы хотели, но им не предоставляется шанса. Всем будет лучше, если подружить эти две потребности )
Для менеджеров в некотором смысле важнее задумываться о карьере, так как их движение на желаемую позицию занимает несколько шагов. Недостаточно просто получать опыт и дождаться, пока ты начнешь считаться сеньором.
У кого-то это особенно актуально для первой менеджерской позиции. Кто-то задумывается - вот я разработчик, как стать тимлидом? Или: я тимлид, как вырасти до engineering manager или CTO?
Успех данного мероприятия складывается из двух частей - личных усилий и удачи.
По всевозможным исследованиям, люди склонны недооценивать удачу (внешние обстоятельства, которые привели к положительным или отрицательным результатам) и склонны приписывать успехи своим личным качествам. У вас есть возможность не быть как все )
Возникает закономерный вопрос: если удача - это внешние обстоятельства, то как на нее можно повлиять?
Представим, что Вы разработчик и хотите занять позицию тимлида. Для упрощения представим, что устроиться с улицы на эту позицию нельзя. Предположим, по личным качествам Вы - достойный кандидат. Вы работаете в какой-то команде разработки. Возьмем шанс, что среди всех команд тимлидов не хватает в 30%.
Базово, это означает, что с вероятностью 30% Вы станете тимлидом, просто продолжая работать в своей компании. В таком упрощенном варианте - с нулевой вероятностью, если Вы оказались не там, где надо, и с 100% если там, где надо.
Так вот, если Вы поработаете в 4 разных компаниях, такой шанс уже вырастает до 76%.
Это значит, что надо никогда не забывать, что если вы что-то делаете, и у Вас не получается - возможно вы просто делаете это не в том месте, и не в то время.
Во всех компаниях, начиная с первой, я предлагал различные вполне разумные улучшения. Только в третьей это кому-то действительно понадобилось, и только в четвертой это реально принесло пользу мне и компании.
Короче, удачу можно увеличить просто чаще перебирая варианты.
Конкретно касательно менеджмента - это в первую очередь смена компании и развитие нетворка. Если Вы - классный, то чем больше людей Вас будет оценивать, тем большая вероятность, что Вы кому-то приглянетесь на желаемой позиции.
Усилить этот эффект можно, если перебирать не случайно, а анализируя. Хорошие руководители чаще нужны, например, в компаниях, которые недавно переросли из одной управленческой структуры в другую (например, из стартапа в средний бизнес. Или из среднего бизнеса в корпорацию), потому что при масштабировании нужно организовывать работу по новому. И гораздо реже они нужны там, где ничего не меняется. Даже в компании, где все отвратительно организовано - у вас будет гораздо больше шансов, чем в той, где все стабильно, все позиции уже заняты и нет текучки.
В одних компаниях любой ответственный достойный кандидат почти автоматически будет приглашен на руководящую позицию. В других - сидят люди, которые бы хотели, но им не предоставляется шанса. Всем будет лучше, если подружить эти две потребности )
👍10🔥5
Личные интересы vs. интересы компании
Мне однажды (а может такое было и пару раз) попался рабочий документ, где фигурировал тезис типа "если личные интересы противоречат интересам компании, то". Ну и, конечно, то нужно действовать в интересах компании и/или сообщить менеджеру об этом ) Что-то в этом духе.
Это показывает всю сюрреалистичность образа мыслей некоторых корпоративных служащих.
Нет никаких интересов, кроме личных интересов разных людей. Ну и уж конечно, никто не предпочитает чужие интересы своим. В силу лицемерия или отсутствия понимания, как работает этика, люди могут утверждать иное.
Но тот факт, что все действуют в своих интересах, осознаваемых или нет, не отменяет того, что люди могут что-то совершать для общего дела, помощи другим или развития чужого бизнеса. Это происходит, когда люди считают, что это в их интересах.
Исходя из этого есть несколько основных стратегий, которые используются в разных компаниях, в какой-то пропорции:
1️⃣ Обращение в фанатиков/болельщиков/сектантов - убеждать сотрудников, что в их интересах действовать в чужих интересах. Работает примерно как гос. пропаганда - надо слушаться, быть благодарным, преследовать шкурные интересы стыдно, пиетет к символике и т.д.
2️⃣ Контроль и надзор - создание системы, в которой становится слишком невыгодно и/или неприятно не делать то, что от тебя требуют. Сюда входит сдельная работа, KPI, регулярные отчеты о сделанной/планируемой работе.
3️⃣ Обмен - скрытый или открытый, "ты-мне, я-тебе".
Тут важно уточнить - речь не идет о обмене типа "ты работаешь, тебе платят". В разработке (как и во многих других вещах) этого не достаточно. Всегда есть десятки ситуаций, когда человек принимает решения наедине с самим собой, основываясь на своем отношении к делу - закрыть ли глаза на проблему, сделать как попросили или как правильно, постараться или просто тянуть лямку.
В зависимости от настроя, разница в производительности и приносимой пользе может легко составлять несколько раз. При этом объективное измерение разработки - задача не имеющая на сегодняшний день эффективного решения. Поэтому о таких вещах и думают.
Следующим постом раскрою тему чуть глубже, добавлю примеров и расскажу о своем подходе к этому.
Мне однажды (а может такое было и пару раз) попался рабочий документ, где фигурировал тезис типа "если личные интересы противоречат интересам компании, то". Ну и, конечно, то нужно действовать в интересах компании и/или сообщить менеджеру об этом ) Что-то в этом духе.
Это показывает всю сюрреалистичность образа мыслей некоторых корпоративных служащих.
Нет никаких интересов, кроме личных интересов разных людей. Ну и уж конечно, никто не предпочитает чужие интересы своим. В силу лицемерия или отсутствия понимания, как работает этика, люди могут утверждать иное.
Но тот факт, что все действуют в своих интересах, осознаваемых или нет, не отменяет того, что люди могут что-то совершать для общего дела, помощи другим или развития чужого бизнеса. Это происходит, когда люди считают, что это в их интересах.
Исходя из этого есть несколько основных стратегий, которые используются в разных компаниях, в какой-то пропорции:
Тут важно уточнить - речь не идет о обмене типа "ты работаешь, тебе платят". В разработке (как и во многих других вещах) этого не достаточно. Всегда есть десятки ситуаций, когда человек принимает решения наедине с самим собой, основываясь на своем отношении к делу - закрыть ли глаза на проблему, сделать как попросили или как правильно, постараться или просто тянуть лямку.
В зависимости от настроя, разница в производительности и приносимой пользе может легко составлять несколько раз. При этом объективное измерение разработки - задача не имеющая на сегодняшний день эффективного решения. Поэтому о таких вещах и думают.
Следующим постом раскрою тему чуть глубже, добавлю примеров и расскажу о своем подходе к этому.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥6
Предположение о чужой тупости
Я еще давно подметил одну очень любопытную штуку, которая меня вообще очень поразила, когда я ее обнаружил.
Есть два типа людей (нормальные и те, которые делят людей на два типа):
1. Одни, когда что-то идет не так, как бы предполагают в другом тупость по умолчанию
2. Другие исходят из презумпции разума, что другой человек наверно подумал, когда что-то делал, пока не доказано иного
Наверно звучит не очень понятно, поэтому объясню на метафорическом примере:
Человек видит, как другой вышел из туалета с мокрыми штанами.
Первый вариант - он скажет (неиронично): "даю фидбек: когда идешь в туалет, надо снимать штаны"
Второй вариант - он задаст вопрос: "что случилось?", предполагая множество вариантов, например, что это вода и не было полотенца и т.п.
То есть в целом, первый вариант - это по умолчанию предположение в действиях других (но не в своих) худшего возможного сценария, который предполагает, что мозг не включался при выполнении задачи, причем неиронично, без цели задеть и вообще без каких-то задних мыслей.
Я сталкивался с такой логикой очень много раз, и, если честно, у меня нет нормального объяснения, почему у некоторых таким образом работает мышление. Первые разы мне это казалось нелепым и оскорбительным, потом я понял - это просто какая-то психологическая особенность. Ни в каких источниках ранее мне не попадалось описание этого явления.
Тем не менее, в целом это достаточно деструктивное поведение и оно мешает работать/создает неприятную атмосферу.
Самый лучший, проверенный способ действовать, если вы видите что-то, похожее на неправильно/плохо сделанную работу - это не делать никаких предвзятых умозаключений, а просто задать вопрос: почему так получилось/почему так было сделано, и потом выяснить все обстоятельства.
Рабочие примеры:
1. Видишь, задача несколько дней лежит в ревью
➖(плохо) нужно обращать внимание на задачи и не забывать делать ревью
➖(нормально) я смотрю задача на ревью застряла, почему так?
2. Видишь задачу закрыли какую-то непонятно почему
➖(плохо) почему задачу не сделали и закрыли?
➖(нормально) тут есть задача закрытая непонятно почему, а что там было?
Окей, даже если вы знаете что другой принял неверное решение - все равно лучшим решением может быть расспросить его, вместо того, чтобы начинать с негативных заключений. Лишь если человек по мере обсуждения в упор продолжает не видеть проблему в своих действиях - тогда ему уже стоит прямо на нее указать.
Может показаться мелочь, но из таких нюансов коммуникаций формируется (или не формируется) здоровая комфортная атмосфера работы в команде.
P.S. после написания, решил проверить как прокомментирует наблюдение grok: https://grok.com/share/c2hhcmQtMg_7a9a6754-681d-4dfb-a3d0-b9e873a7b096
Я еще давно подметил одну очень любопытную штуку, которая меня вообще очень поразила, когда я ее обнаружил.
Есть два типа людей (нормальные и те, которые делят людей на два типа):
1. Одни, когда что-то идет не так, как бы предполагают в другом тупость по умолчанию
2. Другие исходят из презумпции разума, что другой человек наверно подумал, когда что-то делал, пока не доказано иного
Наверно звучит не очень понятно, поэтому объясню на метафорическом примере:
Человек видит, как другой вышел из туалета с мокрыми штанами.
Первый вариант - он скажет (неиронично): "даю фидбек: когда идешь в туалет, надо снимать штаны"
Второй вариант - он задаст вопрос: "что случилось?", предполагая множество вариантов, например, что это вода и не было полотенца и т.п.
То есть в целом, первый вариант - это по умолчанию предположение в действиях других (но не в своих) худшего возможного сценария, который предполагает, что мозг не включался при выполнении задачи, причем неиронично, без цели задеть и вообще без каких-то задних мыслей.
Я сталкивался с такой логикой очень много раз, и, если честно, у меня нет нормального объяснения, почему у некоторых таким образом работает мышление. Первые разы мне это казалось нелепым и оскорбительным, потом я понял - это просто какая-то психологическая особенность. Ни в каких источниках ранее мне не попадалось описание этого явления.
Тем не менее, в целом это достаточно деструктивное поведение и оно мешает работать/создает неприятную атмосферу.
Самый лучший, проверенный способ действовать, если вы видите что-то, похожее на неправильно/плохо сделанную работу - это не делать никаких предвзятых умозаключений, а просто задать вопрос: почему так получилось/почему так было сделано, и потом выяснить все обстоятельства.
Рабочие примеры:
1. Видишь, задача несколько дней лежит в ревью
➖(плохо) нужно обращать внимание на задачи и не забывать делать ревью
➖(нормально) я смотрю задача на ревью застряла, почему так?
2. Видишь задачу закрыли какую-то непонятно почему
➖(плохо) почему задачу не сделали и закрыли?
➖(нормально) тут есть задача закрытая непонятно почему, а что там было?
Окей, даже если вы знаете что другой принял неверное решение - все равно лучшим решением может быть расспросить его, вместо того, чтобы начинать с негативных заключений. Лишь если человек по мере обсуждения в упор продолжает не видеть проблему в своих действиях - тогда ему уже стоит прямо на нее указать.
Может показаться мелочь, но из таких нюансов коммуникаций формируется (или не формируется) здоровая комфортная атмосфера работы в команде.
P.S. после написания, решил проверить как прокомментирует наблюдение grok: https://grok.com/share/c2hhcmQtMg_7a9a6754-681d-4dfb-a3d0-b9e873a7b096
Grok
Презумпция глупости vs разумности | Shared Grok Conversation
а ты можешь пояснить или дать ссылку на пояснение что это такое и почему так происходит? "Я еще давн
👍14🔥5❤3
Новогоднее настроение
Атмосфера под конец года на работе часто немного другая. Декабрь в B2B SaaS - обычно более расслабленный, потому что основной объем переговоров по сделкам активно идет в октябре-ноябре, а под конец года, особенно ближе к рождеству - это скорее время B2C ажиотажа.
И это хорошо. Можно привести дела в порядок, люди могут морально перезагрузиться от смены обстановки на некоторый период. А с другой стороны - какое-то особенное настроение тоже можно использовать с пользой, совместив ее с удовольствием.
Короче, захотелось поделиться, что в этом году придумали у нас.
1️⃣ Внутри команды в последних числах декабря проводим внутреннюю конфу по применению AI в разработке. Это уже вторая такая, прошлая была летом, прошла классно, к сожалению не могу поделиться записью, так как это внутренняя между группой компаний тусовка была. Было 4 спикера - сеньор разработчик, архитектор, head of dev и vp of engineering, каждый рассказал что-то со своей перспективы. Было много интересных хайлайтов, например, что кодинг с AI больше похож на работу тимлида, чем на программирование.
2️⃣ Решили попробовать устроить внутренний хакатон, тоже с прицелом на AI тулы. Даже с кое-какими призами для большего фана ) Не знаю что из этого получится, но сидеть вместе с head of product и marketing lead и придумывать как всё должно быть организовано было местами довольно весело
3️⃣ Ну и третье, мб не такое веселое, но тоже важное - я решил забрать на себя и переделать систему performance ревью, который будет в начале следующего года. Те, в которых я участвовал, не удовлетворяли моему чувству вкуса, и даже местами просто соображениям рациональности ) поэтому захотелось переделать, а не просто оставить это дело HR'ам. Были давно в голове мысли, как это должно быть сделано по организации и содержимому, частично на основании анализа ошибок, частично на основании нетворкинга и понимания, как это сделано в некоторых других местах, что людям нравится, а что нет. Наверно, размышления о перформанс ревью стоят отдельного поста.
Знаю, что в разных компаниях есть какие-то специальные активности за рамками ежедневной работы, кто-то устраивает code freeze, кто-то - неделю креатива и инициатив от разработки, может быть и у вас есть что-то особенное? )
Атмосфера под конец года на работе часто немного другая. Декабрь в B2B SaaS - обычно более расслабленный, потому что основной объем переговоров по сделкам активно идет в октябре-ноябре, а под конец года, особенно ближе к рождеству - это скорее время B2C ажиотажа.
И это хорошо. Можно привести дела в порядок, люди могут морально перезагрузиться от смены обстановки на некоторый период. А с другой стороны - какое-то особенное настроение тоже можно использовать с пользой, совместив ее с удовольствием.
Короче, захотелось поделиться, что в этом году придумали у нас.
Знаю, что в разных компаниях есть какие-то специальные активности за рамками ежедневной работы, кто-то устраивает code freeze, кто-то - неделю креатива и инициатив от разработки, может быть и у вас есть что-то особенное? )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤1🎉1