Тимлид (team leader)

Содержание:

Настройте основные инструменты
- Визуализируйте цели
- Систематизируйте работу с препятствиями
Подытожим
Когда рекрутер «пинает» тимлида и команду разработки — это нормально
Алгоритм подбора подходящего руководителя
Демократический стиль
Шаг номер 0. Зачем?
Дополнительные материалы
Обязанности
Как им стать
Варианты будущего роста
Кому не подходит должность
Профессиональный рост в IT
Приведите в порядок встречи один на один
Плюсы и минусы профессии
Шаг номер 0. Зачем?
Какая же деятельность для тимлида родная?
- Лидерство
- Компетентность команды

Настройте основные инструменты

Цели — визуализировать. Под визуализацией я подразумеваю не то, что по утрам, лёжа на кровати, нужно воображать, как вы завершаете проект и празднуете. Я имею в виду, что каждая из целей и договорённостей должна быть представлена в наглядном виде: дашборд, график, таблица и т. п.
Работу с препятствиями — систематизировать: собрать все отвлекающие факторы и организовать работу с ними.

Визуализируйте цели

График открытых и закрытых багов, на котором видно соотношение открытых и закрытых багов за последние n дней. Помогает оценить динамику роста/сокращения количества багов.
Круговая диаграмма «Задачи по компонентам». Помогает оценить, сколько у нас проблем в тех или иных компонентах (условных областях бизнеса), и вовремя сменить фокус.

Систематизируйте работу с препятствиями

Управляем централизованно. Я изменил подход к реакции на задачи: создал новый фильтр, куда попадают все новые задачи по тем компонентам, за которые отвечает моя команда.
Подтверждаем необходимость задачи. В новом фильтре мы смотрим, необходимо ли выполнение задачи, или есть причины, по которым её делать не нужно (например, это дубликат). Если выполнение задачи необходимо, то мы её подтверждаем (мы настроили себе специальный флаг «Approved» и соответствующую кнопку) и переходим к следующему пункту.
Калибруем приоритет. Так как команде известно про приоритеты и бэклог, то здесь же мы калибруем приоритет новой задачи относительно бэклога.
Задача улетает в бэклог. Фильтр у нас либо пустой, либо содержит минимальное количество непросмотренных задач. В то же время бэклог отсортирован и содержит только то, что нужно сделать, а наверху находятся те задачи, которыми стоит заняться в первую очередь.

Итого.

Подытожим

Собрать топовую команду — задача непростая, но посильная. Семь советов руководителю:

Будьте командным игроком и принимайте решения вместе с сотрудниками.
Распределите зоны ответственности и сроки выполнения задач.
Нанимайте заинтересованных людей — тех, кто не работает от звонка до звонка, а действительно хочет влиять на компанию. Такие люди с радостью примут участие в собеседовании новичка.
Не завышайте требования в заявке на подбор и тексте вакансии — указывайте только то, что действительно нужно.
Сократите этапы воронки и давайте тестовое только при необходимости — когда для принятия решения по кандидату недостаточно портфолио и личного разговора.
Вопросы-клише на собеседованиях давно устарели: вместо «кем вы себя видите через 10 лет?» лучше спросить «в каком направлении вы хотите развиваться?».
Используйте рекрутинговое ПО — это сэкономит кучу времени и поможет оптимизировать процессы найма.

Источник фото на тизере: Quino Al on Unsplash

Когда рекрутер «пинает» тимлида и команду разработки — это нормально

Воронка подбора — это зеркало найма, то, как он проходит у вас в компании. Поэтому воронка бывает разной: у кого-то шесть-семь этапов, а у кого-то — все двадцать. В разработке hh.ru воронка выглядит так:

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

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

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

В результате сели за круглый стол: я, команда, рекрутер. И нарисовали схему:

Как идет процесс
Кто за что отвечает
Какие максимальные сроки у нас заложены под каждый этап

Решили, что если накапливается определенное количество нерассмотренных кандидатов, то рекрутер пишет в общий чат и не стесняется нас «пинать»

