Привет! Меня зовут Дима Салахутдинов, я principal-инженер в Купере и автор tg-канала «Стафф-инженер». В первой части статьи я уже рассказывал, какими задачами занимаются стаффы и какие компетенции для этого нужны. Сегодня хочу поговорить о том, как развиваться синьору, чтобы вырости в стаффа. Для того, чтобы написать эту статью я провел 10 интервью со своими коллегами стафф-инженерами — их опыт вместе с моим личным и стали основой этой статьи.

Разберем следующие темы:

• как происходит рост: 3 способа стать staff-инженером;

• с каким трудностями в процессе роста вы столкнетесь;

• рекомендации от staff-инженеров: что делать, куда прокачиваться, чтобы вырасти;

• мотивация от действующих staff-инженеров на карьерный рост.

Давайте начинать!

Путь к staff-инженеру

В этом разделе рассмотрим три пути становления staff-инженером. Хотя внешне, они кажутся различным, их объединяет пара общих моментов:

• наличие солидного опыта;

• успешно реализованные проекты с значимым участием стаффа.

Путь 1: Карьерный рост по инженерному треку

Вы наверняка встречали людей, которые приходят мидлами или джунами, но хотят шире и больше. Их интересует бизнес-эффект, интересует сложное, когда одновременно и глубоко и широко. Они прокачивают техническую экспертизу, вникают в то, как работает бизнес. Постепенно растут, перерастают senior-ных коллег, и на этом не останавливаются — вот тебе готовый кандидат в staff-инженеры. Не хватает только пару-тройку крупных и успешных проектов за спиной, на которых он выложился на все 200% и ярко заявил о себе.

В Купере большинство staff-инженеров — выходцы из senior-разработчиков. История успеха у каждого своя:

• кто-то проработал огромное продуктово-архитектурное изменение и затащил его;

• кто-то залидировал знаковый технический проект и затащил его;

• кто-то закрыл острую проблему бизнеса, и уберег компанию от штрафов/убытков.

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

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

