Собирательство, рыбалка, золотоискательство

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

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

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

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

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

Публикуем второй кейс!

👉Кейс #2: +40% к зарплате или провалить проект

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

Что вы будете делать? Делитесь в комментариях! И не забывайте голосовать за лучший вариант 👍🏻

Если хотите разобрать ваш кейс, пишите в специальный бот @TeamleadDoNotSleepBot.

Алгоритм работы с людьми с плохим перфомансом

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

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

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

Founder Mode

Весь англоязычный твиттер на прошлой неделе обсуждал новое эссе Пола Грэхема, "Founder Mode". В чем суть – по умолчанию считается, что в успешных стартапах, которые вошли в фазу роста, фаундеры переходят в режим менеджеров. Они делегируют большие зоны ответственности нанятым топ-менеджерам, перестают сами погружаться в детали, и совсем забывают о продукте, который их компания разрабатывает. Из-за того, что нанятые менеджеры в первую очередь заинтересованы в личном успехе, а не в успехе компании, постепенно принимается ряд субоптимальных решений, которые делают когда-то эффективную команду чем-то медленным, неповоротливым, и постепенно проигрывающим конкурентам.

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

Ну а все споры ведутся вокруг того, где грань между действительно полезным founder mode, и чайка-менеджментом.

Еще несколько связанных ссылок:
👉Твиттер-тред про то, в чем именно заключается полезный founder mode
👉Подкаст с фаундером Airbnb, где он рассказывает свой опыт трансформации компании в пресловутый founder mode

Кстати, мы выложили новый кейс в "Тимлид не спит". В этот раз разбираемся, как быть с лоу-перформером на испытательном сроке. Приходите обсуждать!

Коллаборативный подход к найму

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

Ловушка гибкой конфигурации

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

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

Как работать с зависимостями между командами

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

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

Менеджеры-антипаттерны

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

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

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

Запугивающие вопросы

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

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

❌Я просил тебя это делать?
❌Кто дал тебе право принимать решение?
❌С чего ты взял, что это будет работать?

Вот более корректные варианты формулировок:

✅Из каких вариантов решения и как ты выбирал?
✅Какие факторы повлияли на то, как ты принимал решение?

Как группа становится командой

Отличная статья от Дмитрия Болдырева, разбирающая каждый из этапов формирования команды – forming, storming, norming, performing, на примере монтажной бригады, прокладывающей ЛЭП где-то в тайге. Всю статью пересказывать не буду, поделюсь лишь одной частью – список вопросов, на который у группы должны быть ответы, чтобы она могла функционировать как нормальная команда:

👉Предмет деятельности (чем мы будем заниматься?)
👉Цели (зачем мы всё это делаем и каких именно результатов планируем достичь?)
👉Стратегия (каким образом, за счёт чего мы добьёмся поставленных целей?)
👉План (что, когда, в какой последовательности будем делать?)
👉Рабочие процессы (как что должно происходить?)
👉Роли (кто за что будет отвечать, кто конкретно, что именно будет делать?)
👉Регламенты взаимодействий (кто, что, кому передаёт, когда, в каком виде и т.д.?)
👉Стандарты качества (какое выполнение работы будет считаться хорошим, а какое плохим?)
👉Способы контроля качества (как мы будем проверять и оценивать выполненную работу?)
👉Система ответственности и вознаграждений (что получат участники, если добьются или не добьются ожидаемых результатов; как индивидуальных, так и групповых?)
👉Правила принятия решений (какие решения могут приниматься индивидуально, какие только группой и, если группой, то по какому принципу – единогласно, большинством или каким-то иным способом?)
👉Нормы поведения (какое поведение приветствуется, а какое нет?)
👉Система статусов, она же внутренняя иерархия (кто какой имеет вес и влияние?)
👉Лидерство (кто будет всем управлять, кого мы будем слушаться?)

Если предпочитаете смотреть, а не читать, вот тот же материал в видеоформате.

Как Leetcode влияет на прохождение интервью

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

👉В целом корреляция между решением задач на Leetcode и успешным прохождением интервью довольно сильная.
👉На силу корреляции влияет количество решенных задач и их сложность. При этом количество влияет только до определенного порога, после 500 задач эффект перестает расти так сильно.
👉Рейтинг на Leetcode не коррелирует с успешностью интервью.
👉Прорешивание сложных задач в два раза эффективнее, чем задач средней сложности. Каждые 50 сложных задач ведут к повышению успешности прохождения интервью на 7%.

Про зомби-процессы

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

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

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

Как давать субъективный фидбэк

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

Несколько правил, которые вам помогут:

👉Вообще забудьте о том, что фидбэк обязан быть объективным, это не так. Любая обратная связь от другого человека так или иначе субъективна. Главное, чтобы она была направлена на пользу общему делу.
👉Как обычно, по максимуму фокусируйте обратную связь на работе, а не на личности. Это касается как обсуждения нежелательного поведения, так и результатов – вам не надо просить человека меняться, вам надо объяснять ему, как его работа влияет на общий результат.
👉Чтобы дополнительно показать, что вы пришли поддержать, а не обвинять, подсветите роль окружения и внешних факторов в нежелательном поведении.
👉Расскажите, какой вы бы видели работу человека в идеальном мире, фокусируясь на конкретных изменениях.

База про компенсационную модель

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

👉Определяется иерархия ролей, состоящая из функции (маркетинг, разработка, дизайн), подфункции (разработчик, qa, sre), карьерного трека (менеджер или индивидуальный контрибьютор).
👉Для определения уровня оплаты каждой из клеточки получившейся матрицы проводится бенчмаркинг – либо через закупку отчетов у специализирующихся на этом компаний, либо с использованием рыночных данных с того же Glassdoor.
👉Расчитываются вилки – обычно от 80% до 120% от мидпойнта. Вилки соседних уровней чаще всего идут внахлест.
👉На все это накладываются региональные коэффициенты, если компания работает сразу в нескольких странах или районах.

Что делать, когда компания вам не подходит

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

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

Кент Бек про проектный треугольник

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

Как Scrum изматывает команды

Месяц не будет полным, если хотя бы раз не побухтеть на Scrum. В этот раз статья про то, как разные особенности фреймворка постепенно изматывают команды разработки.

👉Спринты никогда не кончаются. Команда работает постоянно в условиях фиктивных наступающих дедлайнов, важных лишь ради самого процесса. Времени для отдыха нет, уровень стресса не снижается. А длительное нахождение в условиях стресса – сильный предиктор проблем со здоровьем.
👉Роли и нагрузка в скраме предопределены, что ограничивает автономию каждого участника команды в рамках спринта. Меньше автономности – меньше контроля и, опять же, больше стресса.
👉Скрам подбивает к тому, чтобы оценивать задачи без достаточного уровня подготовки и уверенности в них. Настоящее понимание сложности приходит только тогда, когда начинается работа. Искуственное разделение подготовки и разработки чаще вредит.

Новые выпуски тимлидских подкастов

За последние пару недель вышло еще несколько полезных выпусков менеджерских подкастов, которыми хочу с вами поделиться:

👉Подлодка про джунов: про то, что в 2024 году происходит с обучением начинающих разработчиков и вообще входом в IT
👉Бреслав и Ложечкин про менторство: как найти ментора и получить от него максимальную пользу для своей карьеры
👉Три тимлида заходят в бар про микроменеджмент: когда погружение в детали является нормой, а когда – излишней тягой к контролю
👉КОДА КОДА про внутренний пиар: как сделать так, чтобы про успехи вашей команды знала вся компания

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

👉Кейс в канале