Мы все пришли в IT разными путями. Кто-то шёл по этому пути с самого детства, другие начали свой путь с выбора института и computer science в качестве основной дисциплины. Есть и те, кто свернул на эту дорогу, уже имея другую профессию и опыт работы совсем в другой сфере.

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

Я сам прошел путь от Junior-инженера до Technical Unit Lead в крупной компании. Мой собственный путь не был оптимальным: каждый мой шаг можно было сделать быстрее и проще. Мои ошибки дали мне колоссальный опыт, который я использую сейчас, чтобы помочь вырасти другим инженерам. Надеюсь и вам он тоже поможет.

Junior → Middle

Когда Junior-инженер начинает свой путь, он почти ничего не умеет. У него могут быть теоретические знания: например, пройти несколько курсов или прочитать несколько книг. А практического опыта очень мало: он не знает best-practice, часто ошибается и ходит кругами. Его решения неэффективны: в лучшем случае, они просто работают. В худшем — ломаются сами и уничтожают всё на своем пути. Все мы слышали историю о Junior-инженере, который уничтожил базу данных в проде.

Junior-инженеру в этот момент важно найти наставника, который направит его в правильную сторону, поможет освоить базовые принципы разработки, покажет, как эффективно использовать инструменты и избегать типовых ошибок.

Это не значит, что самообучение теряет ценность. Наоборот, Junior-инженер должен приложить много усилий для развития своих навыков. Он должен научиться учиться и понять, как искать новую информацию в неизвестной области. Задача хорошего наставника — подсказать, что из потока информации действительно важно сейчас, а что лучше отложить на потом.

Хорошая новость: процесс роста от Junior- к Middle-инженеру выстроен и работает во многих крупных компаниях. Часто новичок на старте получает план развития, набор задач подходящей сложности и наставника. Всё это позволяет быстро расти. Получается, что самая быстрая дорога к позиции Middle-инженера — попасть в хорошую IT-компанию.

Плохая новость в том, что не все компании охотно берут Junior-разработчиков, а если и берут, то предъявляют к ним неоправданно высокие требования.

Вот лазейки, которыми можно воспользоваться:

1. Найти компанию, которая нанимает стажёров и отправить резюме для стажёрской программы. Конкурс на одно место может быть очень большим, поэтому требования высокие. Тем не менее, требования для стажёров существенно ниже чем для Junior-разработчиков. Начать со стажерской программы и вырасти внутри компании проще, чем устроиться на позицию Junior-инженера без опыта.

2. Самостоятельно отрабатывать навыки на pet-проектах или open-source проектах в областях, близких к тому, чем занимается компания мечты. Вместе с ростом практического опыта растут и шансы устроиться в крупную компанию. Это длинный путь, по которому прошел я сам.

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

Мне повезло: компания занималась решением сложных технических проблем и работала над нетиповыми решениями. Мне удалось поработать с несколькими языками программирования, круто прокачаться в работе с Linux, пощупать сразу несколько принципиально разных баз данных и очередей сообщений. Я активно контрибьютил в open-source проекты и даже какое-то время был мейнтейнером одного из них.

Основная сложность была в том, что в этой компании не было продуманного механизма развития инженеров. Каждый был сам за себя и сам добывал те знания, которые были нужны ему в моменте. У меня не было ни наставника, ни какого-то системного подхода к развитию. Я, как и другие инженеры в компании, просто решал возникающие передо мной задачи.

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

Независимо от выбранного пути Junior-инженеру нельзя забывать о важности упорного труда и непрерывного обучения. Только так можно подняться по кривой обучения и сделать следующий шаг — получить Middle-грейд.

Middle → Senior

Основное отличие Middle-инженера от Junior — он имеет практические навыки и опыт самостоятельного решения реальных проблем. Он может декомпозировать большие задачи на отдельные этапы, исследовать проблему и самостоятельно искать варианты решения во внешних источниках знаний. Ну и конечно, он умеет писать код и эффективно использовать инструменты разработки.

Чего он пока не умеет, так это видеть всю картину происходящего целиком. В решении проблем он действует реактивно, устраняя симптомы, а не проактивно — устраняя причины появления проблем. Он редко видит взаимосвязи между несколькими проблемами и пытается решить их по отдельности. Даже если инженер делает это качественно и эффективно, такая работа отнимает много времени и сил. Middle-инженер просто не понимает, что у нескольких, внешне не связанных проблем может быть одна первопричина.

Развитие Middle-инженера носит хаотичный характер. Он подключается туда, где нужен прямо сейчас и осваивает те технологии и навыки, которые нужны для решения сегодняшних проблем. В таком развитии нет ни четкой осознанной цели, ни системности в подходах.

С другой стороны, Middle-инженер на этом этапе нарабатывает широкий кругозор в технологиях и подходах. Например, он может разбираться в 3 разных СУБД, но не быть экспертом ни в одной из них. Такой подход помогает инженеру расти, но в какой-то момент широта накапливаемых знаний должна смениться глубиной. В противном случае, мы рискуем получить Middle-инженера с 10 годами опыта, который никак не может стать Senior.

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

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

Плохая новость в том, что системы развития Middle-инженеров существуют и хорошо настроены далеко не в каждой компании. В одних компаниях они просто отсутствуют, в других — существуют только на бумаге. А если и существуют, то могут быть настолько сложны и непонятны, что пользоваться ими невозможно. Даже работа в крупных отраслевых компаниях вовсе не дает гарантии, что Middle-инженер сможет вырасти до Senior-уровня.

