Тимлид кто это: что это за профессия, обязанности специалиста, зарплата

Кто такой тимлид и как вырасти до этой должности

О собеседнике: Прокурат Виталий, team Lead в Минском центре разработки компании Wargaming. Больше 10 лет опыта в веб-разработке.

Дмитрий Дементий: Какую роль в профессиональной жизни начинающего разработчика играет тимлид? Или перефразирую: почему стажёру или джуниору надо плотно общаться и дружить в профессиональном плане с тимлидом?

Виталий Прокурат: Тимлид в жизни начинающего разработчика играет роль ментора. Следит за уровнем сложности задач с которыми работает джун. Даёт своевременную обратную связь об успехах или неудачах. Помогает джуну разобраться с рабочими вопросами. Советует, какую литературу почитать: книги или ссылки на статьи по профильной теме.

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

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

На самом деле, взаимодействие с тимлидом полезно не только начинающим разработчикам, но и разработчикам уровня middle и senior.

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

В. П.: Для того, чтобы стать тимлидом, разработчику нужно развить в себе менеджерскую оставляющую. Научиться часто переключаться с одной задачи на другую. Научиться распределять и планировать свое время. Уметь просто «на пальцах» объяснить, как работает та или иная функциональность.

Сейчас существует большое количество тренингов. По people-менеджменту, тайм-менеджменту, стресс-менеджменту, конфликт-менеджменту и прочие. Разработчику нужно прикинуть свои сильные и слабые стороны и посетить какой-либо тренинг. Как правило, это занимает не так много времени: в среднем от одного до нескольких дней. В некоторых компаниях, особенно в крупных, есть обучение и развитие сотрудников. Рекомендую им воспользоваться.

Могут помочь не только тренинги, но и профильные конференции. Нужно посмотреть несколько топовых докладов с конференции TeamLeadConf, чтобы иметь представление, с чем придётся столкнуться на позиции тимлида.

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

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

Вопросы которые могут в этом помочь:

1. Всем ли было понятно, что и в какой последовательности нужно делать?
2. Был ли прозрачен процесс разработки?
3. Были ли какие-то подводные камни, которые не запланировали заранее?
4. Как участники оценивают результат?
5. Как участники/руководитель/менеджер оценивают работу разработчика в роли лида по этой задаче?

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

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

Д. Д.: Тимлид нужен в любой команде, или где-то можно обойтись без этого специалиста? Возможно, роль тимлида может сыграть какой-то другой сотрудник?

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

В команде, где три и более разработчиков, я считаю, нужен тимлид.

Д. Д.: Тимлид — больше менеджер-организатор или разработчик с глубокой экспертизой? На что больше тратит времени тимлид: на работу с кодом или общение с другими программистами?

В. П.: Большая часть времени уходит на общение с другими разработчиками:

1. обсуждение рабочих вопросов по текущим задачам и code review внутри команды;
2. митинги с разработчиками из других команд по обсуждению совместных задач;
3. работа с бэклогом и приоритизация задач.

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

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

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

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

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

Заключение: вырасти можно, но джуниорам придётся запастись терпением

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

Оригинал статьи опубликован в блоге Хекслета. Code Basics — сайд-проект Хекслета.

Тимлидство — роль, которая может стать ловушкой для разработчика, а может дать огромные возможности для создания ПО

Вернёмся года на два назад, когда я был разработчиком. Что я думал? «Хочу стать тимлидом. Это круто, он решает все вопросы, получает больше денег, им становятся после сеньора». Тогда не было никого, кто сказал бы мне: это вообще про другое. Пришлось учиться на своих ошибках.

Я дважды становился тимлидом

У меня есть такая черта: стараться во всем наводить идеальный порядок, систематизировать, выстраивать процессы. Поэтому меня всегда тянуло брать на себя больше, чем просто написание кода. В моём первом стартапе, назовем его «T», был полный хаос в процессах разработки.

Сейчас бы я вряд ли стал там работать, но тогда это было очень атмосферно. Только представьте. Много параллельных заказчиков. Руководитель ходил напрямую (и точечно) к разработчикам. Мы часто не укладывались в озвученные сроки и сидели допоздна. Помню, как однажды шеф позвонил в 20 часов и попросил приехать на работу, чтобы докрутить фичу для заказчика, — потому что «озвучил срок завтрашним утром». Но в «Т» мы были «семьей».

А еще делали все сами — как умели. Помню, как ставил Ubuntu на рэковый сервер, который отдал нам один из инвесторов. Когда я включал его, он издавал звук взлетающего вертолета!

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

В «D», куда я пришел разработчиком, все было иначе — особенно в том, что касалось процессов.

В компании был реализован классический Scrum: четкие спринты, burndown chart’ы, демо, планирование, стори поинты, груминги для подготовки будущего спринта. Я был поражен качеством процесса, тихонечко писал код и наблюдал, как все работало. Затем подружился со скрам-мастером и стал закидывать его вопросами. Он охотно отвечал и делился крутыми книгами.

