В чём проблема?
В ответ на вопрос «В чём функции роли [Team]Lead?» раз за разом получаю «Распределять задачи в команде и определять приоритеты». Даже в статьях пишут, вот тут, например:
— распределяет нагрузку среди программистов;
— смотрит за тем, как продвигается задача;
— …
Фантастически вдохновляюще
Когда-то я тоже так думал и даже делал, но хей, народ, это же невыносимо унылая функция, которая может отнимать до половины рабочего времени. Неужели её должен делать человек, переросший уровень Senior? Не удивительно, что новоиспечённые лиды фрустрируются и задаются вопросом «есть ли жизнь после Senior?». Но самое страшное, что более высокоуровневому менеджменту и HR начинают приходить в голову идеи оформлять лидами персонажей, у которых с основной деятельностью просто «чёт не задалось». Так как функция же простая.

Следующая проблема, определяемая причиной невнятности функций лида — куда расти Senior’ам в команде, в которой уже есть тимлид? Особенно таким, которые и не хотят руководить, а хотят дальше по технической ветке развиваться. Вроде как возникшее направление техлидов решает проблему. Но если нет менеджерско-лидерских функций (распределения задач и присмотра за продвижением задачи, хе-хе), где грань, определяющее переход из Senior в Lead?
Подходы гибкой разработки внесли свою долю хаоса в эту тему. Если команда обсуждает план итерации с Владельцем продукта, задачи выбирают сами, а прогресс отслеживается на стендапе, то что делают лиды? Становятся скрам-мастерами? Руководителями проектов? Не всем это интересно.
Отдельно теперь доставляют споры в комментах на тему наличия или отсутствия тимлидов в скраме. Одни говорят, что раз в гайде их нет, то их не должно быть. Другие утверждают, что отсутствие упоминания не предполагает запрет. Как и прочие догматические споры всё определяется ментальными моделями и толкованием терминов.
Почему вообще есть такая установка: тимлиды планируют, декомпозируют, распределяют задачи, другими словами принимают решения за всю команду — что делать, как делать, кому делать? Во времена, когда дискеты были большими, а технологии не менялись десятилетиями, концепция «главный инженер + группа миньонов» была актуальна. Сейчас — нет. Технологий много, меняются они быстро, изменения планов постоянны. Может ли один человек поддерживать высокое качество решений и одновременно уровень технической экспертизы, тратя до половины времени на «распределение задач и определение приоритетов»? Сомнительно.
Пройдя путь от системного администратора до «руководителя лидов», выработал свою лидерскую модель, на которую теперь и опираюсь, как в оценке, так и в обсуждении планов по развитию. Достоинством этой модели является простота и универсальность (применима не только к разработке, и даже не только к ИТ). Она предаполагает, что роль лида основывается на трёх компетенциях.
Лидерство
Ну логично, Lead — от слова Leader, ведущий. Вести людей — это не про назначение задач. Это про умение определить цель и сподвигнуть к её достижению какую-то группу людей. Движение предполагает изменение от текущего состояния в сторону желаемого, «более лучшего» состояния. То есть лидерство — это постоянный драйвинг изменений, которым, как правило, сопротивляются. Сопротивляются, потому что менять привычные устои некомфортно. А драйвить надо, потому что движение — жизнь, мир постоянно меняется и надо адаптироваться.
Чтобы сформулировать цель, надо её представить. То есть сформировать видение. Как должно выглядеть желаемое состояние.
Влиять на других трудно, если цель не несёт выгоды никому, кроме вас. До принятия пути обретения блага через повышение блага окружающих надо дозреть. Лидерство — это уровень зрелости.
Скилы и характеристики: целеполагание, ясность изложения мыслей, стремление к саморазвитию.
Мониторинг: количество внедрённых изменений на уровне команды; позитивный эффект этих изменений; наличие видения, к которому в данный момент движемся.
Профильный менеджмент
Чтобы вести к цели, надо быть уверенным в необходимости её достижения. Это трудно, если имеющийся кругозор не выходит далеко за границы текущего status quo. Значит надо а) хорошо разбираться и продолжать непрерывно познавать предметную область; б) уметь анализировать недостатки и причины проблем текущего состояния.
Возможно и не надо нарабатывать себе по 10 000 часов практики с каждым новым фреймворком и инструментом (да и едва ли получится), но надо отслеживать, какие новые инструменты, подходы и практики появляются, чем их появление обусловлено, какие проблемы они решают. Есть ли эти проблемы у вас, не внедряете ли вы технологию ради технологии. Ну и просто — пробелы в знании предметной области не улучшают взаимопонимание с командой.
Отдельно о проблемах — если вы не видите проблем, это проблема. Потому что нет оснований для изменений, а значит мир меняется, а вы нет. Если вы стремительно решаете возникающие проблемы, но эффективность команды не повышается, скорее всего вы решаете не проблемы, а их симптомы. Умение докапываться до корневых причин — одно из ключевых для менеджера любого уровня.
Скилы и характеристики: представления о предметной области, понимание актуальных подходов, практик и инструментов; системное мышление (понимание влияния изменений на систему в целом, выделение систем разного уровня, изъянов систем); root-cause анализ и problem solving.
Мониторинг: отличный инструмент мониторинга — командные ретроспективы. Насколько на них докапываются до корневых причин, насколько результаты предыдущих ретроспектив выполняются и воплощаются. Насколько в целом в команде адекватные и актуальные инструменты, практики, регламенты и договорённости. Насколько регулярно случаются одни и те же сбои, факапы и проблемы человеческого фактора.
Управление людьми (people-management)
Организовать работу над достижением цели и донести необходимость изменений это одно. Достичь конечной точки — другое. Люди могут уставать, конфликтовать друг с другом, у них может не хватать нужных навыков, зато в избытке может быть других точек зрения на происходящее. У них падает мотивация и растёт фрустрация. Они хотят расти (как минимум, в доходах), но не всегда знают как.
А ещё люди могут быть неэффективны, непродуктивны и склонны к ошибкам по разным причинам: недостаток хардскилов и умений, ошибочные ментальные модели и несоответствующие личностные установки и убеждения или временные факторы разного рода аффектных состояний. И в каждом случае требуются свои подходы.
А ведь рост и развитие людей в команде — одна из непрерывных целей настоящего лида. Даже если сами люди, кажется, не хотят.
Скилы и характеристики: влияние на людей без формальных полномочий, умение формировать ожидания от людей (здесь снова требуется навык формирования видения — идеального разработчика или, скажем, ожиданий от уровня Senior); умение слушать и слышать; умение формулировать и доносить обратную связь; менторские навыки и владение коучинговыми инструментами (GROW, CTFAR etc.); умение выявлять и разрешать конфликты.
Мониторинг: атмосфера в команде, коммуникации (знают ли люди к кому и по какому вопросу можно обращаться, или все идут к кому-то одному, или все идут к лиду), насколько быстро адаптируются новички в команде, регулярность 1-to-1 встреч, эффективность групповых совещаний и обсуждений (фасилитация командных встреч). Ещё много информации даёт то, как проходят собеседования кандидатов, на какие характеристики обращается внимание, как выявляются знания, умения и черты характера.
Резюме
Итого, три основных столпа, на которых стоит лид — уровень зрелости лидера, уверенная ориентация в предметной области и пипл-менеджмент. Все известные мне лидерские роли укладываются в эту концепцию.
Разного рода тимлиды, деливери лиды и скрам-мастера — больше упора на пипл-менеджмент и коучинговые практики, в том числе командные. При этом знание предметной области на уровне понимания современных практик, подходов и инструментов должно быть, возможно, не таким глубоким и доскональным, но на уровне, позволяющем донести необходимость соответствующих изменений.
Техлиды, девлиды чаще больше погружены в технические аспекты, чем и заслуживают авторитет и влияние на людей без всякого коучинга. Навыки работы с людьми, хоть и не такие масштабные, тем не менее нужны. Надо ведь проводить собеседования, выращивать джунов, да и людей убеждать. Хорошие советники и адвокаты изменений для тимлидов. Если договорятся, конечно :)
Может ли быть в команде больше одного лида в такой концепции? Легко. Хоть вся команда. У каждого свои акценты просто вырабатываются.
«В чём функции роли [Team]Lead»
А как же наставничество/менторство? Эта функция развивает технические навыки неплохо.
«куда расти Senior’ам»
В архитекторы или в CTO.
Наставничество и менторство действительно неплохо развивают. Но эта функция проявляется на middle+ и является одной из основных у Senior’ов. Кажется естественным, что прежде чем лидить команду надо научиться наставничать хотя бы над одним человеком.
>«куда расти Senior’ам»
>В архитекторы или в CTO.
Прям сразу в СТО? Минуя уровень управления командой? :)
Конечно надо выбирать кратчайший путь к своей цели, а какой девелопер не мечтает стать СТО или фаундером? Опыта можно набраться и потом уже. Все равно всех ошибок не переделать и всему-всему не научиться, и не получится быть на 100% готовым к «большим» ролям, так зачем откладывать?
Хорошо, что врачи не руководствуются таким подходом.В основном политики и менеджеры :)
Если врач стремится стать CTO то это интересный сценарий, ничего плохого не вижу в этом)))
А почему бы просто не посмотреть на примеры больших компаний, вроде Гугла, чтобы понять все возможные роли.
Там нет роли тимлид, как таковой. Есть в команде Senior Engineer, который по сути и есть тимлид. Может быть еще Product Manager и Program Manager в идеале. Если кого-то из них нет, то эту роль на себя берут другие члены команды.
А после Senior Engineer уже идет Principle Engineer. Либо подаваться в менеджеры.
Можно и посмотреть. Но для чего? Интересуют не формальные названия должностей, а требования и ожидания к уровням профессиональной зрелости технических специалистов, где на определённом этапе начинается много противоречивых толкований и ожиданий.
Опять же, надо ли всем компаниям перенимать оргструктуру гугла? Охватывает ли она «все возможные роли» или это просто один из вариантов структуры?