В продолжение вчерашней темы про организационные структуры еще одна статья. В ней организационный дизайн проводится с применением фреймворка Team Topologies из одноименной книги. Самое интересное там то, что инженерных лидеров – архитекторов, руководителей функций, директоров, рассматривают как отдельные команды с выделенной ролью. Условно, вместо того, чтобы рассматривать каждого Engineering Director как отдельную единицу, ответственную за свою область, они в первую очередь работают как команда с едиными целями и задачами.

Короче, забирайте в копилку статей, повышающих насмотренность.
https://adhoc.team/2022/01/04/crafting-leadership-teams-for-fast-effective-information-flow

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

Ключевая идея – люди всегда узнают, кто сколько в команде зарабатывает, поэтому правила должны быть едины и прозрачны для всех.
https://review.firstround.com/A-Counterintuitive-System-for-Startup-Compensation

В крупных инженерных компаниях менеджерский карьерный трек – это только одна из веток развития. Вторая, равная по количеству уровней и компенсации – техническая. В статье Principal Engineer из Амазона делится тем, как устроен процесс повышения до принципала и какие ответственность и влияние на компанию появляется с этой лычкой.

Чтобы зацепить ваше внимание, краткое описание условий для повышения:
- Наличие подробного документа от твоего менеджера, описывающего твои достижения
- 5-7 людей выше по уровню, подписавшихся под этим документом и оставивших свой фидбэк
- Два ассессора, которые детально изучили все, что ты делал на работе: дизайн документы, код, комментарии на кодревью и доклады
- Аппрув от специального комитета
- Аппрув от еще более специального комитета самых мощных инженеров
https://medium.com/geekculture/belonging-to-amazons-principal-engineering-community-aa8059152fbf

1-1 встречи все уже давно взяли себе на вооружение. Но есть несколько интересных кейсов, которые хорошо решаются встречами другого вида: 1-1-1. У «тройничков» есть своя групповая динамика, которой стоит уметь пользоваться.

В статье рассматривается несколько конкретных кейсов «тройничков»:
1. Смена руководителя у сотрудника
2. Временный перевод человека из проекта в проект
3. Ввод в кроссфункциональную команду новой роли, ожидания от которой не понятны
4. Пропушивание решений с помощью третьего человека
https://davidxiang.com/2021/12/30/use-more-1-1-1s/

Многие разработчики и тимлиды становились жертвой ошибки «я все сделаю сам». Уверен, что у вас тоже были похожие кейсы – вы брали на себя большой проект, исчезали с ним на продолжительное время, отделываясь статус-апдейтами вроде «я рисерчу», а потом оказывалось, что вы изначально решали не ту проблему. Или изобрели велосипед. Или получившееся решение можно было сделать в разы проще. Короче говоря, если бы вы работали над проектом не в одиночку, этих проблем бы не случилось.

В статье хорошо разложены причины такого поведения и конкретные способы борьбы с ним.
https://www.thezbook.com/the-biggest-mistake-i-see-engineers-make/

RACI-матрица – супер простой и дико полезный инструмент для того, чтобы достичь прозрачных договоренностей о ролях и ответственности в проекте. Работает он следующим образом – вы выделяете конечный набор обязанностей в проекте, а затем каждому вовлеченному в него человеку назначаете одну из ролей:
- Responsible – тот, кто физически выполняет работу
- Accountable – тот, кто отвечает за результат и аппрувит его
- Consulted – тот, с кем надо обсудить решение и принять мнение во внимание
- Informed – тот, кому надо сообщить по факту принятия решения

Я использовал эту матрицу для очень разных задач:
- Описать роли в релизном процессе
- Договориться, кто что делает при организации большого командного планирования
- Спланировать крупный рефакторинг, затрагивающий несколько команд

В общем, советую, это один из инструментов, которыми должен уметь пользоваться любой тимлид.
https://habr.com/ru/company/timeweb/blog/597281/

На прошлой неделе у нас разгорелся хороший такой холивар в комментариях к материалу про систему определения зарплат в Facebook. Вдогонку к этому, ребята из стартапа ConvertKit поделились своим подходом к определению финансовой компенсации для своих сотрудников.