Если кандидат нереально хорош, то эйчар может отправить сразу ссылку на вакансию — «кандидат горящий, важно не потерять!»

Когда мы это сделали — все зависания исчезли. Главное принять, что рекрутер тут — «пинатель», это его работа и не стоит на него за это злиться.

А еще от зависаний нас спасает сервис из экосистемы hh.ru —

Кандидаты у нас долго не залеживаются, поэтому приложил скриншот из соседнего отдела:

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

Алгоритм подбора подходящего руководителя

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

Какие из стилей предпочитаете лично вы, как сотрудник?
Какой стиль подходит команде, которую вы рассматриваете в данный момент?
Какой стиль будет подходить команде через год, два, пять (зависит от того как на долго вы собираетесь с ней остаться)?
Какой стиль использует руководитель?
Способен ли он менять свой стиль?

О том, как ответить на эти вопросы мы поговорим ниже, а пока разберемся, как интерпретировать ответы:

Запишите ответ на первый вопрос, скорее всего у вас выйдет несколько предпочтительных стилей.
Стили из вопросов 2-4 должны быть из списка ваших предпочтительных.
Ответы на вопросы 2 и 4 должны совпадать.
Единственная ситуация, когда на этот вопрос можно ответить отрицательно — если все предыдущие ответы совпали и руководитель должен использовать, использует и будет использовать подходящий для вас стиль руководства.

Демократический стиль

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

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

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

Это займет время, но в конце концов команда сама придёт к решению, что списывать время — единственный рабочий вариант и примет его (если это действительно так). Таким образом, руководитель добивается полной осознанности и понимания этого процесса со стороны команды, снимает стресс, ведь все будут понимать, что трекинг времени нужен не для того, чтобы наказать кого-то за уход с работы на 20 минут раньше, а для того, чтобы лучше планировать, попадать в оценки и не перерабатывать.

Частый ответ на вопрос о странном legacy решении в проекте

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

Шаг номер 0. Зачем?

Итак, вам предложили стать тимлидом или вы сами захотели им стать. Что надо сделать в первую очередь? Хорошенько подумать, а надо ли оно вам.

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

Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же:

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

Ложные цели, на которые не надо вестись:

Больше денег. В большинстве тимлидских вакансий зарплата выше сениорской не намного, а порой может быть даже и ниже. При этом всём тимлид разрывается между командой, сроками, заказчиками, кодом, процессами, бизнесом и так далее. В то время, как сениоры спокойно пилят код и иногда ревьювят код коллег.
Больше власти. Да, повлиять вы можете на что-то больше, чем рядовой разработчик, но спрос с вас будет тоже ощутимо выше. При этом зачастую реальной власти у тимлидов особо и нет. Очень часто бюджеты, найм, увольнения и прочие реальные административные рычаги в других руках. В итоге какую команду вам дали, такую и тащите, да при этом чтобы результаты были феерические.
Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.

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

Где-то нужен полуменеджер-полуразработчик, где-то техлид/архитектор, где-то пипл менеджер и т.д

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

Советую заранее узнать, что же именно от вас требуется.

Спойлер: 80-90% вакансий на российском рынке — полуменеджер-полуразработчик. Формально говорится, что 60-70% времени надо писать код, а 30-40% менеджерить. При небольших размерах команды и порядочном работодателе это может неплохо работать. Лично у меня где-то сейчас 40 на 60 получается делить код с менеджементом. Хотя я чувствую, как при разрастании команды код отодвигается от меня всё дальше и дальше.

Однако при недобросовестном или просто непонимающем работодателе, от вас будут ожидать примерно 100% менеджмента и 100% написания кода. Постарайтесь узнать об этом как можно раньше, чтобы СБЕЖАТЬ.

Дополнительные материалы

Какие-то темы я не стал подробно раскрывать, потому что и текст получился бы слишком длинным, да и я уже писал об этом ранее в своем телеграм-канале. А копипастить, или повторяться не хочется.

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

