Вообще же, атмосфера в коллективе поддерживается руководителем. И если человек увольняется с мотивировкой «было токсично», то это факап руководителя. Либо он нанял не того, либо атмосфера херовая

Что значит «сложно»?

Я не о том. Я о том, что ты имеешь в виду под «сложно» или «невозможно»

Ты же говоришь о проблеме, ты ее подробности знаешь.

А в чем они проявлялись? И что ты делал, чтобы эти проблемы решить?

Ты задаёшь вопрос «стоит ли его уволить»

Или я неправильно понял вопрос твой?

Ну вот же

Понял.

Я бы посмотрел на компанию и команду и проект и оценил риски. Если все четко регламентировано, то важность коммуникации невысока, и такого человека, вероятно, можно-таки куда-то поставить

Если же это какой скрам, скажем, то безусловно не нанял бы

Уже понял тебя, спасибо :)

Теперь по статье.

— Звучит круто, но не очень понятно — зачем оно? Зачем дополнительно заниматься мотивацией, неужели одной зарплаты не хватает?

— Если я правильно понял, ваш подкаст слушают руководители разработки. Так вот, куча народу сталкивалась с ситуацией, когда разраб на критику кода отвечает что-то в духе: ”Что было в ТЗ, то я вам и накодил”. И это пример немотивированного сотрудника, который работает за 2 смски в месяц — просто за деньги.



Не соглашусь. Это пример не немотивированного сотрудника, а полного факапа онбординга. Если система управления проектом полностью регламентирована, то откуда негативная коннотация у "что было в ТЗ, то и сделал"? Если система не регламентирована, и многое построено на коммуникации и инициативе, почему руководитель не донёс до разработчика ценность этих качеств, почему при первом же случае появления такого отношения не скорректировал поведение сотрудника? Дополнительной мотивацией здесь что-то решать поздновато. Руководителю необходимо скорректировать свой стиль управления и заняться прояснением всей ситуации в отделе.

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

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


Куча вопросов.
Все ли разработчики — люди творческого труда? Если нет, то почему эксперимент именно со свечой, а не скрепками, используется как обоснование меньшей применимости финансовой мотивации?

Дальше у автора идут вообще нелогичные вещи:

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

Квантор всеобщности "любая" неприменим. Финансовая мотивация, подкрепляющая результативный труд, не имеет "свойство кончаться".

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

Справедливо, но опять же лишь в разрезе "повышения базовой зарплаты"

Или тимлид не заметил критичного изменения атмосферы.

— В разных компаниях разные премии, где-то годовые, где-то ежеквартальные. Какая между ними разница в плане влияния на человека?

— Тут все процессы индивидуальны. Вот есть перфоманс-ревью. Ряд компаний считают, что если человек хорошо перформит, то дадим ему премию побольше. Я замечал, что сами разрабы не думают о премии, когда приходят работать. Они не начинают писать код с мыслями вида: “Сейчас напишу побольше кода и премия будет больше”, нет. Они вспоминают-то о премии за месяц-два, потому что начинается ревью.
Я чаще негатив тут вижу.


На примере нескольких увиденных дисфункциональных систем перфоманс ревью автор формирует мнение о том, что все системы перфоманс ревью дисфункциональны, что совешенно не так.

Исследования показывают, что с разработчиками это работает негативно. Если говорить про механический труд, тут да, для них это проще. Ну вот как у продажника: работать за процент — это ОК. А для разрабов за количество кода — не ОК

Хотелось бы получить у автора ссылки на исследования. Я видел примеры как неработающих систем оценки и фин.мотивации, так и участвовал в строительстве и поддержке работающей системы фин мотивации вида "больше результата = больше денег"

Почему по строкам кода?

— ОК, а периоды —раз в год, в полгода или чаще нужно?

— Я работал в нескольких моделях. В годовом и полугодовом циклах перфоманс-ревью. Особой разницы тут нет. Лично мне лучше было в полугодовом. Если есть сотрудники, которые у тебя просто досиживают до премии, то ты в этом случае хорошо сокращаешь период отсева таких токсичных элементов. А если проводить такое раз в год, то такие сотрудники могут уйти в silent mode и отсиживаться молча, лишь бы была премия. Поэтому раз в полгода лучше. Для команды разработчиков вознаграждение в том числе зависит и от ежедневного перфоманс-ревью.
Исследования показывают, что с разработчиками это работает негативно.

Хотелось бы получить у автора ссылки на исследования. Практика показывает, что достаточно частый (не раз в год / полгода) перфоманс ревью работает позитивно.