×Закрыть

Куда ты идешь, сениор?

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

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

Немного предыстории

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

Основной принцип карьерного роста можно описать так: чем более сениорным становится инженер, тем более замедляется его карьерный рост. Это происходит потому, что с ростом сениорности специалист все меньше времени тратит на свое развитие. На графике я привел приблизительное соотношение между «полезным временем» для проекта и временем, которое тратится на саморазвитие для каждого из профессиональных уровней. Тут важно отметить, что под саморазвитием имеется в виду выработка навыков, полезных для проекта, так как инженер может очень активно развиваться в сфере робототехники, но в проекте по разработке системы кредитования это может быть мало применимо.

Детально я все это описывал в моей предыдущей статье — на этом мы останавливаться не будем. Однако при взгляде на этот график резонно появляется вопрос: а что же делать сениору, который «взобрался» на плато 95/5?

Такой вопрос я слышу очень часто, но простого ответа у меня на него нет. Давайте есть этого слона по частям.

Эффект эскалатора

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

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

Почему так происходит? Потому что на определенном этапе сениор становится способным решить 95 % проектных задач, на что и уходит все его время. У него высокая производительность и высокая зарплата, вот только зон развития все меньше и меньше, пропадает «челлендж» и видимость дальнейшего карьерного роста.

Я называю это эффектом эскалатора. Когда-то все было понятно и происходило практически само по себе: джун дорастал до мида, а мид — до сениора. Эскалатор двигался. У кого-то быстрее, у кого-то медленнее, но у всех только вверх. И тут — «плато»! Оказалось, что на определенном этапе эскалатор заканчивается. И когда приходит осознание этого факта, инженер чувствует, что отсутствуют две привычные ему ранее вещи:

Во-первых, пропадает определенный вектор движения. Вместо одного направления «вверх» (джун-мид-сениор) появляется целый ряд опций и возможностей. Эскалатор поднимает инженера на площадку, с которой можно шагать в любую сторону. Осталось понять — в какую.

Во-вторых, исчезает эта привычная самоподнимающая сила. Раньше потребности проекта заставляли специалиста двигаться вперед: он совершал ошибки, учился и рос. Теперь проект требует от него просто хорошо делать свою работу и не «отвлекаться». А рост — это уже его личное дело. Как говорится, главное — чтобы не мешал работе.

В реальном мире, когда эскалатор доставляет нас на верхнюю площадку, мы выбираем направление и идем ножками, прилагая собственные силы. Но в мире карьеры это не совсем так.

Проблема в том, что человек — существо ленивое, а правильнее сказать — существо эффективное. Он прилагает экстра-усилия только тогда, когда понимает, что они окупятся. А когда возврат инвестиций неясен, тогда и усилия будут посредственными.

Проблематика

Казалось бы, зачем вообще поднимать вопрос «карьерного плато»? Может, просто забить и пустить все идти своим ходом? Ну поднялся он на этом самом эскалаторе, ну не знает, куда идти, значит пускай сидит себе на верхней площадке и работает.

Увы, это не совсем так. Инженер — человек творческий и привыкший решать сложные задачи. Более того, на протяжении своей предыдущей карьеры он решал все более и более сложные задачи и оценивал себя исходя из того, как хорошо он с ними справлялся. Теперь — плато. Уровень задач остается примерно одинаковым, челлендж может заключаться только в их количестве. Но просто возросший объем работы не всегда является мотивирующим фактором, а если и является, то ненадолго.

Что же предпринять творческому человеку в этой ситуации? Чаще всего он может просто найти другую работу: другой проект и небольшая прибавка к зарплате поправят ситуацию. Но есть и иные варианты:

  1. Если сложностей нет — надо их создать! А потом решить! И часто это может выглядеть вполне обоснованным. Например: «А давайте перейдем на новый фреймворк, так как старый себя уже изжил». (Изжил ли?)
  2. С другой стороны, инженер может через какое-то время просто потерять интерес к проекту и работать на уровне мида. (Получая при этом, конечно, как сениор).
  3. И самый неприятный случай — потерявший интерес инженер, не развиваясь сам, не дает развиваться остальным членам команды. «Ничего не трогайте. Вы ничего тут не смыслите. Никто не знает, как оно работает». (Или просто он уже забыл).