В отличии от прогресса Junior-инженера для Middle-уровня любая крупная компания уже не подходит. Нужна крупная компания с развитой инженерной культурой.

Кроме этого, нужно понимать, что очень многое зависит от непосредственного руководителя. Если инженеру повезло — руководитель будет использовать своё время и ресурсы компании, чтобы помочь инженеру вырасти. Но что делать, если руководитель не заинтересован в росте?

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

Сам я добрался до Middle-уровня ещё в своей первой аутсорс-компании. Через некоторое время мне стало понятно, что дальше эффективно расти у меня не получится и единственный выбор — менять компанию. Я устроился на работу в крупный международный банк. Это было не идеальным решением: даже в передовых банках с курсом на диджитализацию бизнеса инженерная культура отстаёт от передовых IT-компаний.

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

Рабочие задачи помогали мне расти, но со стороны компании не было системного подхода. Для меня, как для Middle-инженера это уже не было проблемой — я сам определял свой путь. Через какое-то время я стал формальным лидером гильдии и в мои задачи уже входило помогать менее опытным инженерам проходить тот путь, который прошёл я.

В этот момент я открыл для себя ещё один менее очевидный, но более эффективный способ вырасти в Senior-инженера — найти наставника. При этом наставником не обязательно должен стать руководитель или кто-то из команды. Наставником может быть любой Senior-инженер, который уже прошел этот путь сам и хочет помочь пройти этот путь другим. Более того, наставник и его подопечный даже могут работать в разных компаниях.

Наставник поможет найти сильные и слабые стороны инженера и составить план развития. Он поможет сосредоточиться на следующем ближайшем шаге, который действительно необходим для роста и отложить на потом все то, что сейчас не важно. Также наставник покажет неочевидные способы решения задач и поделится best-practice из своего личного опыта. Используя чужой опыт, Middle-инженер сможет избежать типовых ошибок и вырасти быстрее. Ему не нужно будет каждый раз нащупывать эффективные решения самому.

Когда Middle-инженер решает сложную проблему, наставник может стать для него оппонентом в обсуждении. Разные точки зрения в одном и том же вопросе помогут не только найти лучшее решение, но и развить навык поиска компромиссов при решении сложных проблем.

Сейчас, когда я занимаюсь развитием инженеров в своих командах, я почти всегда выбираю для них наставника. Это может быть как один человек, который полностью курирует развитие, так и несколько, которые помогут лучше освоится в отдельных компетенциях. Вместе с чёткими целями и планом развития наставник делает развитие максимально эффективным.

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

Станет ли дальнейший путь проще? Вовсе нет!

Senior → Team Lead

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

Если для инженера самое главное — это уметь писать код и решать технические проблемы, то для тимлида критически важно решать проблемы взаимодействия людей друг с другом. Добавим сюда ответственность за всю систему целиком, необходимость точно планировать сроки и бюджет проекта, а также бесконечное количество рабочих процессов за которыми нужно постоянно следить и только тогда мы получим портрет среднестатистического тимлида. Это буквально другая работа.

Когда я проходил этот этап сам, мне очень хотелось брать пример с моего тимлида. Я хотел узнать: 

• как именно он решает типовые проблемы в работе с людьми;

• как можно сделать процессы более эффективными;

• с чего начинать наводить порядок в команде;

• на что обращать внимание при запуске нового проекта;

• как решать системные проблемы до их возникновения. 

Я искал простого и быстрого пути.

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

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

Уже будучи тимлидом, в какой-то момент я понял, что руководителей, которые действительно помогают Senior-инженерам стать тимлидами — единицы.

Имя компании здесь не имеет значения. Даже в крупных компаниях с высоким уровнем инженерной культуры достаточно мало руководителей, которые помогут инженеру стать тимлидом и сделают этот путь быстрым и безболезненным. Если очень повезёт, инженеру не будут мешать и дадут возможность вырасти самому, но целенаправленно его никто развивать не станет.

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

Но что делать, если Senior-инженер всё-таки хочет стать тимлидом? Есть сразу несколько путей достижения цели.

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

Ещё инженер может найти команду без руководителя и притворяться тимлидом, пока не получится. В худшем случае команда сгорит, проект закроется, а инженер пойдёт искать новую работу. В лучшем — через несколько лет и несколько крупных провалов инженер через боль и страдания освоит навыки тимлида и станет эффективным руководителем.

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

Важно помнить, что потенциальный наставник должен сам пройти путь от Senior-инженера до тимлида. Наставник должен быть успешным тимлидом и обладать теми практическими навыками, которыми хочет овладеть Senior-инженер. Корпоративные коучи, специалисты по обучению и ведущие тренингов не помогут. Они умеют хорошо передавать теоретические знания, но просто не понимают с какими проблемами сталкивается начинающий тимлид на практике.

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

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

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

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

Что ещё важно помнить

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

Чем дальше вы продвинетесь, тем сложнее будет каждый следующий шаг. Опытный наставник поможет сделать этот путь проще.

Знания в менеджерском треке зачастую интуитивны и не поддаются чёткому описанию в книгах и учебниках. Именно поэтому наставник так важен при переходе из инженерного трека в менеджерский.

Мы все были новичками, поэтому уважайте других новичков и помогайте им. Помогайте тем, кто ещё не достиг вашего уровня. Делитесь теми навыками и знаниями, которые у вас уже есть. Помните, что даже самые простые ваши навыки могут быть полезны тем, кто их ещё не имеет. Передача опыта поможет вам отрабатывать эти навыки и самому развиваться быстрее.

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

Предыдущая статья: Как искать уязвимости в проекте на Go: обзор популярных анализаторов кода и их возможностей