Говорят, что профессионалом в своей области становишься в среднем после 5 лет активной работы. Тяга к самореализации остается, но на текущей позиции что-либо сделать в этом направлении не получается. И в этот момент ты встаешь перед стандартным для русских сказок перепутьем. Можно сменить работу, но если в общих чертах круг обязанностей и стек не изменятся, новизна быстро пройдет, снова уступив место рутине. Можно идти в тимлиды, но придется взвалить на себя кучу административки.
Под катом — о том, так ли все страшно, глазами специалистов из “Максилекта”, уже проходивших через аналогичный выбор.
Специалисту умственного труда необходимо постоянно развиваться, причем не только ради востребованности на рынке труда. Расширение спектра знаний — личностная потребность, для некоторых даже источник самореализации.
Закрывать эту потребность можно по-разному. Можно периодически кардинально менять предметную область, например, из разработки каких-то интеграционных вещей перейти в big data или вообще покинуть ИТ, выбрав другую отрасль. Но обычно начинать все сначала желающих мало, поэтому прыжков “с места в карьер” (в незнакомую область) избегают, предпочитая искать пути развития поблизости. Об этом и поговорим.
Очевидный путь развития разработчика — в тимлиды, менеджеры проекта или еще выше по административной лестнице — в сторону управления все большей командой.
Становясь тимлидом, вчерашний разработчик все так же погружен в проект, но у него появляется больше административных обязанностей — взаимодействие с заказчиками, управление командой, распределение задач, контроль выполнения и сроков, оценка новых этапов проекта и т.п. Решение всех этих вопросов требует большого количества коммуникаций. А попытка сделать эти коммуникации более эффективными тянет за собой развитие навыков управления конфликтами, оценки рисков, делегирования и т.п., так что в режиме постоянного обучения ощущению рутины будет просто неоткуда появиться.
Конечно, не всем это нравится. Если до перехода на руководящий уровень вопросы собственной мотивации и управления рабочим временем не были взяты под контроль, может возникнуть ощущение, что тебя буквально рвут на части в течение рабочего дня. Но когда эти первые сложности получится преодолеть, руководящий статус станет новым челенджем и даже приобретет оттенок некой романтики.
Увы, одновременно все это означает, что доля рабочего времени, посвященная непосредственному написанию кода, будет сокращаться. И это неизбежно ведет к потере квалификации в этой теме. Чтобы спустя несколько месяцев с руководящей позиции вернуться на должность линейного разработчика, потребуется наверстывать упущенное. А если пройдет год или два, упущенного накопится так много, что на возвращение придется потратить много времени. Хотя наши наблюдения за рынком показывают, что через год-два часть новоиспеченных менеджеров действительно возвращается в разработку, так что путь назад не закрыт.
Не стоит воспринимать переход на уровень тимлидов и выше как почетное завершение карьеры. Это развитие в ином направлении. Компетенции, которые необходимы (и неизбежно развиваются) на позиции руководителя, — способность шире смотреть на проблему и решать задачи более высокого уровня, софт-скиллы — открывают доступ к принципиально иным, интересным вещам. Например, к выбору стека технологий, формированию команды, выбору архитектуры на проекте. По каждому из таких вопросов придется учитывать массу частных факторов, от распространенности до перспектив развития платформ-кандидатов. Имея большой бэкграунд за спиной и стратегическое видение руководителя, ты можешь решать такие задачи. И твое решение будет иметь для проекта ключевое значение.
Надо помнить, что путь менеджера — это и не универсальный ответ на все вопросы. Он не для всех. С первой же руководящей ступени придется учиться нести ответственность за все, что происходит вокруг — в первую очередь за команду, сроки и бюджет проекта. Придется выйти из своего уютного ИТ-мира и одновременно говорить со сторонниками разных взглядов на ситуацию — с разработкой и бизнесом — выступая своего рода переводчиком. Грубо говоря, уже не получится объяснять необходимость оптимизации кода лишь тем, что тот “некрасив”. Придется вникнуть в детали и представить бизнес-последствия каждого из вариантов решений.
Не всем в этом мире стоит идти в менеджеры, ведь не каждый видит в этом венец своей карьеры (о том, лучше ли это, чем писать код, можно спорить бесконечно).
Решая задачи в своей сфере, опыт получают все — т.е. все в каком-то смысле растут технически, кто-то быстрее, кто-то медленнее. Техническая специализация не имеет своего “потолка”. По мере развития в этом направлении ты фокусируешься на более сложных технологических вещах, глубже в них разбираешься. Когда ты вырастаешь далеко за пределы сениора, становишься своего рода “гуру”, для которых в западных компаниях даже есть свое наименование — principal.
Грамотных нишевых специалистов, способных крутить и обрабатывать огромные объемы данных, строить low-latency архитектуру или разбирающихся в перформансе Java, на рынке не так много, поэтому востребованность и ценность человека как специалиста растет. Хотя при этом диапазон вакансий сужается, а спектр ожидаемых навыков увеличивается. Помимо решения технических задач, на специалиста уровня principal, например, могут возложить задачу код-ревью, за счет которого его собственный опыт станет достоянием команды (ключевой момент в том, что он должен объяснять, почему надо делать так, а не иначе). Что касается денег, то здесь как повезет. У разработчиков зарплата, возможно, и не больше, чем у менеджеров, но стабильность и предсказуемость обычно выше.
Развитие в технологическом направлении в нашем быстро меняющемся мире — это состояние постоянного обучения. Казалось бы, возраст не способствует ускорению обучения (блокируя дальнейшее развитие в данном направлении), но в этом статусе и нет необходимости гнаться за самыми последними фреймворками и опубликованными вчера библиотеками. В дополнение к глубоким знаниям у человека начинает работать основанная на опыте интуиция. Так что не стоит думать, что в 40 жизнь разработчика заканчивается;)
Обычно все ограничивается рассмотрением двух перечисленных выше вариа��тов. На самом деле путей множество. Не имея возможности рассмотреть все без исключения, хочется сделать акцент еще на одной группе вероятностей. Если не столько развивать софт-скилы, сколько брать на себя ответственность, вчерашний сениор приходит к уровню системного архитектора или явным образом выделенного в команде техлида (как именно эта роль называется в проекте, зависит от конкретной компании).
По мере продвижения по этому пути ты берешь на себя ответственность за создание все более масштабных и сложных систем. Кстати, это характерно и для principal. Если уж ты обещаешь, что у тебя есть экспертиза в перформансе сложных систем, ты берешь на себя ответственность за нее. Но от квалифицированного разработчика, который пишет особо важные куски кода, системного архитектора и техлида отличает степень этой ответственности.
В целом архитектурное направление развития проще воспринимать как нечто среднее между технологическим и менеджерским путем. И там, и там есть своя доля ответственности, но в первом случае важна ответственность за системы, во втором — за людей (если сложная система так и не реализована, заказчик в первую очередь пойдет к менеджеру, а если в этот момент менеджер попытается переложить ответственность на разработчиков, это плохой менеджер). Но в отличие от менеджера, архитектор может не обладать такими прокачанными софт-скиллами.
Несмотря на то, что технических познаний архитектору или техлиду нужно больше, чем на позиции руководителя, код они тоже пишут в меньшем объеме, нежели рядовые разработчики.
Иногда хочется не менять круг обязанностей, а сохранить все как есть, но добавить немного драйва в саму работу. И первый порыв — сменить компанию, чтобы поискать более “веселенькую” команду. Но тут важно понимать, что драйв зачастую приходит вместе с рисками. Стабильные проекты обычно самые скучные. Драйв же ассоциируется с созданием своего собственного продукта или с участием в стартапе, которые могут не взлететь из-за промаха маркетинга, ошибки с целевой аудиторией или миллиона других причин, иногда даже не связанных с конечной разработкой (особенности процесса запуска продукта — это тема для отдельного разговора).
Вопрос, который надо задать себе, звучит просто: позволяют ли жизненные обстоятельства в экстренном случае некоторое время посидеть без денег и выйти на поиск работы? Если другие пути не нравятся, трезво оценивая риски, можно хотя бы подготовить подушку безопасности перед тем, как искать драйва.
Речь о рисках можно вести в контексте любого из перечисленных путей. Даже развитие по технологической ветке, где помимо углубления в любимую область, казалось бы, ничего специально делать не надо, — это решение, за которое придется нести ответственность как минимум перед собой.
А как складывается ваш карьерный путь? Осознанно ли вы выбирали это направление развития? Кем вы видите себя в будущем?
Эта статья — четвертая часть нашего цикла публикаций о карьере ИТ-шника.
Первая часть здесь.
Вторая часть здесь.
Третья часть здесь.
Коллектив компании Maxilect.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
P.P.S. С наступающим 2020 Новым годом! Желаем в Новом году двигаться в правильном направлении!
Под катом — о том, так ли все страшно, глазами специалистов из “Максилекта”, уже проходивших через аналогичный выбор.
Специалисту умственного труда необходимо постоянно развиваться, причем не только ради востребованности на рынке труда. Расширение спектра знаний — личностная потребность, для некоторых даже источник самореализации.
Закрывать эту потребность можно по-разному. Можно периодически кардинально менять предметную область, например, из разработки каких-то интеграционных вещей перейти в big data или вообще покинуть ИТ, выбрав другую отрасль. Но обычно начинать все сначала желающих мало, поэтому прыжков “с места в карьер” (в незнакомую область) избегают, предпочитая искать пути развития поблизости. Об этом и поговорим.
Направо пойдешь, развивая навыки руководителя, — станешь тимлидом или ПМ
Очевидный путь развития разработчика — в тимлиды, менеджеры проекта или еще выше по административной лестнице — в сторону управления все большей командой.
Становясь тимлидом, вчерашний разработчик все так же погружен в проект, но у него появляется больше административных обязанностей — взаимодействие с заказчиками, управление командой, распределение задач, контроль выполнения и сроков, оценка новых этапов проекта и т.п. Решение всех этих вопросов требует большого количества коммуникаций. А попытка сделать эти коммуникации более эффективными тянет за собой развитие навыков управления конфликтами, оценки рисков, делегирования и т.п., так что в режиме постоянного обучения ощущению рутины будет просто неоткуда появиться.
Конечно, не всем это нравится. Если до перехода на руководящий уровень вопросы собственной мотивации и управления рабочим временем не были взяты под контроль, может возникнуть ощущение, что тебя буквально рвут на части в течение рабочего дня. Но когда эти первые сложности получится преодолеть, руководящий статус станет новым челенджем и даже приобретет оттенок некой романтики.
Увы, одновременно все это означает, что доля рабочего времени, посвященная непосредственному написанию кода, будет сокращаться. И это неизбежно ведет к потере квалификации в этой теме. Чтобы спустя несколько месяцев с руководящей позиции вернуться на должность линейного разработчика, потребуется наверстывать упущенное. А если пройдет год или два, упущенного накопится так много, что на возвращение придется потратить много времени. Хотя наши наблюдения за рынком показывают, что через год-два часть новоиспеченных менеджеров действительно возвращается в разработку, так что путь назад не закрыт.
Не стоит воспринимать переход на уровень тимлидов и выше как почетное завершение карьеры. Это развитие в ином направлении. Компетенции, которые необходимы (и неизбежно развиваются) на позиции руководителя, — способность шире смотреть на проблему и решать задачи более высокого уровня, софт-скиллы — открывают доступ к принципиально иным, интересным вещам. Например, к выбору стека технологий, формированию команды, выбору архитектуры на проекте. По каждому из таких вопросов придется учитывать массу частных факторов, от распространенности до перспектив развития платформ-кандидатов. Имея большой бэкграунд за спиной и стратегическое видение руководителя, ты можешь решать такие задачи. И твое решение будет иметь для проекта ключевое значение.
Надо помнить, что путь менеджера — это и не универсальный ответ на все вопросы. Он не для всех. С первой же руководящей ступени придется учиться нести ответственность за все, что происходит вокруг — в первую очередь за команду, сроки и бюджет проекта. Придется выйти из своего уютного ИТ-мира и одновременно говорить со сторонниками разных взглядов на ситуацию — с разработкой и бизнесом — выступая своего рода переводчиком. Грубо говоря, уже не получится объяснять необходимость оптимизации кода лишь тем, что тот “некрасив”. Придется вникнуть в детали и представить бизнес-последствия каждого из вариантов решений.
Налево пойдешь, углубишься в технологию — станешь principal
Не всем в этом мире стоит идти в менеджеры, ведь не каждый видит в этом венец своей карьеры (о том, лучше ли это, чем писать код, можно спорить бесконечно).
Решая задачи в своей сфере, опыт получают все — т.е. все в каком-то смысле растут технически, кто-то быстрее, кто-то медленнее. Техническая специализация не имеет своего “потолка”. По мере развития в этом направлении ты фокусируешься на более сложных технологических вещах, глубже в них разбираешься. Когда ты вырастаешь далеко за пределы сениора, становишься своего рода “гуру”, для которых в западных компаниях даже есть свое наименование — principal.
Грамотных нишевых специалистов, способных крутить и обрабатывать огромные объемы данных, строить low-latency архитектуру или разбирающихся в перформансе Java, на рынке не так много, поэтому востребованность и ценность человека как специалиста растет. Хотя при этом диапазон вакансий сужается, а спектр ожидаемых навыков увеличивается. Помимо решения технических задач, на специалиста уровня principal, например, могут возложить задачу код-ревью, за счет которого его собственный опыт станет достоянием команды (ключевой момент в том, что он должен объяснять, почему надо делать так, а не иначе). Что касается денег, то здесь как повезет. У разработчиков зарплата, возможно, и не больше, чем у менеджеров, но стабильность и предсказуемость обычно выше.
Развитие в технологическом направлении в нашем быстро меняющемся мире — это состояние постоянного обучения. Казалось бы, возраст не способствует ускорению обучения (блокируя дальнейшее развитие в данном направлении), но в этом статусе и нет необходимости гнаться за самыми последними фреймворками и опубликованными вчера библиотеками. В дополнение к глубоким знаниям у человека начинает работать основанная на опыте интуиция. Так что не стоит думать, что в 40 жизнь разработчика заканчивается;)
Прямо пойдешь, разовьешь ответственность — станешь архитектором
Обычно все ограничивается рассмотрением двух перечисленных выше вариа��тов. На самом деле путей множество. Не имея возможности рассмотреть все без исключения, хочется сделать акцент еще на одной группе вероятностей. Если не столько развивать софт-скилы, сколько брать на себя ответственность, вчерашний сениор приходит к уровню системного архитектора или явным образом выделенного в команде техлида (как именно эта роль называется в проекте, зависит от конкретной компании).
По мере продвижения по этому пути ты берешь на себя ответственность за создание все более масштабных и сложных систем. Кстати, это характерно и для principal. Если уж ты обещаешь, что у тебя есть экспертиза в перформансе сложных систем, ты берешь на себя ответственность за нее. Но от квалифицированного разработчика, который пишет особо важные куски кода, системного архитектора и техлида отличает степень этой ответственности.
В целом архитектурное направление развития проще воспринимать как нечто среднее между технологическим и менеджерским путем. И там, и там есть своя доля ответственности, но в первом случае важна ответственность за системы, во втором — за людей (если сложная система так и не реализована, заказчик в первую очередь пойдет к менеджеру, а если в этот момент менеджер попытается переложить ответственность на разработчиков, это плохой менеджер). Но в отличие от менеджера, архитектор может не обладать такими прокачанными софт-скиллами.
Несмотря на то, что технических познаний архитектору или техлиду нужно больше, чем на позиции руководителя, код они тоже пишут в меньшем объеме, нежели рядовые разработчики.
Прежде чем сворачивать куда-то еще, оцени риски
Иногда хочется не менять круг обязанностей, а сохранить все как есть, но добавить немного драйва в саму работу. И первый порыв — сменить компанию, чтобы поискать более “веселенькую” команду. Но тут важно понимать, что драйв зачастую приходит вместе с рисками. Стабильные проекты обычно самые скучные. Драйв же ассоциируется с созданием своего собственного продукта или с участием в стартапе, которые могут не взлететь из-за промаха маркетинга, ошибки с целевой аудиторией или миллиона других причин, иногда даже не связанных с конечной разработкой (особенности процесса запуска продукта — это тема для отдельного разговора).
Вопрос, который надо задать себе, звучит просто: позволяют ли жизненные обстоятельства в экстренном случае некоторое время посидеть без денег и выйти на поиск работы? Если другие пути не нравятся, трезво оценивая риски, можно хотя бы подготовить подушку безопасности перед тем, как искать драйва.
Речь о рисках можно вести в контексте любого из перечисленных путей. Даже развитие по технологической ветке, где помимо углубления в любимую область, казалось бы, ничего специально делать не надо, — это решение, за которое придется нести ответственность как минимум перед собой.
А как складывается ваш карьерный путь? Осознанно ли вы выбирали это направление развития? Кем вы видите себя в будущем?
Эта статья — четвертая часть нашего цикла публикаций о карьере ИТ-шника.
Первая часть здесь.
Вторая часть здесь.
Третья часть здесь.
Коллектив компании Maxilect.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
P.P.S. С наступающим 2020 Новым годом! Желаем в Новом году двигаться в правильном направлении!
