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

За свою карьеру я встречала немало таких невероятных людей. Думаю, этим и объясняется удивительная живучесть мема про «10×-разработчика». Возможно, он основан на шатких, так себе исследованиях, а аргументы в его защиту часто смешны (например: «10×-разработчики работают в тёмной теме, их редко увидишь на задачах по интерфейсу, они плохие наставники и интервьюеры») или откровенно подпитывают стереотипы («мы ищем молодых парней в худи, похожих на Марка Цукерберга»). И всё же этот мем чертовски резонирует с опытом. Он как будто «правда».

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

Измерение продуктивности — дело рискованное и несовершенное

Во-первых: как именно вы измеряете продуктивность? Меня смущает предпосылка о том, что существует «единственная истинная метрика» продуктивности, по которой можно стандартизировать людей и рассортировать их по полочкам. Подумайте на минуту о чисто комбинаторном масштабе навыков и опыта, которые здесь замешаны:

• Вы работаете с микропроцессорами, IoT, внутренностями СУБД, веб-сервисами, пользовательским опытом, мобильными приложениями, консалтингом, встраиваемыми системами, криптографией, анимацией, обучением моделей генеративного ИИ… 

• Вы используете Go, Python, COBOL, Lisp, Perl, React или Brainfuck? Какую версию, какие библиотеки, какие фреймворки, какие модели данных? Какие ещё программные и сборочные зависимости вы должны держать в голове?

• На какие смежные навыки, отрасли и предметную экспертизу продукта вы опираетесь — дизайн, безопасность, соответствие требованиям (compliance), визуализацию данных, маркетинг, финансы и т. п.?

• Какая стадия разработки? Какой масштаб использования? Что важнее — давать качественные советы в роли консультанта, быстро прототипировать ради поиска product-market fit или писать код, который остаётся сопровождаемым и производительным многие годы последующей поддержки? Или вы, например, пишете для марсохода или для «коробочного» ПО, которое нельзя будет поменять вовсе?

И ещё: люди, их навыки и способности не статичны. В какой-то период я была неплохим DBRE (Database Reliability Engineer, инженер по надёжности баз данных) — я даже соавтор книги на эту тему. Возможно, тогда я и была «10×-разработчиком» в мире БД, но точно не сейчас. Я не отлаживала план выполнения запроса уже много лет.

Термин «10×-разработчик» звучит так, будто десятикратная продуктивность — это неизменное свойство человека. Но тот, кто является «10×» в конкретном наборе навыков, неизбежно имеет бесконечно больше областей, где он обычный или средний (или ниже). Я знаю немало разработчиков мирового уровня, но никогда не встречала человека, который был бы «в 10 раз лучше всех» по всем фронтам и в любой ситуации.

Разработчики не владеют ПО, ПО принадлежит командам

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

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

Если у вас есть сервисы или компоненты, которые «закреплены» за одним разработчиком, этот человек становится единственной точкой отказа.

Я не говорю, что такого не должно быть никогда. Для стартапов вполне нормально, когда отдельные люди владеют кусками софта: их главный экзистенциальный риск — двигаться недостаточно быстро, не попасть в потребности рынка и закрыться. Но по мере того как компания взрослеет, пользователи начинают требовать большего, а вы планируете выживание бизнеса на годы вперёд… владение должно переходить к команде. Отдельные инженеры болеют, уходят в отпуск и увольняются, и бизнес должен быть к этому устойчив.

Если софтом владеют команды, ключевая задача любого инженерного лидера — собирать высокоэффективные инженерные команды. Если уж вы хотите «умножить на десять» что-то, умножайте на десять это. Стройте 10×-команды.

Лучшие инженерные организации — те, где обычные разработчики могут делать выдающуюся работу

Когда говорят о компаниях «мирового уровня», часто имеют в виду команды с перекосом в сторону ведущих и главных старших инженеров или активный найм бывших сотрудников FAANG и выпускников топовых вузов.

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

