Comments 65
Получается основная мотивация попробовать себя как EM — деньги? И то с проседанием пока растешь от джуна до, минимум, миддла? А как же радость созидания, радость от решения сложных технических задач?
Второй вопрос: как оставаться подкованным технически, если перестать писать код? Есть, конечно, Хабр, есть ченжлоги и т. п., но как-то сомнительно…
Третий, наверное, главный — чем отличается от ПМ, если смотреть для простоты одна компания-один проект-одна команда. Или от тимлида в команде, где есть техлид, а сам тимлид только управленческими вопросами занимается?
Второй вопрос: как оставаться подкованным технически, если перестать писать код? Есть, конечно, Хабр, есть ченжлоги и т. п., но как-то сомнительно…
Третий, наверное, главный — чем отличается от ПМ, если смотреть для простоты одна компания-один проект-одна команда. Или от тимлида в команде, где есть техлид, а сам тимлид только управленческими вопросами занимается?
Менеджеры размножаются почкованием. Так как по вертикали размножаться трудно, то они размножаются в пределах горизонтали. Были тимлиды и техлид, стали тимлиды, техлид, лайн менеджер. Потом добавился SEM. Следующий шаг это технический заместитель SEM.
Второй вопрос: как оставаться подкованным технически, если перестать писать код? Есть, конечно, Хабр, есть ченжлоги и т. п., но как-то сомнительно…
Вот и мне теперь интересно стало. Я бы заслушал
Мне в голову приходит масса вариантов: во-первых, в случае того же Цукерберга, ему точно не даёт окостенеть регулярное вдумчивое общение с одними из сильнейших в мире разработчиков.
Во-вторых, если зайти чуть шире — не обязательно вообще всё знать, чтобы быть на коне. Ни мне, отвечающему на этот комментарий. Ни бывшему разрабу, перешедшему в топ-менеджмент. Потом что, как говорил Гельвеций…
А в-третьих, если вы боитесь перестать совсем писать код — не переставайте совсем писать код. Никто вам пальцы при переходе в управленцы не сломает и контрактом этого не запретит.
Никто вам пальцы при переходе в управленцы не сломает и контрактом этого не запретит.
Просто свободного рабочего времени у вас на это не останется.
рабочего
I see what you did there.
Ну ок: если вы на руководящей должности уровня хотя бы SEM, и вы уверены, что для сохранения адекватности принятия решений вам надо регулярно освежать актуальность своей базы знаний — то, думаю, вы будете в состоянии этот вопрос обсудить с начальством, выделить какое-то время недели на это, и даже бюджет (особенно когда мы смотрим на зарплаты в Aurea). То есть, если вы этот вопрос не сумеете решить полюбовно, то либо лидер вы (пока) так себе, либо начальство у вас не очень. В обоих случаях причина потери квалификации тут лежит не в самом факте смены специализации.
…и всё же мне не даёт покоя это ваше свободного рабочего времени у вас на это не останется. А другое время, кроме рабочего, у вас будет? На него как-то распространяется воля вашего начальства? Ваша ситуация кажется мне чересчур умозрительной: люди, которые готовы повышать квалификацию только в рабочее время за счёт работодателя, выкидывающие все мысли о делах за пределами офиса — ну, во-первых, их вряд ли вообще посещают мысли о потере квалификации. Во-вторых, они вряд часто оказываются в жизни перед выбором: «Так, остаться ли на моей зарплате $5K, развиваясь как крутой специалист, или перейти в управленцы на $8К, но рискуя просто растерять скиллы? Ой, уже 6 часов. Так, рабочий день окончился, пятница — это святое. Подумаю об этом в понедельник. О работе только в рабочее время.»
вы будете в состоянии этот вопрос обсудить с начальством, выделить какое-то время недели на это, и даже бюджет
Ну то есть мы двигаем позицию из изначально описанной в какую-то другую (потому что изначальная позиция работу с кодом не подразумевала).
А другое время, кроме рабочего, у вас будет?
А поддержание рабочей квалификации в нерабочее время дорого обходится для жизни.
Если вы выделяете на это немного времени (скажем, 4-6 часов в неделю) — вам его может и не хватить; а если выделять много времени (ну хотя бы часов 10-16), то у вас в неделе пропали выходные. Нет, некоторых людей это устраивает. Просто совсем не всех.
Ну то есть мы двигаем позицию из изначально описанной в какую-то другую (потому что изначальная позиция работу с кодом не подразумевала).
Вот именно что не подразумевала. Человека взяли на работу, на которой в его должностные обязанности не входит кодить. А он боится растерять квалификацию, и не найти нормально уже следующую работу. Это и есть момент, когда позиция поехала куда-то не туда, потому что это уже сугубо личные переживания человека — на работу-то он устраивался, зная свои должностные обязанности. Это как качок устроится на работу в библиотеку, а потом начнёт переживать, что сдуется и станет требовать поставить ему скамью и разрешит жрать грудки на рабочем месте 3 раза в день.
Нет, теоретически, договориться с руководством можно и в такой ситуации, о чём был мой предыдущий коммент. Но это не отменяет персональной ответственности человека за добровольный выбор. Которая внезапно переехала в зону ответственности работодателя: «А в рабочее время мне почему-то заниматься тем, чего в моей работе изначально и не подразумевалось даже, не дают!»
Если вы выделяете на это немного времени (скажем, 4-6 часов в неделю) — вам его может и не хватить; а если выделять много времени (ну хотя бы часов 10-16), то у вас в неделе пропали выходные. Нет, некоторых людей это устраивает. Просто совсем не всех.
Вы продолжаете так проталкивать сквозь все ваши примеры странную ситуацию, которую вам навязывают: не дают на работе повышать квалификацию для другой должности — это ок. Но теперь получается, что вам уже и за рамками работы прямо график ставят: потрать 10-16 часов! Только кто вам это говорит? Ну, кроме вас? Если вы решили устроиться на одну работу, но хотите быть в форме для другой, и вам на это нужно не меньше 16 часов в неделю… — вы уверены, что кто-то ещё кроме вас в ответе за эту ситуацию?
Некорректный пример с качком. Библиотекаря не требуют разбираться как накачать трицепс, а вот SEM должен прекрасно владеть современными технологиями и т.д. и т.п.
Ваш тоже ситуацию не исправил) Если в библиотеке есть секция спортивной литературы, библиотекарь будет прекрасно подкован в теории, описанной в этих книжках. Как в любом, кстати, магазине спортпита, пузатые продавцы отлично знают все нюансы правильного питания. И могут чему-то научить даже — только пример подать не смогут.
Если повышение квалификации будет критично для выполнения его работы, то я сомневаюсь, что ему будет в нём отказано. Вы просто моделируете каких-то фантомных работодателей, которые требуют от вас того, чем якобы сами же запрещают заниматься. Зачем? Зачем это работодателю? И зачем эти фантазии вам?
SEM должен прекрасно владеть современными технологиями и т.д. и т.п.
Если повышение квалификации будет критично для выполнения его работы, то я сомневаюсь, что ему будет в нём отказано. Вы просто моделируете каких-то фантомных работодателей, которые требуют от вас того, чем якобы сами же запрещают заниматься. Зачем? Зачем это работодателю? И зачем эти фантазии вам?
Некорректный пример, в случае библиотеке вам надо прочитать книги и вы будете отлично в них ориентироваться. А вот не попробовав технологии и не сравнив их в кое каких задачах в современном ИТ мире вы просто утонете
Если в библиотеке есть секция спортивной литературы, библиотекарь будет прекрасно подкован в теории, описанной в этих книжках
Конечно… нет. Библиотекарь не читает (все) книги, находящиеся в библиотеке, это невозможно.
Человека взяли на работу, на которой в его должностные обязанности не входит кодить. А он боится растерять квалификацию, и не найти нормально уже следующую работу
Э нет. Речь шла о том, что для работы SEM нужна техническая квалификация, для поддержания которой нужно самому иногда разрабатывать ("как оставаться подкованным технически, если перестать писать код?"). Мы можем спорить с этим тезисом, это одно дело. Но если мы с ним согласились — и это другое дело, — тогда как раз встает вопрос, как же это поддерживать.
Поэтому все ваши тезисы о другой работе — они немножко мимо, извините.
Обратите внимание, кстати, что в комментах ниже SlavaKulakov пишет "мы от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием". Видимо, они не считают, что это повышение/сохранение квалификации идет для другой должности.
Чаще всего людям с большими семьями уже не хватает времени в НЕ рабочее время заниматся развитием рабочих скилов.
Тем не менее специалистом можно быть хорошим.
Уже которого комментатора затянуло в воронку обсуждения выходов из вымышленной ситуации, вместо того, чтобы задаться вопросом: «А как наш герой в ней оказался-то? Зачем он устроился работать по специальности, которая будет ему только мешать держать форму для работы, на которую он на самом деле нацелен?»
Вы понимаете, что от SEM требуют знания технологий. При чем тут вообще на что нацелен человек.
это ваше предположение, или данность на рынке?
в каком объеме необходимы знания технологий менеджеру?
в каком объеме необходимы знания технологий менеджеру?
Можно мы просто процитируем комментарий выше? С небольшими сокращениями :)
Обсуждаемая в этой ветке история действительно скорее про «фантомных работодателей, которые требуют от вас того, чем якобы сами же запрещают заниматься». Плохие работы бывают, неадекватное начальство встречается. Но если это не системная проблема, то подобные рассуждения будут просто уводить диалог в пустоту.
Если повышение квалификации будет критично для выполнения его работы, то я сомневаюсь, что ему будет в нём отказано
Обсуждаемая в этой ветке история действительно скорее про «фантомных работодателей, которые требуют от вас того, чем якобы сами же запрещают заниматься». Плохие работы бывают, неадекватное начальство встречается. Но если это не системная проблема, то подобные рассуждения будут просто уводить диалог в пустоту.
Всем привет!
Пришел начальник транспортного цеха. Вопрос понравился.
У нас в компании каждый СЕМ должен хорошо разбираться не только в ProjectManagement'е, но и иметь сильные знания в технологиях и инженерных практиках: как правильно организовать код-ревью, continuous integration, test driven development, branching strategy, deployment automation, environment provisioning automation, и так далее.
Ну а поддерживать/улучшать свои технические знания ему помогает одна из его прямых обязанностей, которую мы называем «Gemba Walk», а Toyota — «Walk the line»: чтобы менеджер имел возможность грамотно улучшить процесс — он должен видеть этот процесс вживую. В Toyota менеджеров посылают на заводы, где они ходят за рабочими и смотрят что и как они делают. Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием. Это позволяет им разобраться почему top-performers работают так быстро, научиться у них, а потом изменять процессы/тулы/подходы/практики соответственно и обучать уже всю команду.
А еще, так как один СЕМ обычно поддерживает несколько продуктов (от 5 до 10), то у него есть возможность выучить и разные технологии, увидеть в деле и сравнить различные архитектурные подходы. В общем, поле для профессионального роста просто огромное.
Пришел начальник транспортного цеха. Вопрос понравился.
У нас в компании каждый СЕМ должен хорошо разбираться не только в ProjectManagement'е, но и иметь сильные знания в технологиях и инженерных практиках: как правильно организовать код-ревью, continuous integration, test driven development, branching strategy, deployment automation, environment provisioning automation, и так далее.
Ну а поддерживать/улучшать свои технические знания ему помогает одна из его прямых обязанностей, которую мы называем «Gemba Walk», а Toyota — «Walk the line»: чтобы менеджер имел возможность грамотно улучшить процесс — он должен видеть этот процесс вживую. В Toyota менеджеров посылают на заводы, где они ходят за рабочими и смотрят что и как они делают. Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием. Это позволяет им разобраться почему top-performers работают так быстро, научиться у них, а потом изменять процессы/тулы/подходы/практики соответственно и обучать уже всю команду.
А еще, так как один СЕМ обычно поддерживает несколько продуктов (от 5 до 10), то у него есть возможность выучить и разные технологии, увидеть в деле и сравнить различные архитектурные подходы. В общем, поле для профессионального роста просто огромное.
Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием.
vs
«Семы» же, при должной компетентности в применяемых технологиях и методах, не принимают участия в написании кода, тестов и так далее, и ориентированы на конкретный фронт работ или операцию.
Так и не понял приципиальной разницы между SEM и тимлидом, разве что кроме того, что тимлид — разработчик с обязанностями мереджера, а SEM — менеджер со знанием о технологиях. Не понятно зачем вообще нужна эта роль в команде?! Интеграция между частями команды осуществяется либо руководителем проекта (если менеджерский вопрос), либо архитектором/консилиумом тимлидов. А кроме этого ничего толком и не сказано, а только изображают тимлида в виде хватающегося за всё подряд и вечно-занятого недоменеджера. К тому же став SEMом вместо уважения в своём отделе, ты получаешь место джуниора в иерархии менеджеров и тебя не будет пинать только ленивый…
Получается что в SEM-ы стоит идти только карьеристам или в погоне за высокой зарплаты…
Получается что в SEM-ы стоит идти только карьеристам или в погоне за высокой зарплаты…
Перечитав ваш комментарий дважды, я понял, что не только «разницы между SEM и тимлидом» не поняли)
100% мимо. Тимлид — это менеджер над разработчиками. В словах team lead вообще нет корня dev. Да, обычно тимлиды вырастают из девов — потому что приведи за разработкой смотреть человека вообще без этого бэкграунда, получится первая серия The IT Crowd. А «разработчик с обязанностями мереджера» и вовсе чудище обло, озорно, огромно, стозевно и лаяй. Меня аж кринжит, хотя я сам не разработчик, но ситуации такие наблюдал не раз.
50/50. В статье про бэкграунд SEM'oв ничего не говорится, и, теоретически, такое может быть — но где у нас, интересно, учат на «менеджеров со знанием о технологиях»? Всё равно в 99% случаев это будет чувак с девелоперским бэкграундом.
Наверное, потому что менеджеры без «знаний о технологиях» гораздо хуже?
Мне сперва показалось, что вы предлагаете решать все управленческие вопросы в команде, видимо, любого размера, только силами руководителя и тимлидов… Даже хотел задать вопрос, до какого же предельного размера, по вашему опыту, может вырасти команда, в которой вообще все «менеджерские вопросы» решаются только тимлидами и главой компании? Но потом перечитал, и увидел, что «менеджерские вопросы» вообще все безраздельно относятся к компетенции единственного руководителя. Даже язвить расхотелось. Скажу серьёзно: в этой вашей воображаемой структуре тимлиды бы сами вскоре взбунтовались и насильно скинулись руководителю на пару-тройку захудалых менеджеров среднего звена, например.
О, а здесь можно поподробнее? Это из личного опыта что-то?
Всё-таки мне интересно, где и сколько вы успели поработать, если у вас даже карьеристов с высокой зарплатой запинывали?
тимлид — разработчик с обязанностями мереджера
100% мимо. Тимлид — это менеджер над разработчиками. В словах team lead вообще нет корня dev. Да, обычно тимлиды вырастают из девов — потому что приведи за разработкой смотреть человека вообще без этого бэкграунда, получится первая серия The IT Crowd. А «разработчик с обязанностями мереджера» и вовсе чудище обло, озорно, огромно, стозевно и лаяй. Меня аж кринжит, хотя я сам не разработчик, но ситуации такие наблюдал не раз.
SEM — менеджер со знанием о технологиях
50/50. В статье про бэкграунд SEM'oв ничего не говорится, и, теоретически, такое может быть — но где у нас, интересно, учат на «менеджеров со знанием о технологиях»? Всё равно в 99% случаев это будет чувак с девелоперским бэкграундом.
Не понятно зачем вообще нужна эта роль в команде
Наверное, потому что менеджеры без «знаний о технологиях» гораздо хуже?
Интеграция между частями команды осуществяется либо руководителем проекта (если менеджерский вопрос), либо архитектором/консилиумом тимлидов
Мне сперва показалось, что вы предлагаете решать все управленческие вопросы в команде, видимо, любого размера, только силами руководителя и тимлидов… Даже хотел задать вопрос, до какого же предельного размера, по вашему опыту, может вырасти команда, в которой вообще все «менеджерские вопросы» решаются только тимлидами и главой компании? Но потом перечитал, и увидел, что «менеджерские вопросы» вообще все безраздельно относятся к компетенции единственного руководителя. Даже язвить расхотелось. Скажу серьёзно: в этой вашей воображаемой структуре тимлиды бы сами вскоре взбунтовались и насильно скинулись руководителю на пару-тройку захудалых менеджеров среднего звена, например.
К тому же став SEMом вместо уважения в своём отделе, ты получаешь место джуниора в иерархии менеджеров и тебя не будет пинать только ленивый…
О, а здесь можно поподробнее? Это из личного опыта что-то?
Получается что в SEM-ы стоит идти только карьеристам или в погоне за высокой зарплаты…
Всё-таки мне интересно, где и сколько вы успели поработать, если у вас даже карьеристов с высокой зарплатой запинывали?
Так и не понял приципиальной разницы между SEM и тимлидом, разве что кроме того, что тимлид — разработчик с обязанностями мереджера, а SEM — менеджер со знанием о технологиях
Это очень разные вещи.
Вы произносите слово менеджер так, будто бы эти люди ничего не делают.
Если у вас технические специалисты не могут получать больше, чем менеджеры, то действительно сильных технических специалистов у вас никогда не будет.
Если у вас технические специалисты не могут получать больше, чем менеджеры
Какого уровня должен быть технический специалист в России, чтобы получать под $18000 в месяц, мне интересно? Нет, правда интересно: что делают в том же вашем «Яндексе» чисто технические специалисты, получающие на руки миллион рублей в месяц?
И если разложить весь «Яндекс» на этажи по уровням дохода сотрудников — с увеличением «этажа» % технических специалистов на нём будет расти или уменьшаться относительно «менеджеров»?
Если у вас технические специалисты не могут получать больше, чем менеджеры, то действительно сильных технических специалистов у вас никогда не будет.
Вот купили мы в июне прошлого года JiveSoftware — компанию, которая базируется в Портлэнде — считайте та же Силиконовая долина. Для девелоперов там были созданы все условия — высокие зарплаты, отличный офис в центре города, 5 сортов разливного пива(!!!) в офисе, не говоря уже о еде, треннингах, массажистах и так далее. То есть инженеры у них работали очень даже квалифицированные (могли себе позволить заманить). Так вот — после покупки этой компании мы стали ставить своих иженеров ($50/час которые) в пары с Джайверами — всего за 3 месяца мы наняли 100 новых сотрудников через Кроссовер. И знаете что? Все Джайверы сказали, что наши ребята очень сильные и с ними здорово работать. Я специально постоянно всех спрашивал, так как самому было интересно сравнить наших ребят с коллегами из крутой компанией в Силиконовой долине.
Ваши то девелоперы получают больше, чем ваши же менеджеры, или нет? Если меньше, то какой им резон развиваться профессионально, если выгоднее стать руководителем?
ИМХО у руководителя профессиональный путь не такой гладкий, в какой-то момент гораздо более вероятно оказаться в пустом переулке без денег и перспектив. Т.к. с таким опытом вас в подчинённые не возьмут а начальников своих(конкуренция ннадекватна) хватает.
Наши чиф архитекторы (ака тех-лиды) получают ровно столько же, сколько и СЕМы — $50/час. Следующая позиция над ними — это VP — $100/час.
Ну то есть получается, что "двойняшка" СЕМа — это техлид (а не тимлид, как написано в статье), а СЕМ — не (единственный) способ преодолеть стеклянный потолок над техническим специалистом.
Впрочем, если в плане карьерного роста CEM примерно соответствует тимлиду, а по зарплате — техлиду, то вопрос справедливости зарплат снова возвращается.
SlavaKulakov, можете примерно рассказать о вашей карьерной лестнице?
SlavaKulakov, можете примерно рассказать о вашей карьерной лестнице?
Зачем перед началом «крысиных гонок» заниматься «всякой фигней» в виде программирования?
Не лучше ли, да эффективнее, сразу включиться в «крысиную гонку», чтобы обогнать на старте?
Не лучше ли, да эффективнее, сразу включиться в «крысиную гонку», чтобы обогнать на старте?
Зачем перед началом «крысиных гонок» заниматься «всякой фигней» в виде программирования?
Кому лучше? Вы бы предпочли, чтобы у вас был начальник, вообще не имеющий представления о вашей работе? Включившийся в «крысиную гонку», как вы говорите. Я не думаю, что вам это правда нужно.
Не лучше ли, да эффективнее, сразу включиться в «крысиную гонку», чтобы обогнать на старте?
Зависит от ваших критериев эффективности. Скажем, про трудоустройство в любую из компаний нашего холдинга можно было бы сразу забыть. Наши тесты написаны не в шутку. Пожалуйста, почитайте Славин пост — там он хорошо описывает, как проходил наше тестирование при трудоустройстве в Aurea. В его случае это было удалённо, чаще мы всё же проводим тесты в формате мероприятия — как наш субботний турнир. Суть одна: «крысиные гонщики» к нам, нашим процессам, нашим разработчикам и на пушечный выстрел не попадут.
Так что нет, не лучше. Не эффективнее. Никого он так не обгонит ни на каком старте. В общем, не зашла нам ваша идея :)
Т.к. в статье говориться
1) О карьере
2) О «бесконечном» повышении заработка
то я делаю вывод, что мне, как специалисту, предлагают поучаствовать в «крысиных гонках».
Т.к. «Даже если всего себя посвятить совершенствованию кодерского мастерства, ты лишь отполируешь стеклянный потолок над своей головой.»
Поэтому зачем тратить время и усилия по «совершенствованию кодерского мастерства», когда можно сразу выбрать путь «крысиных гонок».
Это проще и эффективнее.
(см., например, Б.Гейтс, С. Джобс )
Ну и не забываем про «принцип Питера».
Рано или поздно во всех узлах иерархии будут находится некомпетентные сотрудники.
:-)
1) О карьере
2) О «бесконечном» повышении заработка
то я делаю вывод, что мне, как специалисту, предлагают поучаствовать в «крысиных гонках».
Т.к. «Даже если всего себя посвятить совершенствованию кодерского мастерства, ты лишь отполируешь стеклянный потолок над своей головой.»
Поэтому зачем тратить время и усилия по «совершенствованию кодерского мастерства», когда можно сразу выбрать путь «крысиных гонок».
Это проще и эффективнее.
(см., например, Б.Гейтс, С. Джобс )
Ну и не забываем про «принцип Питера».
Рано или поздно во всех узлах иерархии будут находится некомпетентные сотрудники.
:-)
UFO just landed and posted this here
UFO just landed and posted this here
«Статья» от кроссовер.
Жонглирование субъективными тайтлами и ЗП.
Жонглирование субъективными тайтлами и ЗП.
Работал я у вас какое-то время и могу с уверенностью сказать, что единственное преимущество компании Crossover for Work — это конкурентная ЗП, выплачиваемая без проволОчек. На этом — всё. Тебе дают какой-то легаси-проект (там по всей Aurea сплошь виндовое легаси), снимают на веб-камеру, фоткают экран (это же дикость, объяснять что это remmina — это приложение, которым ты ходишь по RDP и что это разрешённая аппликуха) и обвешивают кучей метрик производительности. И ты деградируешь в техническом плане, пытаясь как дрессированная обезьяна при этом соотвествовать этим метрикам. Хорошо хоть повезло с менеджером, она была одной из лучших, которых я встречал.
Ну и как маркетинговый ход — создать шоу, чтобы поднять желанность позиции в глазах претендентов.
Счастливый человек. Мне ни одного приличного менеджера там встретить так и не удалось. Ну или занимаются они чем-то своим, не включающим взаимодействие с разработчиками. Какое там «раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием», банальный ответ на вопрос в слаке можно было по полдня ждать.
А как при таком ожидании считали метрики и оценивали вид экрана с открытым мессенджером или трекером и Ваш скучающий вид перед вебкой?
Так и считали. Для того, чтобы вопросов не возникало, было достаточно открыть IDE, периодически менять открытый в ней файл и нажимать что-нибудь на клавиатуре, почитывая интернет с телефона (к вопросу об эффективности такой слежки). Понятное дело, что заниматься имитацией работы вместо работы ужасно скучно, так что долго в таком режиме я не протянул.
UFO just landed and posted this here
Если это не сарказм, то да, вынужденно и ушёл при первой возможности. У меня была сложная ситуация с работой на тот момент. Если очень интересно, могу в личке рассказать, но не думаю, что это будет интересно.
Почему же, интересно. Нужны реальные подробности от реальных людей. Может, пост напишите?
Ну, я не уверен, что материала хватит на целый постинг. Да и излагаю мысли достаточно сумбурно. Очень не хочется чтобы это выглядело как критика ради критики. Альтернативой была бы "личка", но это будет выглядеть, будто я прячусь опасаясь ответной критики.
Можете почитать тут (нашёл случайно) или тут (это уже мой отзыв). Ну, и присовокупить то, что я написал в топ-комменте этого треда.
SEM — это технический менеджер? Не понял из статьи, за что он все-таки отвечает?
У нас в компании есть 2 типа СЕМов — ПродактСЕМ и КорСЕМ.
ПродактСЕМ больше ориентированы на классический Project Management: scope management, release management, timelines, risks/issues management, очень много общения с «братскими» организациями — SaaSOps, Product Management, Support, Professional Services. ПродактСЕМы заказывают выполнение работы у КорСЕМов.
КорСЕМы больше ориентированы на то, что бы поставить процессы и натренировать людей в команде таким образом, чтобы на выходе было хорошее качество и производительность команды постоянно росла. То есть это более технический человек, который хорошо разбирается в технологиях и инженерных практиках. Я там выше расписал чуть подробнее.
ПродактСЕМ больше ориентированы на классический Project Management: scope management, release management, timelines, risks/issues management, очень много общения с «братскими» организациями — SaaSOps, Product Management, Support, Professional Services. ПродактСЕМы заказывают выполнение работы у КорСЕМов.
КорСЕМы больше ориентированы на то, что бы поставить процессы и натренировать людей в команде таким образом, чтобы на выходе было хорошее качество и производительность команды постоянно росла. То есть это более технический человек, который хорошо разбирается в технологиях и инженерных практиках. Я там выше расписал чуть подробнее.
Так в чем разница между тимлидом и SEM? Судя по комментариям, это многим не ясно. Что мешает сделать тимлида ответственным за узкое направление? Надуманная разница
Почему?
Разница есть… В условной иерархии.
А так, какая разница teamlead или SEM, главное чтобы он работал и за менеджера, и за программиста, и за ментора для юниоров.
По мне teamlead это первый среди равных.
Чтобы споры о красоте того или иного решения не превращались в холивар.
Тот кто будет говорить, что делать надо так и никак иначе.
При этом все остальные программисты с этим согласны.
Ну и по возможности передавать опыт.
Т.е. сплав опыта и авторитета.
Остальное, это просто ленивые/ушлые менеджеры перекладывают свою работу на него.
Разница есть… В условной иерархии.
А так, какая разница teamlead или SEM, главное чтобы он работал и за менеджера, и за программиста, и за ментора для юниоров.
По мне teamlead это первый среди равных.
Чтобы споры о красоте того или иного решения не превращались в холивар.
Тот кто будет говорить, что делать надо так и никак иначе.
При этом все остальные программисты с этим согласны.
Ну и по возможности передавать опыт.
Т.е. сплав опыта и авторитета.
Остальное, это просто ленивые/ушлые менеджеры перекладывают свою работу на него.
Это вроде как главный конструктор главного КБ страны перейдет в главного завхоза главного КБ страны. Не глупо?
Не понимаю я такие статьи.
Как рост у манагера? Не перешел ли лид от «своей верхней планки» которую тут назвали тупиком в настоящий тупик где манагер останется манагером?
И самый важный вопрос: «почему обязателен рост? Книжек начитались?».
Почему нельзя наслаждаться работой сеньёра девелопера ?!
Не думаю что есть чего-то значащие ответы на эти вопросы…
Не понимаю я такие статьи.
Как рост у манагера? Не перешел ли лид от «своей верхней планки» которую тут назвали тупиком в настоящий тупик где манагер останется манагером?
И самый важный вопрос: «почему обязателен рост? Книжек начитались?».
Почему нельзя наслаждаться работой сеньёра девелопера ?!
Не думаю что есть чего-то значащие ответы на эти вопросы…
когда нагрузка по непосредственной работе с кодом осталась в прошлом, уступив исключительно менеджерским обязанностям,… деятельность становится более понятной и прозрачной окружающим
Весьма спорно...
Sign up to leave a comment.
Выход из тупика тимлида: у Software Engineering Manager больше зарплаты, лучше перспективы — и мы их нанимаем пачками