Полагаю, все здесь знают, что такое 1-1 (или one on one, 1:1, один-один, тет-а-тет). Я считаю, что этот формат общения — один из самых важных инструментов в рукаве тимлида/руководителя, но очень недооценен. Про него обе сегодняшние статьи.

Мне 1:1 довольно долго не заходил, пока я где-то не наткнулся на хороший материал про этот формат (к сожалению, найти его уже не могу). Основная идея в том, что он предназначен не для получения статуса по задачам от подчиненного, а для обсуждения успехов, неудач, планов и т.д. Если сделать 1:1 откровенными, честными, открытыми, то можно будет узнавать о людях очень много такого, чего в обычной обстановке они бы не рассказали: свои взгляды на карьеру, чего хочется, что не нравится. Вам, как руководителю, остается только использовать эту информацию для роста человека и предотвращения кризисов. Статья уровня “сейчас я научу вас жизни”, но в ней есть интересные мысли. https://medium.com/@zackbloom/youre-doing-one-on-ones-wrong-dfc27f36f204

Наверное, не сильно ошибусь, если скажу, что большинство тимлидов и руководителей на этом канале так или иначе вышли из разработки/тестирования/администрирования, в общем, люди с техническим бэкграундом. По своему опыту, таким людям не всегда легко дается открытое общение с начальством/подчиненными. Следующая статья как раз про то, что хорошие 1:1 получаются тогда, когда вам “неловко”: вы перешагиваете через себя и рассказываете о своих мыслях, мечтах, планах, неудачах. В статье есть примеры вопросов/тем, которые подталкивают к открытому общению. https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c (есть вторая часть про то, как получать честный фидбек о себе — тоже рекомендую).

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

А вы считаете 1:1 полезными? (Отвечайте отрицательно, если не проводите/с вами не проводят).

Пока в группе “Боль тимлида” не утихают страсти по поводу “performance review”, самое время поделиться статьями на эту тему.

Не смотря на разное отношение, в некоторых компаниях такой способ оценки сотрудников практикуется. Первая статья содержит ряд идей, без которых, по мнению автора, ревью будет приносить больше вреда, чем пользы. Мысли на самом деле довольно простые: перфоманс ревью должно быть в первую очередь про результаты, а не про деятельность (тот, кто больше делает, не факт, что приносит больше пользы), хорошие оценки не ведут к развитию человека, а плохие, не подкрепленные качественным фидбеком, не улучшают ситуацию и т.д. Если честно, мне не зашли “Best Practices” из статьи, возможно, я их просто не понял. Но всё, что до них, считаю годным. https://hackernoon.com/how-to-do-performance-reviews-2f0e8cd170da

В нашей компании перфоманс ревью существует с 2011 года, а за основу был взят процесс Google. С тех пор мы его несколько раз модифицировали (например, самое большое изменение: мы сделали маленькие ежемесячные ревью, которые привязаны к результату здесь и сейчас, и позволяют человеку сразу получать бонус за проделанную работу, и большие полугодовые ревью, которые нацелены на долгосрочные результаты и рост сотрудников). Я ни в коем случае не утверждаю, что наша схема - “правильная”, но для нас она работает. Пожалуй, самая актуальная и подробная информация есть в этой статье: https://habr.com/company/badoo/blog/331570/, либо в докладе с хайлоада: https://www.youtube.com/watch?v=qDzlqNicZ8g.

Я считаю, что самый важный скилл тимлида/менеджера/руководителя - time management. Именно он определяет, будет ли у вас время для роста и развития, или вы будете вечно заняты разгребанием завалов, решением текущих проблем, а чувство перегруженности не будет покидать вас. На эту тему есть множество книг, статей, докладов, где рассказывают о конкретных инструментах и практиках, но по факту, базовыми являются простые идеи, которые описаны в сегодняшней статье: временем управлять нельзя, можно управлять только тем, на что вы его тратите. Поэтому все сводится к умению приоритезировать: продвигать важное, избавляться от неважного, выделять то, что должно быть сделано сегодня (завтра, к конкретному числу). https://www.meme-arsenal.com/memes/a17827e7a1a800d60f20ff9a84f73b8e.jpg
Статья: https://medium.com/thrive-global/why-you-really-dont-have-a-time-management-problem-82eb6e31ffc9

