22009
Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами. Размещение рекламы: @tanyasanovna Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Про доверие к исследованиям
Я часто напоминаю и себе, и всем остальным, что сам факт существования опубликованного исследования, пусть даже прошедшего peer review, и с наличием ссылок на него из других исследований, вообще не показывает, что ему можно доверять. Если вы действительно хотите на него опираться, недостаточно просто прочитать вводную часть и выводы, нужно внимательно вкатиться в методологию и понять, а доверяете ли вы ей. Ну а вообще – опираться на единичное исследование в целом такое себе, и по-хорошему надо искать появления мета-исследований.
На прошлой неделе произошел еще один скандал, который этот тезис подтверждает. В чем суть – есть исследование 2014 года под названием "The Impact of Corporate Sustainability on Organisational Processes and Performance". Его авторы заявляли, что компании, которые серьезно относятся к социальной ответственности, не только делают добро, но и зарабатывают больше денег для акционеров, причем таких сверхдоходов аж 40%, и это видно на горизонте 20 лет. Это исследование стало безумно популярным – 6000 ссылок, цитирование разными топ-менеджерами, финансистами и политиками. Но оказалось, что в нем есть ряд фатальных недостатков:
👉Ключевой результат, помеченный как статзначимый, на самом деле не был таким.
👉Описанный в исследовании аналитический метод на самом деле не соответствовал тому, что делалось реально.
👉Часть важных статистических проверок просто не были проведены.
👉Независимая попытка воспроизвести исследование провалилась.
👉Результаты не проходят стандартную проверку на ошибку выжившего – потому что для него отбирались только компании, дожившие до наших дней.
Причем с академической системой все настолько плохо, что даже эти выявленные проблемы не повлекли за собой ни отзыв исследования, ни публикацию критики в оригинальном журнале, ни принятие его авторами этой критики. Поэтому не забывайте, что за любым рисерчем стоят люди, со своими когнитивными искажениями, желанием подтвердить свои личные убеждения, и собственной агендой.
Как AI влияет на формирование навыков программирования
52 джуна разделили на две группы, каждая из которых решала одинаковую задачу, и после этого отвечала на тестовые вопросы по теме:
1️⃣Группа без доступа к AI. Они часто ошибались в задаче, но лучше справлялись с итоговым тестом. Получается, что в процессе работы они учились.
2️⃣Группа с доступом к AI. Эти лучше справлялись с прогарммированием, но по итогу ничего не поняли.
Какие дополнительные интересные выводы появились:
👉Хуже всего справились с заданиями те, кто делегировал AI и решение задачи, и дебаг, и не пытался вникнуть в суть решаемых проблем.
👉Участники, которые помимо генерации кода, использовали AI, чтобы понять, как и почему он работает, справлялись существенно лучше.
Короче говоря, все ожидаемо – если вы просто бездумно будете вбивать задачи в агента, то ничему не научитесь – поэтому внедрять джунам AI нужно не бездумно, а подкреплять его нормальными инженерными практиками, помощью коллег, и совместным обучением с AI.
Как LLM помогают мышлению
Про то, как LLM влияют на нашу способность мыслить и рассуждать, обычно говорят в негативном ключе. Но это не всегда так.
Как и у автора статьи, многие идеи и принципы, существующие в моей голове, сходу довольно плохо облекаются в слова. Условно говоря, смотришь на какое-то решение, и понимаешь, что оно плохое – но вот ясно и четко объяснить, откуда это ощущение взялось, довольно сложно.
LLM хороши как раз в этом – в процессе диалога с автором собирать его расплывчатый набор мыслей, и превращать в понятные простые формулировки. Как результат, такие ясные формулировки проще докручивать, проверять на заблуждения, и развивать дальше.
Примерно похожий эффект есть и у письма – оно точно так же помогает неясное сделать ясным, и в процессе хорошо обдумать. LLM отличаются в лучшую сторону тем, что с ними этот процесс часто получается быстрее. А со временем, если вы регулярно используете их в таком формате, ваша собственная способность изъясняться ясно тоже может подрасти.
Как получать хорошие советы
Когда вы сталкиваетесь с проблемой или с областью, в которой плохо разбираетесь, один из самых эффективных способов быстрее в нее вкатиться – это поговорить с теми, кто уже проходил похожий путь. Вот несколько рекомендаций по тому, как повысить количество полезных советов:
👉Не бойтесь первыми писать незнакомым людям, у кого есть нужный опыт – многие в целом с радостью готовы делиться своим опытом.
👉Заранее понять, у кого будет прямо релевантный опыт – сложно. Помогает обращать внимание на тех, кто поработал на подходящей роли в интересной вам компании хотя бы пять лет.
👉Будьте конкретными и при первичном запросе, и когда готовитесь к звонку. При подготовке идеально написать короткий документ с вашим контекстом и конкретными вопросами, которые вы хотели бы обсудить – так собеседнику будет проще.
👉Вместо того, чтобы обсуждать конкретные решения, лучше всего просите собеседников проверить, что вы правильно понимаете проблему. Форма решений очень зависит от контекста компании, а вот проблемы у всех общие.
Как получать высокие оценки на performance review
Начнем с важного дисклеймера – don't hate the player, hate the game. Если в вашей компании проводится регулярный перфоманс ревью, и от него зависят бонусы и повышения, то стоит к нему относиться как к отдельному тренируемому навыку, который не всегда будет коррелировать с реальной полезностью вашей работы. Вы можете его игнорировать, но в чем смысл – вы чаще всего просто меняете свое время на деньги, и должны быть заинтересованы в том, чтобы курс был повыше.
Так вот, держите пачку действительно рабочих рекомендаций:
👉Активизироваться нужно вовремя. Если вы равномерно хорошо работаете весь квартал, это никому не интересно. А вот если показать повышенную полезную активность где-то за месяц до старта ревью, менеджер заметит ваш рост и вовлеченность. А последнее впечатление, как рассказывал еще Канеман, самое важное!
👉Будьте вежливым и приятным человеком и с менеджером, и с коллегами. Если вы перепрыгнете минимальную планку того, чтобы не обесценивать чужие идеи, не уклоняться от коммуникаций, и не относиться к просьбам о помощи как к наказанию, вы уже будете лучше большинства и стабильно получать от коллег высокие оценки. Ревью всегда субъективно, позтому приятный в работе человек выигрывает у неприятного, но более компетентного.
👉Решите хотя бы одну проблему за пределами своих обязанностей – поучаствуйте в собеседованиях, наладьте какой-то общий процесс, запилите библиотеку. И подготовьтесь об этом красиво рассказать в своем ревью, обязательно подчеркнув, что вклад сделан за пределами команды – это стандартный зеленый флаг для повышения.
👉Относитесь к слабым сторонам как к козырям. Хорошо знайте их, и старайтесь каждый цикл ревью показывать заметное улучшение хотя бы по одной. Например, в одном цикле ревью расскажите, что ваша слабая сторона – вовлечение в продукт, а в следующем покажите, как круто вы стали контрибьютить в PRD. Короче говоря, покажите маленькую победу над собой.
👉Смотрите на self review не как на отчет, а как на рекламу себя. Рассказывайте о себе, как будто выбиваете инвестиции на проект. Любая выполненная задача обязательно должна иметь понятный импакт и практически спасать компанию.
👉Не бойтесь явно писать, что оцениваете себя выше среднего и превосходите ожидания, объяснив, как именно (вот все эти пункты выше). Менеджеру проще согласиться, чем доказывать обратное.
В итоге с точки зрения вашего менеджера все выглядит так – у него есть супер-вовлеченный сотрудник, которого и все членв команды любят, который и приносит заметную пользу основному проекту, и успевает на стороне что-то сделать, да и сам понимает свою ценность. Ну как такому премию повышенную не дать.
Бреслав и Ложечкин про мечты и цели
На волне обдумывания своих личных планов на 2026 год, послушал последний выпуск Бреслава и Ложечкина на эту же тему. Какие две мысли мне запали в душу:
👉Стоит разделять мечты и цели. Мечты приносят удовольствие сами по себе, даже если вы никогда не приступите к ним. Нет ничего плохого в том, чтобы это удовольствие получить, а потом на них забить. Но надо отдавать себе отчет, что чтобы мечта превратилась в реальность, нужно собраться и начать ей заниматься – и тут уже пригодятся и цели, и планы.
👉К цели нужно относиться как к направлению, а не к ачивке. У достижения крупных целей есть неочевидный психологический эффект – вы можете не почувствовать счастья. Так получается, потому что мозг поощряет процесс движения к цели, и быстро теряет к ней интерес после. Так что счастье в самом пути, и в людях, которые находятся рядом с вами.
📊 Delivery Manager: станьте главным связующим звеном между бизнесом и разработкой!
Хотите выйти на новый уровень управления? Научитесь реалистично оценивать проекты, работать с метриками и эффективно управлять портфелем задач!
🔥 Приглашаем на 3 бесплатных вебинара курса «Delivery Manager» — познакомьтесь с программой обучения и преподавателями, задавайте вопросы и обсуждайте свои кейсы!
🔸 Вебинар 1: Почему ваши оценки проекта всегда ошибочны
📅 28 января, 20:00
Разберём, почему даже опытные менеджеры ошибаются в оценках — и как это исправить.
На вебинаре:
- поймёте, как особенности мышления влияют на планирование;
- сравните классический и Agile‑подходы к оценке;
- освоите инструменты: стори поинты, «майки», буферы рисков;
- проанализируете реальные кейсы и способы избежать срывов сроков.
🔸 Вебинар 2: Измеряя управляй. Метрики как инструмент DM
📅 5 февраля, 20:00
Узнайте, как превратить данные в систему принятия решений.
Что разберём:
- почему метрики — это не контроль, а управление доверием;
- как фреймворк PROJECT помогает говорить на одном языке с бизнесом, командой и заказчиком;
- пошаговую сборку системы контроля для устойчивости организации;
- типичные ловушки (гонка за показателями, «очковтирательство») и способы их обойти.
🔸 Вебинар 3: От проекта к портфелю: как управлять несколькими проектами?
📅 9 февраля, 20:00
Переходите на уровень Delivery Manager? Узнайте, какие инструменты и mindset вам нужны.
В программе:
- отличия управления портфелем от управления проектом;
- причины сложностей при переходе на новый уровень;
- почему привычные методы перестают работать;
- как сформировать новый набор инструментов DM.
Записывайтесь ➡️ OTUS.RU
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Стратегия — это ответ на один, но ключевой вопрос
Директор по продукту ВКонтакте Евгений Васильев про стратегию.
👉 Это рабочий инструмент, который собирается под решение конкретной рыночной задачи.
👉 Именно стратегия определяет, какая оргструктура вам нужна и на какие метрики работает команда.
👉Отсюда и простая логика: стратегия начинается не с идей и фичей, а с честного ответа на вопрос: какую бизнес-задачу мы решаем сейчас.
👉 Если стратегия не формулируется одним-двумя ясными предложениями, скорее всего, это еще не стратегия.
👉 В случае стратегии ВКонтакте - это перевод эпизодических пользователей в core-аудиторию за счет контентного и социального сценариев.
Начинайте митинги на пять минут позже
Редко кто заканчивает митинги на пять минут раньше обычного таймслота. Как результат, первые минуты следующего митинга несколько человек ждут, пока все добегут до нужной переговорки. Вместо этого попробуйте сделать простую вещь – назначайте все свои митинги на 5 минут позже обычного времени (12:05 вместо 12:00). Все участники точно скажут вам спасибо.
Прокрастинация, и как с ней справляться
Если кого-то и читать про прокрастинацию, так это Максима Дорофеева. В статье он постепенно выводит ее определение:
Я прокрастинирую, когда я решаю:
- сделать дело Y, показавшееся более важным, чем X,
- вместо дела X, впоследствии показавшееся более важным, чем Y и …
- испытываю неприятные чувства из-за этого
Уроки 14 лет работы в Google
👉Лучшие инженеры думаю в первую очередь про решение проблем пользователей.
👉Быть всегда правым – легко. Настоящая сложность в том, чтобы прийти к правильносу решению вместе с командой.
👉В первую очередь выбирай действие – лучше сделать что-то, чем вообще ничего. Плохую фичу можно исправить, отсутствующую – нет.
👉Признак сеньорности – ясность. Сложность решения приносит накладные расходы.
👉Новизна – это кредит, который оплачивается сбоями и лишней когнитивной нагрузкой.
👉Ваш код не покажет всем, какой вы классный – это делают люди.
👉Лучший код – тот, который не написан.
👉На большом масштабе даже у ваших багов появляются пользователи, и их починкой вы кому-то навредите.
👉Проблемы медленных команд чаще всего в том, что они не выровнены с остальными.
👉Фокусируйтесь на том, что можете контролировать. Остальное игнорируйте.
👉Абстракции не избавляют от сложности. Они просто прячут ее до того дня, когда абстракция протечет, и вам надо будет разбираться, что находится под ней.
👉Письмо ведет к ясности. Лучший способ научиться чему-то – попробовать научить других.
👉Работа, которая разблокирует другую работу бесценна, и при этом невидима.
👉Если вам кажется, что вы выигрываете в каждом споре, скорее всего вы просто постепенно накапливаете сопротивление людей.
👉Когда метрика становится целью, она перестает быть честным показателем.
👉Признать то, что вы не знаете чего-то, дает больше безопасности, чем притворяться наоборот.
👉Сеть ваших знакомств переживет всю вашу смену мест работы и с вами навсегда.
👉Большая часть способов улучшения протзводительности лежит в избавлении от чего-то, а не в добавлении слоев сложности.
👉Процессы существуют для того, чтобы снижать неопределенность, а не ради бюрократии.
👉В какой-то момент карьеры ваше время станет дороже зарабатываемых денег, так что готовьтесь к этому и берегите его.
👉В накоплении знаний и опыта старайтесь не срезать углы, а наоборот, полагаться на сложный процент.
Законы разработки софта
Все 13 законов из оригинальной статьи я перечислять не буду, тем более многие мы тут уже обсудили. Вот несколько интересных для привлечения внимания:
👉Закон Каннингема – Самый лучший способ получить полезный и правильный ответ в интернете – не спрашивать, как правильно, а запостить неправильный ответ.
👉Закон Стерджена – 90% чего угодно это мусор (ну получается как минимум один пост в две недели в нашем канале должен быть годным).
👉Закон Хайрума – от любого, пусть даже незадокументированного поведения вашего API, кто-то будет зависеть. Про этот закон мы пару лет назад классно поговорили в выпуске Подлодки про дизайн API.
👉Эффект Рингельмана – чем сильнее растет группа, тем сильнее снижается продуктивность отдельных ее участников.
Как разные роли используют AI
Сценарии использования AI инструментов довольно сильно отличаются в зависимости от роли человека:
👉Продакты – подготовка PRD, прототипипование, коммуникации.
👉Дизайнеры – работа с исследованиям. пользователей, генерация текстового контента, генерация идей.
👉Фаундеры – помощь в принятии решений, генерация продуктовых идей, стратегия.
👉Инженеры – написание кода, архитектура, документация.
Тимлидов спросить забыли, но мы ведь понимаем, что в основном для написания перфоманс ревью!
Реорг на вайбе
У реоргов есть несколько очень частых проблемы:
👉Оргструктура редизайнится на основе ощущений и вайбов, а не на основе детального системного анализа. Иногда эти ощущения верны, но иногда растут из когнитивных искажений и попыток повторить чужие лучшие практики.
👉Проблемы и решения обсуждаются без участия людей, находящихся внутри организационной структуры – и это делает ощущения еще менее надежными.
👉Реорг – очень понятное действие, которое маскирует реальные проблемы с пониманием, куда надо дальше двигать продукт. Рисовать квадратики и переименовывать команды просто и приятно, но проблем со стратегией это вообще не решит.
👉Аналогично и с культурой – она не изменится за несколько месяцев только как результат реорга.
Полезные правила работы с календарем
👉Решайте конфликты между накладывающимися друг на друга встречами максимально рано. Чем раньше вы отклоните один из них, тем удобнее будет для всех его участников.
👉Используйте цветовое кодирование для митингов разного типа. Например, их можно делить по требуемому уровню фокуса, формату, решаемой проблеме, роли или еще чему-то, что имеет смысл именно для вас.
👉Используйте эту категоризацию для бюджетирования времени – например, на уровне одной недели можно поставить ограничение на количество собеседований.
👉Бронируйте слот на обед.
👉Делайте события в календаре редактируемыми всеми участниками по умолчанию, так их будет проще переносить.
👉Если у вас есть и личный, и рабочий календарь, слоты в которых пересекаются, используйте Reclaim для их автоматической синхронизации.
👉Забронируйте первый день после отпуска под то, чтобы снова въехать в контекст и разобрать все накопившееся, иначе встречи не дадут этого сделать.
🤖 AI в практике разработчиков: новый сезон Podlodka AI Crew
«Мы поигрались с промптом, но пока не внедряли» — часто разговоры про AI в разработке заканчиваются именно так.
Инструментов всё больше, а вот времени на то, чтобы разобраться и сделать так, чтобы магия заработала, порой не хватает.
С 16 по 20 февраля у Podlodka AI Crew пройдёт сезон «AI-агенты в разработке»: проверенные рабочие сценарии от практиков индустрии.
👀 В программе:
• единый AI-workflow для разработчика
• автоматизация стендапов и работы с документацией
• Claude Code, субагенты для кодинга
• практические кейсы внедрения AI в SRE
• подходы к созданию промптов с насыщенным контекстом
Формат — классический для Podlodka Crew: 5 дней, 10+ спикеров, 10 сессий и закрытое комьюнити в Telegram.
Отдельный плюс — цена: заметно ниже привычных конференций, при этом контента много, и он ориентирован на практику.
👉🏻Если тема AI в разработке вам интересна и хочется меньше хайпа, больше дела — держите ссылку.
До 10 февраля можно забрать билет по early-bird цене!🎁
Почему разработчики выгорают, а фаундеры нет
Вспоминаем понедельничную статью про то, как со стабильным успехом взламывать систему перфоманс ревью. Все те советы действительно могут помочь получать чуть больше денег, чем если им не следовать – но они только чуть-чуть и на короткое время прикрывают зияющую дыру в душе человека, который продает свое время за деньги.
Вся проблема в выгорании – отсутствие смысла в том, что мы делаем каждый день. Если вы не видите четкой связи между движением задач в Jira и созданием понятной вам ценности, которой можно гордиться, то вы будете искать замену этому – пытаться делать пет-проекты, заниматься нужным только вам самому рефакторингом, пытаться гордиться своими оценками перфоманса.
У фаундеров это работает проще – они всегда явдяются авторами того, что делает компания, и видят связь своих действий, успеха компании и качества своей жизни. У программистов такого авторства нет, они исполнители в чужом замысле. А когда ты не являешься причиной происходящего, зачем вообще стараться.
Тот самый проект на 100.000 строк, написанный полностью с помощью Claude Code (оригинал).
Читать полностью…
Развивайте команду с готовой базой знаний
В Библиотеке роста вас ждёт 300+ программ по 9 направлениям — от IT и маркетинга до soft skills и личного развития. Сотрудники учатся в удобное время, а вы контролируете процесс и видите прогресс в HR-кабинете. Каждый участник получает сертификат Нетологии.
💡 Полезное — не только по подписке!
В бесплатном разделе для HR — 6 курсов. Это больше 8 часов контента по актуальным темам: аналитика обучения, микрообучение, кадровый резерв, проектирование образовательных траекторий и многое другое. Плюс анонсы полезных мероприятий, чтобы всегда быть в курсе.
Оставьте заявку, зарегистрируйтесь и получите:
— демодоступ на 7 дней ко всем курсам;
— доступ к бесплатным материалам для HR.
👉 Оставить заявку → https://netolo.gy
Реклама. ООО "Нетология" ОГРН 1207700135884 Erid: 2VSb5y5XPJZ
🗓 30 января, 18:00 мск
📍 Москва, ул. Лесная, 9 | Офис Ви.Tech
🤖 Смоллтех митап vol.2: AI и лидерство в смоллтехе
Если вы тимлид/техлид/CTO в небольшой компании и в 2026 хотите внедрять ИИ — это как раз тот митап, который вам следует посетить: 3 прикладных доклада по 25 минут и круглый стол, где вместе соберем понятный алгоритм внедрения.
Что будет полезного:
— уровни зрелости внедрения AI в разработку: с чего реально начать, как снять блокеры и масштабировать то, что работает
— как заходить с изменениями в команду и не “сломаться” о сильных старожилов: скептик / хранитель / уставший новатор и как с каждым работать
— кейс AI-ассистента для продаж и сервиса: как поставить цель, собрать команду и довести до внедрения в процессы
— круглый стол: «Алгоритм внедрения ИИ в смоллтехе» — подводные камни и шаги, которые стоит сделать в правильном порядке
Спикеры и участники круглого стола:
🪛 Михаил Шваркунов (GRI)
🧲 Иван Поддубный (Вебпрактик)
🔩 Дмитрий Громов и Надежда Кохтачева (ППР)
🛠 Кирилл Россохин (Ви.Tech)
→ Регистрация
Ситуация такая – ваш сеньор разработчик хочет вырасти в стаффа, не доводит до конца свои текущие проекты, но при этом наезжает на вас, говоря, что вы не даете ему достаточно видимости и возможности показать себя перед топ-менеджерами. При этом его текущие проекты правда невидимые инфраструктурные штуки, которые очень важны и вам, и всей команде.
Как поступить в этой ситуации разбираем вместе с тремя опытными менеджерами: Александром Орловым, Александром Поляковым и Игорем Цупко!
👉Весь кейс на канале "Тимлид не спит"
👉Разбор экспертов
Как люди используют LLM на работе
Держите очень интересный эксперимент. В образовательную компанию на 500 человек внедряли AI. Вместо покупки подписок настроили агрегатор разных моделей с единым окном входа в них, а спустя полгода проанализировали запросы:
👉Всего AI хотя бы раз попробовало 80% сотрудников. При этом ретеншн очень высокий – 85%, кто попробовал, потом уже не бросает.
👉Если дать доступ ко всем моделям, то люди будут использовать самую дорогую для всего, даже для самых простых задач.
👉Две трети бюджета по итогам уходило на генерацию картинок. 74% сотрудников делали это хотя бы раз, даже бухгалтерия, которым, казалось бы, они не нужны.
👉20% пользователей сгенерировали 80% запросов, а топ-10 пользователей потратили 20% бюджета.
👉По сравнению со стоимость дефолтной подписки в 20$ в месяц, при работе через API вышли копейки – около 2.5$ на человека.
Почему не надо останавливать все плохие проекты
Сеньорская чуйка, которая вырабатывается после десятка лет в индустрии (а в особо суровых случаях и уже через пару лет), автоматически подсвечивает для вас плохо продуманные проекты, которыми занимаются люди вокруг. Иногда это переусложненный UX, который только ухудшит жизнь пользователя, иногда – недостаточно, или, наоборот, слишком гибкая архитектура, а иногда – вообще отсутствие какого-то смысла в проекте, кроме использования его для получения повышения.
Еще один кусочек мудрости, который появляется вместе с чуйкой – это понимание, что не нужно идти воевать с каждой ветряной мельницей. Даже если вам очевидно, что какой-то проект обречен, не нужно пытаться его остановить. Почему так:
👉Компании в среднем ценят людей, которые пытаются что-то делать, а вот к тем, кто пытается замедлить работу, как раз относятся с подозрением. Если ваши сомнения не подкреплены ну очень сильными аргументами, их скорее всего пропустят мимо ушей.
👉Даже если у вас получится затормозить такой проект, кто-то может воспринять это как личное нападение – ведь из-за вас он не получит новую ачивку в портфолио или оценку на 0.1 балла выше на перфоманс ревью.
👉Если вас не послушали, но в итоге вы оказались правы и проект провалился, вас все равно не станут больше ценить как эксперта, потому что скорее всего вообще забудут этот разговор. А бегать и кричать "я же говорил" – вообще деструктивное поведение.
Вместо того, чтобы пытаться остановить все плохие идеи, относитесь к своему влиянию как к конечному ресурсу. Он пополняется, когда вы сами делаете что-то полезное – выпускаете успешный продукт, помогаете коллеге, исправляете проблемный процесс. А вот когда вы блокируете чью-то работу, вы это влияние тратите – совсем чуть-чуть, придираясь к необязательной проблеме на code review, и огромное количество, когда пытаетесь остановить очередную безумную фантазию CTO про AI. Так вот, если вы потратите все влияние на мелочи, то не сможете остановить действительно важные вещи.
Чтобы понять, на что действительно стоит тратить свой политический капитал, можно смотреть на три фактора:
1️⃣Насколько близко этот проект находится к вашей команде
2️⃣Если все пойдет по плохому сценарию, насколько сильно это повлияет на вашу команду
3️⃣Если все пойдет ну совсем плохо, как это повлияет на всю компанию
Короче говоря, pick your battles!
Про парадокс инвестиций в 2026
Парадокс заключается в том, что сейчас запускать новые продукты, даже достаточно крупные и сложные, гораздо быстрее и безопаснее в одиночку, вместо поднятия инвестиций и найма команды. Помогают в этом, понятное дело, AI агенты, которые в последнее время сделали качественный прыжок.
Минусы понятны – есть огромная вероятность, что код получится не очень масштабируемым, а поддерживать его без глубинного понимания логики будет сложно. Но плюсы тоже большие:
👉Нет потери контекста при общении в команде, он весь содержится в голове у фаундера
👉Не приходится идти на компромиссы с другими людьми, пытаясь не задеть их самооценку, или из-за других политических причин
👉Нет организационной инерции, попыток переиспользовать старые решения и всего с этим связанного
👉Порядок цен, конечно, абсолютно другой – вместо $30k в месяц на зарплаты минимальному костяку команды, в самом отчаянном случае вы заплатите N*200$ за несколько подписок на Claude Code.
А если ваша стратегия не выдержит следующий год?
Стратоплан задумал открытую конференцию для всех, чтобы детально поговорить о стратегии (в частности, об IT-стратегии). И не просто поговорить, а совместно сформулировать принципы её устойчивости и антихрупкости
Будем разбираться:
— что на самом деле считать стратегией и почему она работает не у всех
— где и почему стратегии чаще всего ломаются
— какую роль играет AI и как измерять реальную ценность AI-внедрений
— какие инструменты работы со стратегией эффективны: стратсессии, форматы, ошибки
Что вы заберете для себя:
— поймете, где ваша стратегия уже трещит
— получите актуальные инструменты разработки и пересборки стратегии
— сможете честно проверить, насколько ваша стратегия хрупкая сегодня
29–31 января 10:00–15:00 GMT+3, онлайн
Бесплатная регистрация здесь
Среди спикеров: Никаких теоретиков! Только фаундеры, СЕО, СТО, HRD и эксперты Стратоплана, которые сами проходили через кризисы и знают, как строить стратегию на годы
Бонус:
3 онлайн-воркшопа про разработку и внедрение стратегии, в том числе от сооснователей Стратоплана — Вячеслава Панкратова и Александра Орлова.
Приходите и проверьте, действительно ли ваша стратегия устойчива
За что инженеры ненавидят своих менеджеров
👉Бесконечные синки и митинги, которые вырывают из состояния потока
👉Нетехнические менеджеры, которые не понимают сложности задач, но при этом дают обещания по срокам
👉Менеджеры, которые присваивают себе чужие достижения, фразами вроде "вот что я зарелизил в этом квартале"
👉Фидбэк про зоны роста, который дается раз в год менеджером, который вообще слабо прелставляет себе вашу работу
Про мораль корпораций
На этой неделе весь Reddit обсуждает анонимный пост от сотрудника какого-то крупного приложения доставки еды, в котором рассказано про какие-то совсем неэтичные практики:
👉Фича priority delivery, которая на самом деле не влияет ни на что, кроме флажка, отправляемого на сервер.
👉A/B тесты с замедлением скорости доставки неприоритетных заказов.
👉Автоматическое определение курьеров, которые готовы браться за заказы любой стоимости, и занижение им оплаты.
👉Чаевые, которые целиком уходят в карман платформы.
Спустя несколько дней после того, как я написал черновик поста, выяснилось, что история – не правда, а просто байт на комментарии. Но будем честными – никого не удивило бы, если бы это оказалось правдой. В большинстве крупных корпораций единственный способ оценки правильности действий – это то, как они влияют на ключевые метрики. Если активация, ретеншн или MRR растут – все замечательно. Если кого-то волнует этичность действий, система его автоматически отфильтровывает – без импакта нет повышений, без повышений нет влияния на принимаемые решения.
Очень подробно про это рассказано в вышедшей в прошлом году книге Careless People, в которой бывший топ-менеджер Meta делится байками про то, как Цукерберг и компания принимают решения и разруливают происходящий по их вине геноцид (и даже не один). Если вот эта история про доставку еды показалась вам нереалистичной, очень советую прочитать!
Так вот, расскажите в комментариях, сталкивались ли вы с тем, что ваша компания принимает решения, которые идут вразрез с вашей этикой? Как действовали?
Как думать про компенсацию
Мне нравится, как автор сформулировал цель процесса компенсации:
Создать самую талантливую и мотивированную команду, которую только позволит вам ваш бюджет.
Почему нанимать джунов стало выгоднее
Мы уже обсуждали, что замедлять темпы найма джунов из-за AI – довольно тупая идея. В сегодняшней статье этот тейк как раз хорошо объясняется.
Джун – это ставка с определенным уровнем риска. Вы нанимаете неопытного человека, вкладываете в него время и ресурсы кого-то опытного из команды, и не можете быть на 100% уверены, что по итогу эти вложения оправдаются.
Красная линия на графике – профит от джуна. Первое время он отрицательный, и, если вам повезет, когда-то выйдет в плюс. Сократить эту отрицательную область можно с помощью правильного онбординга и обучения, которые будут помогать быстрее приносить пользу, поддерживая достаточный уровень качества. Так вот, AI как раз с этой частью отлично помогает – если вы еще не использовали тот же Claude Code для онбординга в незнакомый код, обязательно попробуйте.
Если использовать AI правильно – задавать вопросы про кодовую базу, исследовать альтернативные варианты реализации задачи, вместе думать над упрощением кода – то он может существенно ускорить переход джуна в полноценного инженера, а вместе с этим и уменьшить риски, которые вы на себя берете. Что еще лучше – в будущем такой инженер продолжит быстро расти.
Фальшивые догмы
Некоторые правила разработки менеджеры слепо повторяют друг за другом, хотя, если задуматься, они имеют мало смысла. Вот несколько примеров:
👉Не переизобретайте колесо и берите готовые библиотеки. На самом деле, это трейд-офф, на другой стороне которого – ценность хорошего понимания кода, и безопасность от supply chain атак.
👉Каждый PR кто-то должен заревьюить. Цена обязательных ревью очень высокая, поэтому, хоть они и поднимают качество кодовой базы, не нужно доводить это правило до абсолюта и ревьюить тривиальные вещи.
👉Все современные команды должны работать короткими спринтами. Не всегда тот факт, что вы работаете по спринтам, делает вас гибкими. Более того, не вся разработка должна быть гибкой.
👉Каждая фича должна быть за флагом. Точно нет, так как огромное количество флагов усложняет даже самый тривиальный код, а ценность от них есть не всегда.