Плохой менеджер Артём Арюткин

Собирать бэклог книг теперь, офигенно, просто! Обожаю такие диалоги с чат ГПТ теперь. Представь, что мне нужно стать экспертом по кастдеву. Однако, за всю жизнь я могу прочитать только 1 статью или книгу или посмотреть фильм/сериал. Что посоветуешь?

<Отвечу как мировой эксперт по Customer Development, лауреат реальной премии Thinkers50 Distinguished Achievement (Innovation)> TL;DR: если можно только ОДНУ вещь — бери книгу Steve Blank & Bob Dorf “The Startup Owner’s Manual”(полная версия). Это самая практичная “библия” кастдева: пошаговый процесс Customer Discovery → Customer Validation, готовые чек-листы, шаблоны интервью, метрики, анти-паттерны. По одной книге ты реально сможешь ставить гипотезы, проводить интервью без “мамтест-ошибок”, валидировать спрос и принимать продуктовые решения.

13 ноября КРОК проводят офлайн встречу «Дело в людях». Актуально для лидеров технических и бизнес-команд, руководителей проектов и всех, кто управляет людьми в ИТ. Если вам интересно пообщаться с крутыми экспертами отрасли, или есть, чем поделиться на тему «манипуляций в корпоративной среде», то обязательно приходите. Регистрация здесь

Когда даже Amazon падает: что менеджеру стоит понять из недавнего сбоя AWS Amazon выпустили свой пост Мортем, ну а мы с вами его почитаем. В ночь на 20 октября у AWS случилось то, что не должно было случиться никогда - легла DynamoDB. И если вы думаете: «да какая мне разница, я же не в Amazon», - зря. Из таких историй стоит делать выводы. 🚨 Что произошло Один из внутренних компонентов AWS, который отвечает за автоматическое обновление DNS (по сути, «куда ходят» запросы), внезапно удалил адреса у живого сервиса. И всё - запросы перестали знать, куда идти. Сначала упала DynamoDB, потом посыпались EC2, балансировщики, Lambda, EKS, ECS - словом, всё, что от неё зависело. Классическая история про эффект домино, только в масштабе всей североамериканской инфраструктуры. Что оказалось в корне Виновата не халатность и не «людской фактор», а состояние гонки (race condition) - ситуация, когда два автоматических процесса пытаются изменить одно и то же, и старое значение перезаписывает новое. По сути: Один автомат обновил DNS-запись, Второй отработал чуть позже и стер то, что уже было исправлено. Система посчитала, что адрес не нужен, и удалила его. Звучит как мелочь, но когда в цепочке миллионы клиентов - это мгновенный обвал. К чему это привело Невозможно было запустить новые виртуалки (EC2). Балансировщики удаляли здоровые узлы, думая, что они мертвы. Сервисы вроде Lambda и EKS висли из-за потери зависимостей. Даже внутренние инструменты AWS перестали работать, усложнив восстановление. Проблемы тянулись почти 15 часов. Даже для Amazon это больно. 🛠️ Что AWS сделала Переписала логику обновления DNS и устранила состояние гонки. Ввела дополнительные проверки и «тормоза» для автоматизации. Улучшила систему зависимости сервисов (чтобы сбой одного не клал всё подряд). Пересмотрела лимиты и алгоритмы управления нагрузкой. Что из этого важно нам, менеджерам Автоматизация - не панацея. Даже идеально автоматизированная система способна завалить себя же. Нужен контроль, наблюдаемость и механизмы ручного вмешательства. Зависимости - главная угроза. Продукт редко падает сам по себе - его валит зависимый сервис. Чем больше таких связей, тем выше риск каскадного обрушения. В своих системах важно знать: кто от кого зависит и что будет, если этот кто-то “ляжет”. “Blast radius” - новый KPI менеджера. Задача не только в том, чтобы быстро восстанавливаться, но и в том, чтобы сбой не утащил за собой соседние команды и продукты. То есть проектировать системы так, чтобы падать «локально». Коммуникация во время кризиса. AWS держала всех в курсе. И да, это важнее, чем “пофиксить быстро”. Люди легче переживают инцидент, когда им понятно, что происходит. Чем проще инженеру понять, что происходит при сбое, тем быстрее компания восстанавливается. Хорошие инструменты, дашборды, наблюдаемость - это не “для красоты”, это страховой полис. В сухом остатке Падение AWS - напоминание: никакая масштабность и зрелость процессов не спасает от мелких, но критичных ошибок в инфраструктуре. А наша задача, как менеджеров - уметь проектировать так, чтобы даже при падении системы не падали люди: ни по моральному духу, ни по довериям к процессам, ни по коммуникации.