Особенно запомнилась «Scrum и XP: заметки с передовой» от Хенрика Книберга. Процесс в «D» был выстроен близко к этой методологии: в результате весь менеджмент и продавцы отлично понимали, когда будет результат.

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

У нас был отличный тимлид Петя. На созвонах один на один мы могли обсуждать все: от проблем с не попаданием в сроки до настроек таск-трекера. Иногда я просто давал фидбек, иногда что-то советовал.

Так Петя меня раскусил и узнал про опыт руководства командой в «T» и заочном обучении скраму в «D».

В какой-то момент он предложил мне провести стендап.

Операция «преемник» в моем случае выглядела вот так и заняла 6 минут)


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

Все происходит само собой, будто в сторону тимлидства тебя толкает невидимый Закон Притяжения.

Когда у компании появляется нужда в тимлиде и все думают «Где его взять?», то часто берут из ребят, которые:

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

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

Вот как выглядел примерный круг обязанностей тимлида в Skyeng на момент начала истории:

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

Что поменялось и как я с этим боролся

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

Однако со временем чувство эйфории прошло, наступили будни. Вот что я заметил за собой.

Нужно быть морально готовым расстаться с «ежевечерним дзеном»… и подружиться с «ежеквартальным». Результат работы тимлида обычно не увидеть за один день или даже неделю. Это одновременно и плюс, и минус.

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

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

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

Например, моя команда сделала раздел «Изучать темы» для приложения Skyeng на iOS и Android: мы реализовали карту уровней упражнений, шкалу энергии для разных категорий учеников, дневные цели, трекеры прогресса в заданиях, разные механики для карточек заданий, озвучки и не только.

Тот самый раздел в приложении.

Можно оценить количество экранов и механик одного занятия на гифке: ход ускорен

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

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

Ты рискуешь превратится в «оператора колл-центра» — и если не остановить это, выгорание гарантированно в течении одного-двух месяцев.

Тут я хочу передать привет сказать искреннее спасибо своему продакту. Увидев эту проблему, он отправил меня читать «Джедайские техники» Дорофеева, «Тайм-менеджмент» Архангельского, а также изучать каналы и чаты для тимлидов, записи с конференций и так далее.

Практики, которые я почерпнул, помогли устранить расфокусировку. Я предупредил всех, что буду проверять входящие 1-2 раза в день, стал устраивать дни без встреч и созвонов, планировал свой рабочий день в письменной форме (даже пытался ввести эту практику в команде, но разработчики такое не любят). Приоритеты менял, только если случилось что-то реально критичное. В результате те дела, которые я запланировал, перестали откладываться.

В общем, пришлось ломать свои привычки и экстренно осваивать кучу полезных техник.

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

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

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

Больше не тимлид: как не потерять себя и найти снова

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

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

Проработав на позиции лида полтора года (с сентября 2018 по февраль 2020), я осознанно решил оставить эту роль и вернулся в разработку. За это же время тимлид, канал которого я читал, дорос CTO в моей компании.

Мы всегда на удаленке, основная коммуникация в Slack: так что «все ходы записаны». Всё сложилось так, как на картинке: коллега, которого я предложил, пробует себя в роли тимлида, а я радуюсь «вечернему дзену» в рамках другой команды.

А этим летом мы с еще парой ребят, прошедших подобный путь, сделали внутренний митап о своем опыте. И самый главный вопрос, который возник у слушателей: ок, а как понять, когда думаешь, куда развиваться дальше, роль тимлида — это твоё или нет?

Так пришла идея обсудить его в публичном формате с:

• Егором Толстым (подкаст и курсы Podlodka) — он сделал выбор в пользу управления продуктом и расскажет о моменте, когда понял, что устал от руководства разработкой,
• Вадимом Мартыновым (Контур и сообщество RndTech) — он вернулся в разработчики и расскажет, как переучивался писать код и как все это сказалось на финансах,
• и Евгением Котом (Wrike и тот самый доклад о болях тимлида) — в качестве ведущего.

Все пройдет онлайн в ближайшую среду (2 сентября) в 19 часов по Москве/Киеву/Минску на ютубе: для зрителей будет чат и простая возможность включиться голосом. А если у вас останутся силы — пообщаемся в зуме.

Здесь можно поставить напоминалку в календарь.

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

что остается менеджерам? / Блог компании Бизнес-школа РИК / Хабр

Привет, Хабр!

В последнее время в области IT и digital все чаще слышится слово «тимлид». Но при детальном рассмотрении видно, что все по-своему понимают эту профессию.

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

В этой статье мы попробуем разобраться, кто же такой этот загадочный «тимлид» и так ли нужны менеджеры?

Кто такой тимлид?

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

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

Пишет ли тимлид код? Безусловно, ведь он вдохновляет свою команду в том числе и личным примером. Но на написание кода он тратит не более 20-30% рабочего времени, так как в приоритете у него управление командой.

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

