Фраза «нормально делай — нормально будет» давно поселилась в рабочих чатах, на кухнях и в голове у половины индустрии. Но для тех, кто строит карьеру в IT, такой совет может оказаться не безобидной народной мудростью, а плохой операционной системой: она либо удерживает человека в удобной посредственности, либо толкает в переработки без внятной отдачи.
Именно это разбирает автор текста на Habr / Карьера: привычная связка между усилием и наградой в найме часто не работает так прямолинейно, как нас учили. Для разработчиков, тимлидов, продактов и founders здесь неприятная, но полезная мысль: в карьере в IT побеждает не тот, кто просто сильнее старается, а тот, кто умеет проверять, за что в конкретной системе вообще платят повышением, влиянием или деньгами.
Конструкция статьи предельно простая: есть три сценария работы и жизни, и два из них автор считает ловушками. Первый сценарий можно назвать режимом «как все». Человек приходит на дейлики, закрывает задачи по ТЗ, не спорит с системой и не особенно рискует. На бытовом уровне это выглядит разумно: стабильная зарплата, понятная роль, минимум турбулентности. Проблема в том, что эта «норма» означает не качество, а усреднение. Иными словами, речь не про мастерство, а про готовность встроиться в статистическое большинство. В IT такой выбор встречается чаще, чем принято признавать: если базовые потребности закрыты, многие предпочитают не расти вширь и не лезть в зоны, где можно проиграть. Автор не спорит с правом на такой выбор, но напоминает, что безопасность здесь во многом мнимая. Усреднённость не спасает ни от сокращений, ни от карьерного застоя, ни от ощущения, что несколько лет ушли в аккуратное топтание на месте.
Ловушка старания
Второй сценарий выглядит куда благороднее: работай лучше, вкладывайся сильнее, и система это заметит. На бумаге звучит как правильная взрослая позиция. На практике, как показывает Habr / Карьера, именно здесь люди чаще всего попадают в самую дорогую ловушку. Автор разбирает её на двух наглядных примерах. Первый — сотрудник, который делает свою текущую работу образцово и ждёт, что за это его автоматически поднимут выше. Но отличное исполнение одной функции не доказывает пригодность к другой. Если человек идеально моет полы, это не означает, что он умеет управлять сменой. Если разработчик пишет чистый код, это ещё не делает его тимлидом. Для лидерской роли нужны другие компетенции: разговор с заказчиком, защита команды перед менеджментом, работа с конфликтами, расстановка приоритетов. Индустрия любит повторять, что техлид или тимлид вырастает из сильного инженера, но на деле повышение часто требует смены оптики, а не просто прибавки в скорости и качестве кодинга.
Здесь автор попадает в нерв, знакомый многим командам. В карьере в IT люди нередко максимизируют не ту метрику. Они полируют реализацию, закрывают больше задач, дежурят в проде, остаются на связи после рабочего дня, а потом обнаруживают, что решение о повышении принималось по совсем другим признакам. Не потому что мир «несправедлив», а потому что в конкретной компании правила были другими с самого начала. Кого-то поднимают за умение договариваться, кого-то — за политический вес внутри организации, кого-то — за способность удерживать команду, а вовсе не за число merged pull request. В статье есть жёсткая, но полезная мысль: если сотрудник надеется, что самоотверженность внезапно превратит его в совладельца бизнеса или обеспечит исключительный статус, он, скорее всего, играет в игру по правилам, которых не существует. Доли уже распределены, роли уже описаны, а чудо как карьерная стратегия обычно плохо переживает встречу с reality check.
Самая неприятная часть этой модели — чувство вины. Когда человек сделал всё «как надо», а обещанной награды нет, он редко обвиняет систему. Обычно он обвиняет себя: недожал, недоработал, не доказал, не заслужил. Именно этот механизм и делает ловушку особенно токсичной. Она превращает неудачную гипотезу в моральный приговор самому себе. Для отрасли, где культ эффективности давно соседствует с выгоранием, наблюдение болезненно точное. Слишком много специалистов всё ещё живут в неформальном контракте с миром: если работать хорошо, тебе обязательно вернут это бонусом, ролью, акциями или хотя бы признанием. Но если такой договор никто не подписывал, то и требовать исполнения не с кого.
Что вместо этого
Рабочим автор называет третий сценарий: делать, подводить итоги, корректировать. Звучит почти скучно, и в этом как раз его сила. Никакой романтики героического труда, никакой веры в автоматическую справедливость. Сначала ты делаешь не идеально, а достаточно хорошо, чтобы получить данные. Потом смотришь на реакцию реальности. После этого меняешь подход. Для IT-аудитории этот язык знаком: MVP, A/B-тест, post-mortem, итерация после релиза. Статья фактически предлагает применять тот же инженерный подход к собственной карьере. Хочешь повышение — не старайся вслепую, а выясни, что в этой компании реально влияет на решение. Поговори с теми, кто это решение принимает. Посмотри, кого уже повышали и что у этих людей общего. Проверь, совпадает ли официальная риторика с практикой. Если нет, корректируй курс, а не добивай себя чувством вины.
Из этого же следует ещё один неприятный, но полезный вывод: иногда нужная цель достигается не через внутренний рост, а через смену компании, роли или вообще формата работы. В тексте есть пример разработчика, который не ждал особого признания от работодателя, спокойно делал свою часть без самоистязания и параллельно развивал pet-проекты. Несколько он закрыл, один в итоге превратился в бизнес, после чего наёмная работа перестала быть для него главным сценарием. История не подаётся как сказка про лёгкий успех. Скорее как напоминание: энергия даёт лучший возврат там, где у человека есть субъектность, а не только надежда быть замеченным. Если уж распределять внимание, то не в пользу бесконечной шлифовки задач ради абстрактного «молодец», а в пользу тех направлений, где результат можно проверить и масштабировать.
Для бизнеса и руководителей здесь тоже есть неприятное зеркало. Если сотрудники годами верят в несуществующие правила игры, значит, компания плохо объясняет, за что именно вознаграждает людей и какие переходы между ролями вообще возможны. А там, где критерии непрозрачны, неизбежно растут переработки, обиды и кадровая текучка. Поэтому главный вопрос после таких текстов не в том, надо ли работать хорошо. Надо. Вопрос в другом: понимают ли обе стороны, какой именно результат считается ценным и что должно произойти, чтобы усилие конвертировалось в новый статус, деньги или свободу. Для карьеры в IT это, похоже, важнее любого вдохновляющего лозунга.