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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Джунов нельзя заменять на AI

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

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

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

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

Почему data-driven подход неоптимален

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

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

Что почитать тимлиду

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

👉Dr. James Stanier «Become an Effective Engineering Manager»
👉David Marquet. «Turn the Ship Around»
👉Ю. Гиппенрейтер. «Большая книга общения с ребенком»

Обеспечение качества зависит от контекста

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

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

👉Essential domain complexity – неотъемлимая сложность предметной области, в которой работает программа. У интернет-магазина диванов она не очень высокая. У HFT системы, скорее всего, наоборот.
👉Scalability complexity – сложность, создаваемая большим количеством пользователей системы
👉Team maturity – уровень навыков команды и знания предметного контекста

В зависимости от того, попадает ли ваш продукт в ситуацию "low essential domain complexity, high scalability complexity, low team maturity" или "high essential domain complexoty, low scalability complexity, high team maturity", подходы к тому, как обеспечивать качество, будут очень сильно отличаться. Поэтому слепо копировать успешные кейсы других компаний, не понимая, чем их ситуация отличалась от вашей, нельзя.

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

Очень рекомендую статью для тех, кто хочет уложить в понятную модель свои мысли про то, как обеспечивать качество.

Сбор тем и вопросов для большого исследования тимлидов

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

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

👉Сколько зарабатывают тимлиды в зависимости от размера команды
👉Что замотивировало тимлидов уйти из разработки в менеджмент
👉Средний срок жизни сотрудника в команде

Интересы тимлида и рекрутера не совпадают

На Хабре выложили аналитику по зарплатам рекрутеров. И все бы ничего, но есть там несколько интересных моментов:

👉Зарплаты линейных рекрутеров почти всегда зависят от KPI, которым выступает количество закрытых вакансий
👉24% опрошенных считают, что для повышения зарплаты им надо закрывать больше вакансий. Только 12% – что нужно улучшать сорсинг кандидатов.

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

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

Как общаться прямо, но не быть грубым

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

Про эффект Линди

Эффект Линди говорит о том, что чем дольше что-то существует, тем больше вероятность, что это что-то будет существовать и дальше. Например, если какой-5 фреймворк был популярен 5 лет, то он, скорее всего, будет популярен и следующие 5 лет.

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

Еще одна область, где эффект Линди вполне применим – рост команды. Скорее всего, вы сможете вырастить команду в два раза, не сильно перестраивая культуру, процессы и оргструктуру, но вот вырасти на порядок так уже не получится.