Тезисно:
- Все получают одинаковые зарплаты в зависимости от грейда, основанные на данных от Radford;
- Зарплаты одинаковы вне зависимости от локации;
- Компенсируется 5% от зарплаты, если сотрудник откладывает их на пенсионный счет;
- 52% от профита компании выплачивается всей команде в виде performance бонуса. Топы получают 8%, владельцы – 40%;
- Грейд не влияет на бонус. 75% разделяется поровну между всеми, 25% зависит от времени работы в компании;
- Сотрудники получают доли в компании;
- Все финансовые данные абсолютно открыты для команды.

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

Когда я впервые стал тимлидом, я попросил руководителя посоветовать мне каких-нибудь книг по теме. Одной из них было «Руководство фасилитатора» Сэма Кейнера. Это очень крутая книга для всех, кто хочет построить себе системную картинку про принципы работы групповой дискуссии и набрать десятки инструментов по управлению ей. Максимально рекомендую!

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

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

Шесть признаков перфекциониста:
- Страх провала
- Подход «все или ничего»
- Не умеет делегировать
- Часто прокрастинирует
- Слишком сильно сфокусирован на результате
- Тяжело принимает конструктивную критику

Подробный рассказ про эти шесть признаков и подходы к управлению такими людьми

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

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

Сейчас онбординг у меня состоит из следующих больших кусков:
📹 Видеокурс, где простым языком объясняется устройство различных компонентов: компилятора, IDE, билд тудтнга и других штук
🎛 Trello-доска с задачами на погружение в компанию, разными материалами для изучения и ключевыми людьми, с которыми нужно познакомиться
🎯 Цели на период онбординга, которые составляются вместе с новичком спустя пару недель работы
🤝 Наличие ментора, который сопровождает новичка в процессе онбординга

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

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

Максим Шульга поделился в твиттере подборкой полезных ссылок про проведение хороших one-on-one встреч и своими мыслями по теме. Прикладываю сюда его материалы и добавляю несколько от себя.
🆕 О чем поговорить на самой первой встрече
💣 Развенчание мифов про большинство причин проведения 1-1
📖 Нереальные 132 вопроса для 1-1
🤭 Почему надо стремиться задавать неловкие вопросы
🚨 Признаки плохих 1-1
🔥 Подробный гайд по проведению 1-1 от Spotify

Вокруг Scrum всегда велось бесконечное количество холиваров. Покажите мне любую команду, которую затащили на обучение скраму, и я смогу предсказать вопросы, про которые буду вестись споры:
🤔Как считать сторипойнты и зачем они вообще нужны?
😡Зачем проводить ретроспективу каждую неделю, если ее ценность со временем падает?
🤬Зачем вслепую следовать всем указаниям скрама, если на команду хорошо ложатся другие процессы?

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

А вообще, аккуратнее с чистым скрамом, как и с любым другим карго-культом.

Давайте сегодня поговорим про платформенную разработку! Напоминаю, что это общий термин для обозначения инженерных команд, которые делают внутренние продукты для других разработчиков. Если 10 лет назад такие команды были только в самых крупных инженерных компаниях вроде Google и Netflix, то сейчас они появляются практически везде.

Я отвечал за платформенную разработку клиентсайда Авито в течение нескольких лет. Мы отвечали за создание инструментов, библиотек и окружения, которые снимали бы головную боль и уменьшали рутину у фронтендеров, бэкендеров и мобильных разработчиков. Основные особенности, которые определяют работу над платформой:
👻Каждый разработчик – сам себе продакт-менеджер, поэтому требуется обучение базовым продуктовым практикам;
🌩Платформенным командам нужно вкладываться в разработку стратегических долгостроев, выхлоп от которых виден не сразу. Поэтому конфликты с продуктовыми командами неизбежны;
🤔Частично из-за второго пункта, частично из-за технологически сложного домена, а частично из-за необходимости частых рисерчей, не каждой команде получается показывать видимые результаты. Из-за этого ее тимлиду регулярно приходится обосновывать ее ценность;

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

Я набрал себе несколько менеджерских книг для прочтения в ближайшие месяцы. Давайте такой уговор – я делюсь ими в канале, а вы:
1. Расскажете свой отзыв в комментариях, если читали что-то из них
2. Поделитесь своими планами по чтению

📚Мой список:
The Art of Action
Working Backwards
High Output Management
Шум. Несовершенство человеческих суждений
Азбука системного мышления

Всем привет.

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

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

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

Ребята из 🇺🇦, держитесь ❤️

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

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