Те, кто знакомы со мной, знают, что я никогда не поддерживал идею роли Тим Лида. Хотя раньше я думал, что негативная коннотация этой роли скорее связана со стилем руководства и что этому можно обучиться и к этому можно приспособиться.
Все мы знаем, что стиль руководства может быть разным. Но сейчас я считаю, что если вы имеете встроенную роль Тим Лида в команде, то культура в конечном итоге будет следовать структуре. Это означает, что фигура Team Lead, скорее всего, будет преобладать над другими членами команды, оставляя их бессильными и жертвами.
Я в роли Тим Лида
Я помню, как еще на первом месте работы в 2001–2003 годах меня назначили Тим Лидом. Это произошло потому, что ранее я участвовал в этом проекте и кое-что уже знал о предметной области, клиентах и коде. Так, в моем подчинении, оказалось несколько разработчиков.
Некоторые принятые тогда мною решения, на самом деле, были не так уж и плохи. Я внедрил Непрерывную Интеграцию и Модульное Тестирование. Но сейчас, оглядываясь назад, я полностью осознаю, до какой степени я сдерживал свою команду и насколько сильно контролировал ее.
Теперь мне даже стыдно вспоминать, как я отругал умного разработчика за давно назревший рефакторинг. Почему я это сделал? Не потому, что я не хотел более хороший код. И ни потому, что я хотел сделать это сам. Нет. Я просто испугался изменений, которые он вносил. Я думал, что они могут серьезно сломать код и задержать доставку, за что на меня возлагалась полная ответственность.
Я чувствовал себя неуверенно и беспомощно. У меня возникало желание контролировать то, что делает другой разработчик, ведь иначе он бы все разрушил, в том числе и мою карьеру. Уровень ответственности, которая была возложена на меня (или я сам со временем еще больше возлагал ее на себя?), была слишком велика – я не мог действовать инициативно и открыто.
Я препятствовал необходимым изменениям. Я не лидировал - я блокировал.
... прошло 20 лет и теперь я знаю, что, вероятно, был слишком молод для этой роли. Но, с другой стороны, разве такое мое поведение в роли Тим Лида не формирует узнаваемую закономерность, которую мы можем повсеместно увидеть сегодня? Узнаете ли вы себя или своего Тим Лида в этой истории?
Ответственность, возложенная на одного человека, в конечном итоге приводит к его перегрузке и стрессу. И это может привести к различным дисфункциям. Безопасная и реактивная игра — это лишь одна из тех возможностей, с которыми я лично столкнулся. Другие могут вести себя по-другому в условиях стресса под давлением слишком больших ожиданий от них. Но превыше всего стоит одна закономерность — уровень командования и контроля над другими со временем повышается. Тем самым высасывая ответственность из самой команды.
И это становится порочным кругом, самосбывающимся пророчеством. Команда перестает действовать, ожидая действия своего лидера, а лидеру ничего не остается, кроме как действовать, потому что он не видит проактивности со стороны команды. Проходят месяцы и годы, и все, что у вас есть, это чрезмерно измученный человек, пытающийся микроуправлять кучей демотивированных людей. Это тяжелая работа и печальный образ жизни.
Так не должно быть. Мы можем работать намного лучше! Но сначала нам нужно понять, как мы создали эту динамику.
Хорошие намерения. Плохая динамика.
Обратите внимание, что назначение Тим Лида (или аналогичной роли в команде) всегда начинается с добрых намерений:
«Давайте возьмем в команду опытного специалиста (senior), чтобы убедиться, что команда принимает правильные решения».
«Вместо того, чтобы вся команда тратила свое время на разъяснение этого требования, пусть просто Тим Лид взглянет на него».
«Мы должны убедиться, что младшие разработчики не вносят свой вклад плохими кодами, поэтому пусть Тим Лид рассмотрит предложения изменения кода».
Никто никогда не был уволен за высказывание этих или подобных предложений. Они имеют смысл. Они логичны. Кроме того, их с легкостью можно отыскать в других компаниях, с которыми мы сталкивались или в которых работали.
Тем не менее, именно эти предложения приводят к негативной динамике, которую мы только что обсуждали выше. Введение специальной senior роли (как бы вы ее ни называли), скорее всего, приведет к ограничению потока работы и роста команды. Именно так работают узкие места в системе.
"Покажите мне специалиста, и я покажу вам узкое место!" - как выразился мой коллега-тренер по LeSS и хороший друг Грег Хатчингс. А Тим Лид со временем становится адски крутым специалистом.
Вместо этого назначайте Engineering Managers
Чем больше я сейчас работаю с великими компаниями, тем больше я наблюдаю эту закономерность: роль Тим Лида упраздняется, и вместо него назначают Engineering Manager-а с акцентом на долгосрочное техническое процветание. На практике это означает, что Engineering Managers работает с несколькими командами и делает это кросс-функционально.
Можно сказать, что это просто «масштабирование» роли Тим Лида. Но нет. Это создает совершенно другую динамику:
1. Ваши команды свободны от диктатуры любого рода
Команды теперь просто команды. Никаких ролей, никаких игр во власть. Плоские и проактивные, как это определено в Scrum. Все решения, требующие участия всей команды, будут приниматься всей командой. И если для некоторых процессов требуется только представитель команды (или два), эти представители, скорее всего, будут меняться и никогда не приведут к формированию «особых» людей. Особых людей нет. Есть просто блестяще равные члены команды, излучающие потенциал действовать свободно, когда это необходимо.
2. Product Management ведет за собой команды
Мы хотим, чтобы людей вели, а не говорили им, что делать. Деловой человек в команде (например, Владельца Продукта в Scrum), который ежедневно работает с командой, может дать достаточно объяснений, чтобы все понимали направление и действовали соответственно. Нам не нужен еще один лидер, чтобы переварить, упростить и отгородить команду от реального мира. Наконец-то, мы можем начать относиться к людям как ко взрослым.
3. Сосредоточьтесь на долгосрочном росте
Engineering Manager должен работать с несколькими командами, а не с одной. Таким образом, мы сводим к минимуму возможность этого человека знать все детали, а затем пытаться микроуправлять. Этот человек все еще может быть вовлечен в деятельность по развитию и достижению краткосрочных целей. Но не на полный рабочий день. И не ради поставок.
Миссия Engineering Manager состоит в том, чтобы наращивать потенциал команд. Чтобы инженерия снова стала великой.
Ниже приведен пример должностной инструкции Engineering Manager в Gusto:
- Нанимайте, возглавляйте и развивайте команду талантливых инженеров.- Создавайте и поощряйте инклюзивную, совместную и высокоэффективную культуру.- Сотрудничайте с нашими командами по data science, операциям, управлению продуктами и дизайну, чтобы руководить и владеть разработкой сквозных продуктов для сложных потребностей клиентов от начального планирования и исполнения до окончательной поставки.- Работайте в тесном контакте с руководством, чтобы помочь установить приоритеты как для краткосрочных, так и для долгосрочных дорожных карт.
Это компания, в которой Кент Бек работает Engineering Manager-ом (по состоянию на 2022 год). И он много пишет об этой роли, своей миссии и обязанностях руководства.
4. Код с командами
Мы хотим, чтобы Engineering Manager были... инженерами. Не HR-специалистами или лайф-коучами.
Мы всегда хотели, чтобы более опытные инженеры передавали свои знания другим. Тим Лиды были попыткой добиться этого, но с плохими последствиями. Теперь Engineering Manager-ы, лишенные этих недостатков, могут поступать правильно.
Engineering Manager-ы должны следовать подходу «Go Gemba» Lean Manager-ов и программировать с командами, время от времени присоединяясь к разработке функций. Но никогда не в одиночку! Скорее, с помощью парного программирования или, что еще лучше, с помощью методов (удаленного) группового программирования.
5. Engineering Managers в роли Scrum Masters?
Для кого-то я сейчас могу показаться еретиком... Но если вы будете следовать ходу мыслей в этой статье, то вы увидите, что миссия и объемы работы Engineering Manager-ов будут в некоторой степени пересекаться с задачами Scrum Master-а. Мой опыт показывает, что они пересекаются на 80% и более.
Так нужны ли нам оба? Engineering Manager и Scrum Master для группы команд? Вы можете выбирать. Эти двое могут сформировать мощную руководящую команду для обучения и развития технических процессов в организации.
Летом 2021 года компания Poster POS (украинская SaaS для предприятий общественного питания и розничной торговли) внесла это изменение. Они убрали из команд роль Тим Лида и выбрали несколько самых надежных инженеров, которые также были заинтересованы в улучшении производственной системы путем наставничества других. Тогда я играл роль Large-Scale Scrum Coach и временного Scrum Master в Poster. Вместе с Engineering Manager-ами мы сформировали команду и руководили изменениями.
Когда я ушел из компании, позиция Scrum Master была вакантна. И вскоре на эту позицию вместо Scrum Master-ов взяли Engineering Manager-ов.
Также помогло то, что довольно много членов команды прошли обучение фасилитации. Таким образом, они могли проводить мероприятия, не полагаясь исключительно на Скрам-мастеров. Это немного облегчило работу Engineering Manager-а/Scrum Master-а.
Извлечение Лидов из команд
Так что варианты есть. Вы сами увидите, что именно сработает лучше... Но сначала вам нужно извлечь Лидов из ваших команд!
Comments