Вы уволили лучшего разработчика. Надеюсь, вы довольны?

Продолжение спорной истории об увольнении лучшего разработчика компании: инженер Тони Робинсон разобрал объективные ошибки менеджмента, которые в итоге и привели к ситуации, описанной в оригинальной статье.

Давайте присядем, нам нужно поговорить. Если вы не читали эту историю, то прочитайте её и впитайте.

Закончили? Отлично. Давайте проанализируем её, потому что здесь скрыто намного больше. Если вы прочитали историю, вы понимаете, что автор описывает проблемного сотрудника, которого он прозвал “Рик”. Рик — это местный гений с массой специфических знаний об их продукте и ключевой участник команды разработки этого продукта.

На поверхностном уровне это история о человеке, который считает себя божественным подарком, думает, что все остальные должны поклоняться земле, по которой он ходит, и что они должны быть благодарны за его присутствие, но они выгнали его, потому что его репутация вызвала проблемы, которые не могли быть решены его талантом.

Сложности с “рок-звездами” происходят почти в любой сфере работы. Может быть, в вашей сфере их называют по-другому, но рок-звезды считают, что они лучше всех и что они не должны ладить с другими членами команды. Иногда они делают качественную работу, и за это их обожают остальные, но в реальности ими сложно управлять и их сложно вписать в динамику вашей команды. Прямо как настоящих рок-звезд.

Лично я считаю, что если такие люди приходят к вам на собеседование, несмотря на то, какой у них талант, они не стоят вашего времени из-за разлада, который они вносят в команду. Это указано и в самой истории — то, как Рик игнорировал встречи и принижал своих коллег. После того, как Рик ушел, продуктивность возросла, и они объединились, чтобы спасти проект. Автор делает так, чтобы вы возненавидели Рика и сказали: “Да! К черту этого парня! Похоже, что менеджеры наконец набрались смелости и отправили эту рок-звезду погулять! Я хочу работать с этими людьми!”

Посмотрите на мою историю! Я буду использовать персонажей поп-культуры и мемы, чтобы быть ближе к аудитории!

Если вы были достаточно внимательны, в статье возникало несколько тревожных звоночков:

Если у кого-то возникал вопрос или кому-то требовалась помощь, этот человек всегда шел к Рику. У него была гигантская белая доска, установленная только для этой цели. Она была всегда заполнена следами предыдущих дискуссий, которые не стирались до конца.

При возникновении любой достаточно сложной проблемы, Рик брался за неё.

Итак, в самом начале вы уже можете сказать, что компания развивает культуру зависимости от Рика. Рик — наша суперзвезда, которая решит все проблемы, и жизнь хороша.

Где документация? Где встречи по обсуждению этих проблем и путей их решения?

О, об этой части нам не рассказали, вероятно потому, что менеджмент не смотрел в будущее. Если у нас есть суперзвезда, которая может решить все проблемы, зачем нам переживать о документации или о непрерывности операций, если он умрет/будет сбит автобусом/будет поглощен червоточиной/получит лучшее рабочее место?

Если вы читаете между строк, оказывается, что менеджмент закрывал глаза на перекладывание проблем на Рика и не беспокоился о том, что Рик и команда не уделяли времени на то, чтобы задокументировать проблему и её решение.

В этой точке Рик больше похож на Тириона Ланнистера. Он умен и может решать разные проблемы.

Вскоре Рик перестал посещать встречи. У него не было для этого времени, потому что у него было слишком много работы.

Рик закрыл свою дверь. Его доска оставалась неразобранной. У него больше не было времени учить других людей, потому что ему самому нужно было решить слишком многое.

Где были менеджеры? Где метрики? Серьезно, за время своей работы в IT и информационной безопасности я запомнил одно — менеджерам нужны показатели.

Всем было все равно, что Рик пропускал встречи? Никто не измерял количество открытых и закрытых проблем? Никто не документировал проблемы и их решение? Никто не замечал, что Рик запер себя, так как у него было все больше и больше работы?

Они не замечали или, как многие менеджеры, они изо всех сил не обращали внимания

Все работало, прогресс был, а звезда экономила им деньги, предотвращая отправку кода на аутсорс.

На доске нашего проекта зеленые флажки сменились на желтые. Желтые — на красные. Красные огни начали мигать. Задачи постепенно оказались отложенными. Все ждали Рика.

Рик писал код быстрее, чем когда-либо. Он работал семь дней в неделю, двенадцать часов в день.

Рик брал на себя больше работы, чем он мог сделать, и вдобавок он работал по 12 часов семь дней в неделю. Никто ничего не сказал, когда заметил, что Рик находился в офисе или работал удаленно дополнительные часы, дни и недели? Менеджеры не вмешались, чтобы потребовать, чтобы Рик сделал шаг назад и задокументировал свою работу? Никто не проверил его список задач и не решил, что задания нужно распределить? Сверх того, менеджмент позволил этому продолжаться два года?