Матрица доверие-прозрачность https://t.me/general_it_talks/78
Ситуационное лидерство https://t.me/general_it_talks/59
Чайка-менеджмент, микроменеджмент https://t.me/general_it_talks/28
Обучение, приоритеты и иллюзию компетентности в этом деле https://t.me/general_it_talks/60 https://t.me/general_it_talks/41 https://t.me/general_it_talks/116
Овертаймы и подбор темпа работы https://t.me/general_it_talks/42 https://t.me/general_it_talks/61
Теория разбитых окон https://t.me/general_it_talks/48

Обязанности

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

Заключение договора с клиентом, обсуждение всех деталей, поиск компромисса.
Работа с договорами, различной документацией.
Производить оценку обьемов и масштаба работ, бюджета, сроков выполнения работ.
Расставление приоритетов, планирование больших и маленьких задач.
Делегирование полномочий внутри коллектива таким образом, чтобы получить максимальную эффективность.
Планирование релизов и своевременный их выпуск.
Функции продюсера в управлении проектом, дизайнерские работы, грамотный маркетинг, разработка.
Общительность, и налаживание контактов с каждым сотрудником, мотивирование персонала, обеспечение профессионального роста каждого.
Мотивация, нужно показывать все на своем примере, быть образцом для своих сотрудников.
Умение переделать бизнес-идею руководства в техническое задание для разработчиков.
Ответственность за качество проекта, технологию его реализации.
Написание ревью кода.
Тестирование, проверка проекта, разработка его дизайна.
Уметь понять и разобраться в поломке, при надобности – усовершенствовать проект.
Написание технической документации.
Участие в процессе формирования команды.
Программирование архитектуры.
Выбор наиболее подходящей и эффективной технологии для рабочего задания.
Обьяснение общих идей каждому сотруднику команды.
Выбор исполнителя из команды, подходящего для определенной задачи.
Выгружать изменения на сервер.
Обмен опытом между членами команды, с целью повышения эффективности, понимания и навыков.
Оптимизация работы, проведение внутрикомандных совещаний.
Ведение отчетов перед заказчиками в течении всего этапа проведения работа.
Контролировать проект на предмет его соответствия заданным техническим параметрам.
Оценка и поддержка предложений от других участников проекта.

Личностные качества:

Аналитический состав ума
Ответственность
Пунктуальность
Трудолюбие
Дипломатичность
Инициативность
Нахождение простых способов решения сложных заданий
Техническая грамотность (владение серверными технологиями и дистрибутивами)
Нацеленность на результат
Быстрое принятие решений в сложных ситуациях.

Как им стать

Как правило, тимлиды — это бывшие сеньоры.

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

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

Кроме своей области программирования тимлид должен знать и уметь:

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

Короче, тимлид — это менеджер, который в совершенстве знает стек программирования своей команды.

Варианты будущего роста

Раз у вас уже возник вопрос «а что дальше?» в бытность разработчиком, то он у вас возникнет и на этапе team lead. А здесь всё также можно следовать разобранной ранее схеме. Вопрос лишь в том, стоит ли развиваться как менеджер или всё-таки уйти еще глубже в сторону разработки в
роли архитектора. Попробуйте, и вы сможете четко ответить на этот вопрос. Но как я говорил ранее, не задавайте его себе в первые несколько месяцев. Потому что находясь вне привычной зоны комфорта человек по умолчанию склонен негативно реагировать на любые стимулы. Разберитесь хотя бы в базовых вещах, потом принимайте решение.

Кому не подходит должность

Считаете, что вы способны возглавить команду? Будьте осторожны со своими амбициями, так как не каждый разработчик с организаторскими способностями может стать успешным тимлидом. Тщательно взвесьте свои возможности, чтобы не навредить проекту и не испортить отношения с сотрудниками.

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

Крайне сложно быть тимлидом, если вам трудно налаживать коммуникативный контакт с коллегами и вы не можете конструктивно давать обратную связь

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

