Создание отличных продуктов требует доверия и общего понимания

Огромная часть руководства командой разработчиков продукта — научиться работать над проблемой косвенно.

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

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

Лидерство со списками задач

Лидерам так легко думать о своей команде как о продолжении себя. Они пытаются взять то, что сделало их успешными в качестве IC, и просто представить, что теперь у них гораздо больше рук, с которыми они могут выполнять работу. «У меня есть проблема и ответ в моей голове, если бы я мог просто объяснить всем, что им нужно сделать, мы сможем все это сделать!» Вместо того, чтобы сообщать контекст своей команды, они дают им список задач.

Такой подход не работает (по крайней мере, не очень хорошо). Это может помочь вашему проекту сдвинуться с мертвой точки, но это не будет устойчивым. Симптомами такого подхода являются такие вещи, как:

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

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

Великие продукты разрабатываются не так.

Ведущий с контекстом

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

  • Энергия и воодушевление всех в команде чувствуют себя очень хорошо.
  • Проекты начинают идти быстрее. Кажется, они не зацикливаются на деталях, которые не имеют значения.
  • В процессе принимаются лучшие решения. Детали проекта действительно сияют.
  • Команда доверяет друг другу, включая руководство, для принятия правильных решений.
  • Все рады запуску и продвижению проекта. У команды есть дополнительная неделя на полировку и доведение до совершенства.
  • Вы можете привлекать и нанимать новых сотрудников, часто по рекомендации.

Итак, если все действительно так просто, почему так много команд (или лидеров) имеют плохую привычку вести со списками задач? Это потому, что это тяжело. Это просто, но это сложно. Требуется больше усилий, чтобы четко рассказать эту историю, сплотить группу вокруг проблемы, получить поддержку с самого начала. Вы должны быть хорошим коммуникатором и рассказчиком. Вам нужно проводить время с людьми, которые этого не видят, чтобы понять, чего не хватает вам или им.

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

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

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

Ваша команда не является продолжением вас самих. Вы наняли талантливую группу людей с отличными (и разными!) идеями и мнениями. Освободите для них место. Дайте им уважение, внимание и контекст, в которых они нуждаются и заслуживают, чтобы делать большую работу. Поддержите их, а затем уйдите с их пути. Вы будете поражены тем, насколько быстро и насколько хороши результаты. Лучше, чем ваш хромой список задач.