Как и куда развиваться, если ты уже Senior Software Engineer

С таким докладом я выступил на dotNext 2022 Spring 27 июня. Кажется, что вопросам обучения уделяют много времени, но основной фокус на тех, кто еще только хочет войти в IT. Я в своем докладе поговорил про то, как продолжить развиваться, если ты уже Senior. Какие вообще карьерные пути бывают, как проще всего по ним идти и главное как сохранять мотивацию на саморазвитие. Я рассказал о том, какой подход я выработал для себя и почему считаю, что он работает.

План достаточно простой:

• Проблематика роста из Senior дальше
• Варианты роста в сторону
  — Team
  — Tech
• Подходы к обучению
• Как поддерживать мотивацию и ставить цели
• Мои рекомендации насчет роста в сторону техники

Рис.2 “Как выглядит стандартный рост разработчиков”

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

Рис.3 “Стандартный путь к Senior”

Все начинают со школы, где проводят порядка 10 лет. Дальше по дефолту идет университет и если в мое время там можно было получить фундаментальное образование, а программирование приходилось забатывать самому, то сейчас уже не так. Есть превосходные программы в разных университетах, например, МФТИ или ВШЭ — я сам смотрю часть курсов оттуда, которые публикуются на Youtube. Кстати, в университете некоторые пробуют пойти в науку, но я к третьему курсу понял, что не тяну и у меня возникла потребность в зарабатывании денег. Именно так я стал сначала сотрудником техподдержки, а потом и гордым начинающим разработчиком. Лет за 5 я прошел этапы Junior и Middle и дошел до Senior, по-крайней мере в моем мироощущении. У меня как и у многих на этом этапе возник вопрос

Рис.4 “Какие варианты росту у Senior”

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

Рис.5 “Два варианта развития Senior”

Давайте сначала разберем первый путь, по которому я пошел десять лет назад, а именно в сторону тимлида.

Путь в менеджмент

Для начала надо пояснить почему в настоящее время есть запрос на эту роль

• Команда обычно состоит из разных специалистов и кросс-функциональна по своей природе
• Современные процессы разработки выглядят для непосвященных достаточно сложно

В итоге, бизнесу нужен человек, который выступит как интерфейс команды, условно “единое окно”, в которое можно придти с мыслями или проблемами относительно процесса разработки.

Рис.6 “Тимлид как интерфейс команды”

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

• Получить больше влияния на конечный результат как в качественном, так и в количественном выражении
• Улучшить процессы разработки внутри своей команды
• Повысить уровень total compensation

Кстати, я про это рассказывал в статье “Как стать тимлидом?”. Интересно, что на позиции тимлида еще можно совмещать разработку и менеджмент, а вот дальше скорее всего нет. На прошлогоднем московском Highload++ в докладе “Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании” я рассказывал про то, как может выглядеть рост по ветке менеджмента по мере движения компании по ее жизненному циклу.

Рис.7 “Рост по менеджерской ветке”

Давайте пробежимся по этапам

• 10 человек — позиция Teamlead и ответственность за команду, взаимодействие с членами команды, гранулярность — человек в команде
• 50 человек — позиция Engineering Manager и ответственность за группу команд, взаимодействие с тимлидами, гранулярность — команда
• 150 человек — позиция технического директора и ответственность за управление, взаимодействие с Engineering Manager, гранулярность — группы команд

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

Путь в сторону индивидуального контрибьютора

Отдельно скажу, что этот вариант присутствует не во всех компаниях и о нем стоит говорить, если

• В компании уже есть люди, которые являются техническими экспертами и которых еще не выдавило в менеджмент
• Руководство понимает, что такие люди нужны компании и целенаправленно создает понятные правила роста в эту сторону

В нашей компании соблюдены оба эти условия, поэтому я вам расскажу немного про наш подход к high levels of individual contributors, который мы в начале года планировали запустить до лета, но этот проект был немного отложен из-за февральских событий и сейчас все еще в стадии обсуждения. Отдельно хочу отметить, что я входил в рабочую группу по этому проекту, но сам проект вел мой коллега, Андрей Марченко — крутой инженер, которого тоже затянуло в сторону менеджмента:)

В общем, в нашей концепции у нас у ребят SDE (Software Development Engineer) будут следующие высокие грейды

