Кто ты такой мифический Staff инженер?

 Публичный пост

Привет,

я столкнулся с проблемой, что в постсоветском пространстве совсем неразвита лестница Staff инженеров, т.е Senior+.

Долгие годы я считал, что карьера инженера выгляди примерно так:

Jun - Mid -Senior - Lead - ???. Дальше если повезет могут быть вариации в виде Архитектора и СТО.

Если отбросить то, что Lead это не уровень, а роль (привет 23-летним лидам), то как прыгнуть от senior к CTO? Для меня это всегда было непонятно и казалось делом случая.

Недавно моя картина мира перевернулась, я открыл для себя, что после 40 после senior уровня, техническое развитие только начинается.

Год назад я попал в большой американский продукт с ~3k сотрудников. Так как я уже был матерым сеньор разработчиком с 10+ лет опыта, после полугода работы я освоился и начал разбираться, как же расти выше в такой кампании.

Staff ветка развития

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

Staff - Sr. Staff - Principle

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

  • articulate business strategy
  • Leadership
  • influence on developers
  • и т.д

Мой лид посоветовал для начала прочитать книгу Staff Engineer: Leadership beyond the management track.

Как в хорошей технической книге там много воды. Но она дала мне фундаментальное представление кто такие Staff инженеры и в чем их отличие от Jun - Senior ветки.

Что я узнал из книги

  1. Staff уровень это уже не только про технический часть продукта, это больше про людей и про бизнес.
  2. Нужно менять свое мышление. Senior решает технические задачи наиболее интересным ему способом. Staff же должен заботиться и о бизнес интересах.
  3. Раньше ты забирал себе все лакомые кусочки в разработке, а сейчас ты должен отдавать их своей команде, чтоб они могли пройти твой путь. Быть трамплином для своей команды.
  4. И как ни странно, дальше менторство, построения нетворкинга с коллегами, и брания ответсвенностей

Мои выводы

  • Как ни странно, нам мой взгляд всему ключом являются банальные софт скилы. Не будь придурком, учи других, смотри чуть дальше зоны своей ответственности.
  • Нравится ли мне как выглядит американская staff культура? Я не уверен. На мой взгляд, карабкаясь по такой лестнице, сложно держать work-life balance. Очень чувствуется, что все это растет из американской культуры, где работа эта жизнь.
  • Тем не менее жаль, что что на постсоветском пространстве у инженеров не развивают качества нужные для Staff уровня или не акцентируют на них внимание.
  • Если хочешь рости в большом американском техе, придется ломать свой менталитет.

Есть такой бородатый анекдот:

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

Так вот на staff уровне она все-таки твоя.

P.S.

Поделитесь, пожалуйста, в комментах:

  1. Как вы проходили свой путь до Staff инженера.
  2. Есть ли в вашей кампании альтернативная Senior+ ветка развития?

Всем мир!

31 комментарий 👇

В EPAMе есть такие, я как раз один из них. Если упростить, мы это определяем как technical leadership, тех лид на стероидах.

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

В маленьких проектах это с переменным успехом делает лид команды и/или самый сениорный сениор, но в крупных программах с кучей команд и стримов им зачастую не хватает тех самых софтскилов, взрослости, "насмотренности" разных проектов и постмортемов.

В среднем у меня 60% времени уходит на коллаборацию в проекте (среднее за полгода, у меня бывают недели где я практически не вылезаю из IDE и недели где я не делаю ни одного коммита). Я делаю ревью и челленджу тех дизайны и их имплементацию, выступаю SME который может заметить узкое место или подсказать как обойти проблему, являюсь арбитром при спорах об имплементации.

Важная часть работы - я периодически говорю стейкхолдерам "у вас глупые требования". Пример из жизни: есть данные в базе, одна из колонок зашифрована "client side", приходит требование иметь возможность сортировать во фронте таблицу по этой колонке. Лид расстраивается но не видит другого пути как получить и расшифровать все данные (сотни тысяч) на клиент (веб) и там делать сортировку и пажинацию (хаха), менеджер давит потому что срочно. Одному неуютно спорить с клиентом (да еще и клиент всегда прав на галере), второй очень эффективен и ему просто срать. При разговоре с заказчиком выяснилось что данные вбивают люди, и фича нужна чтобы визуально проверять эти данные на опечатки вида "лишний нолик вбили" (они так привыкли делать в экселе:), предложил делать это на этапе ввода данных в лоб сравнивая это с заранее расчитанным условным "средним по больнице" и получил в ответ "а что так можно? да конечно!"

