Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Self-hosted альтернативы инструментам Atlassian Я пропустил новости про уход из России Atlassian стека. Если вас это коснулось, в статье рассказывают про альтернативы, которые можно поднять у себя на сервере. Что использовать вместо Jira: 👉Plane 👉Redmine 👉Tuleap Что использовать вместо Confluence: 👉Outline 👉Bookstack 👉Docuwiki Что использовать вместо Trello: 👉Mattermost Boards 👉Logseq 👉Kanboard Если вы можете порекомендовать другие аналоги – делитесь в комментариях!

Девять подходов к проведению health check команды На позиции тимлида хелсчек – довольно странное занятие. Ты и так должен постоянно держать руку на пульсе всего происходящего, регулярно общаться со всеми участниками команды, и иметь непротиворечивую и близкую к реальности картину мира. Но вот если вы менеджер нескольких команд, то разумный хелсчек может помочь не пропустить сигналы о том, что в происходящее в какой-то команде нужно посмотреть повнимательнее. В статье предлагается сразу девять моделей, посмотрев на которые, вы сможете собрать что-то, подходящее именно вам. Если что, можели по сути одинаковы, различаются только конкретные вопросы и плюшечки визуализации. Вот некоторые из моделей: 1️⃣Parabol's model: анонимная оценка настроения всех в команде. 2️⃣Spotify Squad model: каждый член команды оценивает разные аспекты процессов, продукта и технологий по светофору. 3️⃣Team health radar: самооценка по пяти категориям и представление результата в виде радара.

Always do Extra Представьте, что вы делаете какую-то задачу, и она заняла у вас на 20% меньше времени, чем вы хотели на нее потратить. В этот момент у вас появляется следующая развилка: 1. Не делать ничего 2. Взять следующую задачу (doing more work в оригинальной статье) 3. Сделать текущую задачу лучше (doing extra work) Отличие второго и третьего пункта в том, что выполнение задач на потоке – это обычная работа, то, что от вас ожидается. Выполнение extra work – возможность самому придумать цель, которая одновременно и проекту поможет, и прокачает какие-то ваши скиллы и знания. А заодно еще и поможет превысить ожидания и в каких-то случаях создать вау-эффект. Так вот, автор топит за то, что в большинстве случаев на такой развилке лучше выбирать extra, а не more. При этом, конечно, важно не заигрываться в интересные задачи и не забывать о реальности.

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

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

Как повышать людей в корпорациях В больших технологических компаниях любая попытка повышения влечет за собой кучу политики. Чаще всего оно проявляется следующим образом – повышение легко согласуют тем, кто работал над заметными для всей компании проектами, но очень сложно тем, кто занимался менее волнующими, но не менее важными вещами. Я сам много сталкивался с аналогичной проблемой, когда лидил мобильщиков и фронтендеров. В соседних командах бэкендеры довольно легко получали повышения до Staff уровня, потому что занимались проектами, масштаб, важность и сложность которых были очевидны всем. Например, разносили всю инфраструктуру и данные из одного дата-центра в несколько. При этом настолько же выгодно выглядящих задач на клиентсайде практически не было, хотя ребята делали очень сложные и важные по-своему штуки. И периодически возникала дурацкая ситуация – нужно было либо заниматься тем, что действительно важно, но что будет очень сложно продать комитету по повышениям, либо брать яркий и заметный проект, который на самом деле принесет не очень много ценности. В статье дают несколько советов, как жить в таких условиях: 👉Важно повышать людей за разные виды вклада в общий результат, так как в итоге вам важны и те, кто умеет запускать сложные проекты, и те, кто обладает глубокими доменными знаниями и на ком держатся существующие системы, и те, кто выстраивает процессы в команде. 👉Как можно раньше привлекайте на свою сторону своих пиров, продавая им идею из предыдущего пункта. 👉Готовьтесь к обсуждению повышений с соответствующим комитетом/человеком заранее, подготовив всю нужную аргументацию и факты. 👉Если повышение случилось, расскажите о нем команде публично – это поможет людям откалиброваться в своих ожиданиях за что дается повышение.

Почему нельзя дать точную оценку большим проектам: статистическая модель Исходя из предпосылки о том, что при оценке времени на выполнение задачи люди чаще называют медиану, а не среднее значение, автор статьи построил интересную модель. А потом еще и проверил ее на не самом релевантном, но все же датасете. Основные выводы такие: 👉При складывании оценок задач друг с другом, что часто пытаются сделать в проектном планировании, ошибки накапливаются, и все становится очень плохо. 👉Время выполнения проекта зависит не от самых больших задач, а от задач с наибольшим уровнем неопределенности. Код модели вы можете покрутить сами на GitHub. А если захочется обсуждений – длиннющий тред на Hacker News по мотивам поста.