Рис.8 “High level grades at Tinkoff”

• Principal Engineer влияет на большую команду или множество команд или сложный технический проект или крупный продукт.
• Senior Principal Engineer влияет на отдел с высокой сложностью предметной области, когда нет стандартных способов решения задачи.
• Distinguished Engineer влияет на управление с высоким уровнем предметной сложности, либо разрабатывает сложные технические решения, которые влияют на всю компанию.
• Technical Fellow влияет на всю компанию, разрабатывая уникальные решения с очень сложной и уникальной предметной областью, которые создают для компании конкурентное преимущество на рынке.

Здесь мы рассмотрели эти высокие грейды только с точки их scope, то есть влияния на окружающее. Суть в том, что high level инженеры могут работать как паладины в ролевых играх — они одновременно и сами могут поучаствовать в замесе, но также распространяют ауру типа bless на окружающих юнитов:)

А вообще, мы выделили следующие критерии, по которым мы смотрим на общую матрицу SDE без учета специфики конкретного языка или платформы.

Рис.9 “Критерии оценки в матрице SDE”

• Scope — этот критерий мы обсудили выше
• Impact — какой вклад сотрудник привносит в продукт/проект. Мы считаем, что сотрудник должен решать задачи и закрывать проекты, а не просто быть крутым техническим специалистом, который умеет разговаривать и чай пить с другими. Нам нужен тот, кто создает value
• Complexity — какой технической сложности были решены задачи. Здесь должны быть учтены технические скиллы сотрудника. И при этом ограничены возможности, не может быть так, что сотрудник работает в мелкой команде, которая ставит на поток типовые простые проекты и это будет считаться как Senior, хотя в другой команде это уровень Junior
• Leadership — как происходит коммуникация с другими сотрудниками. Здесь должны быть закрыты софт скиллы и лидерские принципы типа договориться — чтобы решить проблему самостоятельно, нужны лидерские принципы и умение договариваться и их придется прокачивать тут после определенного этапа.
• Improvement — Какие были улучшения в себе, процессах или других сотрудников
  — Софт скиллы по организации и улучшению процессов в команде
  — Развитие других сотрудников
  — Развития самого себя

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

• Если в компании есть запрос на решение сложных технических задач, то забрать на себя такую задачу будучи в роли Senior Engineer
• Если запроса явного нет, то проанализировать что мешает организации и прийти к руководству с формализованной проблемой и предполагаемым решением, реализацию которого взять на себя
• Если найти явную проблему не получилось или руководство ее не купило, то, можно сменить компанию

Дальше мы поговорим про разные подходы к решению проблем и обучению.

Подходы к решению проблем (теоретики и практики)

Рис.10 “Путь инженера теоретика”

Показанный выше путь близок мне. Суть в том, что когда я встречаюсь с комплексной проблемой, то я погружаюсь в глубокое изучение домена — читаю книги, документацию, статьи. Потом наступает время практики, где я пытаюсь, используя изученную теорию, потыкать разные варианты. Дальше появляется идея, которую я заворачиваю в RFC, составляю план и дальше наступает фаза имплементации. Когда появляются результаты, я проверяю насколько они решают изначальную проблему и если что мы уходим на следующий круг.

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

Но есть и другой вариант с изучением нового. У меня есть друзья, что успешно его практикуют. Он приведен ниже.

Рис.11 “Путь инженера практика”

Суть в том, что когда такие люди встречаются с комплексной проблемой, то они начинают экспериментировать, пытаясь решить ее, используя стандартный для них toolset. Потом они чувствуют, что им не хватает инструментов и они начинают копать теорию, используя разнообразные статьи, например, white papers. Дальше появляется идея, которую они решают реализовать. Когда появляются результаты, они проверяют их и дальше уходят на следующий круг.

Инженеры-практики становятся ощутимо круче, если они не сразу бегут имплементировать свои идеи, а сначала пишут документ RFC с описанием проблемы, вариантами решения, составляют некоторый план реализации и дальше идут его имплементировать. В таком случае этот индивидуальный контрибьютор не просто в одиночку уходит вглубь темы, но и тянет других инженеров за собой:)

Рис.12 “Путь выдающегося инженера практика”

Отдельно расскажу про Кеневин фреймворк — интересный фреймворк для классификации сложности домена и задач.

