В 2014 году на встрече президента с представителями интернет‑индустрии прозвучала реплика, которая потом зажила отдельно от своего политического контекста: «надо вылезать из‑под коряги».

В 2014 это означало, что ИТ бизнесу нужно больше работать с властью и социальными проблемами. В 26-м для инженеров эта фраза становится неожиданно точной.

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

Дальше обычно два сценария.

1. Либо вы входите в конфликт и становитесь «сложным», «негибким», «слишком резким».

2. Либо Гибко прогибаетесь, соглашаетесь на неправильную рамку, а потом именно вам и вашей команде разгребать последствия, и теперь уже для команды вы «предатель»

Казалось бы причем тут лидерство? Это и есть реальная точка входа в тему для инженера. Не вдохновение. Не харизма. Не soft skills, как список добродетелей. А момент, в котором спрятаться под корягой уже не получается.

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

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

Сейчас этот промежуточный слой просто не держит перегруз.

Классические Jira‑менеджеры и календарные посредники уходят, перегружаются или перестают держать сложность. Команды становятся гибридными. Решения принимаются быстрее и в большей панике, потому что у менеджера горят уже не строки в плане, а что‑то гораздо ближе к телу. Изменения происходят слишком быстро, чтобы каждая проблема проходила через длинную цепочку согласований. А это значит, что инженеру всё чаще приходится говорить напрямую с теми, с кем раньше он вообще мог не пересекаться.

И мы снова возвращаемся в реальность: либо конфликт, либо прогиб.

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

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

Внешний управленческий мир слишком часто мыслит амбициями, сроками, компромиссами, перераспределением риска, договорённостями и политическим балансом. В общем, там всегда надо быть «договороспособным».

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

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

Это особенно раздражает, когда за разговорами о человечности прячутся более прозаические вещи:

1. Отсутствие знаний о собственном бизнесе;

2. плохой менеджмент;

3. плохой оргдизайн;

4. неготовность принимать реальность (инженерные ограничения);

5. попытка заменить нормальную систему работы моральным давлением;

6. имитация управления вместо реального вклада в результат.

Ситуация: с реальным владельцем процесса инженер почти не встречался

Во многих компаниях инженер годами жил в модели, где с реальным владельцем процесса, бизнеса или прибыли он почти не сталкивался. Между ними стоял промежуточный слой: менеджер, продакт, проектный координатор, кто‑то «коммуникационный», кто‑то «организационный».

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

Проблема в том, что вместе с шумом она изолировала инженера и от прямого влияния, и часто намеренно.

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

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

Вызов: пузырь посредников сдувается

Новая ситуация неприятна именно тем, что она не спрашивает разрешения.

Работать в удобном пузыре становится невозможно по трём причинам:

1. изменения стали слишком быстрыми;

2. промежуточный управленческий слой всё хуже справляется;

3. гибридные команды требуют прямого контакта между функциями.

То, что раньше можно было отложить, теперь приходится проговаривать прямо:

• почему требование нереалистично;

• где реальный trade‑off;

• что сломается при красивом, но неверном решении;

• почему «надо быстрее» не является аргументом само по себе;

• где проходит граница между компромиссом и разрушением системы.

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

Главный вопрос: как говорить со стейкхолдерами и не сломать себя

Здесь обычно и начинается плохой разговор про soft skills.

Инженеру предлагают:

1. быть мягче;

2. быть эмпатичнее;

3. лучше договариваться;

4. пройти тест на EQ;

5. быть командным игроком.

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

Это стремно.

Если команда работает на результат, у неё почти всегда уже есть здоровое инженерное ядро:

• уважение к ограничениям системы;

• причинно‑следственное мышление;

• опора на артефакты истины, а не на настроение;

• привычка различать хотелки, требования и реальные trade‑off;

• отказ считать «договорились на словах» полноценным решением.

Это не то, что надо смягчать. Это то, что вообще создаёт результат.

Поэтому правильный вопрос не «как начать соответствовать HR меркам (стать гуманитарием)».

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

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

Ответ 1: manage up как понимание и контейнирование

Manage up часто понимают слишком мелко: как умение понравиться руководителю или правильно подать идею наверх.

Для инженера это слабое и даже вредное определение.

Более взрослое определение такое: manage up — это умение понимать и контейнировать внешний контур.

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

1. понять, в каком мире живёт стейкхолдер;

2. увидеть, чем он реально ограничен;

3. распознать, где в его речи тревога, хаос, давление, политика или иллюзия контроля;

4. не принять этот хаос внутрь себя как новую норму;

5. вернуть разговор в форму, где снова возможны границы, приоритеты и последствия.

Иными словами, manage up — это не подчинение. Это способность удержать разговор так, чтобы внешнее давление не разрушило реальность системы.

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

Manage up в такой рамке означает:

1. понять, что на самом деле происходит у второй стороны;

2. не спутать чужую тревогу с объективной срочностью;

3. не позволить разговору утечь в туман «давайте как‑нибудь договоримся»;

4. перевести спор в язык последствий;