Отличный способ разгрузить свой список задач, выкроить время на себя, а заодно и людей научить чему-то новому - делегирование. Если вы считаете, что делегирование - это поставить на человека задачу, то это не совсем так. В следующем докладе рассказывается о том, что же такое делегирование, когда его нужно применять и что мешает это делать правильно. Если коротко, то ключевые ошибки: делегирование группе без конкретного ответственного, отсутствие у человека возможности (инструментов) для достижения цели, отсутствие цели/срока/приоритетов, передача ответственности (ответственность остается на вас). Вообще, в докладе довольно много информации, всю не передашь, поэтому рекомендую посмотреть: https://www.youtube.com/watch?v=1bZ9EJ8o7Io

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

Если кто-то смотрел вчерашний доклад про делегирование, то теория там кратко рассказана. Если нет, то можно прочитать следующую статью. Если сжато, то часто руководители выбирают какой-то один стиль управления (авторитарный, демократический или либеральный). Таких руководителей сразу видно: они либо слишком мягкие, либо слишком жесткие, либо слишком безучастные. Настоящие же профи (какими мы все хотим стать) умеют подбирать стиль под ситуацию/человека/задачу. Я не буду пересказывать, как это делается, просто приведу пример из статьи, где показаны четыре варианта постановки задачи в четырех разных ситуациях:
- Приказ: я решил запустить новый проект, вот что ты должен сделать.
- Продажа: я решил запустить новый проект, сейчас я расскажу тебе, почему он так важен, и как ты сможешь запустить его.
- Участие: нам нужно запустить новый проект, давай ты подготовишь план и стратегию, а потом обсудим.
- Делегирование: нам нужно запустить новый проект, ты лучше меня знаешь, как и что для этого сделать.
https://medium.com/swlh/why-your-team-calls-you-a-micro-manager-behind-your-back-bae4b0a9e0be

Выходные - время отдыха, поэтому статьи будут просто “за жизнь” и по одной в день.

В сегодняшней статье автор делится мудростью о том, как ему удалось добиться хороших результатов в своей компании, не смотря на то, что в индустрии продукты становятся все хуже, сотрудники и пользователи несчастны, а серебряные пули, типа скрама, тянут всех вниз, а происходит все это из-за плохих руководителей (что-то мне это напоминает… кстати, про негативное влияние перфоманс ревью в статье тоже есть). Статья большая, в ней много интересных мыслей (и гуглить никто не отправляет, если вы понимаете, о чем я), некоторые из них:
- Нужно настороженно относиться к топ-перформерам (чаще всего они добиваются высокой скорости разработки путем создания тех долга и выбором плохих технических решений)
- Нужно совмещать разработку с рефакторингом, иначе вы не будете успевать устранять тех долг (это похоже на правило бой-скаута: нужно оставлять после себя код лучше, чем он был)
- Поощрять владение кодом (типичная позиция тим лидов: повышать бас-фактор, окуная людей во все места в коде, но это снижает качество, инициативу и скорость разработки)
- Разработка и управление - разные вещи. Вы не лучше/умнее ваших девелоперов только потому, что вы управляете ими. Не нужно создавать у девелоперов ложное ожидание того, что “повышение” в менеджеры - это прогресс их карьеры. Они должны идти в менеджмент, только если действительно хотят этого.
https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450

Жена предлагала запостить сегодня статью про work-life balance, но мне она не зашла.

Сегодняшняя статья тоже очень длинная, но она объясняет, откуда же берутся плохие руководители, и как жить дальше (да, там есть принцип Питера про уровень некомпетентности, но он не рассматривается в качестве основной причины). Вот часть причин, которые, по мнению автора статьи, делают менеджера плохим управленцем (в статье есть и еще):
- люди подсознательно оценивают в других то, в чем хороши сами (в статье был пример про ревью кода: если тимлид - лучший ревьюер на деревне, для него ревью кода станет главным фактором в оценке своих сотрудников)
- тот факт, что они уже в чем-то хороши, затмевает их слабые стороны и усложняет разностороннее развитие
- некоторые считают, что они прекрасно справляются со своей работой (потому что они лучше всех знают, как правильно ревьюить код, просто команда какая-то плохая попалась - не хотят учиться этому)
- в своих неудачах люди привыкли винить обстоятельства, вместо того, чтобы сделать выводы и научиться чему-то
- некоторые менеджеры слишком оторваны от того, чем занимается команда (со стороны менеджера это выглядит как высшее проявление доверия и свободы, но в этом есть свои минусы).
Тому, как жить дальше, посвящена маленькая глава, причем довольно расплывчато, но я сделал из нее такой вывод: если вам что-то не нравится в вашем руководителе - донесите это до него, предложите, что он может изменить (начать что-то делать, перестать что-то делать).
https://medium.com/@jswilder16/how-to-better-manage-your-poor-manager-50b96d944957

