×
Фото Почему нужно увольнять хороших программистов

Почему нужно увольнять хороших программистов

Рыцарь на белом коне (knight in shining armor) — непогрешимая личность, с ЧСВ, равным как минимум квадрату собственной технической квалификации.

Рыцарь на белом коне (knight in shining armor) — непогрешимая личность, с ЧСВ, равным как минимум квадрату собственной технической квалификации. Появляется на сцене в кризисный момент и начинает чинить всё подряд, как правило — чинит успешно, только без сообщений о том, какие изменения он сделал, и почему. Так что при очередном обновлении системы ничего не подозревающим сисадмином старые ошибки возвращаются на свои места, что даёт повод РНБК заявлять о тупости и некомпетентности окружающих, что ещё более увеличивает его ауру непогрешимости.

Позиция начинающего KISA, который таки заметил, что что-то не так (эта часть написана в 2012-ом):

«Если в Вашей компании есть незаменимый человек — увольте его».

Эту цитату, наверняка, все уже видели. Я склонен согласиться с ней. Сложно вести куда-либо компанию, реализовывать идеи, когда knight in shining armor пытается реализовать свои идеи, причём делает это сравнительно успешно.

Хороший программист — он как архитектор или художник: реализует свою потребность в самовыражении доступными ему средствами. Сложно заставить художника рисовать картину «Ленин на броневике» в духе соцреализма, когда у него в голове абстракционистские наброски.

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

Есть ещё третий вариант: уволить его, чтобы не мешал работать другим.

Дабы не доводить дело до крайности, не забывайте периодически бить его тапком, чтобы не зазнавался, и махать перед носом пресловутым бонусом (да, да — пряником), чтобы шёл к «цели» бодрым и весёлым шагом.

Если делать это умело — ваше сотрудничество будет долгим и продуктивным, иначе… третий вариант.

Немного ретроспективы (события 2013-го):

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

В итоге — уход из компании, замена меня на 3-х людей, каждый из которых занимался одним из направлений, которые я поддерживал. Плюсом торможение по всем процессам — люди должны же въехать и выйти на нормальную производительность. А это пара-тройка месяцев. Но и это один из лучших исходов — да, ресурсов тратим больше, но теперь пропала угроза, пропала проблема, что есть незаменимый человек.

Самое что парадоксальное, можно было это сделать ещё до ухода, тогда бы всё было контролируемо, можно было бы распределять нагрузку, больше проектов делать. Да и когда человек становится не единственным, кто может что-то сделать, пропадает «проклятие» KISA.

Для меня же это означало одно: я больше не хочу быть «the only one», вместо этого у меня появилась мечта об одноранговых децентрализованных сетях людей со взаимоперекрываемыми компетенциями.

С самого начала не давать стать KISA (2014-ый + наблюдение со стороны в 2015-2017):

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

Вариант интересный, если вы готовы быть некомпетентным мудаком с сильной внутренней референцией, препятствующей развитию проекта. Ух, загнул!

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

Если же сами проводите большую часть рабочего времени над проектом, плюс являетесь сопоставимым разработчиком по уровню — всё хорошо. «Проклятие» KISA снято.

К чему всё же приводит «контроль со стороны» (когда контролирующий не в проекте)? Понижение мотивации, а тут 2 варианта:

  1. деградация,
  2. уход.

Контролируемый KISA

Давайте попробуем таки оставить KISA на работе. Всё же он крутой специалист + его уход/увольнение сильно отразится на продукте.

Тут надо организовать загончик, в котором он может резвиться. При этом надо чётко указать границы этого загончика. И пару раз преподать урок, что оттуда не стоит вылазить.

Тогда этот товарищ становится «местным князем» — есть вотчина, которая его. Не «начальником участка», а «князем». Его подчинение довольно довольно странно. Возможны «итальянские забастовки» и прочие эксцессы.

Также при этом сложно в эту экосистему внести кого-то с лидерскими задатками — грызня уровня волчьих стай.

Плюсом — потеря ориентации на бизнес полная. Скажите дать опцион/долю?.. работает, но процентов на 20% — в голове иной раз начинают появляться чуждые мысли о прибыли.

В общем, вы получаете почти неподконтрольную структуру внутри компании… Этакий пиратский корабль в своём флоте. Бывает, что план выполняется (нападают на нужные корабли), но по большей части это не так…

В общем, я так и не нашёл ни одной компании, где эффективно работал бы KISA. Поэтому снимайте это «проклятие» с людей, как только видите!

Будь первым – оставь комментарий!

Фото Автоматизация религий
Предыдущая запись:
Автоматизация религий
Фото Боевой Программист Сирасэ
Следующая запись:
Боевой Программист Сирасэ