Польза когнитивных искажений
Даниэль Канеман — человек, который поставил под вопрос нашу рациональность. Его исследования указывают, что значительную часть решений мы принимаем не рационально. Эту нерациональность Канеман систематизировал и составил список когнитивных искажений.
Покажу вам одно искажение — эффект определенности или синица в руках.
Канеман собрал группу и предложил каждому выбор:
- А: $4000 с вероятностью 80%
- Б: $3000 гарантированно
Что бы выбрали вы? В группе 80% испытуемых выбрали Б — гарантию. Думаю, вы тоже.
Но абсолютно рациональный человек выбрал бы А, потому что мат ожидание этого выбора — 3200 баксов. Если сыграть 100 раз подряд, то стратегия А заработает нам 320к долларов, а стратегия Б — 300к.
На бумаге — грех от них отказываться. Разница в 20к баксов! Неплохие денежки.
Так и что же, нужно рисковать?
Да простит меня Канеман, но я скажу — нет, не нужно. Если бы мне предложили сыграть в такую игру, я бы ушел с 3к долларов в кармане и не сильно переживал бы по поводу упущенной выгоды. Не знаю как вам, а мне очень редко предлагают подобные игры. Я бы сказал, настолько редко, что даже никогда.
В жизни есть решения, которые мы принимаем слишком редко, чтобы быть рациональными.
Мудрость в том, чтобы понять: перед вами одноразовая акция или повторяющийся выбор?
Мой пример: никогда не покупаю страховку или платную гарантию на технику. Заплатить 5-10к рублей за страховку от события, чей шанс ниже процента? Спасибо, без меня. И даже если мой новый телефон отрыгнет, не беда: за годы моя стратегия сэкономила достаточно денег, чтобы купить новый и еще остаться в плюсе.
А вершина мудрости — создать условия, при которых быть рациональным выгодно.
Например, венчурные фонды. Вложить миллиард баксов в один стартап — это лотерея и один из самых надежных способов потерять деньги. Создать портфель из десятков стартапов — путь к успеху, пара удачных стартапов окупит все провалы и принесет прибыль сверху.
Когнитивные искажения — не абсолютное зло. В разовых играх они берегут нас от опасных, хоть и выгодных на бумаге решений. В повторяющихся играх позволяют заработать больше.
Наша задача — понять, в какую игру мы играем.
И да, иногда самое разумное, что можно сделать — спокойно забрать свои $3000 и уйти.
Даниэль Канеман — человек, который поставил под вопрос нашу рациональность. Его исследования указывают, что значительную часть решений мы принимаем не рационально. Эту нерациональность Канеман систематизировал и составил список когнитивных искажений.
Покажу вам одно искажение — эффект определенности или синица в руках.
Канеман собрал группу и предложил каждому выбор:
- А: $4000 с вероятностью 80%
- Б: $3000 гарантированно
Что бы выбрали вы? В группе 80% испытуемых выбрали Б — гарантию. Думаю, вы тоже.
Но абсолютно рациональный человек выбрал бы А, потому что мат ожидание этого выбора — 3200 баксов. Если сыграть 100 раз подряд, то стратегия А заработает нам 320к долларов, а стратегия Б — 300к.
На бумаге — грех от них отказываться. Разница в 20к баксов! Неплохие денежки.
Так и что же, нужно рисковать?
Да простит меня Канеман, но я скажу — нет, не нужно. Если бы мне предложили сыграть в такую игру, я бы ушел с 3к долларов в кармане и не сильно переживал бы по поводу упущенной выгоды. Не знаю как вам, а мне очень редко предлагают подобные игры. Я бы сказал, настолько редко, что даже никогда.
В жизни есть решения, которые мы принимаем слишком редко, чтобы быть рациональными.
Мудрость в том, чтобы понять: перед вами одноразовая акция или повторяющийся выбор?
Мой пример: никогда не покупаю страховку или платную гарантию на технику. Заплатить 5-10к рублей за страховку от события, чей шанс ниже процента? Спасибо, без меня. И даже если мой новый телефон отрыгнет, не беда: за годы моя стратегия сэкономила достаточно денег, чтобы купить новый и еще остаться в плюсе.
А вершина мудрости — создать условия, при которых быть рациональным выгодно.
Например, венчурные фонды. Вложить миллиард баксов в один стартап — это лотерея и один из самых надежных способов потерять деньги. Создать портфель из десятков стартапов — путь к успеху, пара удачных стартапов окупит все провалы и принесет прибыль сверху.
Когнитивные искажения — не абсолютное зло. В разовых играх они берегут нас от опасных, хоть и выгодных на бумаге решений. В повторяющихся играх позволяют заработать больше.
Наша задача — понять, в какую игру мы играем.
И да, иногда самое разумное, что можно сделать — спокойно забрать свои $3000 и уйти.
🔥17💯9❤8👍7
Устойчивость — это не доступность
Я часто вижу подмену устойчивости системы ее доступностью. Например, мы видим аптайм 99.95% и делаем вывод: система устойчива.
Опасное заблуждение.
Как пел классик: "Тебе не страшно, потому что тебя еще не пугали". Твоя система устойчива, потому что ее еще не шатали.
Устойчивость — это свойство системы приходить в рабочее состояние после сбоев. Вспомните неваляшку: если ее толкнуть, она вернется в стоячее положение. Как бы сильно вы ее не толкали, она быстро вернется обратно. Неваляшка — устойчива.
Вспомните сбои Cloudflare 18-го Ноября. Его толкнули, он упал и лежал три часа. Cloudflare — неустойчив.
Устойчивость измеряется не в процентах аптайма. Чтобы измерить устойчивость, систему нужно толкнуть, включить таймер и смотреть, как быстро она вернется в начальное положение. Аптайм 99.95% может указывать на высокую устойчивость, а может — на отсутствие внешних раздражителей.
Если хотите измерить устойчивость — измеряйте MTTR (Mean Time To Recovery). Сколько времени от "упало" до "работает". И проверяйте это до того, как упадёт само: chaos engineering, game days, fire drills.
99.95% аптайма могут означать высокую устойчивость. А могут — что сервису просто везло.
Я часто вижу подмену устойчивости системы ее доступностью. Например, мы видим аптайм 99.95% и делаем вывод: система устойчива.
Опасное заблуждение.
Как пел классик: "Тебе не страшно, потому что тебя еще не пугали". Твоя система устойчива, потому что ее еще не шатали.
Устойчивость — это свойство системы приходить в рабочее состояние после сбоев. Вспомните неваляшку: если ее толкнуть, она вернется в стоячее положение. Как бы сильно вы ее не толкали, она быстро вернется обратно. Неваляшка — устойчива.
Вспомните сбои Cloudflare 18-го Ноября. Его толкнули, он упал и лежал три часа. Cloudflare — неустойчив.
Устойчивость измеряется не в процентах аптайма. Чтобы измерить устойчивость, систему нужно толкнуть, включить таймер и смотреть, как быстро она вернется в начальное положение. Аптайм 99.95% может указывать на высокую устойчивость, а может — на отсутствие внешних раздражителей.
Если хотите измерить устойчивость — измеряйте MTTR (Mean Time To Recovery). Сколько времени от "упало" до "работает". И проверяйте это до того, как упадёт само: chaos engineering, game days, fire drills.
99.95% аптайма могут означать высокую устойчивость. А могут — что сервису просто везло.
🔥11🫡7❤6👍1👌1😎1
Увидел в твиттере исповедь сотрудника Amazon. Перевод:
Предположим, что всё это правда. Я там свечку не держал, но кейс слишком показательный, чтобы пройти мимо.
😈 Злодей ли этот человек?
Инженер разобрался, как устроена система, и использовал её в своих интересах. По пути он нанёс компании очевидный вред: новый сервис работает хуже, стоит дороже и ещё течёт по памяти.
Система поставила его перед выбором:
делать хорошо компании и плохо себе
или
делать хорошо себе и плохо компании.
Личный интерес и интересы компании стали антагонистами.
Человек — не злодей. Злодей здесь — дизайн системы мотивации.
🤔 Почему так произошло?
Классический закон Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой.
Ты получаешь то, что ты измеряешь.
Переписал отлично работающий Java-сервис на Go с микросервисной архитектурой. Сервис 5 лет работал без проблем. Но мне нужны были "Scope" и "Complexity" для перехода с L5 на L6. Написал дизайн-док на 20 страниц. Потратил 4 квартала и время трёх инженеров. Новая система медленнее и стоит 2x в вычислительных мощностях. Зато launch email выглядел достаточно "стратегически", чтобы получить промо. На прошлой неделе перешёл в другую команду. Memory leak обычно срабатывает около 2 ночи. Удачи новичку, который это унаследует.
Предположим, что всё это правда. Я там свечку не держал, но кейс слишком показательный, чтобы пройти мимо.
😈 Злодей ли этот человек?
Инженер разобрался, как устроена система, и использовал её в своих интересах. По пути он нанёс компании очевидный вред: новый сервис работает хуже, стоит дороже и ещё течёт по памяти.
Система поставила его перед выбором:
делать хорошо компании и плохо себе
или
делать хорошо себе и плохо компании.
Личный интерес и интересы компании стали антагонистами.
Человек — не злодей. Злодей здесь — дизайн системы мотивации.
🤔 Почему так произошло?
Классический закон Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой.
Ты получаешь то, что ты измеряешь.
👍23🔥3🤔3❤2✍1
Если человек избегает риска, то он серьезно рискует.
Риск несет в себе вероятность победы или проигрыша. Если мы видим в риске только вероятность проигрыша, мы становимся слепы к вероятности выигрыша.
Постоянный отказ от риска — это постоянный отказ от возможности победить, вырасти, заработать. И чем больше человек избегает риска, тем больше он рискует упустить возможность, которая изменит его жизнь или карьеру.
Люди не рискуют менять работу, потому что страшно, синдром самозванца, переживают по поводу "не приживусь и меня уволят, а обратно не возьмут". В итоге — упущенные возможности.
Люди не рискуют выступать на конференциях, потому что волнуются, стесняются или переживают, что аудитория засмеет. При этом упускают апсайд в виде репутации и нетворка, супер важных для карьеры в ИТ.
Люди не рискуют браться за сложные проекты, потому что боятся провала и последствий. Но только адски сложные и до дрожи в коленях пугающие монстро-проекты лучше всего развивают наши харды, софты и уверенность в себе.
Рано или поздно страх уйдет, а достижения, опыт и репутация — останутся.
Риск несет в себе вероятность победы или проигрыша. Если мы видим в риске только вероятность проигрыша, мы становимся слепы к вероятности выигрыша.
Постоянный отказ от риска — это постоянный отказ от возможности победить, вырасти, заработать. И чем больше человек избегает риска, тем больше он рискует упустить возможность, которая изменит его жизнь или карьеру.
Люди не рискуют менять работу, потому что страшно, синдром самозванца, переживают по поводу "не приживусь и меня уволят, а обратно не возьмут". В итоге — упущенные возможности.
Люди не рискуют выступать на конференциях, потому что волнуются, стесняются или переживают, что аудитория засмеет. При этом упускают апсайд в виде репутации и нетворка, супер важных для карьеры в ИТ.
Люди не рискуют браться за сложные проекты, потому что боятся провала и последствий. Но только адски сложные и до дрожи в коленях пугающие монстро-проекты лучше всего развивают наши харды, софты и уверенность в себе.
Рано или поздно страх уйдет, а достижения, опыт и репутация — останутся.
👍13❤10💯4
Менеджер Витя никак не может ускорить поставку новых фич
Разберемся. Прыгнем вместе с Витей в машину и проедем 10 километров до его офиса. Попробуем ехать с разной скоростью и посмотрим, как меняется наше время в пути.
15 км/ч → 40 минут
30 км/ч → 20 минут (×2 скорость, экономит 20 мин)
60 км/ч → 10 минут (×2 скорость, экономит 10 мин)
120 км/ч → 5 минут (×2 скорость, экономит жалкие 5 мин)
Удвоение скорости приносит все меньше и меньше пользы. Виктор давит газ в пол, но чем быстрее едет, тем меньше сокращается время в пути. Не советуем Вите разгоняться до 120 км/ч и выше, потому что выигрыш по времени мизерный, а дяденьки из ГИБДД могут превратить Витю в пешехода на пару лет, если поймают.
Кстати, мы приехали. Пошли разбираться.
Итак, Витя ускоряет раскатку новых фич: уже внедрил CI/CD, Blue/Green деплои, канарейки и автоматический роллбэк в случае чего. Он уже разогнал выкатку до тех самых 120 км/ч, и каждый км/ч сверху приносит совсем мало пользы. Но Витю не остановить, Витя продолжает вжимать педаль в пол!
И это очень плохо для Вити.
Потому что Витя совсем не замечает этап тестирования, который еле-еле выжимает 15 км/ч. У тестировщиков нет нормальных стейджей, нет данных для тестирования, нет даже единого фреймворка. Стоит лишь поднажать на педаль хотя бы до 30 км/ч и получить двукратный рост скорости!
Но нет. Тестирование грустно едет на гужевой повозке и смотрит, как мимо них несется гоночный болид с надписью "DevOps airlines".
Витя может поставить на болид новый спойлер, покрасить в красный и добавить подсветку по кругу. Это не поможет ускорить весь процесс. Надо бы починить телегу тестирования, а лучше — построить такой же красивый QA болид.
Ну или хотя бы купить вторую лошадь.
Разберемся. Прыгнем вместе с Витей в машину и проедем 10 километров до его офиса. Попробуем ехать с разной скоростью и посмотрим, как меняется наше время в пути.
15 км/ч → 40 минут
30 км/ч → 20 минут (×2 скорость, экономит 20 мин)
60 км/ч → 10 минут (×2 скорость, экономит 10 мин)
120 км/ч → 5 минут (×2 скорость, экономит жалкие 5 мин)
Удвоение скорости приносит все меньше и меньше пользы. Виктор давит газ в пол, но чем быстрее едет, тем меньше сокращается время в пути. Не советуем Вите разгоняться до 120 км/ч и выше, потому что выигрыш по времени мизерный, а дяденьки из ГИБДД могут превратить Витю в пешехода на пару лет, если поймают.
Кстати, мы приехали. Пошли разбираться.
Итак, Витя ускоряет раскатку новых фич: уже внедрил CI/CD, Blue/Green деплои, канарейки и автоматический роллбэк в случае чего. Он уже разогнал выкатку до тех самых 120 км/ч, и каждый км/ч сверху приносит совсем мало пользы. Но Витю не остановить, Витя продолжает вжимать педаль в пол!
И это очень плохо для Вити.
Потому что Витя совсем не замечает этап тестирования, который еле-еле выжимает 15 км/ч. У тестировщиков нет нормальных стейджей, нет данных для тестирования, нет даже единого фреймворка. Стоит лишь поднажать на педаль хотя бы до 30 км/ч и получить двукратный рост скорости!
Но нет. Тестирование грустно едет на гужевой повозке и смотрит, как мимо них несется гоночный болид с надписью "DevOps airlines".
Витя может поставить на болид новый спойлер, покрасить в красный и добавить подсветку по кругу. Это не поможет ускорить весь процесс. Надо бы починить телегу тестирования, а лучше — построить такой же красивый QA болид.
Ну или хотя бы купить вторую лошадь.
👍14💯14🔥5🥴5🏆1
Я годами слышал фразу "Нельзя улучшить то, что нельзя измерить".
Спорить с ней — почти ересь.
Тогда вынужден признаться: я еретик! И попробую обратить вас на свою сторону.
Разберемся на примере команды разработки: тимлид, продакт и несколько разработчиков. Мы хотим улучшить их работу по всем фронтам, чтобы ускорить поставку ценности.
Современная школа менеджмента без раздумий говорит нам: измеряйте и улучшайте! Data-driven менеджер предложит измерить DORA-метрики или lead time. Отличные метрики, на самом деле. Их можно внедрить парой человек за пару месяцев и нарисовать дашборды.
В итоге, весь фокус менеджеров будет направлен на эти дашборды.
И это плохо.
Data-driven подход как телескоп, в него очень удобно наблюдать и растить метрики: есть красивые дашборды, есть динамика роста. Но кое-что в телескоп не видно.
Люди ощущают безопасность? Если при мысли об ошибке у команды потеют руки, они будут выбирать самый безопасный вариант. Продакт думает о том, как сохранить работу, а не как завоевать рынок.
Помогают ли люди друг другу? Ведь бывают ситуации "не мой цирк — не мои обезьяны". Инженер видит горящий ультра-важный тикет коллеги, но не поможет, потому что у него есть метрика скорости собственных задач.
Команда видит смысл своей работы? Может быть, они одной рукой быстро пилят фичи, а другой так же быстро обновляют резюме.
В data-driven телескоп эти вопросы никогда не попадут, потому что ответ нельзя оцифровать. А значит, нет смысла думать над ответами. Data-driven помогает нам лучше разглядеть метрики в одном месте, но лишает нас зрения, когда дело касается качественных вопросов.
Поэтому иногда стоит отойти от телескопа и просто поговорить с людьми.
Спорить с ней — почти ересь.
Тогда вынужден признаться: я еретик! И попробую обратить вас на свою сторону.
Разберемся на примере команды разработки: тимлид, продакт и несколько разработчиков. Мы хотим улучшить их работу по всем фронтам, чтобы ускорить поставку ценности.
Современная школа менеджмента без раздумий говорит нам: измеряйте и улучшайте! Data-driven менеджер предложит измерить DORA-метрики или lead time. Отличные метрики, на самом деле. Их можно внедрить парой человек за пару месяцев и нарисовать дашборды.
В итоге, весь фокус менеджеров будет направлен на эти дашборды.
И это плохо.
Data-driven подход как телескоп, в него очень удобно наблюдать и растить метрики: есть красивые дашборды, есть динамика роста. Но кое-что в телескоп не видно.
Люди ощущают безопасность? Если при мысли об ошибке у команды потеют руки, они будут выбирать самый безопасный вариант. Продакт думает о том, как сохранить работу, а не как завоевать рынок.
Помогают ли люди друг другу? Ведь бывают ситуации "не мой цирк — не мои обезьяны". Инженер видит горящий ультра-важный тикет коллеги, но не поможет, потому что у него есть метрика скорости собственных задач.
Команда видит смысл своей работы? Может быть, они одной рукой быстро пилят фичи, а другой так же быстро обновляют резюме.
В data-driven телескоп эти вопросы никогда не попадут, потому что ответ нельзя оцифровать. А значит, нет смысла думать над ответами. Data-driven помогает нам лучше разглядеть метрики в одном месте, но лишает нас зрения, когда дело касается качественных вопросов.
Поэтому иногда стоит отойти от телескопа и просто поговорить с людьми.
👍19❤18🔥5
Саморазрушение — способ стать лучше
Я в детстве посмотрел "Бойцовский Клуб". Ну там, где мужики сначала били друг другу рожи на еженедельной основе, а потом готовили революцию. Очень понравилось. В 14 лет на тебя вываливают громкий манифест, который насмехается над современным обществом потребления.
Сразу понимаешь, что ты — точно не такой. Они — такие, а ты нет. И никогда таким не будешь.
Ты будешь крутым бунтарем в красной кожаной куртке. В идеале, с внешностью Бреда Питта, но тут как повезет.
Потом случилось взросление и к красной кожаной куртке и идеям фильма я подостыл, но вот одна цитата никак не давала мне покоя.
Круто звучит. Круто, но глупо — зачем разрушать себя? Вокруг нас с вами полно примеров таких саморазрушителей: алкоголики, игроманы, да много кто.
И ни одного крутого парня в красной кожаной куртке.
А потом я понял, что имел в виду Паланик.
Саморазрушение — необходимый элемент саморазвития. Это прекурсор, без которого не сварить зелье. Нельзя налить чай в чашку, которая полна до краев. Нельзя построить новое здание, если на месте постройки прижались друг к другу ветхие хижины.
Чтобы ходить в зал по утрам, мне пришлось разрушить в себе привычку ложиться спать в три ночи. Чтобы заниматься боксом, пришлось разрушить в себе страх получить по лицу. Забота о здоровье заставила разрушить привычку съедать большую пиццу в одно лицо.
Саморазрушение пороков создает пустое место, на котором человек возведет лучшую версию себя.
Наверное, я стал тем, кого Тайлер Дерден бы не одобрил. Превратил его панк-философию в лайфхак для продуктивности. И красную кожаную куртку так и не купил.
Ну и ладно.
Я в детстве посмотрел "Бойцовский Клуб". Ну там, где мужики сначала били друг другу рожи на еженедельной основе, а потом готовили революцию. Очень понравилось. В 14 лет на тебя вываливают громкий манифест, который насмехается над современным обществом потребления.
Сразу понимаешь, что ты — точно не такой. Они — такие, а ты нет. И никогда таким не будешь.
Ты будешь крутым бунтарем в красной кожаной куртке. В идеале, с внешностью Бреда Питта, но тут как повезет.
Потом случилось взросление и к красной кожаной куртке и идеям фильма я подостыл, но вот одна цитата никак не давала мне покоя.
Самосовершенствование — удел слабых, саморазрушение — единственное, ради чего стоит жить.
Круто звучит. Круто, но глупо — зачем разрушать себя? Вокруг нас с вами полно примеров таких саморазрушителей: алкоголики, игроманы, да много кто.
И ни одного крутого парня в красной кожаной куртке.
А потом я понял, что имел в виду Паланик.
Саморазрушение — необходимый элемент саморазвития. Это прекурсор, без которого не сварить зелье. Нельзя налить чай в чашку, которая полна до краев. Нельзя построить новое здание, если на месте постройки прижались друг к другу ветхие хижины.
Чтобы ходить в зал по утрам, мне пришлось разрушить в себе привычку ложиться спать в три ночи. Чтобы заниматься боксом, пришлось разрушить в себе страх получить по лицу. Забота о здоровье заставила разрушить привычку съедать большую пиццу в одно лицо.
Саморазрушение пороков создает пустое место, на котором человек возведет лучшую версию себя.
Наверное, я стал тем, кого Тайлер Дерден бы не одобрил. Превратил его панк-философию в лайфхак для продуктивности. И красную кожаную куртку так и не купил.
Ну и ладно.
🔥30👍7❤6❤🔥1😁1🌭1😈1
Прогулка по зоопарку руководителей
Вам понравились типы руководителей, которыми вы не хотели бы стать — так продолжим же!
🧟 Data-зомби
Спрашивает "А какую метрику мы этим улучшим?", даже если речь идет о походе в бар после работы. Оцифровал вообще все процессы и даже добавил метрику для метрик — потому что даже метрики должны быть покрыты метриками!
Data-зомби эффективен, но отрицает саму идею эмпирического подхода и может впасть в ступор, когда данных нет. Поэтому предпочитает игнорировать все, что нельзя оцифровать.
🛑 Шлагбаум
Требует, чтобы все решения проходили через него. Лично. Нельзя написать в соседний отдел напрямую — только через шлагбаум. Ревьюит каждый MR, даже если последний раз писал код еще до Коронавируса. Поставить встречу с его сотрудником можно только через шлагбаум, иначе конфликт.
Искренне верит, что без него тут все развалится. В итоге, команда из 10 человек работает с пропускной способностью одного шлагбаума. Который еще и на обед иногда уходит.
🤴 Иван Васильевич
Поменял профессию, но не поменял подходов. Бывший QA — будет до ночи сидеть в тест-кейсах, пока команда без 1-1 и карьерных треков. Бывший разработчик — залезет в код, а найм подождет. Команда живет сама по себе, руководит по остаточному принципу.
Формально менеджер, фактически — самый дорогой индивидуальный контрибьютор.
Адовое варево получается, если скрестить с Борисом-хрен-попадешь из прошлого поста. Сам пишет код, но если ломается, то виновата команда.
😽 Кот Леопольд
Очень хочет, чтобы ребята жили дружно, но вместо решения конфликтов решил их не замечать. Например, если в команду каждый день влетает продакт с "горящей" задачей, будет просить войти в положение. Если сеньор на ревью так запугал джунов, что те боятся коммитить — "ну это его стиль, он по делу же".
Верит, что если конфликт не замечать, он как-нибудь сам исчезнет. В итоге, сидит на пороховой бочке медленно тлеющих конфликтов. Все вроде неплохо, но рано или поздно бочка все-таки взорвется.
🦜 Попугай
Выучил нужные фразы, повторяет раз за разом с нулевым эффектом. На каждом дейли спрашивает "что блокирует работу?", получает ответ, кивает. На следующем дейли — тот же вопрос, тот же ответ, опять кивает головой. Со временем, команда устает отвечать и попугай решает, что блокер снят.
Спойлер — нет.
Интересная смесь получается, если попугая скрестить с data-зомби. Перестает задавать вопросы, но задумчиво и подолгу смотрит на дашборды.
_
Узнали кого-то? :)
Вам понравились типы руководителей, которыми вы не хотели бы стать — так продолжим же!
🧟 Data-зомби
Спрашивает "А какую метрику мы этим улучшим?", даже если речь идет о походе в бар после работы. Оцифровал вообще все процессы и даже добавил метрику для метрик — потому что даже метрики должны быть покрыты метриками!
Data-зомби эффективен, но отрицает саму идею эмпирического подхода и может впасть в ступор, когда данных нет. Поэтому предпочитает игнорировать все, что нельзя оцифровать.
🛑 Шлагбаум
Требует, чтобы все решения проходили через него. Лично. Нельзя написать в соседний отдел напрямую — только через шлагбаум. Ревьюит каждый MR, даже если последний раз писал код еще до Коронавируса. Поставить встречу с его сотрудником можно только через шлагбаум, иначе конфликт.
Искренне верит, что без него тут все развалится. В итоге, команда из 10 человек работает с пропускной способностью одного шлагбаума. Который еще и на обед иногда уходит.
🤴 Иван Васильевич
Поменял профессию, но не поменял подходов. Бывший QA — будет до ночи сидеть в тест-кейсах, пока команда без 1-1 и карьерных треков. Бывший разработчик — залезет в код, а найм подождет. Команда живет сама по себе, руководит по остаточному принципу.
Формально менеджер, фактически — самый дорогой индивидуальный контрибьютор.
Адовое варево получается, если скрестить с Борисом-хрен-попадешь из прошлого поста. Сам пишет код, но если ломается, то виновата команда.
😽 Кот Леопольд
Очень хочет, чтобы ребята жили дружно, но вместо решения конфликтов решил их не замечать. Например, если в команду каждый день влетает продакт с "горящей" задачей, будет просить войти в положение. Если сеньор на ревью так запугал джунов, что те боятся коммитить — "ну это его стиль, он по делу же".
Верит, что если конфликт не замечать, он как-нибудь сам исчезнет. В итоге, сидит на пороховой бочке медленно тлеющих конфликтов. Все вроде неплохо, но рано или поздно бочка все-таки взорвется.
🦜 Попугай
Выучил нужные фразы, повторяет раз за разом с нулевым эффектом. На каждом дейли спрашивает "что блокирует работу?", получает ответ, кивает. На следующем дейли — тот же вопрос, тот же ответ, опять кивает головой. Со временем, команда устает отвечать и попугай решает, что блокер снят.
Спойлер — нет.
Интересная смесь получается, если попугая скрестить с data-зомби. Перестает задавать вопросы, но задумчиво и подолгу смотрит на дашборды.
_
Узнали кого-то? :)
Telegram
Инженер и Менеджер
Семь типов руководителей, которыми вы не хотите стать
Наткнулся на статью про девять типов плохих менеджеров и подумал, что и сам смог бы составить подобное. Контент как раз для пятницы, легкий и веселый :) Представляю вам список руководителей, которым вы…
Наткнулся на статью про девять типов плохих менеджеров и подумал, что и сам смог бы составить подобное. Контент как раз для пятницы, легкий и веселый :) Представляю вам список руководителей, которым вы…
😁9🔥4❤2👍1💯1