Где были менеджеры? Где были тимлиды?

Мы пригласили Рика обсудить его роль в проекте.

Как на это отреагировал Рик? Только так, как он мог отреагировать: он взорвался.

Он больше не хотел принимать участия в этом фарсе. Если мы не можем оценить его гениальность, виноваты мы, а не он. Рик предсказал, что через несколько месяцев мы приползем к нему, умоляя спасти нас.

Представьте, что месяц за месяцем, или даже несколько лет, вас считают краеугольным камнем и доверенным сотрудником компании. Может быть, даже ответственным за главный продукт. Вы уже долгое время работаете по графику 12×7. Никто этого не ценит, а ваш объем работы только растет, пока этот монстр ужасных хаков и недокументированного кода не начинает угрожать вам, как монстр Франкенштейна.

Все в порядке. Вы все контролируете. Вы можете вернуться и исправить все позже. Вы можете убрать эти пластыри импровизации и заменить их нормальным кодом, которым вы будете гордиться. Сейчас у вас в коде есть части, которые кажутся загадкой даже вам. Мы вернемся, перепишем этот код и задокументируем его. Все, что мне нужно сделать, это довести продукт до RTM/GA, и тогда я смогу вернуться и все улучшить. Я им нужен. Моя работа важна. Мне нужно все сделать. Я не могу провалить. У нас кончается финансирование. Я не могу потерять работу.

Что если я потерплю неудачу? Как я восстановлюсь? Смогу ли я восстановиться?

И вот вас приглашают на встречу с менеджерами и говорят, что вашу работу начнут с нуля. Как вы можете отреагировать? И не говорите, что вы примете это со смирением.

Повторите?

Не могу говорить за вас, но я бы взорвался с яростью тысячи солнц. Я мог бы сказать то, о чем бы пожалел. Я мог бы сделать не совсем верные сравнения. Работа без отдыха может сделать ужасное с физическим и психическим здоровьем человека, и вместо того, чтобы по-взрослому обсудить проблемы и сказать Рику, что он не должен брать на себя так много, вы просто увольняете его, потому что это проще.

Сколько дней и недель он работал по двенадцать часов? Сколько семейных встреч, дней рождения и праздников он пропустил? У него есть семья? У него есть друзья вне работы? Любимый человек? Дети?

Культура стартапов не задает такие вопросы, потому что эта культура (как, во многом, и культура IT) не заботится о вашем благополучии. Только о вашей работе и об ограничении своих обязательств, если им придется вас уволить.

Меня уже увольняли в неидеальных ситуациях, когда я считал, что это несправедливо. И хотя свобода от среды, которой не нравится ваш подход к работе, это прекрасное чувство; сложное расставание с предыдущим начальством может осложнить поиск работы.

Это чувство свободы начинает исчезать, когда ваши сбережения быстро истощаются (учитывая, что компания автора находится в Калифорнии, где нелепо дорого жить), и превращается в ужас, когда эти вопросы начинают преследовать вас:

— Найдете ли вы работу вовремя? Выдержите ли вы это? Почему они уволили вас, когда вы отдали им все? Почему никто не боролся, чтобы оставить вас в компании?

Они говорят, что Рик превратился из доктора Джекила в мистера Хайда. Очевидно, его коллеги это замечали. Может быть, они даже рассказали о его нежелании работать с другими менеджерам. Они могли бы уладить это раньше. Они могли бы сказать Рику сделать шаг назад и разделить свою ношу с коллегами.

В статье не указано, что было сделано или не сделано со стороны компании по поводу всех этих проблем, но судя по тону, кажется, что они просто продолжали перекладывать проблемы на Рика, из-за чего давление все росло и не позволяло ему перераспределить рабочую нагрузку и взять время, чтобы восстановить силы.

Вместо этого они вертели Риком, как хотели, эксплуатировали его талант и навыки, и, как только он перегорел, выгнали его ради продуктивности компании. Как смело и героично!

В оригинальной статье говорится, что увольнение Рика стало их лучшим решением, но в итоге они потеряли человека с огромным объемом знаний; человека, который работал с клиентами над созданием прототипов — а в итоге кончилось это тем, что под жалобы на плохой код Рика они выпустили посредственный продукт с еще большим количеством костылей. Они совершенно забыли о том, какое бремя нес этот человек, чтобы сохранять все в рабочем состоянии.

Вместо того, чтобы создать историю о том, как они остановили падение человека при помощи вмешательства, выдающейся командной работы и грамотного руководства (что действительно нужно людям из IT), они решили рассказать о токсичной среде и проблемах, причиной которых, как казалось, был Рик. Вместо того, чтобы затронуть корень проблемы, они решили применить быстрое и простое решение. Что и следовало ожидать.