Кто ты такой мифический 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 ветки.
Что я узнал из книги
- Staff уровень это уже не только про технический часть продукта, это больше про людей и про бизнес.
- Нужно менять свое мышление. Senior решает технические задачи наиболее интересным ему способом. Staff же должен заботиться и о бизнес интересах.
- Раньше ты забирал себе все лакомые кусочки в разработке, а сейчас ты должен отдавать их своей команде, чтоб они могли пройти твой путь. Быть трамплином для своей команды.
- И как ни странно, дальше менторство, построения нетворкинга с коллегами, и брания ответсвенностей
Мои выводы
- Как ни странно, нам мой взгляд всему ключом являются банальные софт скилы. Не будь придурком, учи других, смотри чуть дальше зоны своей ответственности.
- Нравится ли мне как выглядит американская staff культура? Я не уверен. На мой взгляд, карабкаясь по такой лестнице, сложно держать work-life balance. Очень чувствуется, что все это растет из американской культуры, где работа эта жизнь.
- Тем не менее жаль, что что на постсоветском пространстве у инженеров не развивают качества нужные для Staff уровня или не акцентируют на них внимание.
- Если хочешь рости в большом американском техе, придется ломать свой менталитет.
Есть такой бородатый анекдот:
- А ты ведь не медик, а где так хорошо научился делать уколы?
- А меня один знакомый доктор научил: он сказал, тут главное помнить, что жопа не твоя..
Так вот на staff уровне она все-таки твоя.
P.S.
Поделитесь, пожалуйста, в комментах:
- Как вы проходили свой путь до Staff инженера.
- Есть ли в вашей кампании альтернативная Senior+ ветка развития?
Всем мир!
В 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 года), я возглавил одну из специализаций.
А можно для тех, у кого нет абстрактного мышления, пример какой-нибудь задачи, которую ты решал и того, что именно надо было делать как стаффу?
Сложная роль, нужно быть и менеджером и контрибьютором, причем и там и там надо быть топом. За этим идет багаж проблем, например, авторитета как у менеджера не так много, в плане говорить людям что и как делать, но и как разработчик сказать, что я пишу что мне скажут, отстань от меня, тоже нельзя.
Работал на такой роли в бигтехе, надо как то собраться написать по подробнее, если интересно.
У The Pragmatic Engineer был выпуск тоже об этом. В принципе там то же самое рассказывают, да https://newsletter.pragmaticengineer.com/p/the-staff-engineers-path
Staff Engineer'ы очень разные. Накидаю сухих субъективных мыслей про архитекторов.
Современный стафф инженер - он не про знание кучи баззвордов, он про хорошее понимание фундаментальных принципов. Обычно нет проблем с "не знаю про паттерн/whatever", есть проблема с "знаю про микросервисы/гексагональную архитектуру и хочу все это применить, ведь в GreatCompany это сработало". Зачастую мы начинаем не с problem space: "а есть ли у нас проблема?", а с solution space: "Netflix использует микросервисы, значит и нам они нужны".
К примеру, среднестатистического инженера (myself included) очень легко впечатлить луковой/гексагональной архитектурой. Это что-то прекрасное. Слои, отдельный бизнес домен, базу поменять по одному клику можем (на самом деле не можем)... По итогу мы получаем репозитории с переусложненной структурой. Любое изменение заставляет вас пройти через 5-10 слоев абстракции. Когнитивная сложность проекта достигает критических масштабов, TTM деградирует. А ведь под всеми этими луковыми архитектурами лежит фундаментальный принцип -
Inversion of Control, который можно использовать без всех этих папочек/adapters/ports/in/out:). Одна из задач стаффа - смотреть на problem space в первую очередь, и не допускать повышение когнитивной сложности ради очередного базз ворда.Сделал пару company-wide проектов, повлиял на TTM нескольких продуктов. В целом, собирал боли разработчиков/команд и решал их.
Егор и я тут поразгоняли на тему стаффов и инфляции должностей
Я работал работал в компании, был просто Девопс Лидом. Но в какой то момент, у нас стали вводить уровни и понеслось....
Я себя оценил по шкале, которую сам же и расписал для своей команды, что мой уровень Staff. Просто потому что уровень вовлечённости в проекты и жизнь компании был довольно широк и размах ответственности тоже. Руководство не согласилось и сделало меня Principal, я не возражал, но удивился.
Что я делал:
альтернативы Senior+ не было
Так это же уже не инженер, это менеджер с инженерным бэкграундом? Равно как и Lead, и CTO. Вообще другой набор навыков нужен, мне кажется, и не надо делать из хороших программистов плохих управленцев (или наоборот).