В российских компаниях классический путь программиста заканчивается на должности тимлида или tech lead. Дальше — всё больше менеджера, всё меньше инженера. Хочешь расти в компании — берись за управление людьми, нравится тебе это или нет.
Но что, если есть другой путь? Опыт западных компаний показывает, что можно дать программисту остаться в разработке, а в менеджеры брать тех, у кого есть желание. И это не пойдёт бизнесу в убыток. Наоборот — разработчик сможет вносить бóльший вклад в работу компании и наработать уникальную экспертизу. А ещё не выгорит от бесконечных code review. В этой статье Иван Круглов расскажет, как разработчику расти, минуя менеджмент.
Небольшое предисловие
Меня зовут Иван Круглов, я Staff Engineer в Databricks. Если вы ещё не слышали об этой компании, то обязательно услышите. Компания работает в сфере обработки данных: предоставляет инструменты для обработки больших данных, для Machine Learning, для бизнес-аналитики и так далее.
Должность у меня Staff Engineer, позиция Tech Lead. Я отвечаю за команду, которая разрабатывает один из бизнес-критических сервисов. Классическая история: традиционный монолит перерос по нагрузке все возможности, которые изначально в него закладывались, поэтому нужно перестраивать, перекраивать, пересобирать и делать так, чтобы всё работало.
В Databricks я не очень долго, с прошлого апреля. Никогда не был в офисе: когда я пришёл, ввели все карантинные меры. Даже пропуска в офис нет. И с коллегами вживую виделся один или два раза.
До этого я семь лет провел в Booking.com. Пришёл туда как разработчик и прошёл весь путь до Principal Engineer.Самым большим достижением считаю создание нового PaaS: внутреннего облака на kubernetes. В сумме у нас было 2000 нод с большой автоматизацией, позволяющей автоматически получать доступ к различным ресурсам. Еще я внедрил service mesh, про это я рассказывал на конференции Highload++.
Когда GDPR только входил в наш лексикон, я построил внутренний сервис, который позволил компании соответствовать требованиям регламента. Тогда это было очень важно — приходилось перекраивать если не все внутренние процессы, то большинство. Потому что раньше данные были везде, а теперь их нужно свести в одно место и перестроить внутренние сервисы, чтобы они данные брали из единого места, но продолжали работать как раньше.
Также работал над нашим поисковым движком. Когда вы ищете на Booking.com отель в Москве и нажимаете на кнопку поиск, он производится в том числе с помощью моего сервиса, над которым я работал. Тоже интересный проект.
В 2013 году я переехал в Амстердам. До этого я жил и работал в Иркутске, в компании ISPSystem — поддерживал и разрабатывал панели управления. Одно время я даже был тимлидом. Примерно в то же время у меня отбилось желание быть тимлидом, и с тех пор каждый раз, когда спрашивают “Хочешь в менеджмент?” я говорю — нет.
Пока что я продолжаю с переменными успехами двигаться по карьерной лестнице и оставаться инженером, и об этом я хочу поговорить поподробнее.
Реальность
Я провел небольшой опрос среди российских и западных друзей, чтобы обрисовать картину и дополнить понимание. У нас есть классический карьерный путь Junior-Middle-Senior.
Junior — человек только с института. Опыта мало. Ему нужно выдавать задачи, его нужно постоянно контролировать, поддерживать.
В позиции Middle человеку по-прежнему нужно выдавать задачи, но он может делать их самостоятельно и проявлять какую-то инициативность. Он беспокоит вас не так часто.
Senior может выдавать задачи и себе, и коллегам. Его не нужно мониторить, не нужно сопровождать. Он автономный боевой юнит — сам вступит в бой, сам расставит войска, сам даст команду.
После этого появляется тимлид или техлид. На этом этапе человек уже начинает отвечать за некоторые направления, во главе команды или нескольких команд. Где-то он выступает в роли менеджера.
Сразу оговорюсь: под общим словом “менеджер” я имею в виду people менеджера, который руководит людьми и отвечает за их рост. И в меньшей степени product менеджера или project менеджера.
Техлиду начинают примешивать всё больше задач по управлению людьми и проектом, и все меньше программистских задач — того, что обычно всем нравится. За этой ступенью есть определённая техническая ветка, она уходит немного вбок. Я ее поместил на одном уровне с тимлидом и техлидом, но где-то она чуть выше. Это роль архитектора, человека, который выходит на новый уровень и начинает строить свои города, замки, гайды, подсказывать всем “сюда не ходи, туда ходи”. В общем, пытается всех скоординировать. Дальше архитектора, судя по опросу, для разработчика ничего нет.
Следующим шагом для большинства моих знакомых разработчиков по-прежнему остаётся менеджерский трек — то есть руководитель разработки. Это человек, который отвечает за целое направление. У него десятки команд в подчинении. Он руководит командой из менеджеров, тимлидов или техлидов. Это моё видение ситуации в России.
Как это работает в Booking.com
Давайте я расскажу, как выглядит путь программиста в Booking.com. В компании есть ступени: Graduate Software Developer, Software Developer и Senior Developer. Они соответствуют привычным Junior, Middle и Senior. После этого есть ряд ступеней:
Lead Developer;
Principal Developer;
Fellow Principal Developer.
На этих ступенях ты растёшь, но остаёшься в инженерном треке.
Lead Developer — обычный человек, который работает на уровне отдела, в составе нескольких команд, про него мы поговорим чуть позже. Principal работает на уровне департамента, т.е. какой-то группы отделов. Fellow — человек, чей ранг соотносится с высшим руководством. Смело можно ставить в ряд с VP (вице-президентом) или Senior Director — то есть, это очень высокая должность.
Если вернуться к первой схеме, должность тимлида и техлида смешивается с теми заслугами, которые есть у человека. Тимлид и техлид это одновременно должность. Она определяет тебя по иерархии, к нему привязываются компенсации, и вместе с тем это роль, которую ты выполняешь.
В Booking.com — и это устойчивый тренд в западных компаниях — роль и должность разные вещи. Перед собой вы видите только должности. Ты можешь быть Lead Developer, но это не определяет твои обязанности.
Как расти не в менеджмент
В первых трёх ступенях разработчик должен расти. От инженера уровня Graduate ожидается, что в течении года он перейдёт на следующий уровень. Никому не прикольно, когда человеку нужно постоянно помогать — хочется, чтобы он работал самостоятельно.
Переход от просто Software к Senior Developer в зависимости от человека занимает 1-2 года, и предполагается, что разработчик этот переход все же совершит. А вот в отношении должностей выше больших ожиданий нет. Я знаю людей, которые очень долго работают в определенной позиции, потому что им это нравится и они счастливы.
Есть сайт levels.fyi. Он позволяет сравнивать карьерные лестницы между компаниями. Сейчас я показываю карьерные лестницы крупных IT компаний, т.е. Apple, Amazon, Google, Facebook и Microsoft. Это исключительно инженерные карьеры, но есть и классический менеджерский путь — его можно посмотреть на том же сайте.
В Google картина примерно такая же, как в Booking.com. Software Engineer (SWE) II - III примерно соответствует Junior-Middle-Senior. После Senior идет целых 5 карьерных шагов — то есть 5 дополнительных звёздочек, которые вы можете получить на свои погоны. Это Staff Engineer — моя текущая позиция в Databricks (их карьерный путь копирует путь Google один в один). После этого есть седьмой уровень, Senior Staff, Principle Engineer, Distinguished Engineer и Google Fellow. Людей на последней должности можно пересчитать по пальцам. Это уровень VP.
На одного Fellow в компании приходится тысяча разработчиков. На Principal Engineer и Distinguished Engineer — пара сотен. Senior Staff Engineer — один из 100, и Staff Engineer это один на 10-20 человек. Они работают обычно на этих уровнях.
Какие есть архетипы
Отдельно я бы хотел поговорить про архетипы. Есть звание, должность, а дальше появляется то, чем вы конкретно занимаетесь.
Первый архетип — классический Techlead. Он есть и на российском рынке, но здесь разница в том, что менеджерских задач там не так много. Например, личностный рост и менторинг сотрудников входит в обязанности и менеджера, и техлида. Но техлид не будет заниматься наймом и увольнением. Он может участвовать в интервью, но не более того. Он может участвовать в планировании и бюджетировании, но он за это не отвечает. Это не его основная обязанность.
Его основные обязанности — это выбор технологии, помощь команде и разблокирование. То есть, если человек застрял на процессе коммуникации или сложной технической проблеме, я должен ему помочь — разблокировать его. К этому относится ревью кода, менторинг и общий технический взгляд в моем направлении.
Следующий архетип — это Architect. В России он тоже присутствует на рынке, но здесь я имею ввиду отдельную должность. Задачи зависят от ваших целей: сначала вы можете проектировать архитектуру для группы команд, как Staff Engineer. А если захотите расти — начнете проектировать архитектуру и решать огромные стратегические бизнес-задачи в рамках всей компании.
В ранге архитектора вы можете расти по своим должностям, переходя из Staff Engineer в Senior Staff Engineer и выше. Архитектор — градопланировщик. Сам он не больно строит. Это человек, который следит, чтобы в городе больницы не строились рядом с очистными сооружениями, детскую площадку не разместили в промышленной зоне, чтобы провели коммуникации и проложили широкие дороги. В общем, занят высокоуровневыми вещами. А что конкретно происходит в спальном районе, какие дома строили, сколько там квадратных метров в студии — это работа команд на местах.
Есть ещё два интересных архетипа, с которыми я сталкивался лично. Code machine — это человек, который потрясающе пишет код. Здесь идет речь именно про работу на грани, про какие-то выдающиеся результаты, когда человек с феноменальной скоростью решает проблемы и закрывает баги. Он может делать это не только у себя в команде, но и в соседних.
Если Code Machine больше про скорость и про широту охвата, то Expert — эксперт мирового уровня, или близко к этому. Это узкая специализация, которая позволяет решать очень сложные технические проблемы. В решении задач он тоже может помогать другим командам, делиться экспертизой, в общем — делать так, чтобы людям было проще с их проблематикой. Например, сейчас в Databricks работает такой человек. Он очень хорошо разбирается в фреймворках межсервисного взаимодействия и находится именно в экспертной позиции, не отвечая ни за какую конкретную команду.
Кому отчитываются Fellow Software Developers?
Стоит понять: должность это именно про promotion, про ваши заслуги. Она говорит о том, на каком уровне вы в состоянии работать — и она не определяет, кому вы отчитываетесь.
У меня есть несколько примеров, когда даже Fellow Engineer, человек, стоящий на самой высокой ступени в карьерной лестнице, был в подчинении у простого тимлида. Была команда, которая решала критически важную бизнес задачу по выстраиванию фреймворка для экспериментов. Зная Booking.com — это ключ всего успеха и его секретный ингредиент. Команда работала над решением очень важной технической задачи, человек действительно хорошо понимал как это нужно делать. Он, будучи Principal и Fellow, имел доступ и к высокоуровневым каналам коммуникации связи, он входил в архитектурные ревью, он мог пойти к CTO и проконсультироваться с ним. И при этом он работал на уровне обычной команды. Это была временная ситуация, но тем не менее.
Наблюдается тенденция: с высокой должностью ты работаешь уже на уровне кросс-командного взаимодействия — где-то на уровне нескольких команд, где-то на уровне департамента. Но эта позиция за тобой не закрепляется. Ты можешь немножко опускаться до проблематики определенной команды, чтобы помочь ей с конкретной проблемой.
Будучи Principal Engineer, я работал над облачной платформой. По архетипам я был сочетанием Techlead и code machine. Важно понимать, я был IC, individual contributor, то есть официально у меня не было людей в подчинении. Но тем не менее у меня была команда, в которой я был лидер. Я определял технологию направления развития, где-то я мог выдавать задачи, где-то я мог контролировать, но официально мне никто не подчинялся. Это было 5 команд, в общей сумме 30-40 человек, и мы все вместе делали платформу. Я определял стек технологий, но при этом в определенный момент мы переходили с Openshift на Kubernetes. Мы принимали решение о том, как мы будем делать deployment. За что отвечал я: сбор требований, переговоры, что лучше/что хуже — то есть, общая координация и коммуникация в том числе.
Говоря про вклад: можно вносить свой вклад, оставаясь инженером. Но важно, чтобы ваша работа и ваши действия волной подхватывали людей вокруг и помогали им ускоряться и расти. С ростом ваших званий масштаб и сила волны должны постоянно нарастать.
Если вы большой эксперт в кросс-платформенном взаимодействии, можно выдать рекомендацию, создать tooling, создать автоматизацию. Главное: от вашей работы жизнь других людей должна становиться проще и легче. На английском это называется force multiplication: когда ваше конкретное действие приводит к кумулятивному эффекту и позволяет компании быстрее или эффективнее достигать своих бизнес результатов. С этой точки вы начинаете приносить пользу.
К чему я клоню
Если вы руководитель, то не надо тянуть в менеджмент ваших технических инженеров только потому, что это следующий карьерный шаг. Кажется, российскому рынку надо пытаться перестроиться и измениться, а менеджменту — понять, что человек может принести пользу бизнесу, оставаясь на инженерных позициях. Потому что для многих людей это их экспертиза. Это то, что их драйвит. То откуда они черпают свою энергию.
А если вы инженер и разработчик, расскажите: в других местах это работает, давайте попробуем сделать тоже самое. Сделайте запрос — спрос же всегда рождает предложение. Просите, разговаривайте. Понятное дело, что сразу же в один день ничего магическим образом не случится. Но, мне кажется, нам нужно постоянно говорить об этом, и тогда индустрия изменится. Постепенно мы придем к тому, что нет необходимости переводить инженера на менеджерский путь, начинать заниматься какими-нибудь performance review.
GetMentor.dev — открытое сообщество IT-профессионалов, готовых делиться опытом и экспертизой. Мы помогаем решать проблемы тем, кто к нам обращается, и сами ищем новые возможности для роста и развития.
Иван Круглов — один из многих менторов, с которыми вы можете посоветоваться на нашем сайте. В нашем сообществе в Telegram мы обсуждаем разные вопросы, важные и не очень. Подписывайтесь — будем на связи.
Часть иллюстраций честно взята с icons8.com
