10-11 февраля в Москве состоялась уже пятая конференция специально для тимлидов — TeamLead Conf. Обсуждали, как развиваться самому, помогать развиваться коллегам и вообще, какими задачами должен заниматься тимлид. Особенно остро эти вопросы стоят для тех, кто еще недавно кодил, а теперь должен думать совсем о других вопросах, вникать в психологию людей и проявлять эмпатию. Но и для опытных тимлидов и руководителей уровня CTO было много полезного.
Конечно, за сорок минут доклада нельзя дать исчерпывающую информацию по теме, но можно поделиться опытом, показать, как и какие решения пробовали, что сработало, а что нет. Далеко не все подходы удастся внедрить в своей компании без модификаций. Но иметь ориентир (а лучше несколько) удобно.
На конференции мы сделали краткие конспекты нескольких докладов, основные рекомендации из которых вы можете применить в своей работе без глубокого погружения в тему.
Настоящие задачи руководителя
Иван Лукьянов (Avito)
Чтобы выйти на «настоящие задачи руководителя», представьте, что вы видите проблему, которая мешает соседнему подразделению эффективно достигать целей. Вы, как человек, который болеет за благополучие проекта и компании (а это неотъемлемые качества настоящего руководителя), конечно, знаете, что нужно сделать, чтобы все исправить. Это решение кажется вам очевидным. Например: «Перевести фронтенд на TypeScript — это всегда работает».
Вы предлагаете решение своему руководителю, и по совместительству руководителю того второго подразделения. Но не происходит ничего, или очень медленно, или происходит не то.
Все дело в том, что вы не видите картину так, как видит ваш руководитель. Не видите скрытых зависимостей и задач, не знаете распределение ресурсов, не знаете, что уже пробовали, не знаете скрытых планов бизнеса. И главное, вы можете недооценивать значение человеческого фактора.
Трюк в том, что, к сожалению, при всем желании, вы не можете все это узнать. Ваш контекст имеет ограничения примерно очерченные пунктиром на слайде. Нельзя разбираться во всех деталях законодательства и бухгалтерии и т.п. одновременно.
Если на абсциссе контекста отметить инженера, тимлида и юнит-лида, то:
- у инженера конкретный контекст, руководитель руководителя не попадает в контекст инженера;
- юнит-лид решает верхнеуровневые, абстрактные задачи;
- тимлид где-то посередине.
У тимлида две основных задачи:
1. Проводить информацию в обе стороны.
2. Менять ситуацию, чтобы система приводила к сильным результатам.
Эти задачи нужно балансировать.
Причем, вторая задача распадается на:
- делать так, чтобы команда достигала целей;
- делать так, чтобы через несколько лет команда достигала целей.
И по второй задаче длинная петля обратной связи. Трудно оценить, как вы с ней справляетесь. Однако, забывать про неё нельзя.
В своем докладе Иван разбил задачи руководителя на три области действия: вы и ваш руководитель, вы и стейкхолдеры, вы и ваш клад.
В части вашего взаимодействия с вашим руководителем нужно:
- составить чёткую и полную картину происходящего;
- обсуждать ваши мысли и наблюдения;
- следить за тем, что руководитель понимает, что вы говорите.
Можно говорить, что что-то не знаешь. О проблемах можно говорить. Ваша команда может фейлить, вы можете фейлить, и это нормально! Примите это.
Со стейкхолдерами примерно похоже, только у них проектов гораздо больше, поэтому конкретики нужно меньше.
Чтобы оценить свой вклад, подумайте вот над каким утверждением Ивана: «Основная ценность руководителя в том, что у него есть собственный контекст и собственное видение». Все, что вы делаете, должно соответствовать тому решению, которое вы приняли. В тот момент, когда вы послушали кого-то сверху, не пропустив через себя и не приняв собственно решение, вы не сделали свою работу. Чем выше уровень руководителя, тем более странно будут звучать оправдания вроде: «Как сказал начальник, так и сделали».
И напоследок важное обобщающие утверждение.
Мы как руководители вынуждены принимать решения в области неопределенности по вопросам, в которых не всегда достаточно компетентны, а цена неверно принятого решения всегда очень высока. Естественно, мы совершаем ошибки!
Чтобы их было меньше Иван советует, когда в сложной проблеме видится простое очевидное решение, выдохнуть и попробовать расширить границы «ромашки контекста».
Нам нужно поговорить
Михаил Емельянов (Центр Финансовых Технологий)
Вам повезло, если вы еще не сталкивались с тем, когда сотрудник предлагает поговорить, а на самом деле разговаривать уже не о чем, он уже все решил, он увольняется.
Михаил предлагает пирамиду болей. Начинается все с нижнего уровня и, если не лечить, дальше становится все гораздо запущеннее.
Починить, когда сотрудник уже все решил, будет трудно. Ключ к решению проблемы — общение. А именно, своевременные one-to-one (разговоры один на один).
Но разговор разговору рознь. Нужно продумать три важных этапа: подготовка, сама встреча, после встречи.
Длительность встречи one-to-one от получаса до полутора часов. Короткие встречи могут быть чаще, потому что не утомляют. Более длинные полезны для обстоятельных обсуждений, но чтобы не тратить все время на митинги, можно проводить их чуть реже.
Частота встреч зависит от стажа и того, как давно вы работаете вместе.
Михаил советует с новичками общаться каждую неделю. И не реже, чем раз в месяц в любом случае!
Привлекать HR на one-to-one не рекомендуется. Может сработать стереотип, человек побоится каких-то дисциплинарных действий и не сможет раскрыться. Лучше выделить другой формат для привлечения HR к работе с сотрудниками.
В качестве инструмента: Trello. Хотя до определенного момента работает блокнот, а когда-то может понадобиться что-то более функциональное, например, Imprase или Monday.com.
На этапе подготовки важно учесть контекст и заранее обозначить тему беседы. На встрече: первый one-to-one или нет, новый сотрудник или нет, количество тем в агенде.
Хронологический формат (что обсуждали в прошлый раз, что изменилось, планы) удобен, но можно пропустить боль, которая не вписывается в жесткие рамки, а находится где-то немного сбоку.
Другой вариант — по темам. Это прозрачнее, но можно скатиться к статус-апдейтам. А one-to-one — это не планерка.
Хороший принцип для таких встреч, который с ходу не так-то просто соблюдать, — 90/10. 90% времени слушаете, 10% говорите. Не перебивайте и слушайте, а эго оставьте за дверью. Вы же хотите получить фидбек от сотрудника? Тогда задавайте правильные вопросы: с открытым ответом и в позитивном ключе. «Как дела?» — конечно, позволяет получить открытый ответ, но, скорее всего, он будет односложным: «Нормально».
А после встречи: аккуратно запишите follow up и выполняйте обязательства.
One-to-one не поможет если есть: несоответствие миссии и ценностей у сотрудника и компании, личные психологические проблемы.
Также Михаил не рекомендует обсуждать на one-to-one деньги. Можно использовать этот разговор для последующих решений, но зарплатные вопросы лучше решать отдельно.
И последнее напутствие: «Общайтесь с вашими коллегами, уделяйте им внимание, помогайте решать их проблемы и делайте это регулярно!»
Практические примеры разбиения больших задач на микротаски
Никита Соболев (wemake.services)
Доклад для тех, кто стал тимлидом из инженера и хочет все еще оставаться инженером. А инженеры, что? Хотят автоматизировать всё и вся. В том числе управление людьми и задачами.
Чтобы автоматизировать, надо уметь оценить результат. Иначе непонятно, есть ли выхлоп.
Твиттер-мудрость гласит, что умение разбивать задачи на части — один из самых важных навыков в программировании.
Поэтому, Никита говорит, что задача «на час» гораздо лучше, чем задача «на неделю». И последовательно это доказывает на понятных примерах.
Например, короткие задачи гораздо прозрачнее. А прозрачность дает возможность быстро получать обратную связь.
Что еще можно делать с прозрачностью?
- Мотивировать людей.
- Собирать статистику и предсказывать.
- Общаться с заказчиками.
- Настраивать нотификации и быть спокойным.
Например, прозрачность должна помочь объяснить бизнесу, почему задача передвинуть кнопку переросла в смену фреймворка.
Но как ставить короткие задачи? Утверждение о том, что для этого нужно много крутых менеджеров по мнению Никиты — просто миф. Создавать маленькие задачи легко — берешь и создаешь.
Чтобы задача на час не превратилась в задачу на все выходные, она может и должна порождать новые задачи. Короче, все, что сразу приходит в голову при мыслях о микротасках, на самом деле не проблема.
На самом деле сложно:
- Управлять большим количеством задач.
- Гонять CI, делать ревью кода.
- Архитектура.
- Сохранять стабильность сборки.
- Деплоить и откатывать, мониторить.
По первому пункту хорошо работает связка task chains, todo прямо в коде и боты (много ботов). CI действительно становится намного сложнее, но нет ничего невозможного. А ревью кода можно подтюнить автоматикой.
Дальше в докладе было много интересных концепций для разработки подходящей архитектуры со ссылками (в основном все про Python), и примеры из практики. Это удобно посмотреть прямо в презентации.
Получился сложный доклад для инженеров, с богатыми возможностями для дальнейшего глубокого изучения темы.
Ссылки на другие конспекты докладов TeamLead Conf:
- Универсальная карта компенетций. Галина Голованова (Tinkoff.ru).
- Гибкое управление Data Science-продуктами. Асхат Уразбаев (ScrumTrek).
- Почему часто хочется работать, а иногда нет. Дмитрий Смирягин (ITExpert).
- Как сделать так, чтобы документация не болела? Сообщество Write the Docs.
За них спасибо нашим экспертам по управлению знаниями. Это важная область и в том числе задача руководителя организовать передачу знаний, онбординг новичков и борьбу за рост автобусного числа. Но об этом подробно будем говорить в другой раз — на KnowledgeConf в мае.
Это только малая часть и, возможно, гостям конференции больше всего запомнились другие доклады. Если вы были на TeamLead Conf, напишите в комментариях, какие это были доклады. И мы сделаем по ним полнотекстовые статьи, а через пару месяцев выложим видео в открытый доступ. Если ждать не хочется, то можно приобрести записи или посмотреть на нашем youtube-канале доклады прошлых конференция для тимлидов и руководителей.