Компетенции, необходимые человеку, претендующему на такую позицию в проекте, можно разделить на две группы: технические и менеджерские. Рассмотрим их по отдельности.

Технические компетенции

Тимлид должен, в первую очередь, уметь преобразовать бизнес-задачу в задачу техническую, понятную для разработчиков. Это не так просто, как кажется, ведь бизнес-задачи порой формулируются очень и очень пространно. Более того, ему необходимо уметь объяснить разработчикам не только то, что нужно сделать, но и зачем это нужно.

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

Как уже было сказано выше, тимлид сам пишет код, поэтому, вне всяких сомнений, он должен обладать солидным опытом разработки – от 5 лет и более.

Менеджерские компетенции

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

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

Наконец, тимлид – это наставник для членов своей команды. Поэтому ему нужно уметь правильно развивать людей — распределять интересные и сложные задачи, правильно

давать развивающую обратную связь, составлять планы развития.

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

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

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

И, наконец, самое главное качество для любой профессии – честность. Умение быть честным в первую очередь перед самим собой, способность не закрывать глаза на моменты, когда что-то идет не так. Честность перед членами команды, менеджерами проекта и заказчиком. Только подумайте, сколько неудачных проектов было бы спасено, если бы кто-нибудь вовремя встал и сказал: «У нас проблема».

Роль менеджера

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

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

Резюме

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

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

Что такое быть тимлидом / Хабр

Интро

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

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

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

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

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

На самом деле лиды не должны уметь фейлить, они должны уметь делегировать свои фейлы, как и все остальное (сарказм).

Что изменится

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

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

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

Ты должен стать тем самым интерфейсом, через который бизнес общается с командой разработки. Бизнесу плевать кто у тебя в команде какой задачей занимается, спрашивать будут с тебя. Общаться будут с тобой. И винить во всех косяках будут именно тебя.

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

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

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

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

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

Потому что в конечном итоге ты станешь единой точки ответственности и компетенции команды.

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

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

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

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

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

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

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

Два небольших примера из моей практики

В компании, где я работал, был фиксированный график, разработчики должны были приходить в 11 и уходить не раньше 8, но был один программист, который постоянно выхватывал от меня за то, что приходил на 10-20 минут позже (кстати, это тоже работа тимлида, дрочить людей за такие вещи) и всегда ныл на тему того, что далеко живет и не всегда может оценивать время потраченное на дорогу. На одном из таких общений, я понял, что это один из демотивирующих факторов для него и его это бесило — он хорошо работал, но опаздывал. Он даже думал искать работу, где был бы свободный график. Поэтому я потратил кучу своего времени и добился чтобы официально рабочий день для него начинался на полчаса позже, после этого, естественно все эти изменения были внесены с СКД и для этой системы он приходит раньше начала своего рабочего дня. Меня за него больше еженедельно не дрочила система, а я не дрочил его. Кстати, я не сообщил ему о том, что мы решили его проблему именно так. Я просто разрешил ему опаздывать не больше чем на полчаса. Он был счастлив.

Второй пример, в один момент я не уследил за другим своим подчиненным, у него всегда все было хорошо, ничего не напрягало, но в один момент он пришел ко мне с заявлением по собственному. Я был в шоке. Мы говорили с ним часа полтора. Оказалось, что все это время у него была куча вещей, которая демотивировала и поэтому он решил уволиться. Если бы он обозначал свои проблемы, то большую часть мы бы смогли решить без его увольнения, но увы, момент был упущен, парень был дичайше расстроен. После этого я изменил подход в общению с людьми у которых все хорошо, благо наш отдел HR очень неплохо умел общаться с ребятами, я частенько просил их узнать что и как происходит в жизни моего отдела. И, внезапно, люди открывались. Они не знали, будет ли эта информация донесена до меня. Они открывались совершенно другим людям и рассказывали про свои проблемы. Скажу так, это было одно из самых полезных изменений, которое дало мне огромный фидбек и понимание как работают люди.

В какой-то момент ты осознаешь, что общая ответственность не работает, это миф. Если все ответственны за все — никто ни за что не отвечает. Найдется сотня причин, почему никто в критической ситуации не вмешается и не исправит ее. Тебе придется научиться эту ответственность правильно делегировать.

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

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

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

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

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

А нужно ли это нам именно сейчас, когда все бегают с горящими жопами.

Поэтому тебе придется научиться говорить “нет” и объяснять почему нет. Иногда ты должен будешь зарубить инициативу на корню. Любая инициатива должна поддерживаться сверху, иначе она заглохнет или принесет только проблемы. Не важно, какие поступают предложения — сменить марку кофе, заказываемую в офис, или устаревшую технологию, выбрать новый модный фреймворк или язык программирования. Если предложение неуместно на данный момент и ты можешь объяснить почему, или, как иногда бывает, оно совершенно идиотское, то об этом надо сказать сразу же, без всяких «Мы подумаем», «Необходимо будет обсудить» или «Может быть». И уж тем более без слов: «Бери флаг в руки, а мы подхватим, но чуточку позже, например через месяц».

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

