Выход из тупика тимлида: у Software Engineering Manager больше зарплаты, лучше перспективы — и мы их нанимаем пачками

    Классификация должностей в современных, особенно технологических компаниях сбивает с толку не только обилием сокращений и миксом терминов на двух языках, но и нюансами скрывающегося за ними содержания. Этому нигде не учат — понимание тонкостей, наполнения и специфики тех или иных должностей приходит с опытом и передаётся только с опытом. Со временем мы планируем систематизировать наши знания в этой области, но пока поговорим о насущном: в субботу в Москве состоится очередной Hiring Tournament. На турнир — точнее, сафари, — в котором сразу четыре софтверных компании DevFactory, Aurea, Ignite и Crossover вышли на охоту за головами редкого зверя Software Engineering Manager, пытаясь выманить его на годовой оклад в $100 000. Чем не повод поговорить о том, что это за создание и чем в корпоративных джунглях SEM отличается от должности-двойняшки — Team Lead.


    Чем совершеннее в компании отлажены процессы — тем больше они напоминают конвейер вне зависимости от её профиля

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

    Однако если в вашей компании имеются Software Engineering Manager, «семы» — то они тоже будут руководить командами разработчиков или инженеров, контролируя и обеспечивая работоспособность команды, и поддерживая рабочий контакт с «соседними» отделами разработки. Так в чём же разница с тимлидами? Мы попросили VP of Technical Product Management компании Aurea Software Максима Винникова помочь внести нам ясности в деталях.

    Максим Винников — одна из жемчужин хантинга «Кроссовера». Мы пригласили его в компанию Aurea Software, одну из «дочек» техасского конгломерата ESW Capital, совсем не так давно, в январе прошлого года — и тогда ещё на позицию Technical Product Manager. Но уже в июле 2017-го Максим пересел в (виртуальное) кресло вице-президента.

    На предыдущем месте, в компании AT Consulting, он проработал почти два года как раз-таки в качестве Senior Software Engineering Manager. В общем, практически вся его карьера вела его к моменту, когда он смог помочь нам написать эту статью на Хабр :)

    Узкий специалист vs специалист широкого профиля


    Разница между Team Lead и Software Engineering Manager — как между терапевтом и пульманологом. В наших широтах Team Lead обычно руководит многопрофильными командами и сам может быть многостаночником. «Семы» же, при должной компетентности в применяемых технологиях и методах, не принимают участия в написании кода, тестов и так далее, и ориентированы на конкретный фронт работ или операцию. Да, некоторым может показаться спорным подобный подход, однако он отлично укладывается в парадигму Factory-разработки. Software Engineering Manager – это специалист в своей области, причем специалист высокого класса, который выполняет функции руководителя и организатора, оставляя работу с кодом линейным программистам своей команды.

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

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

    Крутой SEM должен быть мощным специалистом, в котором победил управленец. Ещё одна проблема для любителей антагонизировать эти роли. При этом «ржаветь» и останавливаться в собственной грамотности SEM не имеет права: он должен от начала и до конца понимать, с какими технологиями работает его команда и с легкостью отслеживать возможные проблемы.

    Как коммуникатор, Software Engineering Manager всегда должен контролировать входные и выходные точки выполняемых задач своей команды. Чтобы компания качала продукт как «Северный поток» качает газ, каждый сегмент трубы должен совпадать с соседними по толщине, диаметру и положению в пространстве по меньшей мере. На «входе» SEM обязан отчетливо понимать, что требуется от его подчиненных, а на выходе качественно передать готовый продукт (в виде части кода, тестов и так далее) следующему SEM и уже его «бойцам», которые примут его в дальнейшую работу. Особенно, когда речь идёт не о первичной разработке продукта, а постоянной поддержке, скажем, SaaS-решения — поток задач становится непрерывным, а цикл разработки стремительно закругляется — малейший сбой в этом процессе грозит последствиями разболтавшейся гайки в колесе при выезде на автобан.

    Но и налаженные процессы не повод для расслабления. Отладив процессы — их надо начинать чистить. Банальный пример: повышение числа коммитов – это хорошо, однако если в итоге 50% и более из них в последующем правятся, то это не повышение производительности, а бег на месте с отягощением. Отлаживая процессы, SEM увеличивает объём выполняемой работы, чистя их — уменьшая затраты на выполнение конкретных её элементов, получая в результате постоянно растущее соотношение результата к усилиям. То есть ту самую производительность труда.

    Карьера окончена, да здравствует карьера


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

    Но этот выбор стоит риска. Даже если всего себя посвятить совершенствованию кодерского мастерства, ты лишь отполируешь стеклянный потолок над своей головой. На каком-то этапе зарплаты просто перестают расти — остаётся разве что менять локацию, переезжая из краёв посуровее, с условной пятёркой $ в месяц, в края более солнечные, где и по 15 заплатят — но где и жизнь несопоставимо дороже, и налоги кусаются больше. В общем, если к старости вы хотите накопить не только почёт и уважение, этот потолок не заметить не получится — Хаттори Ханзо мог делать лучшие катаны в Японии, но если бы он открыл свой заводик вместо мастерской, то стал бы ещё и гораздо богаче.

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

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

    Software Engineering Manager — это место, куда приходят умирать разработчики, чтобы вырасти из собственного праха уже руководителями. Дальше, впрочем, цепочка во многих компаниях не слишком длинная. В дочерних компаниях холдинга ESW Capital, например, SEM отчитываются перед VP, которые, в свою очередь, рапортуют уже напрямую CEO компании. Но зато каковы размахом эти шаги: с зарплаты «сениора», скажем, $5K в месяц — к $8K у «семы» в компаниях наших клиентов. А на следующей ступени уже пресловутый миллион рублей в месяц на позиции VP. Можно оговориться, что и этот рост тоже не безграничен, но ваши будущие стеклянные потолки будут уже стеклянными куполами. И вид оттуда открывается уже совсем иной.

    Другая оговорка — зарплаты, принятые в компаниях группы ESW Capital, в которую входит и, собственно, Crossover, отличаются от рынка, причём сильно и в лучшую сторону. $8000 — это позитивная флуктуация в нашем случае. В среднем же, в столицах Software Engineering Manager могут рассчитывать на заработок от $2500-3500 в месяц. В общем, выбирать между завтраком и поездкой на метро не потребуется. Так что игра всё равно стоит свеч — попробовать себя в роли управленца стоило бы многим разработчикам.

    Турнир стеклянного потолка


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



    Вести турнир и делиться опытом на месте будут действующие SEM, работающие в компаниях ESW Capital. А по скайпу общаться с участниками будет VP of Engineering компании Aurea Software SlavaKulakov, к которому, мы надеемся, сможет присоединиться и соавтор этого поста Максим Винников. Мы считаем очень важным участие специалистов такого уровня в Hiring Days — потому что считаем, что самое ценное знание о вашей будущей работе — не как на неё попасть, а как на ней не застрять. В этом смысле нашим VP точно есть, чем поделиться с SEM как будущими, так и действующими, если кто-то из них вдруг нацелился на смену места работы сейчас. Ну а пользователям Хабра доступна привилегия задавать им вопросы в комментариях в течение всей недели. Как обычно, отвечать наши коллеги будут по возможности, но обещают уделить время хотя бы самым интересным вопросам.

    Crossover

    494,00

    100% удаленная работа в международных IT-проектах

    Поделиться публикацией
    Комментарии 65
      +3
      Получается основная мотивация попробовать себя как EM — деньги? И то с проседанием пока растешь от джуна до, минимум, миддла? А как же радость созидания, радость от решения сложных технических задач?

      Второй вопрос: как оставаться подкованным технически, если перестать писать код? Есть, конечно, Хабр, есть ченжлоги и т. п., но как-то сомнительно…

      Третий, наверное, главный — чем отличается от ПМ, если смотреть для простоты одна компания-один проект-одна команда. Или от тимлида в команде, где есть техлид, а сам тимлид только управленческими вопросами занимается?
        +6
        Менеджеры размножаются почкованием. Так как по вертикали размножаться трудно, то они размножаются в пределах горизонтали. Были тимлиды и техлид, стали тимлиды, техлид, лайн менеджер. Потом добавился SEM. Следующий шаг это технический заместитель SEM.
          +2
          Второй вопрос: как оставаться подкованным технически, если перестать писать код? Есть, конечно, Хабр, есть ченжлоги и т. п., но как-то сомнительно…

          Вот и мне теперь интересно стало. Я бы заслушал начальника транспортного цеха господ VP of something something :-) Но что тут сомнительного-то? Как будто не было никогда такого, а тут опять. Марк Цукерберг давно не разработчик, но вряд ли его представления о технологиях так и остались в 2006 году.

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

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

          А в-третьих, если вы боитесь перестать совсем писать код — не переставайте совсем писать код. Никто вам пальцы при переходе в управленцы не сломает и контрактом этого не запретит.
            +4
            Никто вам пальцы при переходе в управленцы не сломает и контрактом этого не запретит.

            Просто свободного рабочего времени у вас на это не останется.

              –2
              рабочего

              I see what you did there.

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

              …и всё же мне не даёт покоя это ваше свободного рабочего времени у вас на это не останется. А другое время, кроме рабочего, у вас будет? На него как-то распространяется воля вашего начальства? Ваша ситуация кажется мне чересчур умозрительной: люди, которые готовы повышать квалификацию только в рабочее время за счёт работодателя, выкидывающие все мысли о делах за пределами офиса — ну, во-первых, их вряд ли вообще посещают мысли о потере квалификации. Во-вторых, они вряд часто оказываются в жизни перед выбором: «Так, остаться ли на моей зарплате $5K, развиваясь как крутой специалист, или перейти в управленцы на $8К, но рискуя просто растерять скиллы? Ой, уже 6 часов. Так, рабочий день окончился, пятница — это святое. Подумаю об этом в понедельник. О работе только в рабочее время.»
                +2
                вы будете в состоянии этот вопрос обсудить с начальством, выделить какое-то время недели на это, и даже бюджет

                Ну то есть мы двигаем позицию из изначально описанной в какую-то другую (потому что изначальная позиция работу с кодом не подразумевала).


                А другое время, кроме рабочего, у вас будет?

                А поддержание рабочей квалификации в нерабочее время дорого обходится для жизни.


                Если вы выделяете на это немного времени (скажем, 4-6 часов в неделю) — вам его может и не хватить; а если выделять много времени (ну хотя бы часов 10-16), то у вас в неделе пропали выходные. Нет, некоторых людей это устраивает. Просто совсем не всех.

                  +1
                  Ну то есть мы двигаем позицию из изначально описанной в какую-то другую (потому что изначальная позиция работу с кодом не подразумевала).

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

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

                  Если вы выделяете на это немного времени (скажем, 4-6 часов в неделю) — вам его может и не хватить; а если выделять много времени (ну хотя бы часов 10-16), то у вас в неделе пропали выходные. Нет, некоторых людей это устраивает. Просто совсем не всех.

                  Вы продолжаете так проталкивать сквозь все ваши примеры странную ситуацию, которую вам навязывают: не дают на работе повышать квалификацию для другой должности — это ок. Но теперь получается, что вам уже и за рамками работы прямо график ставят: потрать 10-16 часов! Только кто вам это говорит? Ну, кроме вас? Если вы решили устроиться на одну работу, но хотите быть в форме для другой, и вам на это нужно не меньше 16 часов в неделю… — вы уверены, что кто-то ещё кроме вас в ответе за эту ситуацию?
                    +1

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

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

                      SEM должен прекрасно владеть современными технологиями и т.д. и т.п.

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

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

                          0
                          Если в библиотеке есть секция спортивной литературы, библиотекарь будет прекрасно подкован в теории, описанной в этих книжках

                          Конечно… нет. Библиотекарь не читает (все) книги, находящиеся в библиотеке, это невозможно.

                        +2
                        Человека взяли на работу, на которой в его должностные обязанности не входит кодить. А он боится растерять квалификацию, и не найти нормально уже следующую работу

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


                        Поэтому все ваши тезисы о другой работе — они немножко мимо, извините.


                        Обратите внимание, кстати, что в комментах ниже SlavaKulakov пишет "мы от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием". Видимо, они не считают, что это повышение/сохранение квалификации идет для другой должности.

                      +1

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

                        +2
                        Уже которого комментатора затянуло в воронку обсуждения выходов из вымышленной ситуации, вместо того, чтобы задаться вопросом: «А как наш герой в ней оказался-то? Зачем он устроился работать по специальности, которая будет ему только мешать держать форму для работы, на которую он на самом деле нацелен?»
                          0

                          Вы понимаете, что от SEM требуют знания технологий. При чем тут вообще на что нацелен человек.

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

                              Это тезис поста.

                                0
                                да? прочитал еще раз, не нашел это утверждение в качестве тезиса
                                  +1
                                  При этом «ржаветь» и останавливаться в собственной грамотности SEM не имеет права: он должен от начала и до конца понимать, с какими технологиями работает его команда и с легкостью отслеживать возможные проблемы.
                                    0
                                    для этого не обязательно глубокое погружение в стэк
                                    достаточно крепкого высокоуровнего понимания и слаженного взаимодействия с архитектором
                              +2
                              Можно мы просто процитируем комментарий выше? С небольшими сокращениями :)

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

                              Обсуждаемая в этой ветке история действительно скорее про «фантомных работодателей, которые требуют от вас того, чем якобы сами же запрещают заниматься». Плохие работы бывают, неадекватное начальство встречается. Но если это не системная проблема, то подобные рассуждения будут просто уводить диалог в пустоту.
                      +2
                      Всем привет!

                      Пришел начальник транспортного цеха. Вопрос понравился.

                      У нас в компании каждый СЕМ должен хорошо разбираться не только в ProjectManagement'е, но и иметь сильные знания в технологиях и инженерных практиках: как правильно организовать код-ревью, continuous integration, test driven development, branching strategy, deployment automation, environment provisioning automation, и так далее.

                      Ну а поддерживать/улучшать свои технические знания ему помогает одна из его прямых обязанностей, которую мы называем «Gemba Walk», а Toyota — «Walk the line»: чтобы менеджер имел возможность грамотно улучшить процесс — он должен видеть этот процесс вживую. В Toyota менеджеров посылают на заводы, где они ходят за рабочими и смотрят что и как они делают. Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием. Это позволяет им разобраться почему top-performers работают так быстро, научиться у них, а потом изменять процессы/тулы/подходы/практики соответственно и обучать уже всю команду.

                      А еще, так как один СЕМ обычно поддерживает несколько продуктов (от 5 до 10), то у него есть возможность выучить и разные технологии, увидеть в деле и сравнить различные архитектурные подходы. В общем, поле для профессионального роста просто огромное.
                        +2
                        Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием.

                        vs


                        «Семы» же, при должной компетентности в применяемых технологиях и методах, не принимают участия в написании кода, тестов и так далее, и ориентированы на конкретный фронт работ или операцию.
                    +2
                    Так и не понял приципиальной разницы между SEM и тимлидом, разве что кроме того, что тимлид — разработчик с обязанностями мереджера, а SEM — менеджер со знанием о технологиях. Не понятно зачем вообще нужна эта роль в команде?! Интеграция между частями команды осуществяется либо руководителем проекта (если менеджерский вопрос), либо архитектором/консилиумом тимлидов. А кроме этого ничего толком и не сказано, а только изображают тимлида в виде хватающегося за всё подряд и вечно-занятого недоменеджера. К тому же став SEMом вместо уважения в своём отделе, ты получаешь место джуниора в иерархии менеджеров и тебя не будет пинать только ленивый…

                    Получается что в SEM-ы стоит идти только карьеристам или в погоне за высокой зарплаты…
                      –5
                      Перечитав ваш комментарий дважды, я понял, что не только «разницы между SEM и тимлидом» не поняли)

                      тимлид — разработчик с обязанностями мереджера

                      100% мимо. Тимлид — это менеджер над разработчиками. В словах team lead вообще нет корня dev. Да, обычно тимлиды вырастают из девов — потому что приведи за разработкой смотреть человека вообще без этого бэкграунда, получится первая серия The IT Crowd. А «разработчик с обязанностями мереджера» и вовсе чудище обло, озорно, огромно, стозевно и лаяй. Меня аж кринжит, хотя я сам не разработчик, но ситуации такие наблюдал не раз.

                      SEM — менеджер со знанием о технологиях

                      50/50. В статье про бэкграунд SEM'oв ничего не говорится, и, теоретически, такое может быть — но где у нас, интересно, учат на «менеджеров со знанием о технологиях»? Всё равно в 99% случаев это будет чувак с девелоперским бэкграундом.

                      Не понятно зачем вообще нужна эта роль в команде

                      Наверное, потому что менеджеры без «знаний о технологиях» гораздо хуже?

                      Интеграция между частями команды осуществяется либо руководителем проекта (если менеджерский вопрос), либо архитектором/консилиумом тимлидов

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

                      К тому же став SEMом вместо уважения в своём отделе, ты получаешь место джуниора в иерархии менеджеров и тебя не будет пинать только ленивый…

                      О, а здесь можно поподробнее? Это из личного опыта что-то?

                      Получается что в SEM-ы стоит идти только карьеристам или в погоне за высокой зарплаты…

                      Всё-таки мне интересно, где и сколько вы успели поработать, если у вас даже карьеристов с высокой зарплатой запинывали?
                        0

                        Невероятно но факт у Software Engineer тоже нету корня dev.


                        Если менеджеру без "знаний о технологиях" гораздо хуже, зачем они вообще нужны?


                        Человек написал про "интеграцию между частями команды", а вы ему про "все менеджерские вопросы"

                        –4
                        Так и не понял приципиальной разницы между SEM и тимлидом, разве что кроме того, что тимлид — разработчик с обязанностями мереджера, а SEM — менеджер со знанием о технологиях


                        Это очень разные вещи.
                        Вы произносите слово менеджер так, будто бы эти люди ничего не делают.
                        +9
                        Если у вас технические специалисты не могут получать больше, чем менеджеры, то действительно сильных технических специалистов у вас никогда не будет.
                          0
                          Если у вас технические специалисты не могут получать больше, чем менеджеры

                          Какого уровня должен быть технический специалист в России, чтобы получать под $18000 в месяц, мне интересно? Нет, правда интересно: что делают в том же вашем «Яндексе» чисто технические специалисты, получающие на руки миллион рублей в месяц?

                          И если разложить весь «Яндекс» на этажи по уровням дохода сотрудников — с увеличением «этажа» % технических специалистов на нём будет расти или уменьшаться относительно «менеджеров»?
                            +1
                            А давно ли менеджеры типа тимлидов и SEM получают в РФ под $18000 в месяц?

                            Про Яндекс могу сказать так: можно расти как технический специалист и получать столько же, сколько при росте менеджером/управленцем. И не только на уровне руководителей групп.
                            0
                            Если у вас технические специалисты не могут получать больше, чем менеджеры, то действительно сильных технических специалистов у вас никогда не будет.


                            Вот купили мы в июне прошлого года JiveSoftware — компанию, которая базируется в Портлэнде — считайте та же Силиконовая долина. Для девелоперов там были созданы все условия — высокие зарплаты, отличный офис в центре города, 5 сортов разливного пива(!!!) в офисе, не говоря уже о еде, треннингах, массажистах и так далее. То есть инженеры у них работали очень даже квалифицированные (могли себе позволить заманить). Так вот — после покупки этой компании мы стали ставить своих иженеров ($50/час которые) в пары с Джайверами — всего за 3 месяца мы наняли 100 новых сотрудников через Кроссовер. И знаете что? Все Джайверы сказали, что наши ребята очень сильные и с ними здорово работать. Я специально постоянно всех спрашивал, так как самому было интересно сравнить наших ребят с коллегами из крутой компанией в Силиконовой долине.
                              +1
                              Ваши то девелоперы получают больше, чем ваши же менеджеры, или нет? Если меньше, то какой им резон развиваться профессионально, если выгоднее стать руководителем?
                                0

                                ИМХО у руководителя профессиональный путь не такой гладкий, в какой-то момент гораздо более вероятно оказаться в пустом переулке без денег и перспектив. Т.к. с таким опытом вас в подчинённые не возьмут а начальников своих(конкуренция ннадекватна) хватает.

                                  0
                                  Наши чиф архитекторы (ака тех-лиды) получают ровно столько же, сколько и СЕМы — $50/час. Следующая позиция над ними — это VP — $100/час.
                                    0

                                    Ну то есть получается, что "двойняшка" СЕМа — это техлид (а не тимлид, как написано в статье), а СЕМ — не (единственный) способ преодолеть стеклянный потолок над техническим специалистом.

                                      0
                                      Впрочем, если в плане карьерного роста CEM примерно соответствует тимлиду, а по зарплате — техлиду, то вопрос справедливости зарплат снова возвращается.

                                      SlavaKulakov, можете примерно рассказать о вашей карьерной лестнице?
                              +1
                              Зачем перед началом «крысиных гонок» заниматься «всякой фигней» в виде программирования?
                              Не лучше ли, да эффективнее, сразу включиться в «крысиную гонку», чтобы обогнать на старте?
                                0
                                Зачем перед началом «крысиных гонок» заниматься «всякой фигней» в виде программирования?

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

                                Не лучше ли, да эффективнее, сразу включиться в «крысиную гонку», чтобы обогнать на старте?

                                Зависит от ваших критериев эффективности. Скажем, про трудоустройство в любую из компаний нашего холдинга можно было бы сразу забыть. Наши тесты написаны не в шутку. Пожалуйста, почитайте Славин пост — там он хорошо описывает, как проходил наше тестирование при трудоустройстве в Aurea. В его случае это было удалённо, чаще мы всё же проводим тесты в формате мероприятия — как наш субботний турнир. Суть одна: «крысиные гонщики» к нам, нашим процессам, нашим разработчикам и на пушечный выстрел не попадут.

                                Так что нет, не лучше. Не эффективнее. Никого он так не обгонит ни на каком старте. В общем, не зашла нам ваша идея :)
                                  +2
                                  Т.к. в статье говориться
                                  1) О карьере
                                  2) О «бесконечном» повышении заработка
                                  то я делаю вывод, что мне, как специалисту, предлагают поучаствовать в «крысиных гонках».
                                  Т.к. «Даже если всего себя посвятить совершенствованию кодерского мастерства, ты лишь отполируешь стеклянный потолок над своей головой.»
                                  Поэтому зачем тратить время и усилия по «совершенствованию кодерского мастерства», когда можно сразу выбрать путь «крысиных гонок».
                                  Это проще и эффективнее.
                                  (см., например, Б.Гейтс, С. Джобс )
                                  Ну и не забываем про «принцип Питера».
                                  Рано или поздно во всех узлах иерархии будут находится некомпетентные сотрудники.
                                  :-)
                                0

                                Конкурс они решили замутить. Ни разу не на жадных лохов статья рассчитана

                                  0
                                  Crossover в своем репертуаре… и в своей реальности…
                                    0

                                    Полностью согласен.

                                    +1
                                    «Статья» от кроссовер.
                                    Жонглирование субъективными тайтлами и ЗП.

                                      +11

                                      Работал я у вас какое-то время и могу с уверенностью сказать, что единственное преимущество компании Crossover for Work — это конкурентная ЗП, выплачиваемая без проволОчек. На этом — всё. Тебе дают какой-то легаси-проект (там по всей Aurea сплошь виндовое легаси), снимают на веб-камеру, фоткают экран (это же дикость, объяснять что это remmina — это приложение, которым ты ходишь по RDP и что это разрешённая аппликуха) и обвешивают кучей метрик производительности. И ты деградируешь в техническом плане, пытаясь как дрессированная обезьяна при этом соотвествовать этим метрикам. Хорошо хоть повезло с менеджером, она была одной из лучших, которых я встречал.
                                      Ну и как маркетинговый ход — создать шоу, чтобы поднять желанность позиции в глазах претендентов.

                                        +1
                                        Счастливый человек. Мне ни одного приличного менеджера там встретить так и не удалось. Ну или занимаются они чем-то своим, не включающим взаимодействие с разработчиками. Какое там «раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием», банальный ответ на вопрос в слаке можно было по полдня ждать.
                                          0

                                          А как при таком ожидании считали метрики и оценивали вид экрана с открытым мессенджером или трекером и Ваш скучающий вид перед вебкой?

                                            +1
                                            Так и считали. Для того, чтобы вопросов не возникало, было достаточно открыть IDE, периодически менять открытый в ней файл и нажимать что-нибудь на клавиатуре, почитывая интернет с телефона (к вопросу об эффективности такой слежки). Понятное дело, что заниматься имитацией работы вместо работы ужасно скучно, так что долго в таком режиме я не протянул.
                                              0

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

                                                0
                                                Ну, я сменил проект, чтобы не имитировать. Это считается?
                                                  0
                                                  Нет, конечно. Мы ж так и не знаем, что будет, если оставаться работать — и не имитировать деятельность во время простоев по вине менеджмента заказчика.
                                                    +1
                                                    Это да. Я подозреваю, некоторое количество нервотрепки явно было бы, так что ставить такой эксперимент желания не возникло.
                                                –1
                                                >>к вопросу об эффективности такой слежки

                                                Интересно, а кому нибудь приходило в голову, что у разработчика на столе может находиться два и более компьютеров? У меня например дома… ща гляну… вот сейчас три — десктоп (используется напрямую крайне редко), рабочий лептоп и собственный лэптоп. Есть еще (где-то) «старый лэптоп», два гибридных планшета 10 и 12 д.ймов соотвественно. Лжптом жены и ребенки я не считаю ибо они могут находиться в самых неожиданныхместах, но точно не на моем столе… что еще… еше есть серверок домашний, и еще один старый десктоп — когда нибуль станет вторым серверком…
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0

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

                                                +1

                                                Почему же, интересно. Нужны реальные подробности от реальных людей. Может, пост напишите?

                                                  +2

                                                  Ну, я не уверен, что материала хватит на целый постинг. Да и излагаю мысли достаточно сумбурно. Очень не хочется чтобы это выглядело как критика ради критики. Альтернативой была бы "личка", но это будет выглядеть, будто я прячусь опасаясь ответной критики.
                                                  Можете почитать тут (нашёл случайно) или тут (это уже мой отзыв). Ну, и присовокупить то, что я написал в топ-комменте этого треда.

                                            +1
                                            SEM — это технический менеджер? Не понял из статьи, за что он все-таки отвечает?
                                              0
                                              У нас в компании есть 2 типа СЕМов — ПродактСЕМ и КорСЕМ.

                                              ПродактСЕМ больше ориентированы на классический Project Management: scope management, release management, timelines, risks/issues management, очень много общения с «братскими» организациями — SaaSOps, Product Management, Support, Professional Services. ПродактСЕМы заказывают выполнение работы у КорСЕМов.

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

                                                Где — выше? Какой комментарий?

                                              +1

                                              Так в чем разница между тимлидом и SEM? Судя по комментариям, это многим не ясно. Что мешает сделать тимлида ответственным за узкое направление? Надуманная разница

                                                0
                                                Почему?
                                                Разница есть… В условной иерархии.
                                                А так, какая разница teamlead или SEM, главное чтобы он работал и за менеджера, и за программиста, и за ментора для юниоров.
                                                По мне teamlead это первый среди равных.
                                                Чтобы споры о красоте того или иного решения не превращались в холивар.
                                                Тот кто будет говорить, что делать надо так и никак иначе.
                                                При этом все остальные программисты с этим согласны.
                                                Ну и по возможности передавать опыт.
                                                Т.е. сплав опыта и авторитета.
                                                Остальное, это просто ленивые/ушлые менеджеры перекладывают свою работу на него.
                                                  0
                                                  В компании из статьи нет тимлидов, а СЕМы не программируют (хотя в каких-то подразделениях по час в день в виде парного программирования, как было в комментарии выше). Откуда про условные иерархии? SEM — менеджер, сотрудники его команды — исполнители. Вроде де бы все просто.
                                                0
                                                Это вроде как главный конструктор главного КБ страны перейдет в главного завхоза главного КБ страны. Не глупо?
                                                Не понимаю я такие статьи.
                                                Как рост у манагера? Не перешел ли лид от «своей верхней планки» которую тут назвали тупиком в настоящий тупик где манагер останется манагером?
                                                И самый важный вопрос: «почему обязателен рост? Книжек начитались?».
                                                Почему нельзя наслаждаться работой сеньёра девелопера ?!
                                                Не думаю что есть чего-то значащие ответы на эти вопросы…
                                                  0
                                                  когда нагрузка по непосредственной работе с кодом осталась в прошлом, уступив исключительно менеджерским обязанностям,… деятельность становится более понятной и прозрачной окружающим

                                                  Весьма спорно...

                                                    0

                                                    Окружающие начинают видеть, что чел занимается хернёй, вместо того чтоб не понимать, что он там кодит ;)))

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

                                                  Самое читаемое