How to be a CEO when AI breaks all the old playbooks | Sequoia CEO Coach Brian Halligan (Рубрика #Management)

Интересная серия подкаста Лённи, в котором к нему пришел Брайан Холлиган, со‑основатель и экс‑CEO HubSpot. Они обсудили каким становится лидерство и бизнес в эпоху ИИ: как нанимать, расти и продавать, когда старые плейбуки трещат по швам. Брайан был CEO 15 лет, а теперь выступает как внутренний CEO‑коуч в Sequoia и ведёт подкаст про лидеров Long Strange Trip.

Основные инсайты примерно такие

1️⃣ Стартовая компанию проще, чем когда‑либо; масштабировать - сложнее, чем когда‑либо
ИИ и облака кратно удешевили запуск, поэтому число компаний взлетит в небеса в ближайшие 10 лет, но шум и конкуренция делают масштабирование и дифференциацию всё труднее

2️⃣ Работа CEO → бесконечный найм и орг‑дизайн
"Взрослые CEO" тратят до половины времени на рекрутинг, интервью и конструкцию exec‑команды, а не на продукт или операционку.

3️⃣ Все ужасно переоценивают своё умение интервьюировать
Инстинкт "мне кажется, он классный" почти ничего не стоит; куда важнее жёсткие blind‑references, рабочие сессии с кандидатом и правильные вопросы про повторный найм

4️⃣ Нужно нанимать "острых" (spiky), а не консенсусных людей
HubSpot перестал использовать консенсус в виде "3/4 от всех голосов" и начал брать людей с сильными плюсами и заметными минусами; это улучшило хит‑рейт

5️⃣ Люди из bigtech почти всегда не заходят компаниям на ранней стадии
Найм из Microsoft/Salesforce/Google на компанию в 50–500 человек часто даёт "импеданс‑мисмэтч": ожидания процесса и ресурсов не совпадают с реальностью стартапа

6️⃣ Базовый плейбук - команда как Red Sox‑2004: микс homegrown и пары "звёзд"
Большая часть менеджмента вырастает изнутри, плюс несколько дорогих ветеранов, а не "ковёр‑самолёт" из McKinsey/FAANG.

7️⃣ Фреймворк LOCK(S) для оценки фаундеров
- L (lovable): хочется за этим человеком идти, он вдохновляет последователей
- O (obsession): глубоко одержим проблемой, сильный founder–market fit
- C (chip on the shoulder): идиома про "затаить обиду", когда человек чувствует себя оскорбленным из-за прошлого оскорбления или предполагаемой несправедливости, тогда появляется внутренняя мотивация "доказать". Тут интересно, что я раньше не знал эту идиому и она мне нравится (кажется, что я лучше всего работаю, когда у меня есть такое чувство)
- K (knowledge): глубокое знание домена
- S (student): фанатичный студент игры, копает и историю, и современность

8️⃣ CEO может стать не любой, но одновременно и ими не только рождаются
Есть редкие "5‑tool CEOs", которые умеют кодить, продавать, вдохновлять, иметь вкус и видение (пример - Брет Тейлор), но большинству приходится добирать умения: обратная связь, детектор BS, вдохновение людей.

9️⃣ Боль №1 у фаундеров - давать фидбек и менять ранних сотрудников
Самое тяжёлое - сказать кофаундеру/раннему head of X: "ты больше не управляешь, ты - визионер/CTO, а мы нанимаем операционного лидера над тобой" и сделать это экологично, но жёстко

🔟 ИИ уже сильно бьёт по разработке и саппорту, но не по enterprise продажам
Кодинг, support, legal уже трансформируются, а enterprise‑продажи, где нужно доверие между двумя людьми, будут последними в белых воротничках, кого заменит ИИ.
Но вообще у всех будут свои персональные агенты, подключённые к почте, календарю и заметкам, которых можно звать в митинги как активного участника, а не просто как запись

Ну и финально про воронку go-to-market, которая становится ориентирована на агентов
- Воронка "Google → сайт → demo" сменится на "Gemini/Claude/ChatGPT → глубокое исследование → уже образованный клиент". Сайт станет менее важен
- На сайте будет "всезнающий аватар", который понимает продукт, цены и контекст клиента, ведёт беседу и пишет в CRM
- У сейлза на созвоне будет свой "аватар", который знает всё о продукте и клиенте и помогает отвечать в реальном времени

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

#Leadership #Management #Software #AI #ML

A Brief History of Bjarne Stroustrup, the Creator of C++ (Рубрика #Engineering)

Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др.

Ниже интересные моменты про его биографию, не все из которых я знал
- В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки
- На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные.
- В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой".
- Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя.

Не забыли они обсудить и сам C++, его предназначение и историю развития
- В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы.
- Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором.
- Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество.
- Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык.

В итоге, я себе отметил моменты
1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора.
2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий.
3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто.
4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге
5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара.
6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы.

#Engineering #Software #Management #Leadership #Architecture

The Rise and Rise of FastAPI (Рубрика #API)

Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте:
- Стандарты** (ASGI, OpenAPI/JSON Schema)
- Типизацию как интерфейс** (type hints → Pydantic модели)
- DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт)
- Композиционную архитектуру (Starlette‑стек, middleware, зависимости)
В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг

Если говорить про вехи развития проекта, то получится следующее
1️⃣ Side‑project → фреймворк
Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически

2️⃣ Технический стержень
- ASGI‑модель (современная I/O‑архитектура)
- Starlette как "тонкий" веб‑слой
- Pydantic как слой данных: строгая валидация/сериализация поверх type hints

3️⃣ Контракт становится "живым артефактом"
- OpenAPI генерится из кода.
- Интерактивная документация /docs и /redoc делает API‑контракт частью ежедневной разработки, ревью и интеграций

4️⃣ Снежный ком крутого DevEx (developer experience)
- Шаблоны, практики, интеграции, “как правильно” из коробки.
- Порог входа падает → adoption растёт.

5️⃣ Взросление и коммерциализация вокруг поддержки
- Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п.
- Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка".

Если раскрывать ключевые инсайты подробнее, то получаем примерно так
1) FastAPI - это "композиция стандартов + DX", а не "магия"
FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация.
По итогу у нас становится меньше неявных договорённостей и "случайных JSON"

2) Контракт‑ориентированная разработка - становится нормой
OpenAPI в FastAPI - не "дока на потом", а контракт в процессе:
- Проще подключать фронт
- Проще делать партнёрские интеграции
- Проще ревьюить изменения
В итоге, скорость и надежность на другом уровне

3) Производительность - следствие правильной I/O‑модели, а не цель
ASGI + async дают выигрыш только если вы:
- Не блокируете event loop
- Используете правильные драйверы/клиенты
- Умеете проводить границы sync/async
Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99

4) OSS‑рост почти всегда приводит к вопросу устойчивости
Если фреймворк становится критическим для тысяч компаний, возникает давление:
- На поддержку
- На эксплуатационные "best practices"
- На продуктовую упаковку вокруг деплоя/наблюдаемости
В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью

На сайте system-design.space есть чуть более подробный разбор.

#Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture