В российских компаниях классический путь программиста заканчивается на должности тимлида или tech lead. Дальше — всё больше менеджера, всё меньше инженера. Хочешь расти в компании — берись за управление людьми, нравится тебе это или нет.
Но что, если есть другой путь? Опыт западных компаний показывает, что можно дать программисту остаться в разработке, а в менеджеры брать тех, у кого есть желание. И это не пойдёт бизнесу в убыток. Наоборот — разработчик сможет вносить бóльший вклад в работу компании и наработать уникальную экспертизу. А ещё не выгорит от бесконечных code review. В этой статье Иван Круглов расскажет, как разработчику расти, минуя менеджмент.
Должность у меня Staff Engineer, позиция Tech Lead. Я отвечаю за команду, которая разрабатывает один из бизнес-критических сервисов. Классическая история: традиционный монолит перерос по нагрузке все возможности, которые изначально в него закладывались, поэтому нужно перестраивать, перекраивать, пересобирать и делать так, чтобы всё работало.
В Databricks я не очень долго, с прошлого апреля. Никогда не был в офисе: когда я пришёл, ввели все карантинные меры. Даже пропуска в офис нет. И с коллегами вживую виделся один или два раза.
До этого я семь лет провел в Booking.com. Пришёл туда как разработчик и прошёл весь путь до Principal Engineer.Самым большим достижением считаю создание нового PaaS: внутреннего облака на kubernetes. В сумме у нас было 2000 нод с большой автоматизацией, позволяющей автоматически получать доступ к различным ресурсам. Еще я внедрил service mesh, про это я рассказывал на конференции Highload++.
Когда GDPR только входил в наш лексикон, я построил внутренний сервис, который позволил компании соответствовать требованиям регламента. Тогда это было очень важно — приходилось перекраивать если не все внутренние процессы, то большинство. Потому что раньше данные были везде, а теперь их нужно свести в одно место и перестроить внутренние сервисы, чтобы они данные брали из единого места, но продолжали работать как раньше.
Также работал над нашим поисковым движком. Когда вы ищете на Booking.com отель в Москве и нажимаете на кнопку поиск, он производится в том числе с помощью моего сервиса, над которым я работал. Тоже интересный проект.
В 2013 году я переехал в Амстердам. До этого я жил и работал в Иркутске, в компании ISPSystem — поддерживал и разрабатывал панели управления. Одно время я даже был тимлидом. Примерно в то же время у меня отбилось желание быть тимлидом, и с тех пор каждый раз, когда спрашивают “Хочешь в менеджмент?” я говорю — нет.
Пока что я продолжаю с переменными успехами двигаться по карьерной лестнице и оставаться инженером, и об этом я хочу поговорить поподробнее.
Junior — человек только с института. Опыта мало. Ему нужно выдавать задачи, его нужно постоянно контролировать, поддерживать.
В позиции Middle человеку по-прежнему нужно выдавать задачи, но он может делать их самостоятельно и проявлять какую-то инициативность. Он беспокоит вас не так часто.
Senior может выдавать задачи и себе, и коллегам. Его не нужно мониторить, не нужно сопровождать. Он автономный боевой юнит — сам вступит в бой, сам расставит войска, сам даст команду.
После этого появляется тимлид или техлид. На этом этапе человек уже начинает отвечать за некоторые направления, во главе команды или нескольких команд. Где-то он выступает в роли менеджера.
Сразу оговорюсь: под общим словом “менеджер” я имею в виду people менеджера, который руководит людьми и отвечает за их рост. И в меньшей степени product менеджера или project менеджера.
Техлиду начинают примешивать всё больше задач по управлению людьми и проектом, и все меньше программистских задач — того, что обычно всем нравится. За этой ступенью есть определённая техническая ветка, она уходит немного вбок. Я ее поместил на одном уровне с тимлидом и техлидом, но где-то она чуть выше. Это роль архитектора, человека, который выходит на новый уровень и начинает строить свои города, замки, гайды, подсказывать всем “сюда не ходи, туда ходи”. В общем, пытается всех скоординировать. Дальше архитектора, судя по опросу, для разработчика ничего нет.
Следующим шагом для большинства моих знакомых разработчиков по-прежнему остаётся менеджерский трек — то есть руководитель разработки. Это человек, который отвечает за целое направление. У него десятки команд в подчинении. Он руководит командой из менеджеров, тимлидов или техлидов. Это моё видение ситуации в России.
Lead Developer — обычный человек, который работает на уровне отдела, в составе нескольких команд, про него мы поговорим чуть позже. Principal работает на уровне департамента, т.е. какой-то группы отделов. Fellow — человек, чей ранг соотносится с высшим руководством. Смело можно ставить в ряд с VP (вице-президентом) или Senior Director — то есть, это очень высокая должность.
Если вернуться к первой схеме, должность тимлида и техлида смешивается с теми заслугами, которые есть у человека. Тимлид и техлид это одновременно должность. Она определяет тебя по иерархии, к нему привязываются компенсации, и вместе с тем это роль, которую ты выполняешь.
В Booking.com — и это устойчивый тренд в западных компаниях — роль и должность разные вещи. Перед собой вы видите только должности. Ты можешь быть Lead Developer, но это не определяет твои обязанности.
Переход от просто 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 Engineer, человек, стоящий на самой высокой ступени в карьерной лестнице, был в подчинении у простого тимлида. Была команда, которая решала критически важную бизнес задачу по выстраиванию фреймворка для экспериментов. Зная Booking.com — это ключ всего успеха и его секретный ингредиент. Команда работала над решением очень важной технической задачи, человек действительно хорошо понимал как это нужно делать. Он, будучи Principal и Fellow, имел доступ и к высокоуровневым каналам коммуникации связи, он входил в архитектурные ревью, он мог пойти к CTO и проконсультироваться с ним. И при этом он работал на уровне обычной команды. Это была временная ситуация, но тем не менее.
Наблюдается тенденция: с высокой должностью ты работаешь уже на уровне кросс-командного взаимодействия — где-то на уровне нескольких команд, где-то на уровне департамента. Но эта позиция за тобой не закрепляется. Ты можешь немножко опускаться до проблематики определенной команды, чтобы помочь ей с конкретной проблемой.
Будучи Principal Engineer, я работал над облачной платформой. По архетипам я был сочетанием Techlead и code machine. Важно понимать, я был IC, individual contributor, то есть официально у меня не было людей в подчинении. Но тем не менее у меня была команда, в которой я был лидер. Я определял технологию направления развития, где-то я мог выдавать задачи, где-то я мог контролировать, но официально мне никто не подчинялся. Это было 5 команд, в общей сумме 30-40 человек, и мы все вместе делали платформу. Я определял стек технологий, но при этом в определенный момент мы переходили с Openshift на Kubernetes. Мы принимали решение о том, как мы будем делать deployment. За что отвечал я: сбор требований, переговоры, что лучше/что хуже — то есть, общая координация и коммуникация в том числе.
А если вы инженер и разработчик, расскажите: в других местах это работает, давайте попробуем сделать тоже самое. Сделайте запрос — спрос же всегда рождает предложение. Просите, разговаривайте. Понятное дело, что сразу же в один день ничего магическим образом не случится. Но, мне кажется, нам нужно постоянно говорить об этом, и тогда индустрия изменится. Постепенно мы придем к тому, что нет необходимости переводить инженера на менеджерский путь, начинать заниматься какими-нибудь performance review.
GetMentor.dev — открытое сообщество IT-профессионалов, готовых делиться опытом и экспертизой. Мы помогаем решать проблемы тем, кто к нам обращается, и сами ищем новые возможности для роста и развития.
Иван Круглов — один из многих менторов, с которыми вы можете посоветоваться на нашем сайте. В нашем сообществе в Telegram мы обсуждаем разные вопросы, важные и не очень. Подписывайтесь — будем на связи.
habr.com
Но что, если есть другой путь? Опыт западных компаний показывает, что можно дать программисту остаться в разработке, а в менеджеры брать тех, у кого есть желание. И это не пойдёт бизнесу в убыток. Наоборот — разработчик сможет вносить бóльший вклад в работу компании и наработать уникальную экспертизу. А ещё не выгорит от бесконечных 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 мы обсуждаем разные вопросы, важные и не очень. Подписывайтесь — будем на связи.
Есть ли жизнь после разработки: Как расти, минуя менеджмент
В российских компаниях классический путь программиста заканчивается на должности тимлида или tech lead. Дальше — всё больше менеджера, всё меньше инженера. Хочешь расти в компании — берись за...
habr.com