36 записей с тегом "leadership"

VP of Engineering сказал число, которое болит: «Мы потратили $140,000 на offsite в Бали в Q1. К Q3 никто в команде не помнил ни одного решения, которое мы там приняли». Offsite на 40 инженеров регулярно стоит $80-200K прямых расходов (перелёты, площадка, питание, активности) плюс 200-320 инженеро-недель вытесненной работы, и Gallup Workplace Report 2023 фиксирует, что только 29% компаний могут сформулировать измеримый outcome от последнего off-site.

Дефолтный фейл — не площадка и не agenda, а то, что offsite был назначен как культурный ритуал с outcomes, определёнными постфактум. Переворот порядка меняет ROI на порядок. Фреймворк ниже — то, как инженерные лидеры с повторяемо-измеримым ROI планируют offsites, и работает он через три формата, дающих измеримые результаты: hackathons, strategy sprints и team-bonding. У каждого формата своя экономика.

Публичная компания X выбила DEI-цель 2023 по инженерии: 28% женщин в инженерной команде, рост с 21%. Через два года цифра откатилась к 22%. Найм продолжал работать; retention — нет. Постмортем нашёл три паттерна, которых не было в исходной программе: заниженные промоушены женщин с tenure 2-4 года, выше-среднее code review rejection у представителей under-represented групп и assignment bias в «glue work», который не идёт в промоушен.

Большинство DEI-программ в инженерии перестают мерить на верху воронки. Числа найма публичные, собираются легко, под них удобно ставить KPI. А что происходит после выхода — скорость промоушенов, цикл ревью, паттерн назначений — вот где живёт культура. И там программы тихо проваливаются или побеждают — часто без ведома менеджмента, пока не накопятся exit-интервью.

Два senior-инженера в 60-человеческой SaaS, которую я менторил, перестали разговаривать на семь недель. По их версиям, причина — «несовместимость характеров». По данным: инженер A мёржил без ревью в сервис инженера B 23 раза за 8 недель; очередь ревью инженера B выросла с 4 PR до 31 за то же окно. У каждого была легитимная обида, которую не получалось чисто сформулировать. В момент, когда EM положил оба числа на слайд, драка закончилась — не потому, что кто-то выиграл, а потому что спор перестал быть про характер другого человека.

Большинство конфликтов в инженерных командах — не про личности. Это пробелы в процессах, рассинхрон приоритетов и неравенство нагрузки, которых люди не видят изнутри конфликта. Исследование Harvard Business Review 2022 по командной дисфункции назвало «неоднозначность, кто за что отвечает» драйвером №1 межличностных конфликтов в knowledge-work-командах. Решение — не лучшие чувства, а общая картина реальности. Данные — как её строить.

"Freedom & Responsibility" Netflix — дек, скачанный больше 20 миллионов раз после того, как Пэтти Маккорд выложила его в 2009. Engineering principles Stripe, GitLab Handbook, Shape Up от Basecamp — публичные документы культуры, ставшие ориентирами, делят три свойства: короткие, opinionated, описывают как принимаются решения, а не что команда ценит в абстракции.

Большинство документов культуры в большинстве компаний умирают в течение года. Умирают потому, что написаны для оффсайта, распечатаны на постер и никогда больше не упоминаются, когда приходит реальный тест: конфликт между скоростью отгрузки и качеством кода в 17:30 в четверг. Пост даёт шаблон, который выживает этот момент, с тремя заполненными примерами из реальных инженерных организаций.

Series-B презентация совету в 2023 пошла под откос, когда директор — бывшая VPE GitHub — задала CTO три вопроса подряд, к которым он не был готов. Он знал deployment frequency и размер команды. Он не знал median lead time, скорость найма против плана и долю инженерного фонда от operating burn. Совет не урезал инженерку, но добавил квартальный engineering review с другим CTO на созвоне. Встреча стала экзаменом, который команда сдала, а CTO нет.

К совету готовиться сложнее, чем к инвесторам, — у них больше контекста и меньше терпения. Это список вопросов — что реально спрашивает работающий совет, что CTO должен принести без спроса, и красные флаги, которые опытный директор ловит за 15 минут. Собрано из разговоров с CTO, которые успешно презентовали, с CTO, которые провалились, и с двумя директорами, сидящими в инженерно-тяжёлых портфелях.