🪚Инструменты тимлида На неделе встретились лидовской гильдией. Хотели закопаться в роадмап тимлида и набрать листочков на прокачку начинающего лида, но все скатилось в обсуждение технических инструментов: таск-трекеров, тулзов для фокусировки и прочее. Приведу подборку по группам с комментариями. ✅Таск-трекеры Лидером оказался Todoist. Но как по мне, без разницы что использовать и вообще я цели на месяц веду снаружи, а тут операционные проекты, которые я делаю прямо сейчас. Для прокачки своей системы здорово поможет Дорофеев “Джедайские техники”. Он притапливает за свой инструмент, но можно набрать кучу дельных советов для построения собственной. 📝Заметки Всех обошел Obsidian. Если кто не в курсе, это маркдаун-редактор с плагинами. При помощи него можно сделать собственный репозиторий знаний а-ля маленькую Википедию. Тоже им пользуюсь, но считаю, что только для лидских задач этот инструмент – оверкилл. Возможно вам надо вести карточки сотрудников, проекты, ну может какие-то общие мысли. Из-за того, что структура заранее известна, можно обойтись даже Apple заметками. Еще в пуле инструментов оказались: - Confluence. Ну а почему бы не держать доку и рабочие заметки в одной системе? - Miro. Медитировать над организационной структурой в нем намного удобнее, чем в том же мардаун-файле. Отдельный плюс – удобство шаринга и совместной работы 🎯Фокусировка Часть ребят использует технику Pomodoro с фокусировкой интервалами 25-45 минут. Приложений и физических трекеров – бесконечность. Сам комбинирую технику с режимом “Do not disturb”. Мне помодорки помогают в двух случаях: - Сфокусировано поработать - Стартануть неприятное дело, которое прокрастинирую. Спустя одну-две помодорки разгоняешься и уже идет с удовольствием ✉️Почта / мессенджеры Планирую написать “Новейшие правила деловой переписки”. В ней будет одна страница, в которой будет капсом: не читать почту. У нас есть корпоративный мессенджер, туда сам залезаю раз в неделю. Я шел от идеи “если ответить на сообщение спустя час – мир не рухнет”, и вот что со мной стало… Если что, про почту наброс, туда залезаю тоже раз в неделю. Страдают только финансовые аналитики, которые подбивают ФОТ раз в квартал и пишут письма, а когда реакции нет – пытаются догнать в корпоративном мессенджере. Но в остальных 99% случаев все работает прекрасно. Основная переписка команд происходит в телеге. Знаю, что некоторые заводят отдельные аккаунты. Мне хватает папки. 📅Календарь Тут вообще скучно. День, а лучше два без встреч. Забитый час каждый день под обед. Встречи по возможности перевожу в переписку. Знаю радикальных ребят, которые встречи без агенды отменяют не глядя. Но я до этого еще не дошел. Только про почту такой смелый. — Есть еще всякие зумы, гугл таблицы, дропбоксы и прочее, но там вообще ничего интересного. Если есть мегатулзы неупомянутые выше, делитесь 😉 #тимлидство

Readability кода в Google В Google есть интересная практика, направленная на повышение читаемости кода – readability reviews. Каждый pull request ревьюится не только связанными с конкретным компонентом людьми, но и как минимум одним экспертом в языке, на котором написан код. Эксперт в этом контексте – инженер, который хорошо знает лучшие практики конкретного языка, рекомендуемые паттерны, принятые в компании стиль кода и список библиотек. С одной стороны, такой процесс добавляет жуткой бюрократии – вместо обсуждения действительно полезных вопросов, вы будете зарубаться с незнакомым вам человеком о том, насколько правильно названа какая-то переменная (намеренно утрированный кейс, я предполагаю, что такие вещи все-таки на уровне линтера закрываются). Но с другой стороны, в том числе благодаря этому подходу Google получает похожие друг на друга кодовые базы вне зависимости от конкретного отдела и продукта. А, значит, переход людей между проектами становится значительно проще.

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

McNamara fallacy Оказывается, есть специальный термин, которым обозначают практику принятия решения на основе одних только количественных данных и с отрицанием любых других сигналов – McNamara fallacy. Назван он так в честь министра обороны США, который пытался свести войну во Вьетнаме к чисто математической модели, и судить об успехе по соотношению числа убитых с обеих сторон. Когда его спросили, почему он не учитывает отношение к войне среди мирного населения, он ответил, что раз не может измерить его, то оно не важно. Напоминает большую часть попыток компаний уходить в хардкорную data driven культуру🤷‍♂️

Новость для опытных продакт-менеджеров Найден быстрый путь в Тинькофф — Product Manager Week Offer. Можно пройти онлайн-собеседование за выходные и присоединиться к команде уже через неделю. Дальше — создавать продукты для 30 млн пользователей, работать с данными, ориентироваться на свою экспертность и здравый смысл. Как работать, решать вам, — оценивают только результат. Оставьте заявку до 9 августа: https://o.tinkoff.ru/wo-product.2023