Совершенно нормально, если в команде не будет сложных задач (команда красит кнопки и делает CRUD'ы) — тут стоит рассмотреть вариант ротации в команду, где сложных задач навалом. В компании в целом таких задач и даже более сложных, как правило, вагон. А необходимость в людях, способных их решать, со временем только растет.

Нет задач — не надо их высасывать из пальца. Скорее это skill-issue менеджера, если такое приходится придумывать. Просто сделайте ротацию красиво и по-человечески: заранее поговорите с боссом, чтобы планомерно к этому подготовятся и никого не подвести.

Потеря сеньора (при переходе в стаффа) — это тоже skill-issue менеджера. Обговорить ротацию с руководителем стоит сильно заранее, прояснить все моменты и готовится: выбить деньги на ФОТ, кого-то подрастить.

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

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

Путь 2: Ротироваться из управленческого трека

Это в том числе и моя история в Купере, я расскажу ее от первого лица.

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

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

Я стал тимлидом, собрал классную команду, потом две (сейчас это отдел Ruby-платформы в Купере) и стал юнит лидом (тимлидом тимлидов). Дружным отделом мы затаскивали большие технически-сложные проекты.

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

Отчасти поэтому несколько лет назад я стоял у истоков формулирования (или заимствования у Вилла Ларсона) роли staff-инженер в компании Купер. К тому же компания в тот момент бурно росла и на то был запрос.

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

• чтобы иметь больше влияния (или из-за отсутствия альтернативы) инженер выбирает менеджмент;

• а преисполнившись управленческими делами, понимает, как лучше и масштабней делать инженерную работу, к которой больше лежит душа.

Путь 3: Прийти на позицию staff-инженера

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

Такая история — хороший способ ротироваться в staff-инженера, если достигли потолка в своей компании. В роли юнит-лида я нанимал staff-инженера, и могу ответственно заявить, что такой способ не отменяет наличия у кандидата большого опыта (и достижений) и требования достаточно высоки.

Вместо слов приведу выдержки из требований на вакансию principal-инженера:

• технический эксперт, 7+ лет опыта;

• эксперт в основном технологической стеке, с углубленными знаниями в 2-х или более стеках;

• опыт работы над 10+ производственными проектами и инициативами: техническим дизайном, доказательством концепции (PoC), исследованиями и разработками (R&D), техническим консультированием, участием в проектах с открытым исходным кодом и т.д.;

• опыт полного цикла разработки: от проектирования архитектуры, внедрения, развертывания, до поддержки в производственной среде;

• легко выходит за пределы зоны комфорта для работы с ранее неизвестными инструментами и технологиями;

• опыт работы с множеством технических доменов и технологических стеков;

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

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

Сложности работы staff-инженером

Все staff-инженеры, с которыми мне удалось пообщаться, шли к своей роли (осознанно или нет) через планомерный рост, который невозможен без работы над собой и преодоления трудностей.

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

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

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

Объем коммуникации

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

Или бывает, что для проекта нужно переговорить с сотней человек — идешь и проводишь эти встречи! А может ты до этого был социофобом?

Не переживайте! Проходя такой кризис коммуникаций, учишься справляться со стрессом, тебе постепенно начинает нравится (или начинает тебя устраивает) это количество (и качество) коммуникаций.

2-3 часа общения в день — это норма для стафф-инженера. 4-6 часов — повод заняться оптимизацией встреч (но это может быть временно, пока идет активная стадия проработки проекта).

Помочь могут несколько «гигиенических» правил:

• бронировать в календаре блоки для работы и обеда;

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

Умение работать с календарем стоит отнести к базовой гигиене и жизненно необходимым навыкам работы. Много встреч — уменьшай.

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

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

Качество коммуникации

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

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

• как ты общаешься с коллегами;

• насколько можешь поддержать беседу;

• как формулируешь мысли.

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

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

Выступить медиатором

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

Фокус на договороспособности

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

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

Правильно задать вопрос

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

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

Взаимоотношения с коллегами

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

Сформулировать проблему

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

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

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

Оптимизация работы

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

Таким образом постоянно вырабатываются новые навыки (или чуйка), которые помогают не тратить 3 часа на валидацию и принятие решений, а уместить все в 30 минут.

Ресурсный голод

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

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

Продать решение

Чтобы продвигать технологические улучшения, нужно уметь его «продать», в хорошем смысле этого слова:

• составить техническое обоснование (с метриками);

• просчитать риски и возможные варианты;

• презентовать проект, оказавшись в нужное время в нужном месте.

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

Disagree & Commit

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

Бывает сложно, когда в голове есть «единственный объективно правильный» вариант действий. А команда решила идти в другую сторону.

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

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

Терпимость к неопределенности

Бывает так, что неопределенность гнетет, к примеру, отсутствие функциональных требований к новой фиче.

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

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

Не закапываться

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

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

«Швец и жнец и на дуде игрец»

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

Это точно не конвейер, однотипными операциями не обойтись.

Твой вклад — это не только твой код

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

Очень помогает выписать в каких активностях ты принимал участие и что в них делал.

Не уметь все — это нормально

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

Мы не можем всегда быть всезнающими супергероями. Чтобы понять, как жить с этой мыслью рекомендую прекрасный доклад «Востребованный дизайнер — супергерой?».

Настойчивость и терпение

Представьте большой технический проект (например, «Проект Феникс»). Допустим, у него понятная, очевидная и измеримая польза. Вы его уже «продали» и запустили. Задачи распланированы на полгода вперед. 

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

Вы начинаете работать и с первого дня, что-то идет не по плану и так каждый из 180 дней.

Сгустим краски: что ваш проект — это не новая востребованная фича на миллиард GMV, а внутренние архитектурные изменения (чтобы миллиард не потерять). Которые пользователи даже не заметят. А критерий успеха проекта — «все внутри переделано и ничего не сломалось».

В такой постановке «осталось только сделать» — уже совсем другая история. 

Стафф-инженер иногда лидирует долгосрочные проекты. Работать неделями без видимого результата (и, как следствие, выбросов дофамина) — сложно, лидировать такие проекты — еще сложней.

Как вырасти в стаффа

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

В этом разделе я собрал рекомендации от стафф-инженеров, которые возможно дадут вам направление роста.

Понять бизнес

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

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

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

В этом случае ты можешь вести диалог с продуктом о технических вещах на языке продукта.

Решать проблемы бизнеса

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

Пушить идеи

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

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

Смотреть шире

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

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

Найти проблему и взять задачу

Не ограничивайтесь только теми задачами, которые вам назначает руководитель. В любой компании тонна интересных вызовов за пределами обычной работы: это и активность на уровне архитектурных комитетов и inner-source в платформу и DevRel-активности и многое другое. Даже сам процесс поиска таких задач уже помогает вам расти.

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

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

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

Одного «хочу» тут будет недостаточно. Задача должна решать проблемы бизнеса (смотри предыдущий пункт).

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

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

Кто ясно мыслит, тот ясно излагает. Стафф умеет и то, и другое делать хорошо. Для этого он учится:

• разговаривать;

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

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

Выражению своих мыслей в речи помогает выражение своих мыслей на письме. А предварительная подготовка к любой важной встрече — это 90% успеха!

Само-маркетинг

Немаловажным элементом идет маркетинговая составляющая: если вы сделали что-то крутое, но никто об этом не знает — то вы ничего не сделали.

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

Без маркетинга вы как будто ничего не делали, особенно, если для внешнего наблюдателя задача плохо-презентована и непонятна.

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

Качать project-management

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

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

Нет перфекционизму

Важный навык стаффа — умение пользоваться ограниченными ресурсами (время). Его надо прокачивать очень сильно и заранее, чтобы хоть что-то успевать.

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

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

Стоит оно того? Чем мотивируются staff-инженеры

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

Больший импакт

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

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

Рост в деньгах

Не секрет, что верх сеньорской вилки и низ стаффовой — очень рядом. Но при переходе в эту роль объем прибавки и геморроя может расти непропорционально деньгам. Поэтому точно не стоит, если единственная мотивация у карьерного роста — деньги. Скорее прибавка — это гигиенический фактор (и подтверждение твоей экспертности). 

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

Профилактика выгорания

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

Статусность

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

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

Выводы

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

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

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

А требуемые для этого навыки прокачиваются в процессе, самое главное — захотеть. Желание и инициатива должны исходить от senior-разработчика. 

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

На случай, если вы решили, что оно вам нравится, можете использовать эту статью как kick-start.

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

Но даже если так, скорее всего есть альтернативные варианты роста. И это точно не повод отказываться от своего развития.

Благодарю, что дочитали. Жду ваших вопросов и комментариев!

Дополнительно

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

Почитать

• Двухтомник «System Design Interview», Райнер Роб. 

• «Высоко-нагруженные приложения» (кабанчик), Клеппман Мартин.

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

Чтобы понять и разобраться, чем занимается технический менеджер:

• Проект «Феникс», Джин Ким, Джордж Спаффорд, и Кевин Бер.

• «Elegant Puzzle», Уилл Ларсон.

И еще несколько очень хороших книг:

• «Practical Process Automation», Бернд Рюкер. За практическими знаниями и инструментов эффективной автоматизации бизнес-процессов

• «Современная программная инженерия», Дэвид Фарли.

• «Эволюционная архитектура», Нил Форд, Патрик Куа, Прамод Садаладж, Ребекка Парсонс.

• «Learning DDD», Влад Хононов.

• «Enterprise Integration Patterns», Грегор Хоп и Бобби Вульф.

• «Databases — designing data-intensive applications», Клеппман Мартин.

• «Шаблоны проектирования для облачной среды», Дэвис Корнелия.

Научиться

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

• Курс «Сильная речь», больше сфокусирован на технических нюансах речи, поможет заговорить по-новому.

Зафолловить

• Телеграм-канал Димы Салахутдинова «Стафф инженер: задачи staff/principal-инженера и их решения»

• Телеграм-канал Олега Федоткина «Инженер и менеджер»

• Содержательный цикл статей от Александра Поломодова с выкладками из книги-первоисточника.

Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.