Лучше сразу решительно сказать: «Нет, этого не будет никогда» или «Извини, но в данный момент это предложение не уместно, но мы можем попробовать поговорить об этом через 3-6-12 месяцев», (понятно, что, скорее всего, никто не будет возвращаться к этому разговору), чем позволить человеку погрузиться в мир иллюзий, возвращение из которого крайне болезненно. При возвращении в реальный мир, у сотрудника возникают вопросы — «Ценен ли я», «Могу ли я что-нибудь изменить». Это первый шаг к смене работы.

Ты будешь всегда помнить про незаменимых людей и снижение bus factor. Будет очень неприятно, если единственный человек, который знает про какую-то часть кода решит уволится или поедет в отпуск. Это один из рисков. А если человек, который делает критически важные задачи за неделю до релиза собирается в долгожданный отпуск. Тут метод договорится пойти в отпуск после релиза уже не работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очень часто ты будешь заниматься не своей работой, потому что ты — главный в команде, кому это еще поручить. Тебя будут готовы познакомить со многими финансовыми аспектами работы твоей команды,. Это только кажется, что очень просто, например распилить премию выданную на команду, по всем ребятам (один из примеров). До первого раза. Так же ты будешь писать кучу унылых отчетов и общаться о своей команде с людьми, кто твою команду даже по именам не знает, и так же отстаивать интересы этих людей. Совещания. Созвоны. Митинги. Презентации. Собеседования. И много других увлекательных и отнимающих у тебя время и силы активностей.

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

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

Если кратко

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

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

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

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

Что делать то

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

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

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

Как стать тимлидом и не взорваться / Блог компании Touch Instinct / Хабр

Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:

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

Если вы стали лидом и первоначальная эйфория сменилась небольшим горением и унынием, то пара советов не будет лишней.

Откуда берутся лиды

Исторически сложилось, что существует две классические структурные модели управления компанией.

Первая — горизонтальная система управления. Её практикуют реже, к примеру basecamp или 37 signals. Смысл заключается в том, что у вас есть ряд сильных специалистов, способных самостоятельно регулировать свою деятельность.

Вторая — иерархическая система управления.

Есть разработчик, за ним стоит platform lead, за ним CTO, далее CEO. Каждый участник курирует определенный вектор развития. Чем ниже располагается в иерархии человек, тем за более узкоспециализированный участок он отвечает. Разработчик отвечает лишь за код, который он производит. Lead отвечает целиком за платформу и за её развитие. Технический директор отвечает за техническую составляющую в компании. А генеральный директор — за развитие компании.

Чем больше становится компания, чем больше появляется процессов и участников, тем сложнее становится иерархия. Появляются дополнительные роли, такие как Mobile Lead. У него в подчинении находятся лиды мобильных платформ, которых может быть больше одного на платформе. Это зависит от количества подчиненных на конкретном уровне в компании.

Оптимальное количество людей, которых может контролировать один человек, сильно варьируется от сферы деятельности и от модели управления. В IT в классической литературе это число колеблется от 5 до 9 человек.

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

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

Рассмотрим классическую ситуацию карьерного роста в IT-компании. Когда человек достигает определенного уровня квалификации, он может либо перейти на следующий уровень иерархии при наличии определенных личностных качеств, либо сменить род деятельности/область деятельности/компанию и расти дальше в технической стезе. На картинке ниже представлена классическая краткая форма развития. Следующая ступень развития разработчика — team lead либо tech lead. Первая предполагает уход в сторону менеджмента, вторая — глубокий технический рост специалиста. Team lead дальше уходит в platform lead. Из tech lead получаются архитекторы разного калибра.

Роль лида в компании

Для начала определимся, что ждет руководство от лида. В зависимости от размера компании его роль может сводиться как к управлению конкретной командой, так и развитию направления целиком. При этом необходимо быть готовым к тому, что разработчики будут требовать от вас высоких технических навыков, а управленцы более высокого звена — выполнения менеджерских задач. Чаще всего team lead это в некоторой степени программист, и в некоторой степени менеджер.

Техническая роль

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

Построение экосистемы. Сейчас в IT бизнесе выигрывает та компания, которая предоставляет не просто продукт, а старается построить экосистему. Которая может решать множество задач бизнеса и позволяет пользоваться различными функциями, которые предоставляет компания. Это касается и Apple, и Google, и Facebook. Со временем любой бизнес начинает превращаться в платформу. Похожая ситуация наблюдается и в разработке. Вам необходимо построить для разработчика экосистему целиком, чтобы вопросов возникало как много меньше. Это касается и процессных вещей, и архитектуры. Нужно сформировать документированную систему гайдов, которые позволят новым разработчикам быстро влиться в процесс, а участникам команды не забывать принятые нормы.