Остаток времени я читаю и пишу код, половина этого кода это "production" чтобы не терять бизнес контекст, другая половина это в основном reusable code, или люди везде повторили один и тот же шаблон и есть смысл сделать более DRY или мы начинаем адоптать новый сервис-технологию и нужен начальный набор абстракций для нее. Так же я лидаю/сам делаю R&D spikes, когда мы пробуем новые странные штуки.

UPD: я не ответил на второй вопрос, как же я до этого докатился?

Моя карьера до EPAM состояла из длительной череды 1-2 летних "проектов" в разных областях и ролях. Я был (зачастую совмещая) сисадмином, разработчиком, QA, менеджером, архитектором. Это дало мне прекрасный бэкграунд для консультанта, но юношеский максимализм и перфекционизм не дали мне туда улететь, я все еще предпочитал сначала все придумать а потом сам же сделать. Я довольно долго боролся с собой чтобы научиться отпустить и дать другим людям сделать часть работы :)

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

Поняв что летать так много я не хочу и не могу, я "дауншифтнулся" в инженера, однако как individual contributor я был откровенно overqualified и too expensive для почти всех проектов кроме самых унылых огромных enterprise махин, да и шило в жопе мешало, так я стал инжнером сразу в нескольких проектах и функциональные обязанности естественным образом сдвинулись в сторону collaboration/enablement и я даже нашел единомышленников которые занимались схожей работой. Когда решили формализовать этот "staff" трек (официально ему в EPAM 2 года), я возглавил одну из специализаций.

  Развернуть 1 комментарий

@z7oVrp8oKLzP700a,

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

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

  Развернуть 1 комментарий

@inkoit,

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

В моем описании можно заметить что моя роль пересекается с архитектурной и это так by design.

В EPAM есть еще роль "Delivery Manager" которые те самые менеджеры с инженерным прошлым о которых тут говорили, у них другие KPI и задачи и чаще всего там или менеджеры не очень или программисты плохие, но роль определена так что они могут выполнять (и правда выполняют) часть этой функции.

Архитекторы же у нас бывают разные, я для себя их разделяю на "наседок" "кукушек" и "чаек":

  • "Наседки" чаще всего остаются с проектом и делают governance, следят за тем что арихтектура действительно соответствует требованиям, эволюционируют ее и всякически о ней заботятся. Таких по моем ощущениям большинство, они сильно более технические.
  • "Кукушки" больше консультанты - прилетели, отложили "яйцо", полетели дальше в новое гнездо, а проектная команда остается растить птенца. (Это нормально, ведь держать архитектора на small team довольно дорого, не всегда есть бюджет да и архитекторов столько нет. В компании даже есть как-то формализованный сервис где можно попросить на время архитектора который сделает review и предложит изменения.) Такие ребята естественным образом отрываются от "земли" и далеко не всегда знают что же случилось с их дизайном в проде.
  • "Чайки" это почти как "кукушки", только не яйца отклывают, и часто лучше бы они совсем не прилетали, так же как "чайка-менеджеры"
  Развернуть 1 комментарий

@z7oVrp8oKLzP700a, понял, спасибо!

  Развернуть 1 комментарий

@z7oVrp8oKLzP700a, Интересно б было послушать про работу "кукушек". Сталкиваются ли они с предвзятостью со стороны команды оунеров проекта. Или у них есть право вета, т.к они все-таки архитекторы.

  Развернуть 1 комментарий

@DenisMarusevich, классификация моя личная, официально не существует, с мнением компании не соответствует и т.д. :)

В большинстве случаев оунеры проекта понимают кто им нужен и зачем и стараются выбрать правильного человека, но с учетом масштаба организации это далеко не всегда возможно, поэтому бывают всякие ситуации когда клиент разносит "кукушку/чайку" вопросами про day 2 operations их решения и тогда зовут pinch hitter спасать ситуацию.

Большие бизнесовые ребята которые имеют портфолио клиентов и проектов обычно имеют "своих" архитекторов (и "наседок" и "кукушек") и D8 которых они зовут в свои новые пре-сейлы и проекты (или ротируют между ними) чтобы все прошло хорошо.

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

  Развернуть 1 комментарий

@z7oVrp8oKLzP700a, кто такой D8?

  Развернуть 1 комментарий
🕵️ Юзер скрыл свои комментарии от публичного просмотра...

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

  Развернуть 1 комментарий
Вастрик Блогер, питонист, мизантроп 5 апреля 2023

У The Pragmatic Engineer был выпуск тоже об этом. В принципе там то же самое рассказывают, да https://newsletter.pragmaticengineer.com/p/the-staff-engineers-path

  Развернуть 1 комментарий