Итак, если вы как менеджер проигнорируете вопрос карьерного плато, вам, возможно, придется отвечать уже на другие вопросы:

  • как удержать/заменить ценного сотрудника?
  • как поднять производительность команды на прежний уровень?
  • как исправить климат и наладить командную работу?

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

Если говорить аллегорически, вам надо исследовать местность, проанализировать ресурсы человека, понять, куда дует ветер, и найти для него «точку взлета» с плато. А дальше, как говорится, все в его руках.

Рука помощи

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

К счастью, менеджеру это вполне по силам, так как, по своей сути, его должность предполагает видение более целостной картины, а именно:

  1. Менеджер должен понимать, куда именно хочет двигаться «готовый к полету» сениор.
  2. Менеджер также должен правильно оценивать реальный профессиональный уровень специалиста: знать, насколько его хард- и софт-скиллы востребованы.
  3. Менеджер должен видеть потенциальные потребности своего проекта. Например, пора ли вводить новую экспертизу.
  4. Менеджер также должен понимать потребности своей компании. Об этом мы поговорим далее.

Другими словами, он должен видеть, где именно экстра-усилия сениора принесут экстра-ценность его проекту или компании в целом, и что с этого будет иметь сам инженер. Ниже я приведу ряд типичных примеров, чтобы было понятно, что именно я имею в виду.

Примеры

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

Рост в лида / PMа

Итак, самый простой вариант — это вырастить из сениора лида. Это «естественная» следующая ступенька для инженера. Лид приносит экстра-ценность тем, что разгружает менеджера, позволяя ему инвестировать свое время в другие активности. Роль лида предполагает новый спектр сложных задач и более высокую компенсацию. Тут все понятно.

Новая экспертиза

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

Консультирование

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

Presale-активности

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

Тренинги / конференции

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

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

Фруктовый сад

Вместо вывода, я хочу привести одну аналогию. Я бы сравнил команду разработчиков с садом плодовых деревьев, а менеджера — с садовником. Когда в саду появляется молодое дерево (трейни) — оно требует ухода, но пользы поначалу приносит мало. Через некоторое время появляются первые плоды (джун). Потом плодов становится больше (мид), и в какой-то момент их может быть даже в избытке (сениор).

И тут, садовник становится перед выбором — оставить все как есть и надеяться, что переспевшие яблоки не сломают ветви деревьев, или придумать, как их использовать.
Может быть пора экспортировать излишек плодов? Или начать делать из них сок? А может научиться готовить вино? :)

В любом случае, тут дело за вами — забить и наблюдать либо растить и развивать. Желаю вам поменьше проблемных проектов и побольше радостных моментов в вашей работе.

LinkedIn

57 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Загнанных лошадей пристреливают, не правда ли?© :)

Потом плодов становится больше (мид), и в какой-то момент их может быть даже в избытке (сениор).

Когда дерево стареет его просто вырубают. А его плоды восполняются подросшими молодыми.

Хм, ну до этого этапа в карьере еще далеко )

Это пока молодой, а потом окажешься этим деревом. И не так долго тебе ждать. Сколько до 45 осталось?

Это у работодателей и HR спроси. Такова местная традиция.

Куда ты идешь, сениор?

К тридцатнику

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

Оп-па... надо срочно на семинар по linux kernel development сходить.

Почему то название статьи навеяло начало 90-ых :)

Бляха муха, в сучасному світі вміти програмувати і нити, що галера не дає вирости із формошльопства, це як у якомусь фентезі народитися магом і скаржитися на занудність збільшення приплоду корів. Куди рости далі? Може піти керувати фермою?