Построение системы обучения. Адекватный лид должен грамотно выстраивать процесс обучения всех членов команды, правильно соотнося их собственные интересы с бизнес-задачами компании. Если человек хочет изучить сложный кастомный UI, то задача лида придумать, как это можно использовать во благо. Это касается и других направлений, будь то технические знания или менеджерский бэкграунд. Важно следить за выполнением этих задач, обычно разработчики в своей голове ставят более низкий приоритет данным таскам. Старайтесь помочь в развитии даже в тех областях, в которых у вас меньше знаний. Сводите с нужным специалистом или дайте время разобраться самому, а потом пусть расскажет другим. Так человек укрепит свои знания. Ситуация, когда у разработчика или у вас отсутствуют знания в какой-то области, нормальна. Осознание и принятие этого способствует обучению.

Привитие принципов отношения к коду. Очень важно донести до разработчика мысль, что сам код не стоит ни гроша. Лишь функциональность, которая выполняется этим кодом, имеет смысл. Отсюда и растёт вся экосистема, которую необходимо построить. Важно понимать, что бизнес диктует правила для написания кода, а не наоборот. Если у вас банковская система с крайне высокой надежностью, то TDD вам необходим. Если же вы пишете MVP-приложения, то смысла строить сложную систему и архитектуру на первом этапе попросту нет.

Психологическая роль

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

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

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

Внедряйте «безликий код». Самый долгий и трудный процесс — привести код вашего отдела к «безликому коду», когда нельзя по стилю определить, кто его написал. Это направление правильное и трудное. Если возможна вариативность решения, вы встретите несколько лагерей. Чтобы в случае кризисной ситуации в ваш адрес не посыпалось «вот решили тогда так, а это оказалось плохо, и сейчас все минусы всплыли», необходимо дипломатично решать каждый вопрос. Помните, что с базовыми решениями, которые вы разрабатываете и согласовываете, будут работать другие люди. Делайте удобно для них.

Как сделать, чтобы стул не сгорел раньше

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

• Начинаете работать намного больше, чтобы успеть и как разработчик, и как team lead. Обычно это ведет к перегоранию.
• Работаете столько же, сколько и раньше. В итоге не успеете сделать и фичи, и задачи лида.

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

Именно поэтому нужно четко регламентировать, зачем вам программировать, сколько времени и что это даст отделу и в целом компании. Если речь идет о 30% времени, в течение которых вы будете проектировать архитектуру общих решений, библиотек или стандартов — одно дело. Это поможет не заниматься рутинными задачами, не забыть код и смотреть на него более глобально. Но если вам говорят о 70% или 90% времени, то люди просто не понимают, зачем им нужен team lead. Или заранее планируют, что вы будете работать больше 40 часов. Можете либо аргументированно объяснить, как сделать лучше, либо просто ответить отказом. Лучше всего поговорить об ожиданиях.

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

• люди не понимают, чем вы занимаетесь;
• вы и сами не понимаете, чем занимаетесь и что нужно сделать. Находитесь в совершенно неконтролируемом хаосе.

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

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

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

Автоматизируйте.Плюс различного рода оптимизации в виде CI/CD/статических анализаторов, кодогенераторов, базовых либ и так далее. Всё это экономит нам время в будущем.

Тайм-менеджмент и делегирование

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

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

Контролируйте время. Следите за временем, отведенным на задачу. Речь о тактических и стратегических задачах. Говорю не о ежедневной работе, хотя она и будет являться основным фактором успеха. Под тактическими задачами подразумевается выполнение конкретных больших задачах в виде создания базовых библиотек, задокументированных процессов или процесса обучения. Под стратегическими — определения вектора развития. В какой момент уйти с objective-C? Как сформировать экосистему, чтобы она работала эффективнее? Что надо сделать, чтобы эффективность решения задач бизнеса возросла? Это и есть примеры стратегических вопросов. Они наиболее сложные и наиболее длительные, но именно от них зависит ваше завтра.

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

Ошибки, негатив и минусы

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

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

Принятие решений. Бывает, что людей в команду спускают сверху. Вам необходимо сразу четко обозначить здесь правила: либо у вас есть право вето на абсолютно все решения по построению команды, либо необходимо объяснить руководству, почему будет работать именно так. В идеале и самое часто встречающееся на практике — когда team lead сам формирует себе команду. Повышается моральная ответственность так как решения принимал сам lead.

Личностные качества. В команде есть человек, который по каким-то причинам вас не устраивает. При этом абсолютно не важно, наняли его вы, или он уже был, или дали со стороны. Все люди ошибаются и вы не исключение. Особенно на первом этапе, когда всё ваше собеседование строится не на том, чтобы понять насколько человек вообще впишется в команду, а знает ли он, как решить алгоритмическую задачу по поиску элемента в бинарном дереве. Вы должны понимать, что любой алгоритм можно выучить за один день, любой framework при должном усердии от начального применения в первый же день до глубокого погружения в течение месяца. А личностные качества, некое «абстрактное чувство кода» за день-неделю-месяц или год не исправишь. В этом вопросе тем более не нужно ориентироваться на hr и считать, что это их работа. Потому что в итоге человек будет работать большую часть своего времени именно с вами в период работы в компании, а не с hr.