Профессиональный рост в IT

Рассмотрим типичную IT-компанию. Как и в других отраслях, здесь возможен рост «по горизонтали» и «по вертикали».

Горизонтальный рост — это освоение более широкого стека, близких направлений (например, мобильной разработки) или уход в смежную профессию (в управление проектами, продажи, аналитику).

Вертикальный — это переход на лидерские позиции (техлида, тимлида) или руководящие должности. О нём мы сегодня и поговорим.

Это — обычная схема профессионального роста:

junior developer (специалист начального уровня);
middle developer (специалист среднего уровня);
senior developer (специалист высокого уровня);
technical leader (технический лидер);
team leader (лидер команды).

Иногда выделяют дополнительные промежуточные ступени, например junior+ (это джун, который совсем чуть-чуть не дотягивает до миддла).

Стать тимлидом можно и раньше — со ступени middle-разработчика.

Senior developer может выбирать направление на свой вкус: стать техлидом, который управляет ходом работ, но больше погружён в архитектуру и качество кода, или же тимлидом, который тоже управляет командой, но более ориентирован на коммуникации. Эти роли одинаково авторитетны. В редких компаниях тимлид может руководить техлидом, но обычно они работают параллельно и на равных.

Если техлид достиг «потолка» в своей должности, но не хочет расти «параллельно» и идти в тимлидерство, он может углубиться в техническую часть, например в экстремальное программирование.

Приведите в порядок встречи один на один

Пример формата записи результатов и договорённостей по итогам встречи