На этом моя неделя заканчивается, с вами был @andreygomenyuk, пока!

Подкастов не бывает много. Встречайте еще один, от создателей одноименного митапа. Тема первого выпуска – профессиональное выгорание.
http://bit.ly/2RVOt4B

Знаете Егора Бугаенко только по его холиварным выступлениям и блогу? В первом выпуске нового сезона АйтиХайпа мы выясняем, зачем ему это нужно, как он зарабатывает деньги, пишет книги, устраивает соревнования по качеству кода и многое другое. Также много говорим про Зерократию – авторскую методологию Егора по управлению проектами и программистами. Ну а впереди – еще 9 выпусков со знаковыми людьми из отечественного айти. Stay tuned, теперь мы выходим регулярно! https://www.youtube.com/watch?v=ca9ou5t6yyY #ithype

Выложили новый выпуск АйтиХайп с Олегом Буниным. Поговорили про то, сколько зарабатывают конференции, как курится кальян с Дуровым, про Роскомнадзор с блокировками и Рамблер в самом расцвете его жизни. Всем Кремниевой слободы!
А для тех, кто хочет получить билет на тимлидконф, в конце конкурс.
https://youtu.be/HRQ73xZuIZQ

Devleads выпустили второй выпуск своего подкаста, в котором разобрали чем отличается финансовая мотивация от нефинансовой, почему деньги не помогают удержать человека, как проводить личные встречи и почему нельзя забывать имена своих подчиненных.
https://soundcloud.com/devleads/devleads-2-nefinansovaya-motivatsiya

#podcasts

Записали отличный выпуск Podlodka про развитие команды и выращивание тимлидов вместе с Виталием Шароватовым. За кнопкой «плей» бесконечность практических советов для инженеров и руководителей.
http://podlodka.tilda.ws/95

#team

Запущен ежегодный опрос известности команд мобильной разработки. Если у вас в компании или в друзьях есть мобильщики – отправляйте им ссылку!
Результаты обязательно пошарю в канале.
http://bit.ly/2RoSPjA

#polls

Крутой разбор кейса внедрения LeSS Huge в Додо Пицце.
https://www.facebook.com/notes/dodo-pizza-engineering/less-huge/1477977539005264/

#less

Воспользуюсь тем, что у меня не отжали права на пост в канал. https://ppc.world/articles/70-knig-dlya-razvitiya-soft-skills/ . Очень годная подборка книг по soft-skills. Многие я регулярно рекомендую к прочтению. Читать можно смело сверху вниз, про продажи не пропускайте, даже если вы не в продажах. Именно там на софт-скилах в части коммуникаций собаку съели. Рейтинг построен на основе общественного мнения, а не только на мнении авторов, есливдруг.

А я тут стартую небольшой новый проект – коллективный твиттер руководителей разработки leadunderhood. Концепция простая как два пальца. Каждую неделю – новый автор. Каждый день – новая тема для обсуждения. Автор рассказывает о своем опыте, а подписчики реплаят, спрашивают и холиварят. Короче говоря, подписывайтесь, будет круто! Автор первой недели – известный вам Роман Ивлиев.
https://twitter.com/leadunderhood

#news

Чеклист для разработки архитектуры нового сервиса. На первый взгляд, автор охватил все, что нужно.
https://link.medium.com/u1fishkp2T

#architecture

Подъехал новый выпуск АйтиХайпа с Андреем Себрантом, главным за стратегический маркетинг в Яндексе. В выпуске много инсайда про Яндекс, историй про инновации и Китай, беспилотников и ИИ. С вас подписки лайки и шеры!
https://www.youtube.com/watch?v=HtK7pWhm3WE

Подробный обзор CI/CD в команде Яндекс.Такси – процессы, инструменты, культура.
https://habr.com/ru/company/yandex/blog/439704/

#processes

Открыли регистрацию на очередной devleads митап в Mail.ru. В программе все про рост – себя, сотрудников, Озона и противоречий между разработчиками и тестировщиками.
http://bit.ly/devleadsmail

#events

Ребята в Туту.ру весь год работали над переработкой своего процесса собеседований и по итогу подняли скорость набора в 4 раза. По ссылке – хороший анализ исходных проблем и выработка решений для каждой из них.
https://habr.com/ru/company/tuturu/blog/440112/

#hiring