К минусам можно также отнести то, что со временем ваши технические навыки будут падать. Это и миф, и правда одновременно. Роль лида позволяет более широко взглянуть на некоторые технические аспекты, на мета-принципы программирования. А то, что вы не будете знать как запрограммировать в iOS 10 новый фреймворк CallKit и какие интерфейсные методы в нём есть — это пережить будет тяжело, но в целом можно.

Coming out

Я долгое время испытывал чувство гордости за то, что никто из членов моей команды не уволился, а уж тем более его не уволили за низкую производительность/крупные косяки в работе. Считал неким долгом помочь человеку, даже если это занимало некоторое количество моего свободного времени на выходных. Но необходимо раз и навсегда понять, что всё, что должен делать менеджер любого уровня — это направлять и помогать человеку, а не делать за него. Проведите несколько личных бесед для того, чтобы обозначить проблему. Чтобы не было конфликта ожиданий и что вы оба понимаете, проблема нужно решать. Постройте стратегию решения проблемы и жестко её контролируйте. Это может не сработать. Чтобы удостовериться, что проблема не в вас, то попросите другого разработчика в команде выступить неким независимым экспертом по оценке производительности/квалификации или просто моральной работы в команде. Если ваши мнения сошлись, то расставайтесь без тени сомнения. Так вы убережете и свои нервы, и нервы членов команды. И даже сам человек будет благодарен спустя какое-то время, что именно так всё закончилось. Чем больше времени проходит и больше опыта я получаю, тем меньше нужно времени, чтобы понять, совершил я ошибку или нет.

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

Построение масштабируемой схемы. Отход от роли «кольца всевластия»

Одна из самых частых негативных историй, которые я слышу от разработчиков про lead’ов — все интересные куски лид забирает себе. От лидов же получаю другой фидбэк, что самая частая проблема — есть задача и её ВООБЩЕ НИКАК!!!111 нельзя делегировать.Отсюда вытекает ряд проблем.

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

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

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

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

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

Что делать, если стали лидом

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

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

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

Помните, что учиться можно не только на своём опыте, но и на чужих ошибках. Teamleadство — это круто.

Список источников

С. Макконнелл. Сколько стоит программный проект

Дж. Ханк Рейнвотер Как пасти котов

Давид Хейнемейер Ханссон и Джейсон Фрид. Rework

Кто такой техлид и почему он нужен команде

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

Но в нашей индустрии даже градация должностей junior/middle/senior колоссально отличается от компании к компании. Что уж говорить о техлиде, который и вовсе не должность, а роль. Поэтому решили разобраться, что вкладывают в это понятие чаще всего. Заодно очертить зоны ответственности, сформулировать ключевые навыки техлида и понять, наконец, чем техлид отличается от тимлида (Спойлер: тимлид — это тоже роль, поэтому один человек может одновременно быть и техлидом, и тимлидом. А может и не быть).

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

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

Начнем с главного.

Техлид — это роль

Причем, часто — неформальная. Однажды инженер оказывается в команде самым опытным и инициативным, он становится неформальным лидером и начинает «топить» за совершенствование инженерных практик. Всё, он уже техлид, и назад, как правило, пути нет.

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

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

Чем занимается техлид

Конечно, это сильно зависит от специфики команды и компании и от направления работы самого лида. Наверное, от техлида мобильной-разработки не стоит ожидать помощи в разворачивании Kubernetes (но и такое бывает :)). Мы выделили верхнеуровневые задачи, которые не зависят от стека:

• Определяет стек технологий для конкретных проектов или задач.
• Берет на себя ответственность за внедрение новых подходов к разработке, тестированию, доставке и выбор новых технологий.
• Выстраивает процессы (например, CI/CD, код ревью), внедряет и развивает инженерные практики.
• Минимизирует риски для развития продукта, связанные с техническими ограничениям, преодолевает технические блокеры для бизнеса.
• Определяет технологическую стратегию развития проекта или продукта, работает на перспективу.
• Отвечает за качество реализации, продукта.
• Развивает технические навыки членов своей команды.
• Решает технически сложные задачи, которые другие инженеры в команде не в состоянии решить.

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

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

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

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

Главные качества техлида

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

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

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

А еще техлид, как и любой высококлассный специалист, должен думать о том, как он думает. Должен понимать ментальные модели и тюнить их.

Должен ли техлид работать руками

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

С другой стороны, если большую часть времени посвящать непосредственно разработке, то может не хватить на что-то из нашего первого списка задач техлида. На определенных этапах становления компании у техлида могут преобладать, например, задачи исследования или менторства. Тогда вряд ли команда должна рассчитывать на то, что техлид возьмет на себя какие-то продуктовые таски. Он может временами работать с кем-то в паре, контрибьютить в open-source или экспериментировать в pet-project. Главное, «не терять хватку» и осваивать новые стеки технологий.