Пхахахах Ну чисто мы😁 #пятничное

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

Так-с, в пятницу было Avito Tech Conf. Я заехать не сумел, чуть придавило работой. Но! Интернет все помнит. Так что ловите 8 часовое видео! А фото для затравки, чтобы оценить крутизну мероприятия!

С днем отца, друзья! Нет у нас в жизни работы, важнее, чем эта! Быть папой - это быть примером крепкой любви к маме, быть примером амбиций и силы, быть тем примером моря спокойствия, которое нужно иногда всем нам!

И с задачкою трудной самой Папа справится, дайте срок! Мы потом уж решаем с мамой Все,что папа решить не смог!

И помним, что чудесные у нас такие детки, в наших девочек ❤️

внутренние обучающие материалы IBM, слайд из 1979 года

#пятничное

Я уже не знаю, как доказать Демке, кто круче (а этот любитель борьбы еще и отрицает ударников, в принципе), так что вызвал на помощь чатГПТ. В общем, пора обсуждать действительно важные вопросы!

Вот бегаем мы с вами с этими AI, LLM, Агентами и тд. с горящими глазами. А прикиньте, если для окружающих мы выглядим такими же фанатиками, как для нас выглядят ярые Криптаны, и от нас так же стараются держаться подальше?

🎯 Почему у вас нет стратегии (и никогда не было) В итоге я не удержался и дочитал книгу) Напомню, мы тут с вами обсуждаем книгу Ричарда Румельта «Взлом стратегии». Да, того самого, кто когда-то разрушил корпоративные “стратегические сессии” фразой:

Хорошая стратегия - это не список целей

. 🧩 Румельт предлагает новое слово - Crux.

Блин, мне очень понравился это символ 🧩, он супер подходит.

Crux - это не “направление развития”, не “инициатива по улучшению”. Это та самая проблема, которая держит вас за горло. Проблема, которую если решить - всё остальное начнёт двигаться само. 🚀 Примеры: • SpaceX - не «летим на Марс», а снижаем стоимость запуска в 10 раз. • Netflix - не «становимся лидером стриминга», а уходим от зависимости от лицензий.

Стали делать свой контент, а все остальное подтянулось

• Nvidia - не «растим долю GPU», а ищем область, где GPU дают преимущество.

Ииии… кто в век ИИ продает лопаты 😉

И вот ты сидишь на корпоративной «стратегической сессии», где обсуждают 12 инициатив. Digital, AI, NPS, HR-brand, CX… А на самом деле никто не ответил на главный вопрос: в чём наш Crux? 💣 Румельт жёсткий: Если вы не можете сказать, от чего отказались, у вас нет стратегии. А если стратегия не говорит «нет» - значит, она просто Excel с цветными квадратиками. 🧗 Хорошая стратегия, как альпинизм. Ты не штурмуешь гору со всех сторон. Ты ищешь тот хребет, который реально пройти. И лезешь по нему, шаг за шагом. 📉 Всё остальное - брейнштормы, красивые слайды и бессмертные “инициативы по улучшению эффективности”. 🔥 Итого «Взлом стратегии» - книга не про стратегию. А про честность. С собой, с компанией и с тем, что ты называешь “планом на год”. 🔥 - если читал и зашло ❤️ - если забрал в бэклог 💊 - если читал и не зашло @badtechproject

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

Короче, есть такой прикол, что природа вокруг дает нам уроки менеджмента. Вот пара примеров: 1. Чтобы образовалась звезда/планета, нужна «песчинка», материал вокруг не и центробежная сила. Дальше все закрутится и образуется новый объект. 2. Чтобы образовалась на ниточке соль (помните такой эксперимент, все в школе делали) нужны: нитка - аналог песчинки, материал вокруг нее и испарение лишнего. Вот тебе и образуется новый кристалл. Чтобы сделать безболезненную трансформацию нужно: 1. общую цель/врага 2. Давление сверху - аналог того самого испарения. Или желание участников - аналог центробежной силы. 3. А дальше процессы и продукт поменяется под те самые общие цели.

