0xc0d3r

Оригинал: A Life Engineered — “7 More Behaviors That Separate Juniors From Seniors”

Источник: https://alifeengineered.substack.com/p/7-more-behaviors-that-separate-juniors?utm_source=perplexity

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

Один разработчик воспринял совет буквально: начал чаще говорить на митингах и писать более длинные письма — с «умными» словами. Документы распухли, стали затрагивать больше тем.

Другой на пару недель притих. Но потом я заметил сдвиг. Он стал начинать письма для руководства с коротких executive summary, где выносил главное и описывал его почти без технических деталей. Документы стали более сфокусированными, но при этом глубокими.

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

Догадываешься, кто есть кто?

В прошлом марте я писал о первых 7 поведениях, которые отличают джунов от сеньоров. Тот текст стал самым расшариваемым в истории рассылки. Если не читал — начни с него.

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

Эти следующие 7 — тоньше. Они меньше про «что ты делаешь» и больше про «как ты думаешь».

• Как ты подстраиваешь коммуникацию под аудиторию.
• Как ты решаешь: это твоя проблема или пора эскалировать.
• Как ты понимаешь, что не нужно строить.

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

Если ты читал Nobody Cares How Hard You Work, ты знаешь: одного усилия недостаточно.

Эта статья — про конкретные поведения, которые действительно двигают карьеру.

1) Коммуницируй «на нужной высоте» (знай аудиторию)

Большинство людей общаются в одном режиме: объясняют техническое решение одинаково и продакту, и инженеру. Пишут одно и то же сообщение дизайнеру и человеку из ops.

Когда ты закапываешь продакта в детали имплементации, он не думает «Вау, какой тщательный». Он думает: «Я вообще не понимаю, мы в сроках или нет».

Когда ты говоришь дизайнеру «Технически невозможно», но не объясняешь ограничения языком пользовательского опыта — ты закрываешь сотрудничество, а не помогаешь ему.

И наоборот: если коллегe‑инженеру ты даёшь слишком общий, «воздушный» пересказ без глубины — он решит, что ты сам не понимаешь работу.

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

Перед разговором или документом спроси себя: для кого это и что этому человеку нужно от меня?

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

Второй инженер из истории во вступлении это понял. Он не просто «стал лучше коммуницировать». Он начал упаковывать одну и ту же информацию по‑разному: executive summary для руководства, человеческие trade‑offs для продуктовых партнёров и детальные разборы для команды.

Главное правило коммуникации: знай аудиторию.

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

2) Закрывай “open loops”

Вот что разрушит твою репутацию, если позволить этому случаться: незакрытые хвосты.

• Ты сказал менеджеру, что «посмотришь», и не вернулся.
• Коллега спросил в Slack, ты увидел, хотел ответить позже — и забыл.
• Тебя попросили поревьюить документ: ты пробежался глазами, но так и не оставил комментарии.

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

Джуны начинают. Сеньоры заканчивают. А если не могут закончить прямо сейчас — они всё равно закрывают цикл коммуникацией:

«Я посмотрел, пока нет ответа, но будет к четвергу».

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

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

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

3) Определи “Done” до первой строчки кода

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

И дальше обычно происходит одно из трёх:

• ты шипишь то, что работает, но не решает проблему;
• ты продолжаешь строить, потому что не определил, когда остановиться;
• ты приносишь результат, а менеджер говорит: «Я имел в виду другое» — и выясняется, что вы не согласовали, как выглядит «хорошо».

Сеньоры делают вещь, которая кажется замедлением, но на деле ускоряет всё: они определяют “done” заранее.

• Как выглядит успех?
• Что в скоупе, а что явно вне?
• Как мы поймём, что это сработало?
• Кто должен согласовать?

Это не обязательно должен быть длинный документ. Иногда достаточно трёх буллетов в Slack. Важен не формат, а то, что у тебя и у того, кто поставил задачу, одна картинка в голове до старта.

Как я писал в 5 Simple Ways to Impress Your Boss, худший кошмар менеджера — сюрпризы. “Done” заранее убирает большинство из них.

Быстрый выигрыш: перед следующей задачей не пиши ни строчки кода, пока не сможешь чётко сформулировать, как выглядит финальный продукт. Запиши это и покажи тому, кто дал задачу.

4) Думай на два хода вперёд (second‑order thinking)

Джуны говорят: «Это, наверное, сработает». Сеньоры спрашивают: «А потом что?»

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

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

