Бывает так: код хороший, задачи закрыты, к технической части претензий нет. Но и повышения тоже нет. Или идею не взяли. А на интервью — отказ без внятной причины.

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

Стаж рос, и понимание вместе с ним. Но всегда с опозданием, потому что впереди стояла новая стена, и пробить её сразу я не мог.

Сейчас я Staff Engineer. Мне нравится то, чем я занимаюсь, я влияю на решения, которые считаю важными, и в стену больше не упираюсь. Помогло не то, что я стал сильнее как инженер — сильным инженером я был и тогда, когда упирался. Помогло другое: я разложил эти ситуации по полочкам, расстался с иллюзией собственного инженерного величия и начал комбинировать техническую экспертизу с семью вещами, которых поначалу не замечал.

Это семь языков. И ни один из них — не язык программирования.

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

1. Технический CTO, или как я отбрил вопрос и через год пришёл каяться

Времена были десктопные. Первым продуктом, который я делал с нуля с маленькой командой, было Windows-приложение с серверной частью.

Всё шло хорошо: появились первые клиенты, они были довольны.

В какой-то момент ко мне приходит CTO и спрашивает: сколько будет стоить портировать бэкенд на Linux.

Я насчитал два года и сказал, что оно того не стоит.

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

Через год я сам пришёл к нему просить ресурсы на этот самый порт.

Выяснилось следующее: пилотные клиенты действительно сидели на Windows, но это была случайная выборка. Основная часть рынка держала серверы на Linux, причём на бесплатных дистрибутивах. А в нашем ценнике половину суммы составляли не мы, а закупочные лицензии Microsoft. Мы одновременно были неконкурентоспособны по цене и отрезаны от большей части рынка.

Порт занял восемь месяцев — это вместе с переучиванием команды. Не два года.

Я честно сказал CTO, что ошибся. Он дал ресурсы и не стал напоминать, кто был прав.

Урок, который я вынес: когда технический руководитель приходит с вопросом «сколько будет стоить», он редко спрашивает про смету. Он проверяет, видишь ли ты то же, что видит он. Я услышал вопрос про ресурсы и ответил про ресурсы. А вопрос был про рынок.

И вторая часть урока, менее приятная: я тогда защищал не архитектуру и не сроки команды. Я защищал собственную зону комфорта и упаковал это в техническую аргументацию так убедительно, что сам поверил.

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

2. Нетехнический CEO. «Где деньги, Зин?»

Это была поворотная точка, хотя тогда я так не думал.

У меня были амбиции: взять направление под полный контроль, вести его с технической и не только стороны и сделать это рывком в карьере — первым по-настоящему своим решением, а не исполнением чужого.

Я пришёл к CEO продавать идеальное техническое решение. Объяснял, как красиво оно устроено, как надёжно будет работать, какое счастье получат клиенты.

Он не понял ни слова и задал один вопрос: где деньги?

Я ответил, что деньги придут, потому что продукт очень крутой.

На этом разговор закончился. Он развернул и моё решение, и мои амбиции.

У меня был подробный ответ на вопрос, как это будет работать. И не было никакого ответа на вопрос, откуда возьмутся клиенты. Я даже не заметил, что второго ответа у меня нет: мне казалось, он следует из первого.

Тогда я решил, что меня не оценили. Это был не единственный повод, но именно тот разговор стал финальным гвоздём — вскоре я закончил долгое сотрудничество и с компанией, и с этим человеком.

Прошло много лет, и я могу сказать прямо: он задавал правильный вопрос, а я на него не ответил.

Сегодня это очевидно даже сильнее, чем тогда, ведь реализация продукта — это самая понятная и дешёвая часть цикла, а ответ на вопрос «кому мы это продадим» — самая дорогая и самая важная. Начинать надо было с неё, а не с того, чтобы построить рабочий, красивый и никому не нужный продукт.

Это был самый простой, зато самый важный урок в моей инженерной карьере: CEO без технического бэкграунда не притворяется, что не понимает твою архитектуру. Он правда её не понимает — и не должен. Он оценивает не решение, а то, снимаешь ли ты с него неопределённость или добавляешь новую. Я тогда добавил неопределённость: пришёл с большим планом и без единой цифры под ним.

Язык второй, возможно, самый важный — язык инвестиций. Каждое решение здесь звучит как «мы вкладываем столько и рассчитываем получить вот это». Нужно перестать продавать качество решения и начать отвечать на вопрос, как это окупится. На это мне понадобилось несколько лет и одна потерянная работа.

3. Команда. Вчера равный — сегодня даёшь указания

Первые два языка я учил, стоя перед людьми, которые принимали решения обо мне. Дальше начинается другая часть карьеры — та, где решения начал принимать я.

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

