# Что делать с творческими, но токсичными звёздочками в разработке?
Меня, как руководителя разработки, давно беспокоит вопрос: что делать с сотрудниками, которым непрерывно хочется внедрять в проект что-то новое? Скорее даже не хочется, а вот прям НАДО!
Предположим, есть у меня сотрудник Петя — очень крутой специалист, на голову выше остальных коллег. Ему скучно делать простые, однотипные решения, постоянно хочется пробовать что-то новое. И сложно его в этом упрекнуть: всем нужно развиваться, узнавать что-то современное и интересное.
Но проблема в том, что это происходит в ущерб проекту. Не всегда на проекте есть пространство для именно тех внедрений, которые Пете интересны, и именно для тех технологий, которые Петя хочет применить на практике. Но Петю остановить сложно, поскольку совсем недавно Петя был на конференции, и там рассказали про новую архитектуру, которая показалась Пете очень удачной, и Петя тут же захотел переписать проект под неё.
В чем же ущерб? А в том, что эта архитектура (фича, фреймворк) проекту особенно-то и не требуется. На рефакторинг проекта уйдёт время, порог вхождения в проект повысится, плюс могут обнаружиться неочевидные "подводные камни", которые помешают всё сделать гармонично и оставят за собой набор костылей. И даже если сам Петя будет доволен внедрением, далеко не факт, что менее скиловые коллеги смогут его работу по-настоящему оценить и воспользоваться её плодами.
В то же время отказать Пете сложно. Петя – человек творческий, и если сказать ему просто: "ничего не делать в данном случае дешевле, чем делать что-то сомнительное", то Петя может не понять и обидеться. После этого он может демотивироваться, начать саботировать свою работу или даже работу всей команды. Что делать с Петей?
Как опознать токсичную звёздочку при найме?
Нанимать только тех сотрудников, которые готовы разделять культуру Disagree and commit.
На собеседованиях явно проговаривать поведенческие кейсы типа: "Расскажите о случае, когда вы не согласились с решением команды или руководителя, но всё равно пришлось это выполнять. Что вы чувствовали и как поступили?"
Или наоборот: "Что вы почувствовали и как поступили, когда ваше мнение проигнорировали, но позже оказалось, что вы были правы?"
Если такой сотрудник уже есть в команде
Ситуация вполне может быть поправимой, если сотрудник способен менять своё мнение. Однако нужна фактура – конкретные примеры, с которыми можно провести аналогию. Иногда можно дать Пете совершить и исправить ошибку, если чужой опыт для него не работает. Петя может быть не согласен с руководителем лично, но спорить с конкретными результатами или с собственным опытом из прошлого – сложно.
Очень часто желание "творить" возникает от того, что не чувствуешь реальной ответственности за результат, и как только на кон поставлена собственная "жопа", пропадает желание "экспериментировать" и появляется желание делать что-то реальное. Если ситуация повторяется раз за разом, то можно выделить Пете обособленную зону ответственности. Дать ему автономный проект, на котором у него в случае неудачи не будет возможности сказать, что "проблема не во мне, а я всё сделал правильно".
Если совсем ничего не помогает — ну что же, нужно вовремя признать, что "мэтч" не случился и нужно двигаться дальше. Рабочий коллектив – тоже своего рода ячейка общества, и ситуация, при которой люди просто "не сработались", "не подошли друг другу", вполне нормальна.
Мне, к моему счастью, не так часто приходилось сталкиваться с "творческими программистами с тонкой душой" (и сейчас в моей команде таких нет), но это один из типажей, с которыми мне лично сложно работать.
Редко прошу фидбек, но в этот раз прям интересно – насколько вам это откликается, сталкивались ли вы с подобным и что можете добавить?