Про плоскую структуру коммуникаций

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

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

Can I ask a favor of you? Even though we have layers in our reporting structure, I am paranoid about introducing layers in our communication structure. We should strive to keep as much communication as possible within one degree of freedom. So if you ever feel like you have to go through someone else to get your job done, let me know.

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

Что ожидается от топ-менеджеров

1️⃣Ратифицировать решения

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

2️⃣Обеспечивать соблюдение ценностей и культуры компании

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

Чем полезны скрам-мастера

В Вастрик Клубе обсуждают, кому и когда вообще пригождался скрам-мастер. В целом все по классике:

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

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

Как сделать стратегию читаемой

Каждый раз, когда я пишу стратегию по заветам книги "Хорошая стратегия, плохая стратегия", я получаю документ со следующей структурой:

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

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

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

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

Как может выглядеть идеальный процесс обучения

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

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

Вот основные идеи:

👉В процесс обучения на своем проекте можно добавить элементы направляющего обучения как раз с помощью AI, который знает все про текущий уровень знаний человека, его интересы, и имеет доступ к происходящему на компьютере. Условно говоря, начинаете делать какой-то проект в новой области, а AI сразу же в режиме диалога дает релевантные подсказки и кусочки нужной теории, как в виде текста, так и в виде интерактивных демок, где это имеет смысл.
👉В тех случаях, когда требуется классическое обучение – скажем, при чтении какого-то учебника, такой AI может учитывать контекст проекта, над которым вы работаете, подсказывать, на какие куски теории обратить внимание, и приземлять ее на релевантные примеры. А в идеале – строить персонализированный learning track.
👉Доказанный способ сохранить новые знания в долгосрочной памяти – регулярно к ним возвращаться. AI может существенно улучшить опыт работы с Anki-карточками, периодически модифицируя и миксуя задаваемые вопросы, подстраиваясь под то, сколько времени вы готовы выделить на повторение в каждый конкретный день. Кстати, в самой статье приведены результаты офигенного эксперимента, показывающего реальную ценность repetition-based learning.

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

Рекрутеров можно заменить броском монеты

Ребята, которые делают сервис мок-собеседований interviewing.io провели офигенный эксперимент. Они попросили 76 технических рекрутеров отсмотреть по 30 резюме, и ответить на два вопроса:

1️⃣Позвали ли бы вы этого кандидата на собеседование?
2️⃣Какая вероятность того, что этот кандидат пройдет техническое собеседование?

Ответы рекрутеров сравнивали с реальными данными о том, с каким успехом эти кандидаты проходили мок-интервью. При этом отдельные рисерчи уже показали высокую корреляцию между прохождением таких типов интервью и последующим наймом. Короче, выводы такие:

👉Рекрутеры правильно решают пригласить кандидата на интервью только в 55% случаев. По сути, аналогично броску монеты.
👉Кандидаты, которым рекрутеры дали 0-5% вероятность прохождения интервью, на самом деле успешно прошли его в 47% случаев.
👉Кандидаты, в успешности интервью которых рекрутеры были уверены на 95-100%, прошли интервью только в 64% случаев.
👉В среднем разница в оценке вероятности прохождения интервью для одного и того же кандидата между двумя рекрутерами – 41%.
👉Декларируемые рекрутерами причины отказа от резюме не соответствуют реальным предикторам отказа.
👉Обученные на коленке ML-модели показали заметно более точные результаты в оценке резюме.

Расскажите в комментариях, почему, даже при таком раскладе, вы все еще подключаете рекрутеров в качестве фильтра входящего потока резюме.

Как работать с друзьями

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

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

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

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

Подборка книг по продакт-менеджменту

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

👉Chrossing the Chasm, объясняющая, как выглядит цикл адопшна новых продуктов и технологий.
👉Escaping the Build Trap, про то, как работают фиче-фабрики, и как это прекратить.
👉Sprint, хороший фреймворк, с помощью которого всего за неделю вы можете получить работающий прототип своей идеи.

Как управлять bottleneck командой

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

На увеличение time to market влияет не только сам факт обособленности команды, но еще и то, что с ростом компании такие команды не всегда растут теми же самыми темпами. А это влечет за собой рост количества клиентов, размазывание ресурсов команды еще более тонким слоем, растущий бэклог невыполненных задач и еще более растущий TTM.

Несколько советов из статьи для менеджеров таких команд:

