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

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

В статье рассказывается про альтернативную систему ценностей: Люди->Бизнес->Деньги, в которой главной целью компании становится реализация и развитие ее сотрудников, а все остальное – просто производные от успеха людей.

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

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

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

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

Есть два подхода к приоритизации:
1️⃣Собрать большой лист всего, что вы хотите сделать, отсортировать его, и стараться делать больше важных вещей и меньше не важных
2️⃣Отказаться от такого списка и делать только одну самую важную в настоящий момент вещь

С первым способом мы все работаем постоянно, и большинство им недовольны – ресрусов постоянно не хватает, куча разных задач висит в in progress, и движутся к завершению они очень медленно. Второй способ гораздо более контринтуитивный. Держите статью с его разбором.

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

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

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

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

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

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

Задавайте вопросы
Если вы видите, что вам приносят уже готовое решение, задайте заказчику несколько вопросов, которые помогут докопаться до исходной проблемы и контекста:
1. Какую проблему наших пользователей это решает?
2. Для кого конкретно мы решаем эту проблему?
3. Почему ты уверен, что эта проблема стоит решения?
4. Почему нужно решать ее именно сейчас?
5. Как решение проблемы повлияет на цели команды/продукта (если они есть)?
6. Что еще надо учесть при реализации задачи?

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

Если вы хотите глубоко погрузиться в теорию ограничений, то рекомендую такую последовательность:
1. Цель, Элияху Голдратт
2. Цель 2, Элияху Голдратт
3. Теория ограничений Голдратта, Уильям Детмер (именно здесь дается подробный обзор всей методологии и инструментов)

Если вы хотите вкатиться побыстрее, то вот короткий воркшоп от нас со Стасом Цыгановым про наш опыт применения ДТР для поиска корневых причин проблем.

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

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

Если вы чувствуете, что вас слишком сильно завалило различными пожарами, проектами и обещаниями, то вам может помочь один из самых простых и действенных инструментов тайм-менеджмента – мартица Эйзенхауэра. Ключевая идея проста – разбейте весь свой бэклог на четыре категории:
1️⃣Срочное и важное
2️⃣Не срочное и важное
3️⃣Срочное и не важное
4️⃣Не срочное и не важное

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

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

Причина большинства проблем многих команд – это их тимлид. Знание частых антипаттернов может помочь вам не попасть в число таких команд. В статье разбираются три довольно часто встречающихся случая:
📌Слишком сильная декомпозиция и конвейерная работа над задачами
📌Переизбыток встреч по грумингу/планированию/ретроспективе
📌Чрезмерное увлечение диаграммами Ганта и проектными планами

Пару лет назад я написал шуточную статью «Как подсидеть тимлида». Но шутки-шутками, а кто-то подсиживает тимлидов на самом деле, и даже написал готовую инструкцию:
1️⃣Найти проблему в команде
2️⃣Начать ее исправлять, показав максимум инициативы и добившись результатов
3️⃣Пожаловаться вышестоящему руководству на то, что лямку самому тянуть приходится, а текущий руководитель не справляется
4️⃣Перейти решать проблемы в другой части компании и ждать, пока старый руководитель зафейлится
5️⃣Профит

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

Автор статьи предлагает кардинально упростить систему найма. Вместо того, чтобы оценивать кандидата по десяткам параметров, он сводит все к четырем базовым:
1️⃣Талант: способность создавать что-то новое, ум, креативность
2️⃣Выдержка: способность завершать то, что начал
3️⃣Эстетика: качество результата работы
4️⃣Репутация: наличие рекомендаций от бывших коллег

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

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

Команда безопасников обычно отвечает за три вещи:
📌Защита от утечек данных
📌Продуктовая безопасность
📌Поддержка пользователей по практикам безопасного использования продукта

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

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

Все знания, которые нужно получить новичку во время онбординга, можно разделить на две категории:
1️⃣Known unknowns
2️⃣Unknown unknows

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

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

Задача хорошего процесса онбординга – выводить вещи из второй категории в первую, а оттуда – в разряд known knowns. В статье предлагается неплохой подход к его организации, разделяющий все погружение на 4 стадии: первые 30, 60, 90 и 150 дней, и дающий критерии оценки успуха каждой.

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

Если у вас есть предложения по тому, как развивать канал и какие новые форматы попробовать – пишите в комментариях!

🐣Развитие тимлида
Как развивать свое продуктовое чутье
Как принципы помогают тимлиду отстраивать процессы в команде
Антипаттерны поведения тимлида

🐞Работа над качеством
12 принципов обеспечения качества в GitLab
Чем технический долг отличается от технического хлама

🛠Инструменты, гайды, чек-листы
Ментальные модели, помогающие принимать тяжелые решения
Таблица с карьерной лестницей для инженерной ветки развития
Что делать, когда заказчик не понимает, какую проблему он хочет решить

👨‍👨‍👦‍👦Работа с людьми
Как оптимизировать время, которое нужно новичку в команде, чтобы вкатиться
Лоу-перформеры не всегда мало работают, а иногда просто делают не то
Что такое микроконтекст, и как его избежать, чтобы команда была продуктивной
Причины, по которым сеньоры не могут раскрыться в вашей команде

📚Рекомендации по книгам
Цель, Элияху Голдратт
Цель 2, Элияху Голдратт
Теория ограничений Голдратта, Уильям Детмер
Принципы, Рэй Далио

Если дайджест вам понравился – ставьте ❤️, 👍 и 🔥. Благодаря этому я пойму, что собирал его не зря!

#digest

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

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

Пять лет назад мы с Виталиком Леоновым работали вместе в Авито. Я руководил мобильной разработкой, а он – бэкендом. Виталик – крутой инженер и технический руководитель, у которого очень многому можно научиться. Сейчас он – СТО в Skyеng, а параллельно ведет Telegram-канал "Тимлид Леонид", в котором делится разными тимлидовыми практиками и результатами их внедрения. Вот мои любимые посты:
Time to productivity новичков: замеряем по десятому пулл реквесту
Затраты на инфраструктуру в разных типах российских компаний
Как СТО вкатиться в новую компанию
Эволюция тимлида

Подписывайтесь, Виталик фигни не посоветует!

Приоритизация – это не просто аналитический процесс. Очень часто к любым попыткам разложить задачи по RICE, Kano или другим фреймворкам, начинает примешиваться политика. В статье собрали подходы, которые помогают и не работают в таких случаях:
❌Просить стейкхолдеров коллективно приоритизировать длинный список задач
❌Обучать всех алгоритмам приоритизации и процессам разработки
❌Настраивать модельку в спредшите и ожидать, что она все объяснит
✅В явном виде распределить ресурсы по нескольким верхнеуровневым категориям
✅Собирать у каждого стейкхолдера короткий список их ключевых потребностей
✅Использовать разбитие задач по категориям «сейчас»/«следующая»/«никогда»
✅Заранее продумывать возможности аутсорса части работы