• не убьёт ли это стимул писать более надёжный софт?
• не станет ли саппорт‑инженер бутылочным горлышком?
• не превратится ли временная боль в постоянную ставку?

Ответ всё ещё может быть «нанимаем». Но сеньор прогоняет последствия до решения, а не после.

Это везде: один подход быстрее сейчас, но привязывает к вендору. Другой дольше, но сохраняет свободу. Джун выберет быстрый из‑за дедлайна на следующую пятницу. Сеньор взвесит, что будет через 6 месяцев, когда бизнес захочет сменить вендора, а вы построили зависимость, которую не размотать.

Как качать мышцу: перед решением делай паузу и спрашивай:

«Что это сделает проще, а что — сложнее?»

Прокрути сценарий на 1–2 шага вперёд.

Быстрый выигрыш: когда предлагаешь решение на встрече/в документе, добавь секцию «риски и second‑order эффекты» — даже 2–3 предложения.

5) Эскалируй вовремя (и правильно)

Многие ошибаются с эскалацией в обе стороны.

Слишком рано: любая преграда — сразу сообщение менеджеру. Человек не попытался разобраться, не собрал контекст, не продумал варианты. По сути он просит менеджера думать за него. Это быстро сжигает доверие.

Слишком поздно: человек сидит на проблеме днями/неделями, убеждая себя, что разберётся, а ущерб растёт. Когда он наконец сообщает, это уже кризис. Реакция менеджера — не «спасибо, что сказал», а «почему я узнаю это сейчас?»

Сеньоры находят линию между этими крайностями. Эскалация — не слабость, а judgement call. Вопрос не «я справлюсь?», а:

«Я ли подходящий человек, чтобы решать это? И сейчас ли подходящее время?»

Фреймворк автора (из опыта в Amazon): эскалируй, если верно хоть одно:

• проблема требует полномочий/доступа, которых у тебя нет;
• решение влияет на команды/таймлайны за пределами твоего скоупа;
• ты застрял больше дня без ясного пути вперёд;
• цена ошибки настолько высока, что кто‑то ещё должен быть в курсе.

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

• вот ситуация,
• вот что я попробовал,
• вот варианты,
• вот моя рекомендация.

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

Быстрый выигрыш: вспомни последнюю проблему, на которой ты сидел слишком долго. Какой сигнал ты пропустил, что пора было эскалировать? А теперь — последнюю эскалацию, которую, вероятно, мог закрыть сам. Твоя «золотая середина» где‑то между ними.

6) Оптимизируйся не на скорость, а на «скорость с направлением» (velocity)

Джуны оптимизируют скорость: быстрее закрыть тикет, быстрее «показать output». Кажется продуктивным: менеджер видит движение, доска едет.

Но скорость без направления — это просто движение.

Velocity — это скорость с направлением: то, что ты делаешь сегодня, должно накапливаться в ценность завтра.

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

В моменте это не выглядит продуктивно. Тесты не так «приятны», как шипинг. Сказать «не будем строить» не так весело, как сказать «я построил».

Но сеньоры (обычно болезненно) понимают: самые быстрые команды — не те, кто пишет больше кода. А те, кто пишет правильный код.

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

7) Будь проактивным: предотвращай пожары

Джуны реактивны. Появилась проблема — бегут тушить. Пришёл вопрос от руководства — срочно ищут ответ. Сломалась зависимость — выходные на восстановление.

Сеньоры видят такие вещи заранее. Не потому что они ясновидящие, а потому что у них есть привычки раннего предупреждения:

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

И тут всё начинает складываться. Если ты коммуницируешь на нужной «высоте» — стейкхолдеры не удивляются. Если закрываешь циклы — ничего не загнивает. Если определил “done” — нет финальной неоднозначности.

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

Быстрый выигрыш: выбери один проект, над которым работаешь сейчас. Запиши 3 вещи, которые могут пойти не так в ближайшие две недели. Для каждой — что ты можешь сделать на этой неделе, чтобы снизить риск.

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

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

Хорошая новость: этому можно научиться. Каждый сеньор‑инженер, с кем я работал (включая меня), развивал эти навыки осознанно. Никто не рождается с пониманием «когда эскалировать» или «как читать комнату». Учишься, когда делаешь неправильно, замечаешь, что случилось, и корректируешь.

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

Попробуй неделю. Посмотри, что изменится.

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