На рынке не так много книг, которые помогают начинающим тимлидам, которые еще вчера писали код и строили архитектуру, понять, как нужно приступать к работе с людьми и строить свое развитие по ветке управления. Это, естественно, две популярные книги: "Мама, я тимлид!  Практические советы по руководству IT-командой" Перескоковой Марины и "Как пасти котов. Наставление для программистов, руководящих другими программистами" Дж. Ханк Рейнвотера.

И вот на свет вышка книга: "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs", которую Издательство Питер @ph_piter перевело как: "Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО". Не нужно пугаться позиции "Software Engineering Manager" - это именно что тимлид в понимании рынка РФ. И эта книга по своей сути является такой же отправной точкой в карьере начинающего тимлида, как и две предыдущие, но немного иначе!

Об Авторе

James Stanier

Director of Engineering at Shopify

Джеймс Стэньер — технический директор в Shopify. Также написал такие книги, как "Эффективная удаленная работа" и "Инсайты интернет бизнеса: уроки интернет-компаний". Имеет Ph.D. в области информационных технологий и ведет сайт для it-менеджеров: theengineeringmanager.com. По его собственному мнению, он больше практик, нежели теоретик.

Кратко о сути книги

Представьте, что у вас уволился тимлид одной из команд. Технический директор набирает вас и говорит, что он хотел бы предложить вам роль тимлида в этой команде. Вы понимаете, что это хорошая возможность развиваться по ветке управления и соглашаетесь. Но уже после того, как вы согласились, вы понимаете, что ничего не знаете в области тимлидства. Советы других тимлидов выглядят на уровне: "Хорошо делай, хорошо будет", а гитхаб Виталия Шароватова с краткими руководствами (https://github.com/sharovatov) вы еще не нашли – тогда именно эта книга поможет вам найти опору на первое время и начать работать с командой, постепенно доучивая теорию и оттачивая её на практике.

Обзор содержания книгии

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

Онбординг. Далее начинается самый первый этап в жизни тимлида - онбординг в команду. Автор описывает, как нужно знакомиться с ребятами, вникать в проект, корректировать ожидания от работы каждого участника и понимать, какой пласт работы должен закрыть сам тимлид. Советы максимально конкретные.

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

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

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

Работа со своим начальником. Очень интересная глава, которая объясняет тимлиду, что ему необходимо не только работать со своей командой, чтобы добиваться результатов, но и работать со своим начальником (unit-менеджером), чтобы была прозрачность процессов, целей и результатов. Это позволяет, как показать себя, так и вовремя получить необходимый совет, помощь.

Искусство One-to-Ones. Для чего нужно проводить one-to-one, как часто нам их нужно проводить. Какие цели ставить на one-to-one, какие вопросы задавать, как вести беседу, на что обратить внимание.

p.s. После прочтения этого раздела, хорошо бы посмотреть доклад Юрия Милютина по One-to-One, и вы сможете смело идти на one-to-one.

Что мотивирует людей. Тут каких-то секретов нет, автор приводит пирамиду Маслоу и делает аналогию по работе инженеров. p.s. Кто-то считает, что она уже давно устарела и её не нужно использовать, кто-то её использует или как-то адаптирует под себя. Но уже как есть.

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

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

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

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

Найм и увольнение.

• Найм - работа по составлению портрета идеального кандидата и сама методология проведения интервью.

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

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

• Люди сложные (обзор ситуаций по общению с людьми, формирование гильдий по экспертизе, ворк-лайф-баланс и так далее)

• Проекты сложные (базовый проджект менеджмент, налаживание процессов в команде, донесение плохих новостей до команды, замедление процессов с ростом проекта и так далее).

• Карьерное планирование (куда расти после тимлида, чего можно добиться, почему сегодня так мало разработчиков хотят становиться тимлидами, работать в стартапах или корпорациях и так далее);

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

Плюсы книги:

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

• Даны практические советы по тем или иным моментам в работе. Даны ссылки на дальнейшее углублённое изучение.

• Хороший материал по работе с личной мотивацией становиться тимлидом.

• Приведены дальнейшие ступени, после тимлидсва.  

Минусы книги:

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

• Некоторые методики исключительно американские, в странах СНГ они работают немного иначе.

Итоговое мнение

Я бы сказал так, что если вы больше целитесь на российский рынок, то вам стоит ознакомиться с книгами "Мама, я тимлид" и "Как пасти котов", а если вы рассматриваете перспективы работы на западный рынок, то "Карьера Software Engineering Manager" и «Как пасти котов».

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

В общем, стоящая книга для начинающих тимлидов, брать можно и нужно!

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