Это и подтолкнуло к решению: выйти из роли обычного разработчика и на ощупь искать себя в роли человека, который должен ещё и управлять командой. Теми самыми людьми, с которыми буквально вчера я сидел в одной роли и ждал указаний откуда-то сверху. А теперь этим «сверху» стал я сам.

Самым сложным оказалось несогласие. Раньше с этими же людьми я спокойно находил компромисс — мы были в равных позициях, и спор был просто спором. Теперь при каждом расхождении внутри поднималось желание ударить кулаком по столу: ребята, мнение у вас есть, но главный тут теперь я, и сейчас я вам всё объясню.

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

Это был перелом. Я буквально шёл вразрез с тем, как обо мне думали вчерашние сокомандники, а теперь подчинённые.

Но у роли обнаружилась вторая сторона, о которой я до этого не думал. У меня появился инструмент, чтобы команду защищать. Выбивать условия — и технические, и финансовые. Договариваться с руководством за конкретного человека, менять формат взаимодействия, искать новых людей. Вся организационно-административная работа, которую до этого не делал никто. Я, разумеется, тоже — учился на лету.

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

Авторитет сложился не из того, что я требовал и настаивал. Он сложился из двух вещей. Первое — я научился аргументировать свои решения. Второе — команда увидела, что положиться на меня можно и в вопросах, к разработке отношения не имеющих. Ровно так же, как я полагался на них в технических решениях.

Это и был мой первый настоящий урок в роли лида. Получая в руки инструменты (назовём их управлением, слово «власть» тут неточное), применять их надо в обе стороны сразу. И чтобы стоять на своём, и чтобы защищать людей. Односторонний вариант не пройдёт: команда очень быстро считывает, на кого ты работаешь.

Так что третий язык — это язык доверия. Он всегда взаимный. Односторонней версии не существует: если ты не доверяешь команде, она не будет доверять тебе, сколько бы полномочий у тебя ни было. Моя трансформация в лида — это перестать видеть в новой роли право распоряжаться и увидеть в ней обязанность быть надёжным.

4. Продакт: а если «нет» прилетит тебе?

На одном проекте я вёл команду и одновременно закрывал продуктовую функцию — по тайтлу это называлось CTPO (CTO плюс CPO), а по факту я был тимлидом и продактом в одном лице. За архитектуру при этом отвечал отдельный техлид.

Пришёл я в середине жизни проекта: продуктовые ожидания уже сформировались, и одной из задач было — найти новые точки роста.

Первой из моих идей была рекомендательная система контента с несколькими нестандартными атрибутами. Логика была такая: рекомендации увеличивают время работы с продуктом, время означает внимание пользователя, а внимание мы умели перепродавать тем, кому оно интересно.

Питчу идею команде. Всем нравится. А техлид начинает сопротивляться — и, надо сказать, вполне резонно: он показывает конкретные ограничения текущей архитектуры. И встаёт в позицию: это нереализуемо.

Вот здесь развилка, ради которой я эту историю и рассказываю.

Будь я классическим продактом без инженерного бэкграунда, я бы опустил руки. Услышав «нереализуемо» от человека, который знает систему изнутри, пошёл бы искать другую идею. Ровно так это и работает в большинстве команд: техлид говорит «нет», продакт не может проверить аргумент и отступает.

Но я эти ограничения видел сам, когда проводил технический аудит. Поэтому предложил посмотреть на ситуацию иначе — не спорить с его «нет», а изменить постановку задачи.

Мы договорились сделать быстрый прототип. Тяп-ляп и в прод — но изолированный так, чтобы качество кода в нём не могло повлиять на ключевые узлы системы. Задача прототипа была не в том, чтобы работать долго, а в том, чтобы проверить гипотезу: нужна ли пользователям эта функция вообще. Считать мы это умели.

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

Что я отсюда вынес.

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

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

И честное замечание напоследок. Я смог развернуть этот разговор только потому, что мог говорить с техлидом на его языке. У большинства продактов такого рычага нет, и когда они слышат «нереализуемо», у них не остаётся никаких инструментов, кроме как поверить или продавить силой. Оба варианта плохие.

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

5. Боль рекрутера: почему подавляющее большинство кандидатов не могут рассказать, что они сделали

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

В моей компании нерядовая практика: рекрутер не ведёт кандидата напрямую на техническое интервью — сначала его пропускают через скрининг инженеры, и я один из них.

И вот моё наблюдение: на 120 скринингах, которые я провёл за последние месяцы, примерно 90% кандидатов не смогли внятно рассказать, кто они и что они сделали. Не потому что слабые — многие сильные. Просто рассказ о себе как о профессионале — это отдельный навык, которым почти никто не занимается.

Провалы делятся на два типа.

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