Я бы даже сказала, всё наоборот. По-настоящему выдающаяся организация — это та, где совершенно обычные, рядовые разработчики, обладающие добротными инженерными навыками и обычным уровнем экспертизы, могут стабильно быстро двигаться, выпускать код, отвечать пользователям, понимать построенные ими системы и шаг за шагом продвигать бизнес вперёд — день за днём, неделю за неделей.

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

Действительно выдающаяся компания ещё и «выращивает» разработчиков мирового уровня. Но это мы уже немного забегаем вперёд.

Поговорим об «обычности»

Многие из технических специалистов крепко привязаны к своей идентичности «талантливых парней». Индустрия разработки ПО подыгрывает и подзуживает это на каждом шагу — от «мы ищем топ-10% мирового таланта» у Netflix до «поднимаем планку» у Amazon и недавнего заявления Coinbase о найме «топ-0,1%». (Серьёзно? Ну хорошо, тогда Honeycomb будет нанимать только топ-0,00001%!)

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

Мысль о себе как об обычном человеке может быть отрезвляющей, но большинство из нас на самом деле довольно обычные люди (пусть и с многолетней узкой практикой и опытом) — и в этом нет ничего дурного. Даже те из нас, кто по каким-то критериям «сертифицированные гении», скорее всего, вполне обычны в других измерениях — кинестетическом, эмоциональном, пространственном, музыкальном, лингвистическом и т. д.

Разработка ПО с одной стороны отбирает, а с другой — развивает определённые типы интеллекта, прежде всего абстрактное мышление, но никто не рождается выдающимся разработчиком. Выдающимися разработчики не рождаются, а становятся. Не думаю, что мы много выигрываем, считая себя «особым классом людей», по сравнению с тем, какую пользу даёт взгляд на себя как на сообщество вполне обычных людей, много лет практикующих довольно нишевое ремесло.

Стройте социотехнические системы с поправкой на «обычных людей»

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

Обычные люди подвержены когнитивным искажениям — предвзятости подтверждения, эффекту недавности, эффекту «я же говорил» и многим другим. Мы много работаем, нам не всё равно, мы стараемся изо всех сил; но мы также о чём-то забываем, порой раздражаемся и устаём от работы. Наш взгляд неизбежно притягивает красный цвет (если только мы не дальтоники). Мы способны вырабатывать привычки и сопротивляемся переменам. Видя один и тот же текст снова и снова, мы перестаём его читать.

��ы — создания с физическим телом, нас может накрывать перегруз и усталость. Если алерт поднимет нас в 3 часа ночи, вероятность ошибок при реакции на него куда выше, чем если бы мы делали то же самое в 3 часа дня. Наше эмоциональное состояние влияет на качество работы. Наши отношения влияют на способность доводить дела до конца.

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

Как превратить обычных разработчиков в 10×-команды?

Я сейчас не скажу ничего сенсационного; это общеизвестные вещи. Чтобы построить социотехнические системы поставки ПО, которые позволяют обычным инженерам быстро продвигаться, постоянно учиться и выдавать отличный командный результат, стоит:

Сократить интервал между моментом, когда вы написали код, и моментом, когда он попадает в прод.

Сделайте его максимально коротким; чем короче, тем лучше. Я писала и говорила об этом много раз. Чем короче интервал, тем меньше когнитивные издержки на удержание контекста. Чем быстрее итерации, тем лучше. Тем больше «мозга» уходит в продукт, а не в процесс его сборки.

Одно из самых мощных решений — сделать цикл деплоя достаточно коротким и быстрым, чтобы выпускать один коммит на один деплой. Я называла противоположную ситуацию «спиралью смерти разработки ПО»: когда деплой длится так долго, что вы вынуждены батчить изменения нескольких разработчиков в каждый билд. Чем медленнее деплой, тем крупнее батчи, тем сложнее понять, что пошло не так, или откатиться. Чем дольше это длится, тем больше людей вовлекается, тем выше издержки на координацию и тем медленнее движется весь процесс.

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

Сделайте откат и восстановление после ошибок быстрыми и простыми.

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

Сделайте правильный путь лёгким, а неправильный — трудным.

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

Инвестируйте в инструментирование и наблюдаемость.

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

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

