Комментарии 13
/offtop Скажите, а Василиса Версус - это настоящее имя или псевдоним? И если псевдоним, то почему вы пишете, что вас так зовут? Кто-то вас зовёт не по настоящему имени, а по вымышленному?
Я бы сказал что обязанности на одной и той же позиции могут отличаться и очень даже сильно в разных компаниях. Причем относится это к любому грейду: джун, мидл, синьор, лид и т.д.
Большая часть того что описано выполняют agile couch /delivery manager, project manager и прочие господа кто работает над процессами и метриками
В моем представлении em это скиловый инжинер который делиться всеми возможными способами этим с командой чтобы качество их сервисов было лучше, а иначе это очередной процессник коих уже не сосчитать
Строить карьеру для карьеры на мой взгяд неправильно. Я понимаю, что автор приводил способы и механизмы карьерного роста, которые потенциально улучшают процессы и способствуют развитию команд, предприятий и отрасли, но какой то осадок все равно остаётся. Из перечисленного мне близок лишь один пример, когда карьерный рост необходим для продвижения своего мнения о направлении развития - без адм статуса тебя могут игнорировать.
Но много ли тех, кому карьерный рост реально необходим для инноваций?) Вряд ли. А если так, то весь этот пиар механизмов карьерного продвижения неконструктивен и часто даёт для отрасли негативный эффект. Инженер всё таки должен оцениваться по его вкладу в профессии. А если инженерные достижения можно заменить работой с руководством и какими то kpi, то значит в этом где то собака порылась)
Боже, каким мерзотным новоязом написана статья! Явно писало её GPT.
И вот это вот вообще за гранью добра и зла:
head of инфраструктуры или разработки
Это как если бы американец писал:
Главный по infrastructure or development
Недавно я писала про свой путь от TL к EM. Подписывайся на мой паблик в тг, там такого будет много, а мы начинаем.
Вот на этом лучше бы и закончили.
Тимлид - это примерно тоже самое что и дедовщина в армии, должности как таковой нет. Но если ноявляются новобранцы в команде, "старички" начинают называть себя тимлидами и пытаются изображать из себя "руководителя". Если появились в команде тимлиды, это признак незрелости компании, дизорганизации и отсутствия налаженных руководством рабочих процессов. Поэтому и начинают проявлятся животные инстинкты в команде. Слабый проектный менеджер, он же слабый офицер, и поэтому появляются деды, лиды и прочая живность.
Это большая боль у ребят кто пытается идти в эту сторону, а особенно не застрять на пол пути. Я сам прошел схожий путь, поэтому поделюсь своими мыслями после прочтения. Возможно, это будет полезно тем, кто сейчас думает о том: "а куда дальше?".
В общей картине разработка больше про людей и взаимодействие между ними, что, безусловно, входит в зону ответственности ЕМ.
Забавно, люди и их взаимодействие являются узким местом в разработке, а не технологии.
С этой точки зрения конечно все зависит от продукта, но очень часто EM, может прийти к выводу, что для выполнения своих обязанностей надо сначала команду построить из кучи людей (то бишь быть TL). Отсюда кстати как по мне и путаница.
А вот когда TL сделал свою работу, или у тебя есть команда, которая поддается изменением уже можно и начать задачи EM выполнять.
Предлагаю рассмотреть гипотетический путь от инженера к TL и потом к ЕМ
Если у тебя нет команды, сначала построй её. Это частый путь для разработчика через team lead. Кому-то повезёт: всё готово, и можно сразу переходить в ЕМ.
TL может совмещать работу PM, но для ЕМ это необычно и неправильно.
"Код" — это продукт для разработчиков, а разработчики — его пользователи. Их работа (coder story 🤣) — менять его. Значит, тут должен быть product owner. Эта метасистема — больше, чем архитектура, она про скорость изменений и про то, насколько более сложные задачи команда может решать на базе существующего кода. Вот EM и развивает этот метапродукт
Обосновывай переход выгодой для твоего руководителя и компании.
Это очень важно. Часто люди на этом спотыкаются. Когда разбираешь это с ними, они удивляются: "О, это так просто! Я вообще не так думал, всё усложнял и спорил."
Четвёртый пункт — про поиск вакансии внутри компании и продажу себя.
У C-level всегда проблема найти человека, готового взять на себя хоть маллую часть ответственности. Как только ты начнёшь это делать, система сама будет тебя продвигать. Такие кадры в дефиците, и всегда найдётся, чем их занять. Иногда достаточно просто помочь коллеге из другого отдела настроить Google Sheets, когда в фичу не делали год для него, сэкономив время и проявив неравнодушие.
Спасибо за статью!
Ого! Спасибо за такой огромный и развернутый комментарий ❤️🔥код есть мета-продукт как идея мне очень близка, хотя кажется сложным это сформулировать так, спасибо ☺️
Про EM сразу в обход TL тоже согласна, но встречала только в англ. мире. Надеюсь на ру рынке тоже так однажды будет.
А вот с тем что СТО всегда ищут кого-то, в моем мире также, но я очень много комментариев с неуверенностью получала и встречала, у меня сильные сомнения в том что они на пустом месте возникли. Как нибудь обязательно проведу исследование на эту тему, ведь круто звучит опросить хэдов и директоров на вопрос как они будут реагировать на инициативу… но тут еще бы придумать методологию, чтобы исключить случаи лести к себе и компании. Боюсь много руководителей некомпетентных 🫨 но если у тебя будут идеи как это можно сделать — буду рада!
Еще раз спасибо за развернутый комментарий 🔥
Классная статья, мне было интересно мнение)
Team Lead VS Engineering Manager