company_banner

Как компании отказаться от роли тимлидов

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

    В PropellerAds решили пойти по принципу «нет человека — нет проблемы» и отказались от роли тимлидов. Как компании удалось это провернуть, не только не потеряв ни одного руководителя, но и успешно привлекая тимлидов из других компаний, в своем докладе на конференции TeamLead Conf 2020 рассказал глава продуктового отдела PropellerAds Яков Беккер.

    Давайте поговорим о том, кому нужен тимлид? Вопрос риторический, поскольку ответ на него знают все: тимлид нужен в первую очередь руководству.

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

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

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

    Что еще, кроме предоставления статуса и спуска распоряжений вниз, хочет от тимлида руководство?

    Ожидание: функции тимлида

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

    Руководство надеется, что тимлид будет управлять процессами в команде, и станет выполнять роль менеджера продукта или проекта. Хотят, чтобы он понимал domain. 

    Кроме того, тимлид должен отвечать за качество. Багов быть не должно, особенно в продакшен. Руководитель не хочет, чтобы его разбудили в 3 часа ночи, чтобы уведомить, что все упало и не работает. Очень удобно, когда есть человек, который отвечает за такие вещи и знает, как все оперативно исправить. 

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

    Кого же нужно найти? 

    Руководители ищут некого сказочного единорога мира кода, который должен уметь делать все. Но в реальности его не существует. 

    Реальность: проблемы в работе тимлида

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

    • Вся ответственность ТОЛЬКО на тимлиде;

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

    • Отсутствие делегирования;

    Часто тимлид перестает делегировать, потому что боится за качество и результат. Или он не умеет делегировать и не понимает, как делать это правильно. Многие думают, например, что делегирование — это просто спускание тасков вниз. 

    • Mикроменеджмент;

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

    • Слабое руководство вызывает недовольство команды;

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

    Вся команда только и говорит о том, как плох тимлид.

    • Тимлид выгорает;

    На тимлиде куча ответственности, есть проблемы, которые нужно решать, команда им недовольна. И при этом он работает по 12 часов. Человека нужно спасать. Если спасти не удалось, он уходит из компании.

    • Проблемы при уходе тимлида из компании;

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

    • 25% лучших разработчиков не пишут код.

    Представьте, что у вас были звезды разработки. Они писали код, а теперь его не пишут. Это ситуация — 25% лучших разработчиков не пишут код — должна приводить в ужас любого CTO.  

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

    Давайте сравним две команды: с тимлидом и без. На этой картинке солдаты смотрят на своего командира (тимлида) и ждут, чтобы он их спас. На нем лежит вся ответственность. Это плохо, потому что команда ее не чувствует, вы оставили ответственность на одном человеке.

    И есть другая команда:

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

    Конечно, на деле все не так ужасно: есть хорошие тимлиды. Но стать единорогом в этой сфере очень тяжело. Есть большое количество курсов и тренингов, есть TeamLead Conf с огромным количеством возможностей учиться. Все это помогает нам вырастить хороших тимлидов и исправить проблемы, описанные выше.

    Но в PropellerAds структура управления устроена по-другому, и это работает.

    Решение: самоорганизующиеся команды

    В PropellerAds есть продуктовые команды, которые стоят в центре системы компании. В них входят:

    • Владелец продукта (Product Owner) — это человек, который разбирается в продукте, работает с бизнесом, строит бэклог, менеджерит риски, пишет User Story и прочее;

    • Разработчики, scrum-мастер;

    • Тестировщики;

    • DevOps.

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

    Где же руководители? Они есть у каждой функциональной группы (PO, разработчиков, тестировщиков, DevOps).

    Что такое функциональный руководитель? Это тренер функции: тренер разработчиков, тренер тестировщиков и т.д. В его задачу входит растить своих людей и поддерживать их уровень. 

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

    Распределение обязанностей в команде

    Кто занимается разработкой — кодом, дизайном, архитектурой? 

    Разработчики.

    Кто занимается продуктом?

    В продуктовой компании это очень важный вопрос. Например, стоит задача создать кабинет для рекламодателя. Нужно разговаривать с заказчиками каждый день. В PropellerAds PO этого направления ездит на профильные конференции, общается с рекламодателями, делает Customer Development, проводит вебинары. 

    Кто занимается управлением процессами в команде?

    В PropellerAds нет выделенной роли scrum-мастера. Эту роль чаще всего играет не senior-разработчик, а тот, кому это интересно. Например, QA, DevOps или middle-разработчик (junior не может). Это должен быть человек, которому интересно этим заниматься.

    Кто управляет инцидентами?

    Логично выделить для этого DevOps-инженера. 

    Что с единой точкой входа?

    После того, как ушли тимлиды, она стала сложнее. Пострадало руководство. Раньше были люди, ответственные за команду, которым можно было задать любой вопрос, и они дали бы ответ. Но теперь вопросы по продукту нужно задавать одному, по коду — другому и т.д. 

    Кто занимается наймом, ростом и мотивацией людей?

    Эти вопросы полностью лежат на функциональных менеджерах. В компании существует оценка удовлетворенности функциональным менеджментом, и сейчас она — 9,6. Это почти предел, и непонятно, как она может стать выше. 

    Почему все так здорово? Функциональные менеджеры целыми днями ведут планы персонального развития, делают one-on-one, правильно проводят квартальные ревью, никого не обижают. Они видят свою роль в том, чтобы их команде было хорошо, а отдельным людям было приятно работать в PropellerAds, чтобы специалисты развивались и через 3 года стали лучшими инженерами. Это одна из самых важных целей функционального менеджера.

    Их задача заключается в развитии людей и в продвижении по эффективности. 

    Из-за того, что есть роли (PO ответственен за продукт, QA за инциденты и пр.) может показаться, что ответственность лежит на определенных людях. На самом деле, это не так, ее несет вся команда. 

    В компании используют Slack. Как вы думаете, кого кастуют в случае инцидента? Чаще всего — не конкретного человека, а всю команду. Например, кастуют команду Core, и отвечают три человека: PO, разработчики и QA — каждый по своим вопросам. То есть точкой входа становится не конкретный человек, а команда.

    Структура управлением бизнеса

    Как в PropellerAds управляют бизнесом? Есть руководитель направления, например, определенного формата рекламы. У него в подчинении маркетинг, продажа и оптимизация. И этому руководителю выделяются 1-2 продуктовых команды, чтобы они выполняли 90-95% его тасков, и ему не пришлось искать помощь на стороне.

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

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

    Структура управления технологией

    В PropellerAds есть функциональный менеджер разработки — R&D-менеджер.

    Он организовал четыре направления и нашел тех, кто согласился их вести. Во главе направлений встали senior, каждый из них лидер. Кто-то ведет ротацию, кто-то данные, кто-то фронтенд, кто-то back office.

    R&D-менеджер собирается с командами, строит технологическую стратегию, презентует ее на стратегической сессии и т.д. 

    Решение: все проблемы устранены

    Что получила компания в итоге:

    • Ответственность всех членов команды — от нее стало очень сложно спрятаться;

    • Несколько человек в команде являются точкой входа; 

    • Командная работа вместо микроменеджмента; 

    • Команды довольны руководством; 

    • Лидеры не выгорают. Выгорают обычно от того, что человек занимается нелюбимым делом, или не способен сделать то, что от него требуют.

    • Нет причин для кризиса при уходе людей из компании. Текучка в компании небольшая, но иногда люди все-таки уходят. Кризиса не происходит, потому что команда не теряет целостность: ушел один человек, но все остальные остались.

    • 25% лучших разработчиков снова ПИШУТ код. И это просто вау! 

    Проблемы

    Выше нарисована, казалось бы, идеальная картина. И все же в PropellerAds есть определенные проблемы. 

    Проблема командной ответственности

    Бывает, в одной из десяти команд, коллективную ответственность воспринимают так, будто ответственности не несет никто. И вот кастуешь команду из восьми человек по какому-то вопросу, а ответа нет. Пропустили Sprint Goal — и это никого не волнует. Раньше по этому поводу нервничал бы хотя бы тимлид. 

    Управлять тимлидом легче, чем целой командой: его можно мотивировать, или поменять. 

    Эта проблема решается просто: в команде должно быть 2-3 лидера. 

    Обычно PO — лидер по определению. Он строит продукт: как же он может не быть лидером? Остаются еще два: например, QA и разработчик. То есть должны быть ребята, которые тащат команду на себе, не потому что им сказали это делать, а оттого, что им самим это нравится — они чувствуют азарт. В большинстве команд так и происходит. 

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

    Проблема управления матричной структурой

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

    Без тимлидов в компании становится сложнее. Но можно наладить успешное взаимодействие, если есть три важные вещи. 

    • Доверие;

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

    • Независимость;

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

    • Пассивный контроль.

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

    Проблемы карьерного роста

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

    Давайте задумаемся, чего хочет человек, который мечтает стать тимлидом:

    • Иметь авторитет и, как результат, получить влияние и независимость;

    • Саморазвиваться;

    • Зарабатывать больше денег. 

    Чтобы получить все это, можно построить карьеру внутри компании.

    Карьера разработчика в PropellerAds

    С тимлидами в компании было бы движение по иерархической лестнице. У них не было бы другого пути: хотели они или нет, но должны были бы превратиться в мифического единорога. И чем лучшими тимлидами они могли стать, тем дальше могли продвинуться по карьерной лестнице. И если CTO уволится, то получится получить его место! Но часто ли вы видели увольняющегося CTO? 

    Сейчас в PropellerAds можно стать функциональным менеджером. У СТО есть команда из шести человек: Head of Analytics, R&D менеджер, Head of QA и люди, которых можно назвать руководителями высшего звена. 

    Можно стать техлидером, или product-менеджером, они всегда нужны: каждый квартал что-то происходит. Как этого добиться? Поинтересуйтесь продуктом, domain, клиентами, сходите на курс, предложите себя. 

    Если вы middle-девелопер, можно стать scrum-мастером, или коучем. 

    Кроме того, можно вырасти в business owner.

    Все в руках сотрудников.

    Изменение структуры

    Легко ли создать структуру, которая сложилась в PropellerAds? Относительно тяжело. Гораздо проще организовать иерархию тимлидов. 

    Описанная система гораздо сложнее, в ней много противоречий. Но в PropellerAds без тимлидов достигли гораздо большей эффективности, чем раньше. И с гораздо более счастливыми людьми.

    TeamLead Осень 2020 пройдет 29 и 30 апреля 2021 года. Приобретайте билеты и становитесь частью единственной профессиональной конференции только для тимлидов.

    А программный комитет Saint TeamLead Conf 2021 ждет ваши доклады.

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

    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Комментарии 36

      0
      А как появляются лидеры в гильдиях QA/Dev? Их кто-то назначает, озвучивая примерный скоуп ответственности, или это самопровозглашённые лидеры с амбициями от природы?
        +1

        Лидерство и амбиции — это вообще-то несвязанные вещи. В статье:


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

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


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

        +1
        Это как и среди разработчиков самопровозглашённые лидеры. Дело не в амбициях. Чаще это просто крутые профессионалы, которым интересно работать и получать результат. Они пользуются уважением команды и руководства за их знания и успехи. К ним идут люди за помощью и они сами часто вызываются вести проекты. Например в QA y нас есть инженер, который развивает методологию авто тестинга. Его никто на эту роль не назначал. И он работает в одной из команд, а не выделен не эту задачу. Важная деталь здесь, что руководство принимает и поощряет его инициативу, в том числе позволяя ему выделять на это время.
          +9

          Тимлид — человек отвечающий за культуру разработки в сочетании с конкретной предметной областью. В статье — просто какое-то феерическое непонимание роли тимлида.

            +3
            Я думаю, что в каждой компании свое понимание роли тимлида.
            +4
            Если отказались от лидов, то какая роль CTO? Он теперь тоже пишет код?
            DevOps управляет инцидентами а Скрам-Мастер процессами?
            Если члены команды имеют разные мнения — каждый делает по своему?
              –3
              Мои роли
              1. Участвовать в разработке стратегии компании
              2. Доносить стратегию компании до всех и следить, чтобы наш роадмап лучшим образом соответствовал продвижению по этой стратегии.
              3. Создание, внедрение и развитие культуры отдела
              4. Управление командой функциональных менеджеров
              5. Бюджет, ресурсы
              6. Создание команд.
              7. Помощь командам в лице функциональных менеджеров в найме, увольнении, решении конфликтов
              8. Помощь в создании и выполнение технологического роадмапа включая внедрение новых технологий и сокращение technical debt
              9. Создание и воплощение индивидуального плана развития для всех членов команды (выполняется функциональными менеджерами).
              10. Прямое управление в кризисных ситуациях.
              И еще вагон и тележка задач. Не сижу без дела. Код не пишу.

              Ответсвенность за инциденты на командах. DevOps, который часть команды, конечно выжнейший человек в этом процессе.

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

                +3

                Судя по описанным обязанностям, вы — project manager?
                По крайней мере у нас нет такого понятия как тимлид. У нас есть тех лид и ПМ. Потому что мифический тимлид находится где-то посередине.

                  0

                  Мифические тимлиды — люди, которым ПМ делегирует свои менеджерские обязанности, если в команде проекта больше 5 человек

              0
              Я правильно понял? Тимлид не нужен? А скрам «я не знаю вообще предметную область, не разбираюсь в бизнес-процессах» мастер нужен?

              Тим лид занимается культурой кода. Вырабатывает правила и следит за их выполнением. Общается с разрабами объясняет моменты. Определяет кому лучше какими тасками заниматься и т.д.
                –2
                У нас культурой кода занимаются ведущие разработчики. Мы не видим смысла выдавать им для этого официальную роль. Вообще история с важностью «культуры кода» преувеличена. Инженеры (не кодеры) с 5 годами опыта умеют писать код очень хорошо. Это как обучать врача лечить. Думать про какие то общие правила написания кода это одно, а постоянно заниматься этим и еще иметь для этого выделенною роль это как то странно. Ведь у нас не школа, чтобы на каждых 4-5 инженеров иметь по учителю. Возможно, что если в компании преобладают джуны, то их нужно постоянно контролировать и учить писать код. У нас есть одна единственная команда SWAT с тим лидом, которая занимается поддержкой. Мы туда нанимаем исключительно джунов. Тим лид их растит, учит код писать.

                Скрам мастера у нас есть. Можно иметь выделенных скрам мастеров, можно чтобы эту роль выполнял кто-то параллельно со своими задачами разработчика или тестировщика (мы так делаем). Можно каждый спринт ротировать скрам мастера (одна наша команда так делает). Можно в очень дружных и эффективных командах вообще без скрам мастера.
                  +4
                  Вы заблуждаетесь в большинстве вашего текста.

                  Начнем с того, что врачи постоянно ходят на повышение квалификации. И даже преподаватели в вузах ходят.
                  Затем вы ошибаетесь, что инженеры пишут код хорошо. Они пишут код чтобы он работал хорошо (и то не всегда), а о том, чтобы он легко поддерживался и был расширяемым мало кто думает, особенно если в команде есть скрам-мастер.
                  В третьих, никто не говорит, что роль тим-лида должна быть выделена и отдельной. Ее может совмещать в небольших командах ведущий разраб. А уже на 10-12 человек у него вообще не будет почти времени на кодирование.
                  Потому что идут десятки коммитов в день и нужно тупо хотя бы пул реквесты проверять.
                    0
                    Я не буду спорить. Я знаю что не ошибаюсь так как под моим руководством 3 компании вышли на исключительно высокий уровень и создали прекрасные продукты, в том числе с технологическом плане. Ревью делают ведущие разработчики. Выделять для этого официальную роль не вижу смысла. Если ваши разработчики не думают про поддерживаемость, расширяемость и так далее, то у вас плохие разработчики. Их нужно менять или растить.

                    Мы вкладываем огромные ресурсы в рост наших разработчиков. Они ездят на конфы включая международные, выступают там, ходят на курсы. Люди участвуют в коммисиях по тех улучшениям. Но нет выделенных тим или тех лидов.
                      0
                      Вот вы в прошлом комменте всё написали правильно, только забыли написать про код-ревью. Действительно, если каждый мердж происходит только после код-ревью несколькими другими участниками команды, то код получается и поддерживаемым и расширяемым.
                        0
                        Каким образом ошибка выжившего говорит о проблеме в целом?

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

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

                        Они ездят на конфы включая международные, выступают там, ходят на курсы.

                        Вы серьезно считаете, что это хоть как-то помогает?
                          0
                          Я описал свою систему. Она отличается от того что практикуется в России. Я не уговариваю вас ее принять или применять. Для меня работает очень хорошо. Я посоветовал бы просто задуматься над тем, что я написал. Возможно, это будет вам полезно. Если нет, то не берите ничего из этих практик. И конечно, как все на свете, эта система не применима во всех случаях. Эта система точно работает в продуктовых копаниях В2С, с численностью отдела разработки до 200-300 человек. Работает ли она в других случаях я НЕ ЗНАЮ. У Spotify и многих других западных компаний есть подобная система, но я не могу сказать что я очень глубоко изучил их опыт. Я действующий CTO а не консультант и у меня нет времени на глубокие исследования.
                    0

                    Кроме последнего пункта вы больше про техлида говорите, нет?

                    0

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

                      –1
                      У нас AdNetwork с 10 миллиардами импрешенами в день. Как можно догадаться у нас мало типичных задач. Команде не нужен «папа» который примет правильное решение. Люди вполне договариваются сами. Культура доверия и уважения очень помогает. Конечно команды ошибаются. Но тим лиды тоже ошибаются и на моем опыте чаще.
                        +6
                        Ох уж эти креативные задачи в баннерной рекламе!
                      0
                      Но часто ли вы видели увольняющегося CTO?

                      Я сам такой )
                        +1

                        А чем техлиды у вас занимаются? Как по мне, многие разработчики идут в тимлиды, лишь потому что позиций чистых техлидов мало, а тимлид чаще всего — это техлид+часть обязанностей ПМ в нагрузку. Вот и идут в тимлиды, чтобы хоть часть времени быть техлидом. Сам такой.

                          0
                          У нас нет тех лидов. В каждой команде есть крутые разработчики. Они по сути выполняют роль тех лидов, но без официального бейджика. Им от этого лучше, потому что оплачиваются они как тех лиды, а формальных обязанностей тех лидов у них нет. Такую систему тяжелей организовать. Гораздо легче раздать должности и часто ничего не означающие титлы, такие как Second degree Senior backend developer. Но зато команда состоящая не из руководителей и подчинённых, а из равных друг-другу людей гораздо более сплоченная, ответственная и вовлеченная. Это не отменяет того что джуны и мидлы уважают мнение сеньоров и учатся у них. И это не отменяет роль сеньоров как менторов молодежи и гарантов качества продукта, технологии и кода.
                          Тут был вопрос — а что же делает CTO. Так вот CTO со своей командой руководителей как раз и выстраивает эту далеко не простую систему.
                            0
                            Крутая статья, и я рад, что у вас всё работает, но у меня впечатление, что всё определяется адекватностью и квалифицированностью конкретной группы людей, а структура просто подходит для этой конкретной группы. У вас это продуктовые менеджеры, а в другом месте это будут тимлиды, техлиды, кто-то вообще скажет QA или dev-ops и т.п.

                            Выше уже указывали на нестыковки, но все таки, если с тимлидами понятно, то что случилось с сеньорами и техлидами (в софтверных компаниях), которые упоминаются в тексте и на картинках? А что с архитекторами?

                            Что-то очень сомнительно, что крутые разработчики находят это лучше. Нет тайтла — нет причин платить им зарплату как тех лидам. Если у вас действительно так, то хорошо, но скорее всего в других местах все будут получать как middle или junior. Если у людей нет возможности роста у вас, то сначала будет демотивация, выгорание и т.п., что вредит всем, а потом они найдут рост сразу в ЗП и тайтле в другом месте.

                            > команда состоящая не из руководителей и подчинённых

                            В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители. И тут можно почти без изменений переписать «Реальность: проблемы в работе продакт менеджера» и далее по тексту.

                            К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д. Плюс добавим проблему коммуникации ПМ: " ПМ видит всю картину, а задача какого-то там разработчика закрывать таски".
                            «Пассивный контроль» — ПМ рассуждает так: «что-то метрики в джире слабоватые, и мои фичи медленно делаются. Нужно узнать, где проблема, а давайте ка соберем метрик побольше». Результат недоверие со стороны ПМ. В итоге недоверие обоих сторон и микроменеджмент.
                            «Независимость» — с ростом числа людей появляется политика, и конец независимости может прилететь откуда угодно.
                              0
                              Нет тайтла — нет причин платить им зарплату как тех лидам.
                              — Мы платим. Никакая система не будет работать если вы говорите одно, а делаете другое

                              — Сеньеры работают в командах. Они же являются неформальными тех лидами. Мы обходимся без архитекторов. Вместо этого у нас меж-командные рабочие группы по развитию технологии. Архитектор вполне может быть в этой системе. Он будет вне команд. Он же не руководитель, а больше советник. У нас например UX вне команд.

                              В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители.
                              — конечно ПО неявные лидеры. Как же по другому? Но они ни кем не руководят. Они занимаются бэклогом, общением с клиентами, сбором аналитики так далее.

                              К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д
                              — Задача руководства это добиться чтобы описанных проблем между ПО и разработкой не было. Это культурная и профессиональная составляющая. Этому еще очень помогает то что главная команда ПО это команда разработки.
                              Если у вас ПМы гробят разработку из за незнания и непонимания тех деталей означает, что у вас ПЛОХО организовано руководство и неправильная культура в компании.
                                0
                                > Если у вас ПМы гробят разработку из за незнания и непонимания тех деталей означает, что у вас ПЛОХО организовано руководство и неправильная культура в компании.

                                Полностью согласен! К счастью, у «нас» такого нет, но все приведённое выше к сожалению живые примеры…
                              0

                              Ну вот же в карьерных возможностях пишите "можно стать техлидером" — это роль или позиция с бейджиком?

                                0
                                Роль
                                  +1
                                  Ну и тим лид это роль. Вы можете автомобиль назвать кактусом, но он не станет кактусом. Соответственно, вы можуете поручить роль тим/тех лида разрабу, но они не перестанут быть задачами тимлида или техлида.

                                  И да, в некоторых случаях необходим чувак с бейджиком. ПОтому что нужен в иерархии человек, который несет ответственность за бардак. Потому что не дело CTO или продукт оунера заниматься микроменеджментом кто просрал таски или что-то уронил.
                                    0

                                    А самовольное занятие какой-то роли — это точно карьерный рост?

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

                                Но код-то хороший? После обучения читается?

                                  0
                                  код хороший ) бывают сценарии что он его написал и уволился или умер (все мы смертны) и тогда единственный источник экспертизы чтобы его разобрать будет гугл
                                    0

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

                                      0
                                      Естественно приходится искать не джунов о чем я и сказал себестоимость сопровождения кода возрастает. Отчасти мне жаль что для джунов растет потолок входа.
                                      Хорошие разработчики у нас не только покупные нередко они появляются по мере саморазвития работая на наших проектах
                                        0

                                        Ну так, хороший код — дорого )

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

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