Второй — опыт, который никуда не привязан. Человек добросовестно описывает, чем занимался, но я не могу вытащить оттуда ни одного факта, который связал бы этот опыт с вакансией, о которой мы разговариваем. Опыт может быть отличным, но если я не вижу пересечения, у меня нет причины двигать человека дальше.

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

Вывод, который я бы отсюда вынес на месте кандидата: скрининг — не проверка квалификации. Это проверка того, можешь ли ты сделать чужую работу за собеседника. Тот, кто тебя слушает, должен потом кому-то тебя пересказать, иначе дальше твой рассказ не пройдёт, каким бы сильным ты ни был.

Пятый язык назвал бы языком пересказа. Всё, что нельзя воспроизвести чужими словами через час после разговора, не существует. Если ты идёшь в найм, перестань описывать себя качествами и начни описывать ситуациями с измеримым результатом. Опыт при этом не меняется ни на грамм. Меняется только то, можно ли его передать дальше.

6. Бизнес, или как мы считали себестоимость кода в строчках

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

Выяснилось, что по применимому праву у продукта должна быть номинальная стоимость: она нужна как доказательство общей стоимости работ, которые компания выполняет. А считается эта стоимость в человеко-часах, потраченных на изготовление.

Дальше бухгалтерия задала вопрос, к которому я оказался не готов: хорошо, а себестоимость какая? То есть нужно было соотнести зарплаты команды разработки с конкретным результатом на выходе.

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

Я всё время находился в ощущении абсурда. Потому что регулярно случалось так, что одно и то же функциональное требование мы переписывали несколько раз — просто потому, что этого требовал процесс разработки. И стоимость засчитывалась трижды, как будто мы трижды создали новую ценность.

Честно, я до сих пор не знаю, как корректно свести язык финансов и то, как мы производим продукты. Это два разных языка — они нам про яблоки, а мы им про апельсины.

Забавно, что с тех пор ничего принципиально не изменилось, поменялись только единицы. Сегодня в эпоху AI считают уже не строки кода, а потраченные токены. Метрика новее, выглядит технологичнее, а понимания в ней ровно столько же: она измеряет объём производства и затрат, а не созданную ценность — тот же счёт яблок в апельсинах.

Зато я усвоил другое: момент, когда бизнес не может посчитать твою работу, — это не их проблема, которую можно проигнорировать. Это твоя проблема. Потому что считать они всё равно будут — просто теми метриками, которые придумают без тебя. И тогда разработка окончательно превращается в статью расходов: то, что нельзя связать с результатом, остаётся в отчёте просто затратами.

Практический вывод из всей этой истории оказался неожиданно простым: с бухгалтерией и финансами надо дружить. Не терпеть, не отбиваться от их запросов, а идти к ним самому и разбираться, как они считают. Люди, которые сводят сметы, обычно рады объяснить свою логику, ведь их редко кто спрашивает. А ты получаешь доступ к тому, как твоя работа выглядит на верхнем уровне, и возможность повлиять на метрику до того, как её придумают без тебя.

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

7. Инвестор и борд: Тот-Кого-Нельзя-Называть

Эту историю я наблюдал со стороны.

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

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

Технологически он защитил себя идеально. Решение было закрытым, детали работы и все её нюансы жили у него в голове и больше нигде. Отказаться от этой головы никто не решался.

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

А кончилось всё предсказуемо: он ушёл. Просто взял и ушёл, не передав никому ничего.

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

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

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

Но на уровне борда это описывается одним термином: key person risk. И считается не в уважении, а в деньгах: в оценке компании, которая снижается, потому что критичная часть бизнеса держится на одном сотруднике.

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

Язык седьмой — это язык риска. На нём любая зависимость от одного человека становится не достижением, а угрозой, которая снижает стоимость компании. Зрелость разработчика измеряется тем, насколько уверенно всё работает без него, а не насколько он незаменим.

Что общего у этих семи историй

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

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

Семь языков, и ни один не выучивается по книге. Каждый требует трансформации — перестройки в голове, а перестройка вещь неприятная: приходится признать, что ответ, которым ты гордился, был ответом не на тот вопрос.

Я на все семь долго отвечал одинаково, рассказывая, насколько хорошо разбираюсь в системах. Иногда срабатывало. Чаще нет, и я списывал это на то, что меня не оценили.

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

Мне повезло столкнуться с этим в начале карьеры — и всё равно я потратил время в поисках причины. А многие сидят в этом годами и объясняют застой чем угодно: рынком, руководством, невезением. Настоящую причину при этом не проверяют, потому что она неприятная.

А проверить её просто: вспомни последний разговор, после которого ничего не сдвинулось, и спроси себя — о чём тебя тогда спрашивали на самом деле.