Перед тобою світ, де штучний інтелект захоплює сферу за сферою, де автоматизують все від знайомств до судових позовів. Де нейронні мережі пишуть музику і скоро накатають перший роман. Де за сотку баксів на чорному ринку можна купити персональні дані мільйона людей, разом з маршрутами їх щоденних походів за молоком.

Де алгоритми вираховують терористів, а інші алгоритми допомагають їм шифрувати свої розмови, де війни переходять потрохи в онлайн і хакери вирішують долю виборів у найсильнішій державі світу. Де показуючи різним людям різний контент можна примусити їх купувати те, що ти хочеш, голосувати за того, за кого сказано, підтримувати ідеї, які тобі видаються важливими.

Все, що треба — елементарне вміння складати докупи рядочки коду, готувати суп із опенсорсних бібліотек і деплоїти це все кудись у хмару. І все, в тебе в руках суперзброя, здатна міняти світ на всіх рівнях.

Але навіщо це все, якщо можна продовжувати міряти своє життя булшіт-личками і черговим MBA-сленгом. Якщо дістало бути сіньйором — стань екзек’ютів сіньйором. Whole new life!

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

Живи себе нормальненько
Есть повод веселиться
И может быть в начальника
Душа твоя вселится

© не мое ;)

Хорошую религию придумали индусы!

Любая компания как машина. И если ты пришел в нее «колесом», то никогда не стать самой машиной. Надо трезво мыслить. А при достижении материальных благ и стабилизации коммуникаций в рабочих процессах — личностное и духовное развитие. Творите и размножайтесь))

очередные галерные бредни о карьерном росте)

точняк. девелопер должен педалить молча. нефиг тут.

верно, смысл статьи больше «удержание гребца годами на галере», а не о персональном развитии.

смысл статьи больше «удержание гребца годами на галере», а не о персональном развитии

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

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

годами смотреть на один и тот же репозиторий с отстоявшимся флоу и набором инструментов, общаться с одними и теми же людьми

мне казалось, это специфично только для продуктовых компаний, не?

В аутсорсе полно вечных проектов

ага, только в аутсоре обычно 10+ проектов на разных технологиях, разной степени запущенности(aka архитектура) и с разными процессами. приелся фронтенд — сходи на Ноду, надоела джава — попробуйся в фронтенде. react <-> angular. Java 6 <-> Java 9.

Так и в продуктовых проект бывает не один.

бывает

это понятно.
но мне казалось, что это скорее исключение.
какие у нас есть продуктовые компании с несколькими продуктами сразу?

у нас

Всё время забываю, что у нас могут быть разные

а у вас какие продуктовые с несколькими продуктами?

Где ща работаю, есть от смарткарт, автомотива до клаудов и ангуляров.
С другой стороны в аутсорсе проекты вроде есть, а найти интересный внутри конторы не проще, чем новую работу.

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

бросить весло, покинуть детсад то есть ненапряжный дуплеж на галерах разного водоизмещения. Перестать думать в сервисной парадигме «бабло за время» + «формошлеп таски» и попробовать себя в другой бизнес-модели, тут весь пахфос и помидорность как рукой снимет (в т.ч. способность решить без напряга 95% любых задач, ахаха). Имхуется челленджа хватит надолго.

попробовать себя в другой бизнес-модели, тут весь пахфос и помидорность как рукой снимет (в т.ч. способность решить без напряга 95% любых задач, ахаха). Имхуется челленджа хватит надолго.

Ещё бы найти того, кто за это будет платить больше чем галерные 3-5 тысяч.

на то и не детсад, что нет «того, кто будет платить». Платить будут клиенты, если оно того стоит. Сначала дауншифтинг (как без этого), взамен возможность превысить стеклянный потолок 5-6-7куе (кто куда добрался) и оценить настоящее преимущество софта — масштабирование оборота\дохода без прямой связи с затраченным временем. Вот так помидорность и возможность решать эффективно 95% задач проявится в полной мере!