@vas3k, и в догонку бложек и книга https://staffeng.com/
этот же чел написал менеджерскую Elegant Puzzle, если выбрали путь манагера

  Развернуть 1 комментарий

Staff Engineer'ы очень разные. Накидаю сухих субъективных мыслей про архитекторов.

  1. Современный архитектор разительно отличается от архитекторов 70х годов. Тогда экспертиза в технологиях/инструментах была сосредоточена в узкой касте специалистов. Вокруг всего этого была некоторая элитарность, попробовать всем технику тогда нельзя было - дорого. Фраза: "Я архитектор, мне виднее, будем делать так" должна уйти из майндсета современного стаффа напрочь (см. Ivory Tower Architect)
  2. Архитекторы не должны быть исключены из feedback loops продукта (желательно "выходить в поля", и осязаемо видеть последствия своих действий)
  3. Архитектор должен энейблить разработчиков, а не создавать им констрейнты
  4. Архитектор должен смотреть не только на дизайн систем, но и на сам процесс создания софта. Современный архитектор должен руководствоваться TTM и developers' satisfaction
  5. Управлять сложностью, integrity и прочими NFRs

Современный стафф инженер - он не про знание кучи баззвордов, он про хорошее понимание фундаментальных принципов. Обычно нет проблем с "не знаю про паттерн/whatever", есть проблема с "знаю про микросервисы/гексагональную архитектуру и хочу все это применить, ведь в GreatCompany это сработало". Зачастую мы начинаем не с problem space: "а есть ли у нас проблема?", а с solution space: "Netflix использует микросервисы, значит и нам они нужны".

К примеру, среднестатистического инженера (myself included) очень легко впечатлить луковой/гексагональной архитектурой. Это что-то прекрасное. Слои, отдельный бизнес домен, базу поменять по одному клику можем (на самом деле не можем)... По итогу мы получаем репозитории с переусложненной структурой. Любое изменение заставляет вас пройти через 5-10 слоев абстракции. Когнитивная сложность проекта достигает критических масштабов, TTM деградирует. А ведь под всеми этими луковыми архитектурами лежит фундаментальный принцип - Inversion of Control, который можно использовать без всех этих папочек /adapters/ports/in/out :). Одна из задач стаффа - смотреть на problem space в первую очередь, и не допускать повышение когнитивной сложности ради очередного базз ворда.

Как вы проходили свой путь до Staff инженера.

Сделал пару company-wide проектов, повлиял на TTM нескольких продуктов. В целом, собирал боли разработчиков/команд и решал их.

  Развернуть 1 комментарий

@zakirullin, лол, так я оказывается стафф инженер

  Развернуть 1 комментарий

@urtow, у тебя и в профиле: "разработчик-архитектор", конфликта нет, значит :)

  Развернуть 1 комментарий

@zakirullin, я просто подобрал ближайшее, что понимал. А вон оно как называется оказывается :))

  Развернуть 1 комментарий
Dmitriy Rozhkov Distinguished Notion API Consultant 20 апреля 2023

Егор и я тут поразгоняли на тему стаффов и инфляции должностей

  Развернуть 1 комментарий

Я работал работал в компании, был просто Девопс Лидом. Но в какой то момент, у нас стали вводить уровни и понеслось....
Я себя оценил по шкале, которую сам же и расписал для своей команды, что мой уровень Staff. Просто потому что уровень вовлечённости в проекты и жизнь компании был довольно широк и размах ответственности тоже. Руководство не согласилось и сделало меня Principal, я не возражал, но удивился.
Что я делал:

  • Определение политики партии внутри команды: внутренние технические правила. Dos and don'ts. По сути: выбор инструментов, способ обоснования введения новых инструментов ну и последний фронтир перед решением
  • Обозначение больших проблем и куда надо стремиться
  • Несколько своих проектов, где я был больше вовлечён и остальные где участвовал как консультант или просто был в курсе дел.
  • Изучение новых технологий
  • Работа с менеджментом
  • Работа с другими командами, чтобы понять их боль и скорректировать наши планы

альтернативы Senior+ не было

  Развернуть 1 комментарий
Egor Suvorov Программист/преподаватель C++ 4 апреля 2023

Так это же уже не инженер, это менеджер с инженерным бэкграундом? Равно как и Lead, и CTO. Вообще другой набор навыков нужен, мне кажется, и не надо делать из хороших программистов плохих управленцев (или наоборот).

  Развернуть 1 комментарий

@yeputons,

менеджер с инженерным бэкграундом

не обязательно. там тоже есть разные архетипы, вот хорошая статья про это: https://lethain.com/staff-engineer-archetypes/

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

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб