Кейс: И швец, и жнец, и архитектор

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

Компания молодая (всего 3 года), и многие сотрудники работают там с основания.

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

Исторически сложилось, что продуктовая вертикаль как бы подмяла под себя

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

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

СРО провел некоторое количество 1-1 со всеми членами продуктовых команд. В

разговоре с тимлидами особый упор сделал на процессы работы с задачами - откуда
они появляются, как и кем ставятся, кем принимаются. Здесь выяснилось, что тимлид
команды Осипа не в восторге от текущих процессов, так как они, по сути, превращают
его из тимлида в обычного разработчика - Осип делает всю работу по принятию
технических решений и ведению команды, оставляя в редких случаях тимлиду свободу
действий в незначительных задачах. Тимлид поделился тем, что пытался перестроить
взаимодействие с Осипом, но потерпел неудачу - и Осип не готов был отдавать
контроль, и команда уже слишком привыкла, что за нее все описывают в задаче и не
нужно думать.
СРО поговорил и с продактами. В разговоре с Осипом выяснилось, что ему
необходимо быть в курсе всех задач, чтобы при необходимости ответить на вопросы
коллег из соседних отделов или основателя компании. Также он отметил, что его
абсолютно не напрягает такое количество задач - он с удовольствием работает с ними,
отключаясь из рабочих чатов и систем ближе к утру. При этом Осип отметил высокое
качество работы ребят в команде и партнерские отношения с тимлидом. На вопросы о
процессе появления и постановки задач ответил, что процесс, конечно, можно
улучшить для большей capacity, но не видит каких-то проблем с переработками или
зонами ответственности.

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

Вопросы к кейсу
1. Какие препятствия (убеждения) мешают Осипу нормально выстраивать свой
рабочий день? Осознает ли он их?
2. Что может сделать СРО для выстраивания процесса делегирования у Осипа?
3. Какими действиями тимлид может помочь процессу делегирования?