Сначала дауншифтинг (как без этого), взамен возможность превысить стеклянный потолок 5-6-7куе (кто куда добрался) и оценить настоящее преимущество софта — масштабирование оборота\дохода без прямой связи с затраченным временем

Сэр, ты посмотри в профиль и поймёшь. Знаю я :) Только вот: тяжело это

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

если коротко: нет. Вид деятельности остается неизменным — создание\развитие\поддержка софта, желательно максимально эффективным образом. Только на вопросы что делать, почему и зачем прийдется отвечать самому, а не ждать что кто-то добавит таски в жире.

Не открою америку: значительная часть галерных разрабов так же далеки от эффективной разработки софта как яйца от продналога. Другими словами, они больше нужны галерам как носители лычек и «продавабельных» CV чем как эффективные разработчики. Команды раздуты (девелоперы закончились, не беда — напихаем QA\BA), результаты более чем скромные — что это как не распил ИТ бюджетов?

Не бывает абстрактного программирования в вакууме. Не бывает эффективного разработчика который не разбирается до условного «5-го зачем» он делает то что делает и понимает кто, как и почему потом этим пользуется — вплоть до понимания экономической целесообразности своих действий. Тем кто помоложе и еще ослеплен галерным баблом это может быть тяжело принять. Сам был 23-летним тимлидом когда-то давно :-) жалею только о том, что не спрыгнул с аутсорсинговой иглы раньше, на то она и игла.

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

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

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

кто же тогда способен принять решение о рентабельности некого инженерного решения, кроме самого инженера? Кто-либо другой имеет еще меньше экспертизы и данных для подобного решения (что и наблюдаем). И опять же, хотелось челленджа и «куда дальше» — чем не вариант. А то хочется и рыбку съесть и ...

кто же тогда способен принять решение о рентабельности некого инженерного решения, кроме самого инженера?

0_0
тот самый момент, когда от растерянности даже не знаю, что сказать
инженер в принципе не может судить о рентабельности
ни информации о конкурентах, ни информации о существующих или потенциальных пользователях, ни информации о состоянии рынка, ничего у инженера нет(конечно, если он не совмещает в себе еще продажника и аналитика).

инженер в принципе не может судить о рентабельности

Ну я полагаю в данном контексте речь об «инженерной рентабельности» не?

об «инженерной рентабельности» не?

та ну.

вплоть до понимания экономической целесообразности своих действий

всего на два коммента выше.
то есть речь о том «какой профит конкретно это техническое решение принесет бизнесу», а не "насколько это решение быстрее/компактнее по памяти/расширяемее, чем решение ХХХ"(вы ж об этом?)

лычки это просто условности. Человек либо обнаруживает, что способен совмещать в себе много условных ролей по необходимости («решать проблемы»), либо гребет на галере, радуется ситуативно неплохому доходу (как за кодинг и весьма узкую специализацию) и не требует «куда дальше». Неплохой пример — M$ тимы которые сейчас работают над опенсорс проектами (неткор и вот это все). Раньше как захотели так и сделали, а теперь надо issues от коммунити разгребать, отвечать на неприятные вопросы, открыто обсуждать и иногда отказываться от каких-то решений под давлением пользователей технологии. Этим всем занимаются те же инженеры, которые коммитят в репо (легко убедиться). Может просто не знают что труъ инженере в принципе не должен таким заниматься? )

Человек либо обнаруживает, что способен совмещать в себе много условных ролей по необходимости

да-да, и требования согласовывать друг с другом, и поддержка инфраструктуры, и дизайн, и тестирование. кроме разработки. окей. еще куда ни шло.
но анализ рынка, сбор и анализ отзывов, сравнение с решениями конкурентов, выискивание ниш и мониторинг трендов — и в то же самое время, что и пункты из списка выше.
к фантастике я отлично отношусь, но в реальности подобное «и швец, и жнец» заканчивается не очень хорошо.

