Как и куда развиваться, если ты уже Senior Software Engineer
С таким докладом я выступил на dotNext 2022 Spring 27 июня. Кажется, что вопросам обучения уделяют много времени, но основной фокус на тех, кто еще только хочет войти в IT. Я в своем докладе поговорил про то, как продолжить развиваться, если ты уже Senior
. Какие вообще карьерные пути бывают, как проще всего по ним идти и главное как сохранять мотивацию на саморазвитие. Я рассказал о том, какой подход я выработал для себя и почему считаю, что он работает.
Для любителей смотреть доклады ссылка на Youtube ниже
Ну а для остальных предлагаю дальше продолжить читать статью, план которой достаточно простой
- Проблематика роста из
Senior
дальше - Варианты роста в сторону
—Team
—Tech
- Подходы к обучению
- Как поддерживать мотивацию и ставить цели
- Мои рекомендации насчет роста в сторону техники
Ну и начну я рассказ с того, как выглядит стандартный рост разработчиков, на примере своего роста и знаний о других компаниях.
Все начинают со школы, где проводят порядка 10 лет. Дальше по дефолту идет университет и если в мое время там можно было получить фундаментальное образование, а программирование приходилось забатывать самому, то сейчас уже не так. Есть превосходные программы в разных университетах, например, МФТИ или ВШЭ — я сам смотрю часть курсов оттуда, которые публикуются на Youtube. Кстати, в университете некоторые пробуют пойти в науку, но я к третьему курсу понял, что не тяну и у меня возникла потребность в зарабатывании денег. Именно так я стал сначала сотрудником техподдержки, а потом и гордым начинающим разработчиком. Лет за 5 я прошел этапы Junior
и Middle
и дошел до Senior
, по-крайней мере в моем мироощущении. У меня как и у многих на этом этапе возник вопрос
Сейчас я понимаю, что вариантов на самом деле масса, но основных два: в сторону руководства командой разработки или в сторону эксперта, который выступает как индивидуальный контрибьютор.
Давайте сначала разберем первый путь, по которому я пошел десять лет назад, а именно в сторону тимлида.
Путь в менеджмент
Для начала надо пояснить почему в настоящее время есть запрос на эту роль
- Команда обычно состоит из разных специалистов и кросс-функциональна по своей природе
- Современные процессы разработки выглядят для непосвященных достаточно сложно
В итоге, бизнесу нужен человек, который выступит как интерфейс команды, условно “единое окно”, в которое можно придти с мыслями или проблемами относительно процесса разработки.
Второй важный вопрос, а зачем на эту роль соглашаться Senior
разработчику. Ответ на этот вопрос строго индивидуален, но для себя я ответил на этот вопрос так:
- Получить больше влияния на конечный результат как в качественном, так и в количественном выражении
- Улучшить процессы разработки внутри своей команды
- Повысить уровень total compensation
Кстати, я про это рассказывал в статье “Как стать тимлидом?”. Интересно, что на позиции тимлида еще можно совмещать разработку и менеджмент, а вот дальше скорее всего нет. На прошлогоднем московском Highload++ в докладе “Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании” я рассказывал про то, как может выглядеть рост по ветке менеджмента по мере движения компании по ее жизненному циклу.
Давайте пробежимся по этапам
- 10 человек — позиция
Teamlead
и ответственность за команду, взаимодействие с членами команды, гранулярность — человек в команде - 50 человек — позиция
Engineering Manager
и ответственность за группу команд, взаимодействие с тимлидами, гранулярность — команда - 150 человек — позиция технического директора и ответственность за управление, взаимодействие с
Engineering Manager
, гранулярность — группы команд
На уровне технического директора существует слишком много обязанностей и он часто имеет помощников по delivery
, architecture
и так далее. Теперь можно посмотреть альтернативный вариант.
Путь в сторону индивидуального контрибьютора
Отдельно скажу, что этот вариант присутствует не во всех компаниях и о нем стоит говорить, если
- В компании уже есть люди, которые являются техническими экспертами и которых еще не выдавило в менеджмент
- Руководство понимает, что такие люди нужны компании и целенаправленно создает понятные правила роста в эту сторону
В нашей компании соблюдены оба эти условия, поэтому я вам расскажу немного про наш подход к high levels of individual contributors, который мы в начале года планировали запустить до лета, но этот проект был немного отложен из-за февральских событий и сейчас все еще в стадии обсуждения. Отдельно хочу отметить, что я входил в рабочую группу по этому проекту, но сам проект вел мой коллега, Андрей Марченко — крутой инженер, которого тоже затянуло в сторону менеджмента:)
В общем, в нашей концепции у нас у ребят SDE
(Software Development Engineer
) будут следующие высокие грейды
Principal Engineer
влияет на большую команду или множество команд или сложный технический проект или крупный продукт.Senior Principal Engineer
влияет на отдел с высокой сложностью предметной области, когда нет стандартных способов решения задачи.Distinguished Engineer
влияет на управление с высоким уровнем предметной сложности, либо разрабатывает сложные технические решения, которые влияют на всю компанию.Technical Fellow
влияет на всю компанию, разрабатывая уникальные решения с очень сложной и уникальной предметной областью, которые создают для компании конкурентное преимущество на рынке.
Здесь мы рассмотрели эти высокие грейды только с точки их scope
, то есть влияния на окружающее. Суть в том, что high level инженеры могут работать как паладины в ролевых играх — они одновременно и сами могут поучаствовать в замесе, но также распространяют ауру типа bless
на окружающих юнитов:)
А вообще, мы выделили следующие критерии, по которым мы смотрим на общую матрицу SDE
без учета специфики конкретного языка или платформы.
Scope
— этот критерий мы обсудили вышеImpact
— какой вклад сотрудник привносит в продукт/проект. Мы считаем, что сотрудник должен решать задачи и закрывать проекты, а не просто быть крутым техническим специалистом, который умеет разговаривать и чай пить с другими. Нам нужен тот, кто создаетvalue
Complexity
— какой технической сложности были решены задачи. Здесь должны быть учтены технические скиллы сотрудника. И при этом ограничены возможности, не может быть так, что сотрудник работает в мелкой команде, которая ставит на поток типовые простые проекты и это будет считаться какSenior
, хотя в другой команде это уровеньJunior
Leadership
— как происходит коммуникация с другими сотрудниками. Здесь должны быть закрыты софт скиллы и лидерские принципы типа договориться — чтобы решить проблему самостоятельно, нужны лидерские принципы и умение договариваться и их придется прокачивать тут после определенного этапа.Improvement
— Какие были улучшения в себе, процессах или других сотрудников
— Софт скиллы по организации и улучшению процессов в команде
— Развитие других сотрудников
— Развития самого себя
Теперь, когда мы знаем как выглядят наши ожидания от высокогрейдовых инженеров, но что делать если в вашей компании нет такой формализованной схемы к росту в ветку техники. Я для себя на это ответил так
- Если в компании есть запрос на решение сложных технических задач, то забрать на себя такую задачу будучи в роли
Senior Engineer
- Если запроса явного нет, то проанализировать что мешает организации и прийти к руководству с формализованной проблемой и предполагаемым решением, реализацию которого взять на себя
- Если найти явную проблему не получилось или руководство ее не купило, то, можно сменить компанию
Дальше мы поговорим про разные подходы к решению проблем и обучению.
Подходы к решению проблем (теоретики и практики)
Показанный выше путь близок мне. Суть в том, что когда я встречаюсь с комплексной проблемой, то я погружаюсь в глубокое изучение домена — читаю книги, документацию, статьи. Потом наступает время практики, где я пытаюсь, используя изученную теорию, потыкать разные варианты. Дальше появляется идея, которую я заворачиваю в RFC, составляю план и дальше наступает фаза имплементации. Когда появляются результаты, я проверяю насколько они решают изначальную проблему и если что мы уходим на следующий круг.
Основная особенность этого подхода в том, что я глубоко копаю теорию и пока не разберусь меня совсем не тянет начать практиковаться. Так было с самого детства.
Но есть и другой вариант с изучением нового. У меня есть друзья, что успешно его практикуют. Он приведен ниже.
Суть в том, что когда такие люди встречаются с комплексной проблемой, то они начинают экспериментировать, пытаясь решить ее, используя стандартный для них toolset
. Потом они чувствуют, что им не хватает инструментов и они начинают копать теорию, используя разнообразные статьи, например, white papers
. Дальше появляется идея, которую они решают реализовать. Когда появляются результаты, они проверяют их и дальше уходят на следующий круг.
Инженеры-практики становятся ощутимо круче, если они не сразу бегут имплементировать свои идеи, а сначала пишут документ RFC с описанием проблемы, вариантами решения, составляют некоторый план реализации и дальше идут его имплементировать. В таком случае этот индивидуальный контрибьютор не просто в одиночку уходит вглубь темы, но и тянет других инженеров за собой:)
Отдельно расскажу про Кеневин фреймворк — интересный фреймворк для классификации сложности домена и задач.
Obvious
— очевидная система характеризуется наличием “лучших практик”, которые можно использовать для получения заведомо хороших результатов. ~ Операционная деятельностьComplicated
— в таких системах меньше определенности насчет гарантированности результата, но скорее не из-за запутанности системы, а от нехватки опыта и информации. ~ Проектная деятельностьComplex
— в такой системе невозможно заранее достоверно предсказать результат наших усилий, мы работаем в условиях повышенной неопределенности. ~ Продуктовая разработкаChaotic
— в такой системе мы не только не знаем результата, но зачастую не знаем что вообще делать. ~ Research & DevelopmentDisorder
— это ситуация, когда мы не понимаем в каком домене работаем. Такое возможно, если мы смотрим на область, которая слишком велика и содержит разные домены, которые относятся к предыдущим четырем уровням
В итоге, в рамках работы над проблемами мы обычно стремимся к тому, чтобы двигаться по часовой стрелке от Chaotic
к Obvious
, упрощая сложность домена:) Таким образом мы решаем проблемы и когда они становятся для нас простыми передаем их на дальнейшее развитие коллегам, а сами занимаемся проблемами более сложными и масштабными.
Теперь мы знаем какие есть подходы к изучению нового, осталось понять
Как мотивировать себя на развитие
Здесь я хотел бы вспомнить про матрицу Эйзенхауэра, которая используется для классификации задач и представляет собой матрицу 2x2, в которой всего две оси: важность и срочность.
Important and Urgent
— тут просто надо взять и сделать такие задачи. Если таких задач слишком много, то что-то идет не такImportant and Less Urgent
—такие задачи надо запланировать. Но это проблемная история, потому что запланировать легко, а начать исполнять планы — сложноLess Important and Urgent
—такие задачи надо делегировать, если есть кому:) Если нет, то надо сначала найти того, кому можно делегироватьLess Important and Less Urgent
— эти задачи надо просто отправить в мусорную корзину
Со всеми квадрантами кроме Important and Less Urgent
все ясно, так как наше решение можно начать реализовывать сразу, а вот с запланированными задачами все не так и просто — кто ни разу не обещал себе начать бегать/худеть/ботать со следующего года/месяца/недели? В общем, запланировать и сделать — это две большие разницы.
Но есть достаточно понятный подход, который может давать результат. И выглядит он как-то так
- Поставь цель — самые устойчивые цели работают сразу на несколько аспектов жизни: на работу, хобби, личную жизнь. От таких целей сложнее отказаться.
- Составь план — план должен быть четким и осуществимым. Желательно, чтобы он задавал ритм и в нем были промежуточные чекпоинты.
- Выкинь цель из головы — нельзя все время фокусироваться на далекой цели, потому что легко словить демотивацию от того, насколько она удалена.
- Иди вперед, радуясь маленьким шагам — достижение очередного промежуточного чекпоинта приносит радость. Хорошо если по мере движения еще появляются и артефакты.
Отдельно расскажу про постановку целей, которые многие делают неправильно. Если бы я действовал также, то до сих пор жил бы в Северодвинске у Белого моря и скорее всего работал бы на градообразующем предприятии, местном заводе:)
Стандартный подход выглядит так
- Обычно люди начинают с того, где они находятся сейчас
- Дальше они придумывают себе цели, учитывая стартовую точку
- Потом они придумывают как закрыть разрыв между стартовой точкой и целью
Здесь основная проблема в том, что здесь мышление зажато размерами текущей ситуации, которая выступает как «коробочка». Но есть и другой вариант
- Начинаем с желаемой цели
- Придумываем в обратном направлении шаги как ее достигнуть, идя от цели. У нас появляется набор промежуточных шагов
- Так мы доходим до старта, составив план преобразований
Здесь мы починили проблему зажатости мышления и составили план изменений.
Ну и напоследок обсудим как развиваться Senior разработчикам в техническую ветку. Для этого можно вспомнить мантру
You build it, you run it
из которой следует, что инженерам надо уметь проектировать, имплементировать и чинить созданные ими системы
Давайте уберем часть про .NET платформу, про развитие в которой говорилось во всех остальных докладах на конференции dotNext и обсудим только System Design и Troubleshooting.
Если говорить про System Design
, то
- Теория предполагает
— Изучения принципов проектирования распределенных систем
— Изучения основных классов систем, их сильных сторон и границ применимости - А практику можно получит
— Работая в роли архитектора над проектированием реальных систем
— Разбирая архитектуру крупных сложных систем (от Google, Meta,…)
— Тренируясь в решении архитектурных ката
Troubleshooting
, чуть отличается
- Теория предполагает
— Изучения практик и подходов, изложенных , например, SRE Book и SRE Workbook от Google
— Изучение инструментов для применения этих методов - А практику можно получит
— Работая вSRE
команде над реальными системами
— Разбирая публичные postmortems крупных и сложных систем
— Тренируясь вtroubleshooting
на задачах, сделанных по мотивамpostmortems
Кажется на этом я закончил обещанную программу и рассказал о всем, что хотел, поэтому рекомендую напоследок материалы, которые помогут прокачаться вам в ту сторону, которая вам покажется более приоритетной и не потеряться на этом пути:)
Рекомендации по изучению
- Про мотивацию и обучение
— Обзор книги “Миф о мотивации»
— Обзор книги “На пике” (“Peak Performance”)
— Обзор книги “Спираль обучения” - Материалы про System Design
— Статья про System Design Interview
— Статья про подготовку к System Design Interview
— Статья про публичное System Design Interview на C++ Russia 2022 - Материалы про Troubleshooting
— Статья про Troubleshooting Interview в Tinkoff
— Google SRE Book
— SRE Workbook - Материалы про рост в сторону менеджмента
— Статья Как стать тимлидом?
— Статья SOLID’ный тимлид, или основы менеджмента
— Статья Трансформация роли CTO по мере роста компании
— Обзор книги “Technology Strategy Patterns”
— Статья “Мои рекомендации техническим руководителям”