Можно ли без техлида

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

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

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

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

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

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

Чем техлид отличается от других ролей и должностей

Конечно, сравнивать техлида и senior-инженера не совсем корректно, потому что одно — роль, а второе — обычно должность. Senior вполне может быть техлидом, но может и не быть. Ниже мы пытаемся определить, чем отличается инженер в роли техлида от тех, кто эту роль не исполняет, но тоже обладает высоким уровнем экспертизы и ответственности.

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

Техлид vs Senior

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

Техлид vs Тимлид

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

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

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

Поэтому на нашей конференции не будет чисто софт-скилловых докладов о том, как проводить 1-to-1 и строить доверительные отношения в команде, — это оставим TeamLead Conf. Мы будем обсуждать то, как выбрать и внедрить подходящие инженерные практики, как добиться технического совершенства и выстроить инженерные процессы.

Техлид vs CTO

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

Значит (возможно, пока не придумали CTO Conf), на конференции TechLead Conf для CTO будет много полезного. И естественно, это не только доклады, но и возможность обсудить с другими техлидами и CTO современные подходы и проблемные области индустрии.

Как стать техлидом

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

Вот на что рекомендует обратить внимание программный комитет TechLead Conf:

Алик Курдюков (UnitedTraders): Во-первых, нужна самоорганизация. От инициативности не будет никакой пользы, если вы неэффективно используете свои ресурсы. На мой взгляд, лучшая книга на русском языке на эту тему — это «Джедайские техники» Максима Дорофеева (с основными концепциями можно познакомиться в докладе Максима Дорофеева на РИТ++). Во-вторых, нужно уметь отстаивать свои решения — в этом помогут материалы по продажам, например, книга «Сначала скажите „Нет“» Джима Кэмпа.

Александр Матвеев (Авито): Увлекаться тем, что ты делаешь. Постоянно развиваться, читать книги и статьи, пробовать применять полученные знания на практике — обязательное условие. Постепенно накопится опыт применения подходов и практик и позволит достичь нового качества. А параллельно нужно развивать стратегическое мышление, чтобы лучше видеть перспективы тех или иных технических решений.

Евгений Сабиров (TELEMED.CHAT, ГК ХОСТ): Для начала нужен определённый mindset: в каждый конкретный момент развития процессов понимать, что можно сделать лучше и за счёт чего. А дальше уже изучать конкретные маршруты, какими можно в это «лучшее завтра» прийти. Чем больше маршрутов будет освоено, тем быстрее будут находиться новые.

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

Антон Бевзюк (Raiffeisenbank): Не сидеть на месте и постоянно учиться тому, что интересно самому человеку. Развивать две руки: изучать современные инженерные практики, инструменты, фреймворки и классические дисциплины программирования, о том как грамотно и качественно писать чистый код.

Вьет Нгуен (МегаЛабс): Расширять кругозор и постоянно тюнить свои ментальные модели и инструменты мышления — начните прямо сейчас!

Евгений Иванченко (DODO PIZZA): Чтобы стать техлидом, необходимо глубоко погрузиться в доменную область. В инструменты и технологии, которые используются в этой области. Прокачать необходимые софт-скиллы и не бояться брать на себя ответственность.

Юлия Долбилова (DODO PIZZA): Как стать техлидом, лучше расскажут спикеры на нашей конференции.

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

Подключайтесь к telegram-каналу и чату конференции — в канале публикуем новости, в чате их обсуждаем и спрашиваем ваше мнение о будущих темах и докладах TechLead Conf.

10 правил тимлида

Александр Груздев — тимлид в DINS. В этой статье он поделится инсайтами профессии и расскажет, почему тимлиду нельзя быть эгоистом, что на самом деле мотивирует сотрудников и как предотвратить выгорание.

#1 Проконтролировать все невозможно

Когда я только стал тимлидом, то хотел все проконтролировать или сделать за других. Всегда хотелось проверить, завершена ли чья-то задача, назначен ли митинг, ответил ли ребята друг другу в чате. Очень скоро я понял, что мне не хватит не то что 8 рабочих часов, но и 24 в сутках, чтобы все переделать. Поэтому мое первое правило: тимлид должен уметь делегировать.

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

#2 Удерживайте сильных специалистов

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

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

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

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

#3 Главная мотивация — интересный проект

Все мотивационные штуки — бонусы, бенефиты и прочие печеньки не работают, если человеку скучно.

Если задачи неинтересные, человеку будет все равно, какая у него зарплата и что входит в ДМС.

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

#4 Помните, что люди разные

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

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

#5 Планируйте

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

Кто является руководителем группы в BPO? За что отвечает тимлид

Кто является руководителем группы в BPO?

За что отвечает руководитель группы в
БПО?

Что такое kRA для руководителя группы в BPO?

Какие основные навыки необходимы команде
Вести?