лычки это просто условности

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

но в реальности подобное «и швец, и жнец» заканчивается не очень хорошо.

есть пример, кто таки умер от того, что умеет слишком многое? )

а вообще, последняя «волна» помидоров разбалована текущим галерным рынком (пока что). «Я бекенд и не знаю жабоскрипта» (шта??), «Я фронтенд и не умею этот ваш сишарп\джава\етц, и верстать тоже не умею». Сеньор разработчики епта... больше смахивает на рабочих конвейера, там тоже специализация ух какая.

есть пример, кто таки умер от того, что умеет слишком многое? )

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

больше смахивает на рабочих конвейера, там тоже специализация ух какая

не, конечно, когда сам один за всех — это щекочет самолюбие. Но эффективность выше, когда что-то знаешь хорошо, а не в 8 языках знаком с основами синтаксиса.

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

Не знаю, что происходит в тех местах про которые ты пишешь, работал только в продуктах. Но мне кажется ты преувеличиваешь.
По твоему получается что «заказчики» немного не в себе, иначе зачем им платить за такое. В это верится очень с трудом.
Могу ошибаться — не видел что там внутри. Но твои слегка «желчные» посты больше похожи на троллинг.
Peace ))

Ради интереса зашел на твой сайт. :) Посмотрел и вышел.
What are you selling ?
Как по мне это и есть пример очень «средней» работы PR. Где месседж, где двумя словами главные features продукта.
Может я не в теме.

не в теме. немного троллинга на доу это святое )

приведеные разрешения не всегда имеют место быть.

Рост в лида / PMа

 — не всегда в них есть потребность, если контора продуктовая то появление новых проектов не так часто и происходит, а даже в аутсорсе, проекты не ежедневно заходят, а сеньоров обычно достаточное кол-во

Новая экспертиза

 — зависит от настроения бизнеса, ведь данная деятельность не всегда может быть нужна/желаема, а ведь именно они башляют

Консультирование

 — на «плато» консультирование это не новые задачи а просто полирование тех же навыков на больших объемов, ибо уметь решать новые задачи это тоже скил который в процессе становления сеньора развивается, но да немного разбавит работу

Presale-активности

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

Тренинги / конференции

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

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

Ну, решение-то простое: заводим трактор в долину, и обнаруживаем, что до синьора еще на самом деле и учиться и пахать. Потом ситуация повторяется уже там, но все равно челенджей хватает на всю жизнь.

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

Ну про долину это условно, на самом деле в любом месте шарика. Разные синьоры бывают, в т.ч. те, которое создают те технологии, которые другие синьоры так усиленно осваивают.

на самом деле в любом месте шарика

Индия хорошая и климат.

Да. Но в Украину те задачи что учиться и учиться, не заходят. А трактор не у всех получается.

Очень странно рассматривать компетенции в статике, ведь всё очень динамично и органично меняется. Есть технологический прогресс, который за 3-4 года полностью меняет архитектуру, технологии, инструменты и тренды. Был человек сениором в своём круге компетенций, а тут прошло 3 года и его компетенции безнадёжно устарели. Поэтому компетенции нужно расширять и углублять, постоянно. Допустим 50% старых знаний остаются, как базовые, 50% нужно доучивать, т.е. это 10-15 % на развитие при органическом, скажем, прогрессе обучения в год.
Таким образом можно постоянно находится в технологическом зените технологий не меняя ролей. Переходя с одного эскалатора на другой, выражаясь словами автора. Другое дело, что люди выдыхаются, жиреют и больше не хотят постоянного развития, а хотят спокойной гавани тимлидства или менеджерства, где техгнологический цикл жизни не 3-4, а 10-15 лет.

освоение «абсолютно новой технологии» это 2 недели поработать с ней — и все, т.к. все новые технологии это обычно rethinked стары

«Программирование, как куннилингус, не важно, какой язык, главное, как ты им управляешься.» Матвей Коперник

Подписаться на комментарии