Рис.13 “Cynefin framework”

• Obvious — очевидная система характеризуется наличием “лучших практик”, которые можно использовать для получения заведомо хороших результатов. ~ Операционная деятельность
• Complicated — в таких системах меньше определенности насчет гарантированности результата, но скорее не из-за запутанности системы, а от нехватки опыта и информации. ~ Проектная деятельность
• Complex — в такой системе невозможно заранее достоверно предсказать результат наших усилий, мы работаем в условиях повышенной неопределенности. ~ Продуктовая разработка
• Chaotic — в такой системе мы не только не знаем результата, но зачастую не знаем что вообще делать. ~ Research & Development
• Disorder — это ситуация, когда мы не понимаем в каком домене работаем. Такое возможно, если мы смотрим на область, которая слишком велика и содержит разные домены, которые относятся к предыдущим четырем уровням

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

Теперь мы знаем какие есть подходы к изучению нового, осталось понять

Как мотивировать себя на развитие

Здесь я хотел бы вспомнить про матрицу Эйзенхауэра, которая используется для классификации задач и представляет собой матрицу 2x2, в которой всего две оси: важность и срочность.

Рис.14 “Матрица Эйзенхауэра”

• Important and Urgent — тут просто надо взять и сделать такие задачи. Если таких задач слишком много, то что-то идет не так
• Important and Less Urgent —такие задачи надо запланировать. Но это проблемная история, потому что запланировать легко, а начать исполнять планы — сложно
• Less Important and Urgent —такие задачи надо делегировать, если есть кому:) Если нет, то надо сначала найти того, кому можно делегировать
• Less Important and Less Urgent — эти задачи надо просто отправить в мусорную корзину

Со всеми квадрантами кроме Important and Less Urgent все ясно, так как наше решение можно начать реализовывать сразу, а вот с запланированными задачами все не так и просто — кто ни разу не обещал себе начать бегать/худеть/ботать со следующего года/месяца/недели? В общем, запланировать и сделать — это две большие разницы.

Но есть достаточно понятный подход, который может давать результат. И выглядит он как-то так

Рис.15 “Как двигаться к цели, сохраняя мотивацию”

• Поставь цель — самые устойчивые цели работают сразу на несколько аспектов жизни: на работу, хобби, личную жизнь. От таких целей сложнее отказаться.
• Составь план — план должен быть четким и осуществимым. Желательно, чтобы он задавал ритм и в нем были промежуточные чекпоинты.
• Выкинь цель из головы — нельзя все время фокусироваться на далекой цели, потому что легко словить демотивацию от того, насколько она удалена.
• Иди вперед, радуясь маленьким шагам — достижение очередного промежуточного чекпоинта приносит радость. Хорошо если по мере движения еще появляются и артефакты.

Отдельно расскажу про постановку целей, которые многие делают неправильно. Если бы я действовал также, то до сих пор жил бы в Северодвинске у Белого моря и скорее всего работал бы на градообразующем предприятии, местном заводе:)

Стандартный подход выглядит так

Рис.16 “Стандартный подход к постановке целей”

1. Обычно люди начинают с того, где они находятся сейчас
2. Дальше они придумывают себе цели, учитывая стартовую точку
3. Потом они придумывают как закрыть разрыв между стартовой точкой и целью

Здесь основная проблема в том, что здесь мышление зажато размерами текущей ситуации, которая выступает как «коробочка». Но есть и другой вариант

Рис.17 “Подход backcasting”

1. Начинаем с желаемой цели
2. Придумываем в обратном направлении шаги как ее достигнуть, идя от цели. У нас появляется набор промежуточных шагов
3. Так мы доходим до старта, составив план преобразований

Здесь мы починили проблему зажатости мышления и составили план изменений.

Ну и напоследок обсудим как развиваться Senior разработчикам в техническую ветку. Для этого можно вспомнить мантру

You build it, you run it

из которой следует, что инженерам надо уметь проектировать, имплементировать и чинить созданные ими системы

Рис.18 “You build it, you run it”

Давайте уберем часть про .NET платформу, про развитие в которой говорилось во всех остальных докладах на конференции dotNext и обсудим только System Design и Troubleshooting.

Рис.19 “Развитие в 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”
  — Статья “Мои рекомендации техническим руководителям”