👉Проблемы такого рода часто растут из архитектуры. Попробуйте привлечь нескольких независимых людей, чтобы они со стороны оценили вашу ситуацию и подсветили бы какие-то слепые пятна.
👉Найдите способ держать ваш менеджмент в курсе ситуации в команде, того, по каким причинам вы не справляетесь со всеми запросами, и как выстраиваете приоритизацию. Вам нужно получить защиту от так называемого stakeholder bullying, когда разные менеджеры с громкими тайтлами будут пытаться продавливать вас, чтобы их фича вышла в топ бэклога.
👉Подумайте, есть ли возможность перейти из сервисной в платформенную команду – и вместо выполнения работы за других людей давать им удобную платформу, которой они смогут пользоваться целиком без вас.
👉Рассмотрите подход внутреннего open source, когда люди из других команд могут сами делать нужные им фичи, а вы только принимаете PR.
👉Установите режим дежурств, в котором все входящие запросы к команде в каждый момент времени направляются строго на одного человека.

Про фидбэк луп

Одна из главных причин фрустрации при переходе из индивидуального контрибьютора в лиды в резком увеличении длины цикла обратной связи о том, что ты молодец, и предпринятые тобой действия влияют на итоговый результат. Когда ты разработчик все сравнительно просто. Фидбэк лупов много, и все они довольно короткие:

🔄Написал код – скомпилировал – увидел результат
🔄Доделал таску – отправил PR на ревью – получил комментарии
🔄Смерджил ветку в мастер – дождался релиза – потрогал новую фичу руками и показал своей маме

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

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

Как проджекту и продакту получить бриллиантовый оффер

Почти 80% проджектов и продактов не могут найти себе нормальную работу с отличной зарплатой и адекватным начальником. А всё потому что не умеют правильно оценивать свой опыт, проходить собеседования и чётко формулировать зарплатные ожидания.

Из этого рождаются абьюзивные отношения с говнокомпаниями, которые не хуже Марата Башарова бьют под дых и роняют всё профессиональное либидо.

Бывает ли по-другому?
Карьерный Цех доказывает, что ДА.
Ребята уже давно закрывают вакансии в ТОПовых компаниях России и точно знают, каким должен быть сотрудник, чтобы ему выкатили идеальный оффер.

Карьерный Цех берёт проджекта за руку, учит правильно искать работу и приводит к вакансии мечты.
Эксперты сопровождения научат правильно проходить собеседования, укажут на пробелы в hard- и soft-skills и приведут за руку в тусовку, где каждый найдёт крутой нетворк.
Знания о поиске работы, которые даёт Карьерный Цех, будут работать и через 5, и через 10, и даже 20 лет.

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

Реклама. ИП Федоров Е.П.
ИНН 532008901966

Культурный контракт с сотрудником

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

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

Вот некоторые из пунктов, которые в такой культурный контракт включает автор статьи:

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

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

Бреслав и Ложечкин про собеседования и найм

Подкастная пятница уже становится традицией канала! Сегодня принес вам релиз нового выпуска подкаста "Бреслав и Ложечкин", в котором подробно разбирается и то, как можно нанимать людей в стартапы, и то, в чем состоят минусы и плюсы сложного процесса, который сейчас работает в Амазоне.

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

Про документацию

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

Факторы, говорящие о том, что документация нужна:

👉Большая потенциальная аудитория читателей. Условно говоря, документация для публичного фреймворка имеет намного больше смысла, чем внутреннего класса, который за все время увидит только три человека.
👉Стабильность. Чем меньше меняется система, и чем более она стабильна, тем меньше костов на поддержание актуальной документации, тем больше в ней смысла.
👉Низкая цена затрат на документацию. Если для того, чтобы написать доки, вы откладываете какие-то важные продуктовые задачи, приносящие ценность бизнесу – скорее всего, вы делаете что-то не так.

Вместо траты время на документацию, можно рассматореть альтернативные способы добиться того же результата:

👉Упрощать систему. Простому коду и архитектуре не нужна документация.
👉Живые коммуникации: парное программирование, рассказы про устройство системы, разговоры за обедом.
👉Тесты. Тут все понятно – при изменении системы приходится менять и тесты, поэтому они легко сохраняют свою релевантность.

Как стратегия связана с OKR

Один из признаков плохой стратегии по Румельту:

Mistaking goals for strategy: Many bad strategies are just statements of desire rather than plans for overcoming obstacles.

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

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

Про проблемы рабочей эмиграции

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

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

👉Разбор актуальной статистике Евростата про жизнь в Европе: безопасность, доходы, уровень счастья и отказы во въезде.
👉Что не так с Нидерландами: тут база, с которой я в целом согласен.
👉Про обладание несколькими ВНЖ: почему это легально, зачем это нужно, и откуда их взять.

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