записывайте фидбэк, который хотите дать сотруднику, если это терпит до встречи;
освежайте в памяти информацию перед встречей (я не раз вспоминал про какую-то часть фидбэка только потому, что делал записи);
предоставляйте первое слово сотруднику (в этом диалоге вы находитесь в сильной позиции — вам понятно, что вы хотите сказать, как его вести и т

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

Плюсы и минусы профессии

Теперь немного о достоинствах и недостатках профессии:

Возможность реализовать свои лидерские качества

Высокий доход

Востребованность на рынке труда

Общение с разными заказчиками и расширение круга общения

Хорошая площадка для развития карьеры

Отсутствие большой конкуренции,так как хороших тимлидов на рынке недостаточно

Ненормированный рабочий день

Ответственность за команду, а не только за себя

Необходимость постоянно совершенствовать свои профессиональные знания

Нужно постоянно быть в курсе всех вопросов, касающихся проекта

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

Шаг номер 0. Зачем?

Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же:

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

Ложные цели, на которые не надо вестись:

Больше денег. В большинстве тимлидских вакансий зарплата выше сениорской не намного, а порой может быть даже и ниже. При этом всём тимлид разрывается между командой, сроками, заказчиками, кодом, процессами, бизнесом и так далее. В то время, как сениоры спокойно пилят код и иногда ревьювят код коллег.
Больше власти. Да, повлиять вы можете на что-то больше, чем рядовой разработчик, но спрос с вас будет тоже ощутимо выше. При этом зачастую реальной власти у тимлидов особо и нет. Очень часто бюджеты, найм, увольнения и прочие реальные административные рычаги в других руках. В итоге какую команду вам дали, такую и тащите, да при этом чтобы результаты были феерические.
Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.

Где-то нужен полуменеджер-полуразработчик, где-то техлид/архитектор, где-то пипл менеджер и т.д

Советую заранее узнать, что же именно от вас требуется.

Какая же деятельность для тимлида родная?

члены команды были согласны выполнять поручения,
достаточно компетентны для этого,
обладали достаточными ресурсами (в первую очередь — временем),
могли ужиться вместе.

Лидерство

с намерением

Проявлять искреннюю личную заинтересованность в успехе проекта. В современной команде разработчиков все видят все, что делают остальные, как делают, насколько стараются. Разработчики с большей охотой пойдут за тем, кто сам вовсю старается ради успеха проекта, даже если этот кто-то и формальной власти то не имеет, из желания помочь. Такой лидер легко удерживает инициативу, пока не выдохнется или не потеряет интерес к проекту.
За счет знания технологий и устройства проекта лучше всех в команде. К таким лидерам тянутся заинтересованные в профессиональном росте разработчики, они часто именно за этим и приходят в проект. Логично, что при достижении разработчиками уровня лидера, если других факторов нет, лидер теряет инициативу, что на практике выражается постоянной критикой решений, порой приводит к игнорированию распоряжений или скрытым саботажам.
Способен добиться уважения окружающих за счет личных качеств. Когда человек объективен, справедлив, последователен, сотрудники могут полагаться на такого человека и его решения. Однако для того, чтобы команда разглядела эти качества в потенциальном лидере требуется время, за которое лидерство захватит кто-нибудь другой. Этот фактор наиболее устойчив к различного рода переменам в команде.
Умение эксплуатировать настроения отдельных членов команды, заставляя действовать по своему плану (кино Filth сразу вспомнилось www.imdb.com/title/tt1450321). Видел таких лидеров, даже немного поработал в профессиональной юности сдуру, но вовремя сбежал. Очевидно, что опытными специалистами, знающими себе цену, долго не поманипулируешь.
Применение административных мер, предоставляемых формальной властью, для того, чтобы заставить сотрудников выполнить обязательства. Если этот фактор лидерства единственный, то это явный пример системы отношений «я — начальник, ты — дурак». Работает также на довольно ограниченном множестве сотрудников.

Компетентность команды

Типовая ошибка — найм недостаточно компетентных сотрудников в силу неумения выявить профессиональные качества кандидата. Простые примеры — это неумение или боязнь задать правильные вопросы на собеседовании, смещение акцента на эзотерические особенности технологий, а не на их практическую сторону. Последствия ожидаемы — кандидат не справляется со взятыми командой обязательствами, следовательно и тимлид тоже.
Другая крайность — найм только экспертов. Чтобы не ошибиться в найме после набития шишек, или из желания собрать команду мечты, тимлид тщательно отбирает только не уступающих в знаниях ему самому кандидатов. Так как такая манера больше свойственна лидерам-экспертам, то ценз получается довольно высоким. Кандидаты ищутся долго, затраты на подбор растут, задачи проекта не решаются, а у тимлида есть отличная отговорка — нет специалистов. Но даже когда команда собрана оказывается, что звезды с рутинными задачами готовы мириться, но хотелось бы задач с вызовом (challenge) и каждому, а вот пойти мусор подмести в проекте никому не хочется. Да и обстановка какая-то напряженная становится, как известно у 4-х архитекторов 8 мнений, большинство из них правильные, хоть и противоречат друг-другу.
Еще типичный пример — игнорирование потребности в привлечении в команду сотрудников других специальностей, например фронтендщика, эксперта в определенной БД, проектировщика интерфейса и т.д. Часто такое происходит просто из-за непонимания того, что такой специалист в команде нужен. В итоге команда суровых бэкендщиков разрабатывает кое как работающий фронтенд в своем проекте, команда разработчиков месяцами бьется с оптимизацией PostgreSQL, ну и мой любимый случай — психбольница в руках пациентов.
Пример сложнее — неравномерность найма, взял пачку джуниоров, чтобы два раза не вставать, а они как начали код писать так, что ревьювить команда не успевает, да еще подходят вопросы всякие задают непрерывно, ломают что-то постоянно.
Или наоборот, работаем, концентрируемся на задачах, найм на потом откладываем, как внезапно уходит кто-то из ключевых сотрудников, другой в отпуске/болеет/забрали в другой проект, а на смену никого из подрастающего поколения нет. Скажете, что мол, ситуация неожиданная? Так вот к такой ситуации тимлид всегда должен быть готов, заранее продумывая как он поступит в случае потери того или иного члена команды. А еще лучше если он отношения построит так, чтобы заранее узнать о таком исходе.