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

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

Для любителей смотреть доклады ссылка на Youtube ниже

Ну а для остальных предлагаю дальше продолжить читать статью, план которой достаточно простой

  • Варианты роста в сторону
    Team
    Tech
  • Подходы к обучению
  • Как поддерживать мотивацию и ставить цели
  • Мои рекомендации насчет роста в сторону техники
Рис.2 “Как выглядит стандартный рост разработчиков”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну и напоследок обсудим как развиваться 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 команде над реальными системами
    — Разбирая публичные postmortems крупных и сложных систем
    — Тренируясь в troubleshooting на задачах, сделанных по мотивам postmortems

Кажется на этом я закончил обещанную программу и рассказал о всем, что хотел, поэтому рекомендую напоследок материалы, которые помогут прокачаться вам в ту сторону, которая вам покажется более приоритетной и не потеряться на этом пути:)

Рекомендации по изучению

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.