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

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

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

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

  • Команда обычно состоит из разных специалистов и кросс-функциональна по своей природе
  • Современные процессы разработки выглядят для непосвященных достаточно сложно
Рис.6 “Тимлид как интерфейс команды”
  • Получить больше влияния на конечный результат как в качественном, так и в количественном выражении
  • Улучшить процессы разработки внутри своей команды
  • Повысить уровень total compensation
Рис.7 “Рост по менеджерской ветке”
  • 10 человек — позиция Teamlead и ответственность за команду, взаимодействие с членами команды, гранулярность — человек в команде
  • 50 человек — позиция Engineering Manager и ответственность за группу команд, взаимодействие с тимлидами, гранулярность — команда
  • 150 человек — позиция технического директора и ответственность за управление, взаимодействие с Engineering Manager, гранулярность — группы команд

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

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

  • В компании уже есть люди, которые являются техническими экспертами и которых еще не выдавило в менеджмент
  • Руководство понимает, что такие люди нужны компании и целенаправленно создает понятные правила роста в эту сторону
Рис.8 “High level grades at Tinkoff”
  • Principal Engineer влияет на большую команду или множество команд или сложный технический проект или крупный продукт.
  • Senior Principal Engineer влияет на отдел с высокой сложностью предметной области, когда нет стандартных способов решения задачи.
  • Distinguished Engineer влияет на управление с высоким уровнем предметной сложности, либо разрабатывает сложные технические решения, которые влияют на всю компанию.
  • Technical Fellow влияет на всю компанию, разрабатывая уникальные решения с очень сложной и уникальной предметной областью, которые создают для компании конкурентное преимущество на рынке.
Рис.9 “Критерии оценки в матрице SDE”
  • Scope — этот критерий мы обсудили выше
  • Impact — какой вклад сотрудник привносит в продукт/проект. Мы считаем, что сотрудник должен решать задачи и закрывать проекты, а не просто быть крутым техническим специалистом, который умеет разговаривать и чай пить с другими. Нам нужен тот, кто создает value
  • Complexity — какой технической сложности были решены задачи. Здесь должны быть учтены технические скиллы сотрудника. И при этом ограничены возможности, не может быть так, что сотрудник работает в мелкой команде, которая ставит на поток типовые простые проекты и это будет считаться как Senior, хотя в другой команде это уровень Junior
  • Leadership — как происходит коммуникация с другими сотрудниками. Здесь должны быть закрыты софт скиллы и лидерские принципы типа договориться — чтобы решить проблему самостоятельно, нужны лидерские принципы и умение договариваться и их придется прокачивать тут после определенного этапа.
  • Improvement — Какие были улучшения в себе, процессах или других сотрудников
    — Софт скиллы по организации и улучшению процессов в команде
    — Развитие других сотрудников
    — Развития самого себя
  • Если в компании есть запрос на решение сложных технических задач, то забрать на себя такую задачу будучи в роли Senior Engineer
  • Если запроса явного нет, то проанализировать что мешает организации и прийти к руководству с формализованной проблемой и предполагаемым решением, реализацию которого взять на себя
  • Если найти явную проблему не получилось или руководство ее не купило, то, можно сменить компанию

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

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

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

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

Рис.14 “Матрица Эйзенхауэра”
  • Important and Urgent — тут просто надо взять и сделать такие задачи. Если таких задач слишком много, то что-то идет не так
  • Important and Less Urgent —такие задачи надо запланировать. Но это проблемная история, потому что запланировать легко, а начать исполнять планы — сложно
  • Less Important and Urgent —такие задачи надо делегировать, если есть кому:) Если нет, то надо сначала найти того, кому можно делегировать
  • Less Important and Less Urgent — эти задачи надо просто отправить в мусорную корзину
Рис.15 “Как двигаться к цели, сохраняя мотивацию”
  • Поставь цель — самые устойчивые цели работают сразу на несколько аспектов жизни: на работу, хобби, личную жизнь. От таких целей сложнее отказаться.
  • Составь план — план должен быть четким и осуществимым. Желательно, чтобы он задавал ритм и в нем были промежуточные чекпоинты.
  • Выкинь цель из головы — нельзя все время фокусироваться на далекой цели, потому что легко словить демотивацию от того, насколько она удалена.
  • Иди вперед, радуясь маленьким шагам — достижение очередного промежуточного чекпоинта приносит радость. Хорошо если по мере движения еще появляются и артефакты.
Рис.16 “Стандартный подход к постановке целей”
  1. Обычно люди начинают с того, где они находятся сейчас
  2. Дальше они придумывают себе цели, учитывая стартовую точку
  3. Потом они придумывают как закрыть разрыв между стартовой точкой и целью
Рис.17 “Подход backcasting”
  1. Начинаем с желаемой цели
  2. Придумываем в обратном направлении шаги как ее достигнуть, идя от цели. У нас появляется набор промежуточных шагов
  3. Так мы доходим до старта, составив план преобразований
Рис.18 “You build it, you run it”
Рис.19 “Развитие в System Design и Troubleshooting”
  • Теория предполагает
    — Изучения принципов проектирования распределенных систем
    — Изучения основных классов систем, их сильных сторон и границ применимости
  • А практику можно получит
    — Работая в роли архитектора над проектированием реальных систем
    — Разбирая архитектуру крупных сложных систем (от Google, Meta,…)
    — Тренируясь в решении архитектурных ката
  • Теория предполагает
    — Изучения практик и подходов, изложенных , например, SRE Book и SRE Workbook от Google
    — Изучение инструментов для применения этих методов
  • А практику можно получит
    — Работая в SRE команде над реальными системами
    — Разбирая публичные postmortems крупных и сложных систем
    — Тренируясь в troubleshooting на задачах, сделанных по мотивам postmortems

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

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

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

Alexander Polomodov

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