Что было достигнуто в качестве руководителя группы по прибытии?

С какими проблемами сталкивается руководитель группы БПО?

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

Как руководителю команды играть как хороший командный игрок?

Как руководитель команды умиротворить рассерженного клиента?

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

Объясните, как вы оцениваете окончание проекта / задачи
даты, а затем отслеживать их, чтобы гарантировать, что крайние сроки
встретились.

Как вы оценивали свой успех в команде
лидер?

Как измеряется эффективность команды командой
вести?

Насколько важны лидерские и коммуникативные навыки
играет роль лидера группы?

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

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

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

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

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

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

Какие шаги должен предпринять руководитель группы, чтобы сосредоточить внимание на
навыки членов команды вышестоящим инстанциям?

Какие атрибуты должен искать руководитель группы
при выборе членов для своей команды?

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

Почему атрибут управления людьми очень важен
для тимлида?

Каковы самые слабые качества или атрибуты команды
лидер должен определенно избегать?

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

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

сценарий: —

Что вы будете делать, если членам команды не нравится
вы

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

Объясните сценарий, в котором вы идете в Win-Win
ситуация или сценарий, в котором вы предоставляете решение до
какой клиент и ваша команда остались довольны.

Руководитель группы скрывается на 10 дней
и не сообщил своему руководителю группы. Он пишет своему лидеру на
.
11-й день, когда он нездоров, но когда Т.Л. попытался позвонить ему
назад, он не ответил. Через 1 неделю он вернулся к
офис с медицинской справкой

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

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

.

8 советов для новых руководителей групп | Как вести команду

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

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

1. Найдите время для руководства

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

2. Познакомьтесь со своей командой

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

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

3. Общайтесь, общайтесь, общайтесь

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

4. На примере

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

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

5. Вознаграждайте хорошее и учитесь на плохом (и уродливом)

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

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

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

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

7. Будьте решительны

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

8. Наслаждайтесь!

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

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

Скачать электронную книгу

.

Возглавляет команду, которую вы унаследуете

Вкратце об идее

Что не так

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

Что нужно

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

Что такое эффективный

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

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

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

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

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

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

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

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

Оценка команды

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

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

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

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

Ваши ожидания в отношении членов команды также будут зависеть от того, насколько важны их роли для достижения ваших целей. Люди, занимающие критические должности, будут оцениваться с большей срочностью и более высокими стандартами.У Дэвида Бенета (имена замаскированы) было два руководителя продаж, оба считались критически важными, поскольку их группам приходилось повышать осведомленность кардиологов о новых продуктах. Им обоим нужно было немедленно эффективно сообщать лидерам общественного мнения о преимуществах продукции. Глава отдела кадров также играл жизненно важную роль — в ближайшее время необходимо было устранить серьезные недостатки среднего звена в сфере продаж и маркетинга. Однако глава отдела коммуникаций не был таким большим приоритетом; обзоры его работы и беседы с коллегами показали, что он мог бы быть более изобретательным, но Дэвид решил пока оставить его на месте.

Дополнительная литература

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

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

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

Приготовьтесь.

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

Создайте шаблон интервью.

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

Ищите вербальные и невербальные подсказки.

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

Подведите итоги и поделитесь тем, что вы узнали.

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

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

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

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

Изменение команды

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

Состав.

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

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

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

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

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

Выравнивание

.

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

Чтобы все согласовали, команда должна согласовать ответы на четыре основных вопроса:

Что мы сделаем? Вы указываете это в своей миссии, целях и ключевых показателях.

Почему мы должны это делать? Здесь в игру вступают ваше видение и стимулы.

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

Кто что будет делать? Роли и обязанности людей должны поддерживать все вышеперечисленное.

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

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

Иногда необходимо изменить заявленное направление команды.

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

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

Операционная модель.

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

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

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

Дополнительная литература

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

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

Интеграция.

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

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

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

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

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

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

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

Эта статья также встречается в:

Ускорение развития команды

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

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

Версия этой статьи появилась в выпуске за июнь 2016 г. (стр. 60–67) журнала Harvard Business Review .
.

Что такое лидерство и кто такой лидер?

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

Что такое лидерство?

В рамках исследования для моей новой книги «Будущий лидер» я опросил более 140 генеральных директоров по всему миру и попросил каждого дать определение лидерству.Многие люди изо всех сил пытались или им приходилось делать паузу, чтобы подумать, потому что это слово мы используем так часто, не имея точного определения. Мы принимаем концепцию лидерства как должное и предполагаем, что все мы знаем, что такое лидерство и как выглядит великий лидер. Как только руководители нашли свои определения, их ответы охватили весь спектр. От более чем 140 человек я не получил ни одного повторяющегося ответа.

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

Кто такой лидер?

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

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

Создание фильтров лидерства

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

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

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

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

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

Джейкоб Морган — автор, TED и основной докладчик, футурист и создатель FutureofWorkUniversity.com. Чтобы оставить комментарий, пишите на [email protected].

.