Выделяйте инженерные ресурсы на внутренние инструменты и enablement  — то есть на всё, что снимает препятствия и расширяет возможности команды.

Если быстрые и безопасные деплои, защитные ограждения, инструментирование и высокопараллельные тестовые наборы — «общее дело», это в итоге окажется ничьим делом. Производительность инженерии нельзя отдать на аутсорс. Управление стыками между внешними поставщиками ПО и вашими командами — и наука, и искусство. Сделать это простым и интуитивным очень трудно. У этого должен быть конкретный владелец.

Стройте инклюзивную культуру.

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

Разнообразные команды = устойчивые команды.

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

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

Собирайте инженерные команды из специалистов разных уровней.

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

И кстати: вся работа, которую вы вкладываете в то, чтобы ваши системы были устойчивыми, хорошо спроектированными и человечными, — это ровно та же работа, которая нужна, чтобы эффективнее онбордить новых разработчиков, развивать джуниоров и позволять инженерам переходить между командами.

Эта инвестиция используется снова и снова. И снова. И снова.

Единственная осмысленная мера продуктивности — влияние на бизнес

Единственное, что действительно важно, когда мы говорим о продуктивности разработчиков, — двигаете ли вы бизнес вперёд по-настоящему, материально.

А значит… в вакууме это не делается. Самый важный вопрос — над тем ли мы вообще работаем. Разработка не может ответить на него без помощи продукта, дизайна и остальных функций бизнеса.

Разработка ПО — это не про написание кода, это про решение бизнес-задач с помощью технологий.

Синьоры и миддлы — настоящие «рабочие лошадки» индустрии. Они двигают бизнес вперёд, шаг за шагом, день за днём. Они могут спокойно углубиться в работу и «крутить педали», вместо того чтобы постоянно оглядываться на организацию и решать координационные проблемы. Если, чтобы сдвинуть продукт, вам обязательно нужен инженер ведущего уровня и выше, значит, что-то серьёзно сломано.

Выдающиеся компании растят разработчиков мирового уровня

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

Лучшие компании — это не те, где собраны самые умные и опытные люди на планете, а те, где обычные разработчики могут стабильно расти, приносить ценность пользователям и двигать бизнес вперёд, день за днём.

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

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

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

Но компании системно переоценивают поиск этих людей уже после того, как их «вырастили» где-то ещё, и этим лишь закрепляют и воспроизводят предубеждения и неравенства, существующие в мире. Талант может быть распределён равномерно, а вот возможности — нет.

Не нанимайте «самых лучших». Нанимайте «подходящих»

Мы (то есть всё человечество) уделяем слишком много внимания индивидуальным качествам и «агентности» и слишком мало — системам, которые формируют нас и наши модели поведения.

Мне кажется, целый пласт проблем (самоотсев кандидатов на этапе отбора, разнообразие воронки и т. п.) решился бы, если бы мы сместили фокус в найме и собеседованиях с чрезмерного упора на «лучших специалистов» и переориентировались на более здравый и точный подход — «подходящих специалистах».

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

Именно в такие места инженерные таланты (и просто хорошие люди) тянутся как мотыльки на свет. Выкатывать фичи — приятно. Двигать бизнес вперёд приятно. Приятно оттачивать навыки и мастерство. Это то место, куда идут, чтобы стать разработчиками мирового уровня. И это то место, где разработчики мирового уровня хотят оставаться, чтобы растить следующее поколение.

Когда скорость команд упирается не в людей, а в систему, «героизм» перестаёт работать: инциденты повторяются, метрики не связаны с бизнесом, а постмортемы ничего не меняют. Если узнали себя — приходите на бесплатные демо-курсы от преподавателей курсов:

• 17 ноября 20:00 — Инцидент-менеджмент в SRE: как быстро находить, устранять и предотвращать сбои. Регистрация

• 25 ноября 20:00 — Как, зачем и когда стоит измерять бизнес-процессы. Регистрация

А то, как говорить о сложном (увольнения, фидбек и конфликты без потерь), обсудим на открытом уроке 24 ноября в рамках курса "Team Lead".