Твой код никому не нужен

Равно как и тест-кейсы. Или эти дейли-митинги, планирования и ретро. Они тоже не нужны вместе с грамотно описанным ТЗ. Оптимизации производительности, метрики и мониторинг туда же. А тем более все эти задачи в Jira и прочих трекерах. Все это никому не нужно...
...если не несёт пользы для бизнеса, если не помогает зарабатывать больше или тратить меньше.

Техническим менеджерам в этой теме выпала нелёгкая доля. Если в "бизнесовых" задачах типа "нарасти конверсию в действие Х" понятна денежная ценность (выше конверсия -> больше целевых действий -> больше выручка), то в технических задачах она далеко не так очевидна. Как, например, посчитать денежный профит от ускорения ответа от веб-сервиса? Как оценить влияние на метрики бизнеса от миграции с одной СУБД на другую? И это далеко не самые сложные примеры.

И что
А вот что - одно из отличий классного технического менеджера от середнячка в том, что первый умеет строить в головах команды и стейкхолдеров ту самую связь от технической "лабуды" до понятной бизнесу ценности. Он умеет показать, как рефакторинг кода поможет тратить меньше или как оптимизация вот этого микро сервиса положительно повлияет на опыт клиента. Такое умение приводит к двум прикольным следствиям:
1. Помогает вдохновить команду. Конечно, все люди разные и кого-то совсем не вдохновляет рост бизнеса или улучшение клиентского опыта. Но есть люди, для которых такая обратная связь очень важна и именно она наполняет их работу особым смыслом. Так вот, для таких людей понимание их влияния становится вдохновением, которое помогает им перформить и получать больше удовлетворения от работы.
2. Помогает отбрасывать шелуху. Когда ты хорошо понимаешь, что действительно ценно для бизнеса, а что нет - намного легче говорить "нет" задачам, которые хоть и выглядят полезными, но на самом деле несут меньшую пользу. В условия ограниченного ресурса, такое отсеивание помогает сохранить фокус на действительно важном и дает смелость отбрасывать лишнее. Такое умение само по себе начинает экономить бизнесу деньги, ведь, не будь его, команда, вероятно, занималась бы какой-то сомнительной технической задачей, занимая время, которое можно было потратить на реально полезное дело.

А как
А как именно строить такую связь от техники к бизнесу? Об этом напишу в одном из следующих постов.