Спасибо автору за статью. Из своего опыта хотел бы добавить, что как только специалист замечает необходимость в применении софотовых навыков (даже если взять 8 навыков, перечисленных в данной статье), то этот специалист потенциально уже вырос из позиции просто исполнителя. Дальше, если он начнет развивать свои софты, и если эти софты будут помогать в достижении результатов, естественно это поможет ему в росте. В том числе и финансовом.
Другой случай, когда человек не развивает свои софт скиллз, что очень сильно будет мешать. И если не конкретно этому человеку, то команде где человек работает, очень возможно.
Интересная тема. Рынок греют чуваки, которые пытаются нанимать "хайповые" тайтлы, как в свое время было с DevOps-инженерами или Data Scientist'ами. Причем чаще всего люди, которые пытаются нанимать "хайповые" профессии не всегда даже понимают для чего им это нужно, релевантный ли кандидат к ним пришел. Просто он им нужен и всё. Ну и как правило отклики на "хайповые" вакансии делают все, от мало до велика, а дальше уже как карта ляжет. Из опыта был кейс, когда джуна devops-а брали на оклад выше, чем у просто у системного инженера, который имеет опыт работы со всеми теми же инструментами на уровне уверенного мидла или синьора. Просто на рынке дешевле не было.
Интересное мнение автора. Соглашусь, что чаще всего людям неинтересно и не хочется брать на себя ответственность за решения. Вроде как, это нормально :) В большинстве команд принятие решений делегируется руководителю проекта, или тому кто напрямую контактирует с бизнесом. В каких-то случаях это наверное правильный вариант, в каких-то случаях возможно не очень (например говнокод и техдолги). Задача тимлида доходчиво объяснить возможные риски. Как правило влияние тимлида на реальные процессы и ценность определяется зрелостью его руководителя. Если руководство не слышит, то в такой команде мало какой лид задержится надолго.
Хорошая статья, очень доходчиво разграничены понятия "власть" и "лидерство". Со своей стороны хотел бы отметить, на мой взгляд решающую роль в профессиональном росте играет баланс между техническими и софтовыми скиллами. Очень сложно лидировать, когда не до конца понимаешь суть технологий с которыми работают люди. И очень сложно внедрять новые технологии, когда не обладаешь достаточным количеством влияния.
У нас есть скрипты, которые запускают параллельное выключение виртуальных машин и гипервизоров, вручную выключаются только СХД и сетевое оборудование.
Спасибо автору за статью.
Из своего опыта хотел бы добавить, что как только специалист замечает необходимость в применении софотовых навыков (даже если взять 8 навыков, перечисленных в данной статье), то этот специалист потенциально уже вырос из позиции просто исполнителя. Дальше, если он начнет развивать свои софты, и если эти софты будут помогать в достижении результатов, естественно это поможет ему в росте. В том числе и финансовом.
Другой случай, когда человек не развивает свои софт скиллз, что очень сильно будет мешать. И если не конкретно этому человеку, то команде где человек работает, очень возможно.
Интересная тема. Рынок греют чуваки, которые пытаются нанимать "хайповые" тайтлы, как в свое время было с DevOps-инженерами или Data Scientist'ами. Причем чаще всего люди, которые пытаются нанимать "хайповые" профессии не всегда даже понимают для чего им это нужно, релевантный ли кандидат к ним пришел. Просто он им нужен и всё. Ну и как правило отклики на "хайповые" вакансии делают все, от мало до велика, а дальше уже как карта ляжет. Из опыта был кейс, когда джуна devops-а брали на оклад выше, чем у просто у системного инженера, который имеет опыт работы со всеми теми же инструментами на уровне уверенного мидла или синьора. Просто на рынке дешевле не было.
Интересное мнение автора. Соглашусь, что чаще всего людям неинтересно и не хочется брать на себя ответственность за решения. Вроде как, это нормально :) В большинстве команд принятие решений делегируется руководителю проекта, или тому кто напрямую контактирует с бизнесом. В каких-то случаях это наверное правильный вариант, в каких-то случаях возможно не очень (например говнокод и техдолги). Задача тимлида доходчиво объяснить возможные риски. Как правило влияние тимлида на реальные процессы и ценность определяется зрелостью его руководителя. Если руководство не слышит, то в такой команде мало какой лид задержится надолго.
Хорошая статья, очень доходчиво разграничены понятия "власть" и "лидерство". Со своей стороны хотел бы отметить, на мой взгляд решающую роль в профессиональном росте играет баланс между техническими и софтовыми скиллами. Очень сложно лидировать, когда не до конца понимаешь суть технологий с которыми работают люди. И очень сложно внедрять новые технологии, когда не обладаешь достаточным количеством влияния.
Пока нет, расскажу во второй части статьи, как сделаем.
Пока только один из трех, идем последовательно