5. удержать собственную рамку без позы и без капитуляции.

Ответ 2: командная игра как управляемый конфликт

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

Но у зрелой команды есть и другое определение.

Командная игра — это не отсутствие конфликта.

Командная игра — это управляемый конфликт вокруг результата.

То есть:

1. конфликт признаётся нормальным;

2. противоречия не замазываются вежливостью;

3. позиция каждого переводится в последствия для системы;

4. разговор удерживается в рабочем контуре, а не в театре статуса;

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

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

Для инженерной аудитории здесь важна простая мысль: командная игра не означает комфорт.

Она означает, что:

1. конфликт не отрицается;

2. конфликт не романтизируется;

3. конфликт удерживается в форме, где он производит решение, а не только эмоцию.

Если этой способности нет, команда обычно попадает в один из двух режимов:

1. либо молчаливый прогиб под внешний контур;

2. либо бесконечная война всех со всеми.

Оба режима одинаково плохо совместимы с результатом.

Ответ 3: коммуникация как адаптер, а не как капитуляция

Самый полезный рефрейм здесь такой: коммуникация для сильного инженера — это не отказ от инженерной логики.

Коммуникация — это адаптер.

Как в паттерне проектирования: ядро системы не меняется, но появляется интерфейс, через который оно становится совместимым с внешней средой.

В рабочей реальности это означает:

1. вы не перестаёте видеть противоречия;

2. вы не считаете хаос нормой;

3. вы не размываете критерии качества;

4. вы учитесь заворачивать реальность в форму, которую внешний контур способен воспринять.

То есть задача не в том, чтобы стать удобнее. Задача в том, чтобы защитить результат там, где одних технических аргументов уже недостаточно.

Ответ 4: ИИ как усилитель, а не костыль

Здесь и появляется нормальная роль ИИ.

Не как замены мышления. И не как волшебной прокладки, которая «поговорит за вас».

А как усилителя в нескольких конкретных задачах:

1. собрать и сжать контекст перед сложным разговором;

2. прогнать несколько формулировок одного и того же ограничения;

3. подготовить структуру разговора со стейкхолдером;

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

5. тренировать Слой коммуникации, не меняя инженерное ядро.

ИИ не заменяет влияние. Он усиливает того, кто уже учится думать, различать и удерживать конфликт.

Пять компетенций: что удерживать в себе и что делать для команды

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

1. что он должен делать сам;

2. что он начинает делать для команды и внешнего контура.

Именно так удобно читать пять компетенций.

1. Лидерство и направление

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

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

2. Коммуникация

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

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

3. Процессы и сотрудничество

Про себя: видеть, где плохой процесс создаёт лишнее трение, и не романтизировать хаос как «живую работу».

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

4. Обучение и адаптивность

Про себя: быстро учиться новому типу взаимодействия, не прячась в позицию «я технарь, это не моя территория».

Про команду: помогать команде адаптироваться к новой реальности, где прямой контакт со стейкхолдерами и ИИ уже не исключение, а норма.

5. Стейкхолдеры и внешний контур

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

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

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

Почему здесь вообще уместно слово «лидерство»

На Habr слово «лидерство» вызывает справедливое раздражение, потому что слишком часто связано с корпоративным глянцем: красивые слова, ритуалы, вдохновляющие лозунги и ноль реального влияния на систему.

Но если выкинуть этот слой, остаётся вполне предметная вещь.

Сильный инженер уже влияет на:

1. то, какие ограничения считаются реальными;

2. как команда объясняет внешнему контуру цену решений;

3. где проходят границы допустимого;

4. как проживаются сложные разговоры;

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

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

Меняется не только поведение, меняется сама реальность роли

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

Теперь сдвиг глубже.

То есть меняется не просто набор действий.

Меняется роль инженера в системе:

• раньше он мог оставаться внутри инженерного контура;

• теперь он вынужден работать на границе миров;

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

Заключение

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

Но ему действительно придётся работать напрямую.

И это уже не вопрос вкуса.

Пузырь посредников сдувается. Изменения слишком быстрые. Гибридные команды требуют прямого контакта. Значит, вопрос теперь не в том, хочется ли инженеру заниматься влиянием.

Вопрос в другом: будет ли это влияние реальным.

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

Ни один из этих сценариев не ведёт ни к сильной команде, ни к сильному продукту, ни к реальному развитию бизнеса.

Другой путь сложнее, но взрослее. Инженер сохраняет своё ядро: причинно‑следственное мышление, уважение к ограничениям, опору на артефакты истины и привычку различать хотелки, требования и реальные trade‑off. Но поверх этого ядра он достраивает ещё один слой: умение контейнировать внешний контур, держать управляемый конфликт, переводить инженерную реальность на язык решений и использовать ИИ, как усилитель в сложных разговорах.

Тогда меняется не только стиль коммуникации. Меняется сама реальность роли.

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

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

---

Об авторе и текущих проектах — в профиле на Habr.

Дмитрий Безуглый и Команда Стратегической мастерской. Канал на MAX Мастерская Продуктовой стратегии Безуглого.