«Давай ты будешь лидить». Куда расти сеньору и надо ли — объясняет Павел Вейник
Стеклянный потолок — метафора не только про зарплату разработчика, но и про его скиллы. Куда расти ИТ-инженеру, если он уже крепкий сеньор и точно ли надо куда-то двигаться?
Пообщались с архитектором-фаундером в Hard&Soft Skills Павлом Вейником.
Кто такой сеньор
Давайте определимся с понятием «сеньор». В моём понимании это «опытный дядька», который способен выполнить самую или почти самую сложную задачу на проекте. Он способен пообщаться с постановщиком задач, спроектировать и довести задачу до продакшн, покрыть её тестами и т. д.
Что он делает
Если мидл выполняет только кусочек задачи, то сеньор, как правило, отвечает за задачу целиком. Это-то и делает его сеньором.
Ещё сеньор может менторить, делиться опытом, но главное — он в состоянии выполнить сложную задачу в рамках системы. Он понимает цель проекта, архитектурные приёмы, знает контекст системы и исходя из этого принимает решения.
Чего не делает
Сеньор не распределяет задачи и не проектирует всю систему — только небольшие её компоненты. Он, как правило, не ведёт коммуникации с бизнесом, зона общения сеньора — тимлид, продакт оунер, аналитик, команда.
Надо ли ему расти?
Вообще-то необязательно.
Если мидл не растёт, есть вероятность, что в компании захотят от него избавиться. С сеньором не так. Его роль может оказаться финальной в карьере просто потому, что всё и так прекрасно.
Но что если развиваться всё-таки хочется
Тогда у сеньора есть два пути:
- Менеджерский: тимлид — инжиниринг-менеджер — руководитель отдела — руководитель направления и т. д.
- Технический: сеньор — условный техлид/very important разработчик/кто-то такой (технарь ещё более сильный, чем сеньор, но всё ещё занимающийся по большей части кодом) — архитектор — СТО.
Что не так с карьерой менеджера
Часто инженеры думают, что раз они успешно работают в команде, то запросто могут ею управлять. Я про кейсы, когда молодые амбициозные сеньоры, желая стать важными людьми, берутся за роль тимлида и за год выгорают — таких я видел много. Если у неопытного тимлида без управленческих скиллов что-то получается по наитию, значит, ему крупно повезло.
Проблема в том, что у разработчика нет ни менеджерского опыта, ни понимания, что такое менеджмент в принципе. Ведь в тимлиде половина от сеньора, половина от менеджера. И навыки, необходимые тимлиду, находятся в квадрате неосознаваемого неизвестного.
Поэтому если на работе вам сказали «давай ты будешь лидить», к этому стоит отнестись осторожно: вам добавляют радикально новые обязанности без прибавки в зарплате. Зарплаты у тимлидов и сеньоров обычно одинаковые.
Но если у вас хорошо получается управлять и команда растёт, то из тимлида можно вырасти в Engineering manager и руководить уже несколькими командами, обеспечивая их синхронизацию, мотивацию и т. д. По этой стезе можно расти довольно долго.
Правда есть нюанс. Если человек дорос до сеньора, значит, у него нормальные инженерные способности. Выбирая менеджерскую ветку, он ступает на новый карьерный путь, отказываясь от роста в техническом плане. Осознанно такой выбор делают немногие.
Почему техническая ветка привлекательнее (субъективно)
Большинство сеньоров выбирают другую ветку — технического развития. У неё как минимум два преимущества. Во-первых, она скорее всего соответствует уже имеющейся профдеформации характера сеньора. Во-вторых, сильные инженеры получают заметно больше инженеров-менеджеров.
На уровне СТО в больших компаниях или второго после СТО топа зарплата менеджера может сравняться с зарплатой сильного технаря (или превысить), но в большинстве случаев технарь выигрывает.
На техническую ветку часто возвращаются и те, кто попробовал себя тимлидом и понял, что это не его. Часто на этом этапе сеньор ещё не понимает, куда и как расти. Тимлидства ему больше не хочется: деньги те же, геморроя больше, интереса меньше. Но душа чего-то просит: более сложных задач, денег, интересных проектов.
До сих пор сеньор рос, изучая технологии, базы данных, фреймворки для проектов. И вот он понимает, что можно изучить еще пять фреймворков, три базы данных, попользоваться ещё одним клаудом, но содержание и смысл работы это никак не изменит. Так возникает стеклянный потолок — прежде всего скилловый. Ведь скиллы за счёт освоения новых технологий вообще-то не растут — они остаются теми же, просто применяются к другим вещам.
Как взлететь выше потолка
Потолок можно преодолеть, взяв на себя больше ответственности. Допустим, задрайвить какую-то большую кросс-командную фичу.
Менеджер такие вещи драйвить не может: они требуют больших технических знаний. Инженер же ставит цель, согласовывает её с менеджерами и дальше общается с лидами и сеньорами из нужных команд. Он выясняет детали, ограничения, ищет обходные варианты, делает проектирование.
Если решение начинают реализовывать, такому «большому и толстому» сеньору могут выделить Program Manager, который будет следить за тем, чтобы разные аспекты фичи были слиты воедино.
Так сеньор ради интересов бизнеса выходит за границы своей команды и превращается в техлида/Staff Engineer/Principal Engineer/Very Important Engineer. И дальше развитие идёт в сторону Software Architect, Solution Architect — вплоть до СТО.
Коммуникация
На этом пути инженеру необходимо общаться, коммуникация в его работе занимает больше времени, чем технические решения. Причём коммуникация не менеджерская, а техническая. И чем дальше сеньор будет продвигаться по техническому пути развития, тем больше у него будет коммуникации, как это ни парадоксально.
Важная часть софт-скиллов такого специалиста — увеличивать импакт, изменять организацию или систему, в которой он работает. Он берёт на себя ответственность и за счет своей энергии двигает какие-то фичи.
Импакт, желание драйвить изменения — крайне важная вещь. Этим условный техлид отличается от очень умного сеньора, который сидит спокойно и решает свои задачи.
Кругозор
Кроме коммуникации техлиду нужны новые архитектурные навыки — системный дизайн и инструменты: базы данных, очереди, кэши, балансировщики. Он должен понимать, как связать разные части системы, чтобы она и работала, и поддерживалась. К важным скиллам относится и работа с большой нагрузкой, потому что такие задачи, как правило, возникают на больших системах.
Причём техлид должен не изучать базу данных или фреймворк досконально, а представлять, какие вообще есть инструменты, технологические приёмы, шаблоны, ограничения разных подходов. Его задача — правильно выбрать инструменты, а команды уже изучат (если ещё нет) их детально.
Сеньор выбирает знакомую базу данных или фреймворк, потому что ему так комфортно. Ему кажется, что обычная реляционная база данных сгодится, хотя на самом деле колоночная или Key-value подойдёт лучше. Но он об этом не знает, ведь опыт даже самого сильного сеньора редко превышает знание 5-7 баз данных, включая облачные.
Задача техлида — сделать оптимальный выбор технологий. И здесь происходит радикальное улучшение за счёт кругозора. Ведь нужно отойти от собственного опыта в сторону опыта индустрии. Нужно знать, какие базы данных вообще существуют (их примерно 400), как они разделяются по типам и для каких задач каждый тип предназначен.
Ещё — всевозможные in memory кэши, балансировщики, сервисы, основанные на DNS-инфраструктуре, системы для распределённой обработки и хранения данных, инфраструктурные решения для балансировки и эластичности, шаблоны проектирования распределённых систем, подходы, которые работают с консистентностью данных. Эти вещи нужно изучать целенаправленно и заранее.
Что расширяет кругозор? Чтение статей, книг, обсуждение Building Data Intensive Applications, сайты Мартина Клеппмана и Мартина Фаулера, Reddit в конце концов. Но важна структура этих знаний. Не просто «я знаю 250 терминов, давайте применим случайные из них» — надо понимать ограничения каждого подхода, как масштабировать систему и сделать из нее BASE (Basically Available, Soft state, Eventually consistent).
Когда сеньор за счёт софт-скиллов и кругозора перескакивает на уровень техлида/Staff Engineer, у него открываются возможности расти дальше, на уровень Solution Architect.
Solution Architect
Solution Architect — это человек, который понимает бизнес. Он может поговорить с бизнесом на его языке, потом за счёт понимания архитектуры распределённых систем преобразовать этот разговор в технические задачи, создать design проектa (или препоручить его) и, наконец, объяснить всё команде.
Масштаб задач у него больше, чем у техлида. Если техлид работает с большими кусками системы, то Solution Architect проектирует систему целиком. Его работа итеративна. Ему требуются и навыки коммуникации, и stakeholder management, и управление требованиями, и system design, и умение обосновать выбор решения.
Solution Architect может расти, предлагая всё более масштабные решения для бизнеса. Вот он уже делает не просто корпоративную систему на 250 пользователей, а SAAS-сервис на 250 запросов в секунду, и эта система мирового масштаба.
Далее возможен рост в технологическую стратегию всей компании. Архитектор понимает, что его система через три года будет вот такой, поэтому закладывает такие-то возможности, согласовывая их с целями, приоритетами и рисками бизнеса.
Тут он подбирается к роли Chief Information Officer или Chief Technical Officer. Для неё нужны не только кругозор и умение обосновывать оптимальный выбор, но и умение работать в больших организациях.
В кого ещё может вырасти сеньор
Он может стать просто очень сильным сеньором, distinguished инженером, познав какие-то вещи до глубин, например, за сколько миллисекунд даёт отклик Amazon ElastiCache и как это можно использовать. При этом он остаётся сеньором, так как не волочет какие-то изменения в рамках компании, а просто круто реализует сложные вещи.
Иногда я выделяю еще одну разновидность сеньора на пути к техлиду — Software Architect. Он похож на distinguished инженера, так же глубоко знает технологию, при этом ещё и проектирует архитектуру небольшой задачи.
Как провести грань
На практике границы между статусами стёрты. В разных компаниях под одним и тем же тайтлом подразумевают разное. Мы можем называться сеньором, а выполнять функции архитектора. Или называться Staff Engineer, а на самом деле быть сеньором. Тимлид может одновременно быть и менеджером, и архитектором, и сеньором, и бизнес-аналитиком. Такое тоже бывает. Но на пути от сеньора к техлиду есть принципиальный скачок. И важен не термин, а принципиальные отличия между ролями.
В каких компаниях лучше расти и как
Любой сеньор при наличии амбиций может развиваться самостоятельно, занимаясь самообразованием и проявляя инициативу. Но не у всякой компании есть нужда в архитектурных решениях. Тогда нужно искать компании, где нужда есть, а архитектора ещё нет, или же расти вместе с компанией.
Техлид, который может нарисовать архитектуру небольшой задачи/системы, нужен как правило уже в одной команде. Даже если он называется тимлидом или сеньором, по сути, он выполняет роль архитектора маленькой системы.
В компании с 3-5 командами должен выделиться сильный техлид или архитектор, который будет прорисовывать архитектуру.
В компании на 50+ человек без архитектора обойтись уже сложно. Если сотрудников уже 150+, то среди архитекторов выделяются сильные Staff Engineers. В компании на 500-800+ человек возможно несколько уровней архитекторов:
- отвечающие за свой компонент системы;
- помогающие реализовывать большие фичи;
- общий архитектор (больше про стратегию, чем про реализацию и system design);
- сильные сеньоры, которые делают архитектуру не очень больших фичей.
Продуктовый бизнес, пришедший не из ИТ, часто считает, что архитекторы — это просто дядьки, которые кушают деньги. Я не раз видел такое отношение: ой, пусть архитектуру определяют сеньоры. К тому же в продуктовой компании сложно расширить кругозор: сеньор там будет хорошо разбираться в своем стеке, но про другие подходы без осознанных усилий скорее всего не узнает.
Проще вырастить кругозор в аутсорс-компаниях, так как там чаще меняются проекты.
Альтернатива органическому росту — пойти на курсы, где знания даются системно.
Зачем это всё в кризис
Я бы не сказал, что кризис сократил спрос на хороших стафф-инженеров и архитекторов. Да, мидлы, а иногда и сеньоры под ударом. Увольнение стафф-инженера менее вероятно, потому что он реально двигает бизнес. Такие специалисты редки и ценны.
Про участь сеньора, который не может/не хочет развиваться
В далёкую докризисную эпоху сеньор мог сидеть ровно, и всё у него было хорошо. Сейчас тех, кто не двигается, настигают изменения. И им поневоле приходится шевелиться — превентивно или уже по факту, когда они оказываются не востребованы.
АНОНС. Для тех, кому интересна тема, присоединяйтесь 25 апреля к бесплатному онлайн-митапу «Как расти из техлида до архитектора»,
который ведёт Андрей Ковалев, Director, Technology Solutions в EPAM.
Что читать для расширения кругозора. Список от Павла Вейника
- Проникнуться, какие базы вообще есть:
- Сайт Мартина нашего Фаулера, в последнее время он много пишет про организацию разработки, а не только про архитектуру.
- Сайт Мартина нашего Клеппмана, он глубоко лезет в детали алгоритмов, иногда слишком академичен, хотя продакшн-опыт у него тоже есть. Если вы используете RedLock, то почитайте это. Кстати, RedisRaft ещё не production.
- Если вы уверены, что ваша БД работает как надо, то попробуйте найти её анализ вот тут: возможно, окажется, что база наводит баги.
- Есть ресурс, посвященный дизайну и истории различных систем, например этот. Осторожно, они недавно сменили дизайн, и сейчас там может быть криво.
- Вот тут можно найти, какие стеки используются на проектах, а также отзывы о технологиях и инструментах.
Хороших ресурсов очень много, но ни один из них не даёт структурной информации, куда и как сеньору расти дальше, кроме моего курса, разумеется ;)
Накидайте в комментах ресурсы, которые помогают проектировать системы вам.
Читать на dev.by