Что будет, если в 39 лет спрыгнуть с айтишного карьерного паровозика? Честно говоря, я Антону всегда говорю, что считаю его поступок слегка безумным. Лично я бы точно не решился. Причем не с простого карьерно паровозика спрыгнул, а там: бигтех, должность хорошая, продукт растущий. Антон короче спрыгнул год назад, чтобы делать свои проекты и развивать телеграм-каналы. Отказался от всех артефактов стабильности и успеха: зарплата, ДМС и главное — от бесконечного запаса глазированных сырков на офисной кухне. Но остались обязательства: содержать семью, кредит на другой бизнес и долг по ипотеке на 16 млн₽. Как сам говорит, ушёл, чтобы повзрослеть: можно быть бесконечно крутым элементом выстроенной структуры, но на что ты способен без всего этого? Интерес оказался сильнее страха. В своём канале Антон рассказывает про жизнь начинающего предпринимателя во всех аспектах: • Делай свою работу, работай с тем, что есть: как не проваливаться, когда над тобой не стоит начальник • Сотрудник рывкового типа или тупо прокрастинатор? • Обратная сторона предпринимательского майдсета • Первые финансовые успехи (спойлер — рано радовался) А ещё Антон честно пишет про работу с психотерапевтом, делает разборы популярных продуктов, рассказывает про бэкстейдж корпоративной карьеры и обучение на роль СЕО. Аутентичный контент, интересно наблюдать: @undisrupt

Написал обзор гайда Главная мысль. Агент - это не чатик, а система принятия решений с инструментами, памятью и ограниченной «властью». Работает в вероятностном мире, значит, всё вокруг него должно быть измеряемо, наблюдаемо и ограничено по полномочиям.

Мне особенно нравится мысль про вероятностный мир

Почему это не “ещё один сервис”: От детерминизма к вероятностям: одинаковый ввод → разные исходы. Нужны другие тесты и выпуск. Code-first уходит, приходит evaluation-first: шипим только с доказательствами (качество, латентность, безопасность, стоимость). Агент = инструменты + политика полномочий + трассы рассуждений (observable traces). ADLC вместо SDLC (DevSecOps для агентов): Plan → Code/Build → Test/Optimize/Release → Deploy → Monitor (runtime loop) → Operate. Две «внутренние петли»: эксперименты на сборке и оптимизация в рантайме. Безопасность по-взрослому: Песочницы (Firecracker/gVisor/политики контейнеров) + kill-switch + least-privilege. Агентские угрозы: memory poisoning, tool misuse, goal hijack - нужны отдельные контроли, не только классический AppSec. Наблюдаемость и метрики: Не «жив ли сервис?», а «прав ли агент?». Логи/трейсы рассуждений, groundedness, hallucination rate, cost per outcome, champion-challenger. Говернанс: Каталог сертифицированных агентов/инструментов/промптов, версии, риск-профиль, артефакты оценок и редтиминга - прежде чем выпускать. Интеграции = MCP-серверы: Инструменты выводим через Model Context Protocol, поверх - MCP-Gateway (политики, мTLS, квоты, аудит, многоарендность). Это «входные ворота» ко всем бэкендам. Когда вообще строить агента? Если есть многошаговая логика/суждение и измеримые бизнес-метрики; не стесняйтесь выбирать простые решения вместо «агентов ради агентов». Что делать завтра: 1) Завести ADLC как стандарт (шаблоны метрик/гейтов). 2) Включить агентские evals в CI/CD. 3) Поставить MCP-gateway и каталог. 4) Обязать песочницы и авторизацию «минимум прав». 5) Сделать общую панель «качество-стоимость-риски» Мне отдельно нравится про Evals Evals - это «медосмотр» агента. Проверки, которые показывают: «агент делает правильно, безопасно и за разумные деньги». Они нужны потому, что агент отвечает по-разному на один и тот же запрос - важно мерить «прав ли он», а не только «живет ли сервис». Как их делают (3 вида): • Offline - в сборке/CI: гоняем набор задач и ловим регрессии до релиза. • Online - в проде: постоянно мерим качество/безопасность/бизнес-эффект. • In-the-loop - прямо во время работы: микропроверка, которая подсказывает агенту что делать дальше (например, релевантен ли контекст). Что мерим (примеры метрик): • успех задачи, groundedness, успех вызовов инструментов. • частота джейлбрейков, утечки данных, нарушения политик. • стоимость/токены на задачу, классы ошибок. • CSAT/оценки, cost per outcome (сколько стоит результат). Как раскатывать версии: • Champion–Challenger: новую версию сравниваем с текущей на реальном трафике/данных; победителя - в промо. Это весомее офлайна.

Если вы такие: не знаю чем заняться утром в воскресенье, то можете почитать кукбук от IBM (самая корпоративная корпорация в мире) и антропик о том, как безопасно развернуть агента в корпорации. А если вам лень, то я на неделе выпущу обзор 😉