Несколько недель назад мы подняли тему «эффективного» менеджмента, которая вызвала немало споров в комментариях. Но у любого массового корпоративного явления есть свои первопричины. В нашем случае — это рост компании.
Рост — это почти всегда хорошо. Как бы не относились работники к происходящему внутри компании в дальнейшем, с точки зрения бизнеса рост — индикатор успешности и правильности взятого курса. Найм новых людей, управленцев и даже «эффективных» менеджеров всегда продиктован возросшими потребностями. Без этих новых и, казалось бы, временами не очень нужных людей, бизнес не умеет расти. И вот, одним утром ведущий разработчик, наемный технический директор другой специалист-звезда просыпаются, приезжают в офис и узнают, что теперь они — не властелины своего куска работы. Теперь все изменилось и их должности, фактически, не существует.
Все это очень сильно бьет по эго и самооценке. Почему это происходит? Как с этим справиться? И надо ли справляться? Давайте разбираться вместе.
Как это происходит
Давайте представим, что у нас есть сферический ведущий разработчик в вакууме, который стоял у истоков и плюс-минус год назад поднимал продукт нашей быстрорастущей компании с колен. Этот разработчик писал главные фичи, проводил ревью кода, внедрял новые технологии, посещал собеседования новых сотрудников и так далее.
В какой-то момент продукт вышел из стадии закрытой альфы и успешно занял свой кусок рынка; выручка растет, клиентская база растет, вес владельца компании тоже сдвинулся с мертвой точки и уже через полгода-год будет расти быстрее, чем предыдущие две метрики вместе взятые. Казалось бы, именно сейчас настал тот момент, когда наш ведущий разработчик может подняться на созданный им трон, поудобнее устроиться и гонять холопов работать в свое удовольствие.
Но его вызывают на ковер. В кабинете сидит директор компании — его непосредственный руководитель, а также владелец бизнеса, главный из HR и кто-нибудь еще по вкусу. Беседа начинается достаточно спокойно, даже непринужденно, но в какой-то момент звучит слово «реструктуризация». Или «развитие». Или «изменения». Можете выбрать любое подходящее. Слово может быть разным, но смысл всегда один и тот же: "%%USERNAME%%, ты молодец, спортсмен и комсомолец, но компания растет и твоя работа в текущем виде нам больше не нужна".
В этот момент у большинства героев подобных сцен (наших ведущих разработчиков или других SuperStar) темнеет в глазах и земля уходит из под ног. «Как это, не нужна? Я что, зря пахал по 70-100 часов в неделю, не видел семью, друзей, частично облысел и, в итоге, стал похож на носферату? Алло! Вы меня решили кинуть?»
Но никто никого не кидает, у нас тут приличное общество в большинстве своем. На самом деле все достаточно просто. Все, что делал наш SuperStar на протяжении последнего года становления продукта — было важно и нужно. Очень важно и очень нужно. Большинство владельцев бизнеса и прочее руководство прекрасно осознают роль нашего разработчика в их собственном благополучии.
Но есть одна проблема. Все то, что делал наш разработчик, не масштабируется.
Бизнес — это история про зарабатывание денег
Нужно сделать небольшое отступление, чтобы внести однозначность. Любой бизнес, в том числе и разработка ПО — про зарабатывание денег для основателей, а не реализацию амбиций сотрудников.
Но чаще всего на старте именно амбициозность и стремление к профессиональному самоутверждению и делают вчерашние стартапы успешными компаниями. Первый этап развития и выхода на рынок любого продукта стоит на плечах наших увлеченных товарищей, которые не видят семей, работают по 10-14 часов в сутки и стремительно лысеют от перегрузок, как физических, так и моральных.
Бизнес охотно поддерживает таких людей в их самосожжении на рабочем месте, но только пока ему, бизнесу, это выгодно. Очень быстро компания вырастает из «детских штанишек» бесконечного спринта, нововведений и новаторства, которые привносят отцы-основатели проекта, и переходят в стадию «плато» — размеренного пиления фич, поддержки и пристального наблюдения за существующими и потенциальными конкурентами. Именно на этом этапе наши стахановцы-звезды становятся «лишними», потому что их бесконечный спринт, фичи и «давай по-новой», которое отбрасывает разработку на пару сотен часов назад больше не нужно и вредно для бизнеса, который теперь должен не удивлять, а гарантировать стабильность для клиентов и инвесторов.
Именно поэтому нашу звезду или просят найти новое место работы, или успокоиться, разобрать свой «трон» из черепов, поправить нервы и смириться с тем, что теперь он будет работать в общей упряжке.
Дальнейшие сценарии развития событий
На самом деле подобный расклад очень сильно бьет по эго. Вчера ты был центральным, незаменимым специалистом, который вел продукт в светлое будущее, а сегодня — тебя просят снять корону, надеть бейджик, потому что у вас появилась служба безопасности, и прислушиваться к мнению инвесторов или аналитиков рынка.
Время безумных спринтов осталось позади, в офисе появляется все больше незнакомых людей, а новые разработчики иногда чертыхаются на костыли в коде или непонятные им фишки. Им-то не объяснишь, что так было надо! Вот начинаются разговоры о рефакторинге и внедрении новых, более стабильных инструментов, а разрыв между владельцем компании и нашим девелопером становится все больше и больше.
Многие такого не выдерживают и уходят из проекта. Кто-то сильно обиженным, громко хлопая дверью, да так, что штукатурка осыпается с потолка, кто-то тихо, получая благодарственные «отступные» за подорванное здоровье и потерянные волосы (но не всегда). Но что делать, если продукт, в который было вложено столько сил, времени и нервов бросать не хочется?
Незаменимых быть не должно
При переходе из стадии создания продукта к коммерческой долгосрочной разработке-поддержке бизнес, клиенты и инвесторы должны быть уверены в том, что структура компании стабильна, а процессы внутри нее масштабируемы. Это банальный здравый смысл: незаменимых людей быть не должно. Не должно быть в процессе разработки коммерческого продукта, которым пользуется N клиентов, человека, на котором бы держалось «все и сразу». Именно поэтому «мутация» компании начинается с реструктуризации, расставания с ранее ключевыми SuperStar-девелоперами и найма большого количества новых сотрудников.
В этот момент все зависит от конкретного человека. Если он принимает новые правила игры, видит продукт как товар, чем он и является, и готов делиться властью и ответственностью, то для него всегда найдется выскооплачиваемое «теплое» место.
Но чтобы правильно «сыграть» в этой ситуации, надо понимать логику бизнеса: любая попытка и дальше «замыкать» процессы на себе и выбивать какие-то особые условия, право вето или другие рычаги давления на разработку будут восприниматься как прямой саботаж. Потому что чаще всего все эти инструменты влияния используются для достижения субъективного, а не объективного результата.
Разработчики крайне подозрительно относятся к продажникам и прочим аналитикам, которые говорят, что сейчас пользуются спросом. Еще большее отторжение вызывают ситуации, когда эти самые аналитики указывают на то, что какая-либо часть столь тяжело проделанной девелоперами работы нерелевантна текущим потребностям клиента. В этот момент многие срываются, рвут на груди рубаху и начинают кричать: «Да я же столько сил положил! Не позволю!» и так далее. Именно такого поведения опасается бизнес со стороны SuperStar-девелоперов, которые поднимали проект с нуля, именно его они пытаются избежать через увольнения ключевых членов старой команды.
Фактически, все сводится к одной простой истине: если вы не совладелец бизнеса, то и не вам определять, как он будет развиваться. И не важно, как много времени и сил было отдано на первом этапе становления компании. Да, может быть больно, может быть обидно за то, что продукт повернул в болото корпоративного сегмента и перестал обрастать новыми фичами и фишками. Но прямая конфронтация с интересами бизнеса приведет лишь к одному — поиску новой работы.
И даже если вы в конкретном случае правы и видите, что новый курс ведет в пропасть, а не к звездам — статистика играет против вас. Потому что на одного понимающего ситуацию девелопера приходится 99 разработчиков-звезд, которые тянули одеяло на себя, не видя всей картины целиком.
Как часто вы сталкивались с тем, что ведущие разработчики сопротивлялись изменениям и нововведениям, связанным с ростом компании просто потому что им это не нравилось? Именно не нравилось, а не было не правильно. К сожалению, подобные ситуации далеко не редкость. Для того, чтобы остаться на одной волне с текущими потребностями бизнеса нужно принять то, что написанный код — не ваша собственность, а часть коммерческого продукта, цель которого — зарабатывать деньги, а не радовать кого-то из разработчиков.
Как остаться на «корабле»
Собственно, путь остаться и работать дальше достаточно прост, но лежит в плоскости борьбы с собственными привычками. Многие описываемые нами девелоперы сталкиваются с тем, что новое руководство, владелец компании и даже коллеги начинают мыслить совершенно иными категориями. Собственно, этому учат на MBA — извлечение максимальной прибыли из продукта. Если вы не разделяете подобных взглядов, но хотите остаться на текущем месте, то во внимание следует принять следующие пункты:
- Продукт делается для клиентов и с оглядкой на клиентов, потому что теперь они у вас есть.
- Подход к разработке изменится и это нормально.
- Масштабирование неизбежно.
- Нельзя пытаться замкнуть всю разработку на себе.
- Вполне вероятно, придется занять руководящую должность, а это нравится не всем.
- Интересных задач и профессиональных «вызовов» будет все меньше и к этому надо быть готовым.
- Теперь намного больше людей будет иметь право голоса и влияния на разработку. Таков бизнес.
- Конфронтация с новыми людьми и начальниками не приведет ни к чему хорошему для всех сторон.
В крупных компаниях такие девелоперы-звезды кочуют между разными отделами и проектами, где могут выложиться на полную и уходить каждый вечер из офиса с чувством выполненного долга.
Но если продукт только один, то выбор не слишком велик: поддерживать то, что «натворил», переходить в управленцы или искать новый проект. Как это не печально.
Post Scriptum
Описанное не стоит путать с ситуациями, когда девелопера реально «выжимают» из компании менеджеры-редиски. Об этом мы, возможно, поговорим в другой раз.
Автор: ragequit
