Наделенные полномочиями инженеры — это самое важное, что бывает в компании.

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

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

Я бы мог выстроить большую часть этой книги вокруг концепции инженера с широкими полномочиями.

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

Видение продукта призвано привлекать и вдохновлять этих инженеров.

Продуктовая стратегия нужна для того, чтобы инженеры работали над самыми важными проблемами.

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

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

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

Хочу уточнить, что предоставление инженерам возможности самим решать, как написать код решения, — это не то, что подразумевает концепция расширения полномочий. Конечно, они должны иметь возможность решать, как реализовать это решение.

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

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

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

Если вы используете инженеров только для написания кода, вы получаете лишь половину их ценности.

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

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

По положению инженеров в компании легче всего определить, какие команды она использует — из миссионеров или из наемников.

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

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

Хочу предупредить вас, что очень часто ваши менеджеры по продукту будут сопротивляться. Вы услышите что-нибудь вроде: «Моих инженеров не интересует ничего, кроме программирования».

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

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

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

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

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

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

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