Все вокруг повторяют мантры про «не сдаваться», хакатоны и борьбу с техническим долгом. Эти слова звучат правильно — но почему тогда команды, которые им следуют, часто буксуют на месте? Может, дело не в мотивации, а в том, что мы слепо копируем сценарии, которые давно не работают? Пора выйти за рамки привычного.

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. Публикую перевод интересной статьи для техлидов от технического консультанта Авива Бен-Йосефа, автора книги The Tech Executive Operating System.

«У нас никто никогда не сдаётся!» «Посмотрите, какой хакатон мы провели!» «Мы жёстко закладываем время на борьбу с техдолгом».

На первый взгляд — правильные и вдохновляющие лозунги. Но на деле это просто рекомендации, которым имеет смысл следовать… если вы хотите управлять посредственной командой.

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

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. 

Сегодня — перевод и разбор классной статьи инженера, технического директора и основателя стартап-инкубатора Limbe Labs и лаборатории Red Hat Джереми Брауна. Он рассказывает о том, как эффект IKEA (тот самый эффект, когда мы особенно ценим то, что сделали сами) может работать, и как иногда он больно бьёт по управлению изменениями.

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

Что будет в этой статье:

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями и практиками про управление людьми и командами. Твёрдо верю: самый эффективный путь к прокачке менеджера — это не MBA и не менторство, а хорошая книга, применённая на практике.

В этой статье — системная подборка на год вперёд: 12 модулей по 2-3 книги в каждом, каждый месяц — новая управленческая компетенция. Если пройдёте весь путь, начнёте сильнее и глубже разбираться в менеджменте, чем 90% руководителей, с которыми мне доводилось работать.

Погнали! Первый модуль — про то, как учиться и не сойти с ума.

• Как выглядит API для работы с push-уведомлениями. Рассмотрим схему доставки push-уведомлений и то, где в этой схеме могут возникать потери. 
• Как решили бороться с потерями в Яндекс.Почте — об очереди push-уведомлений.
• Как логировать и какие еще сложности могут встретиться.

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

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

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

Всем привет! Меня зовут Егор Толстой, я руковожу кластером App Platform в Авито. Мои команды в основном занимаются разработкой внутренних продуктов, инструментов и процессов — тем, что принято называть платформенной разработкой.

Год назад я рассказывал в этом блоге, как мы внедрили и используем performance review. Тогда я упоминал, что мы смотрим на него как на индикатор пользы, которую приносит компании каждый отдельный человек. Понимать это важно и полезно. Это помогает ответить на вопрос «насколько Вася молодец по сравнению с Петей?» и определить, какую премию кому выплатить. Но когда мы переходим на уровень команд, всё становится сильно интереснее. Здесь важно оценить конкретный результат команды и его влияние на успех компании. Высокое среднее значение перфоманса всех членов команды совсем необязательно значит, что команда достигла крутых результатов. Какая-то корреляция точно присутствует, но для оценки фактического вклада команды в успех компании этот инструмент использовать нельзя.

Для решения этой и ряда других проблем мы в Авито используем метод OKR — Objectives and Key Results. Он позволяет установить дерево понятных и легко измеримых целей во всей компании, связать результаты различных команд друг с другом и добиться достижения желаемых результатов.

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

1. Работает.
2. Ничего не ломает, в том числе код, который написали ваши коллеги.