Staff+ инженеры: рост без ухода в менеджмент

Алексей представляется сам: несколько лет в компании, работа над архитектурой инвестиционного продукта — по его словам, это «мир в мире», банк внутри банка. Системы высоконагруженные, требуют низкой задержки и высокой надёжности: речь о клиентских деньгах и торговых операциях, потерять их нельзя. Компания росла очень быстро, поэтому архитектурных проблем много — постоянная эволюция из legacy-монолитов в распределённые системы плюс импортозамещение, с которым теперь сталкивается почти каждый. Вместе с сильными инженерами Алексей выстроил процесс принятия и документирования архитектурных решений, а потом вместе с Александром начал переносить его на уровень компании и соседних подразделений. Отсюда и стрим Staff+: разработчик, который ведёт один сервис, не всегда видит ландшафт вокруг и не может подняться выше, а без людей, способных принимать решения большего масштаба, решения выходят хуже.

Александр начинает с матрицы для инженеров, которая появилась примерно с середины 2020 года. Она не про хард-скилы: там не перечислено, какой язык, базу или очередь надо знать, — уровни различаются масштабом, на котором ты работаешь, влиянием на происходящее, сложностью домена, лидерскими навыками и тем, насколько ты улучшаешь работу тех, кто рядом. Большую часть матрицы собрал бывший коллега Андрей Марченко, с которым обещан один из следующих выпусков. Сам Александр раньше считал, что путь упирается в сеньора, а дальше только тимлид: в небольших компаниях инженеры высокого уровня просто не требовались. Здесь он увидел и таких людей, и потребность в них — и картинки западных бигтехов со Staff, principal и distinguished инженерами, а где-то и с должностью инженера уровня вице-президента, обрели смысл. Переходы между ветками участники считают нормальными: наигравшись в менеджмент, можно вернуться в Staff+ уже на большом уровне.

Термин Staff+ закрепил за собой автор книги Staff Engineer; Александр рекомендует и книгу, и сайт с интервью — примерно половину объёма занимают разговоры с такими инженерами о том, чем эти редкие звери занимаются. Дальше идёт классификация, ценная тем, что описывает роли, а не должности. Кто-то сидит в гуще событий и работает как тех-лид направления: улучшает инженерные процессы и надёжность, рефакторит и проектирует сложную систему. Кто-то прыгает между командами и тушит пожары — «супермены», которых зовут, когда остальные не справляются; Александр вспоминает специалиста по оптимизации Java-приложений в Netflix, чьё имя забыл, и пару похожих людей в Яндексе. Архитектор погружается не так глубоко, зато держит ландшафт, кросс-зависимости и договорённости, чтобы горячая картошка не перебрасывалась соседу. Крайний вариант — правая рука руководителя по архитектуре: такую роль, кажется Александру, Алексей и играл в инвестициях. Роли возникают сами, компания их лишь систематизировала — под каждую нашёлся конкретный человек.

Растят ли таких инженеров внутри — вопрос, который задают часто. Растят, но компания растёт быстрее: за три с небольшим года после доклада конца 2020 года клиентов стало втрое больше, внутреннее образование поставляет стажёров и «талантов», и всё равно нужен приток новой крови. Процесс роста устроен так: сотрудник обсуждает с руководителем план по матрице и задачи нужной сложности — скажем, из мидла+ в сеньора за два года; когда он тянет следующий уровень, он заполняет заявку во внутренней системе, где перечисляет, с кем работал и какие артефакты получились, а лидеры профессий из разных стримов решают, дотянулся ли он, и при отказе возвращают фидбек. Если сотрудник приходит уже с офером на тимлида, обычно поздно: что-то пошло не так на уровне его менеджмента. Бывают простые, но критичные для бизнеса проекты, на которых не вырасти, — для тех, кто упёрся в потолок, рядом живёт процесс ротации внутри компании.

Найм с рынка Александр разбирает по слайду про интервью. Техническая часть всегда была «сладкой тройкой»: алгоритмы — в LeetCode оба не видят ничего зазорного и заставляют любить его других, — секция по основному языку, которых в компании почти все, и системный дизайн. Что это такое, Александр напоминает отдельно, потому что вопрос приходил в личку: функциональные и нефункциональные требования, атрибуты качества, публичный API и сценарии через него, концептуальная диаграмма, классы компонентов внутри основного workflow и в конце выбор технологий с расчётом нагрузки — миниатюрная задача на час. Алексей немного спорит: кандидаты, прочитавшие статьи Александра, проходят секцию заметно лучше, но чужой алгоритм без опыта вытягивает разве что на начальный уровень, а задачу всегда можно усложнить. Курирование секции Александр в своё время передал Алексею, и тот сделал её системнее.

Сеньоров, которые не хотят команду, но тянут крупные проекты, раньше отправляли на тимлидскую секцию — от безысходности. Многие сильные инженеры её проваливали: не эмпатичны, не хотят управлять людьми или наелись этим, — и проводившие секцию коллеги сказали, что смысла в этом немного. Наложились и проблемы из доклада 2020 года: сквозные технические решения принимали нетехнические специалисты — «технологи», то есть бизнес-аналитики с функциями проджект-менеджеров; про уже сделанное трудно узнать; целеполагание старых решений не найти; консьюмеры не всегда требовали SLA от провайдеров, а провайдеры не всегда знали, какой SLA дают, и консьюмеры обкладывались костылями, копя техдолг. Так появилась секция «Архитектура и процесс разработки». Алексей уточняет разницу: в менеджменте лидерство — про ресурсы и capacity, в ветке Staff+ — про то, чтобы доказать правоту без формальных полномочий и признать, когда ты неправ. Секция идёт как разговор равных: опыт кандидата, модельные ситуации вроде зависимости от соседних команд со своим бэклогом и вопросы самого кандидата.