В отчёте LinkedIn Workforce Report 2024 «несогласованность HR и инженерии» отмечена как причина №2, по которой масштабирующиеся tech-команды теряют сеньоров — сразу после компенсации. Типичный failure mode: HR рисует уровни по generic-шаблону, инженерия ведёт калибровку как недокументированный бэк-канал, и через два месяца лучший сеньор ушёл, потому что его тайтл не обновился вместе с зоной ответственности.

Это не HR-проблема и не инженерная проблема. Это проблема партнёрства, которая всплывает каждые 6–12 месяцев во время промо- и комп-циклов. Вот playbook, как сделать так, чтобы партнёрство реально работало — кто чем владеет, когда и какие данные шарятся.

Опрос Уилла Ларсона 2021 года среди 14 Staff-инженеров крупных tech-компаний дал вывод, который большинство лестниц до сих пор игнорирует: только один из трёх Senior-инженеров хочет титул Staff, и из них меньше половины получают его за пять лет. Промоушен — не естественное продолжение Senior. Это смена роли — другая работа, другие сигналы, другие режимы провала. Лестницы, где Staff — это "Senior+", производят застрявшие карьеры и очередь IC-инженеров, уходящих в EM-роль в другую компанию.

Этот framework — то, что реально предсказывает готовность: синтез исследования Ларсона, книги Тани Рейли The Staff Engineer's Path и паттернов, которые мы видим в delivery-данных 100+ B2B-инженерных организаций.

В одной 80-человечной инжиниринг-команде, с которой мы работали в марте 2026, ежемесячный обзор затрат шёл 90 минут. Шесть дашбордов. Четыре руководителя отделов, каждый защищает свои цифры. Итог: сообщение в Slack «давайте копнём глубже в следующем месяце». То же сообщение в феврале. И в январе. Дашборды были отличные. Решений не было ни одного.

Проблема не в нехватке данных. Отчёт Asana Anatomy of Work 2024 показал, что knowledge workers тратят 58% дня на «работу о работе»: митинги, статусы, обзоры дашбордов, и что типичный review-митинг не приводит ни к одному конкретному действию. Инженерные cost-обзоры — учебниковый случай. Слишком много чисел, нет forcing function для решения.

Открываем страницу Finances в организации с 38 активными проектами. По умолчанию — сортируемая таблица: имя проекта, расход за 30 дней, расход за всё время, owner, статус. Ежемесячный cost-review CFO начинается отсюда. 38 строк, 8 минут скролла, и в 60% случаев самый дорогой проект сидит на 17-й строке, куда никто реально не доходит. Эдвард Тафти ещё в The Visual Display of Quantitative Information (1983, 2-е издание 2001) показал: человек обрабатывает цвет и размер раньше, чем числа. Heatmap тех же 38 проектов выводит тёмно-красный квадрат меньше чем за секунду. Стивен Фью в Information Dashboard Design (2006, 2-е издание 2013) приходит к тому же выводу через индустриальные исследования: когда задача — «найди выброс», табличный вид это неправильное primary view. В виджете Projects Heatmap у PanDev Metrics обе модели идут бок о бок. Эта статья о том, почему mosaic должен быть дефолтом, а list — проверкой.

Principal-инженер в финтехе на 200 человек за Q3 написала 180 строк кода. Её команда за тот же период отгрузила 340 000 строк. Когда CTO посмотрел дашборды coding-time для performance review, её едва не пометили как отстающую. Что реально произошло в Q3: она переписала спецификацию сверки платежей, разблокировав две команды, менторила трёх senior-инженеров в tech-lead, и закрыла полугодовой проект, который отгрузил бы то, что рынку не нужно. Её измеримый output был крошечный. Её impact — крупнейшим среди всех инженеров компании за квартал.

Это парадокс измерения principal-инженера. Каждый staff-plus-фреймворк (Will Larson, книга Tanya Reilly The Staff Engineer's Path, внутренняя лестница Google) это признаёт: principal-инженерам платят за суждение и умножение силы, а не за throughput. Но большинство инженерных организаций меряют их как senior-инженеров с большим титулом. Эта статья — о том, как честно измерять principal-impact, и как самому principal мерить свой impact к моменту review.