Прододжаю настаивать на том, что техдолг не ортогонален фичам 😀

По-моему, не бывает отдельного техдолга, отдельного продуктового производства и так далее.

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

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

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

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

Если говорить именно о технических задачах, то удобно, когда руководитель проекта - бывший разработчик, освоивший новые специальности 😎 Это многое облегчает, но и свои минусы, конечно, тоже есть. У нас много руководителей продуктов - именно бывшие бекенд-разработчики.

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

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

Вы в аутсорсе работаете?  Про бизнес много пишите.

Ну, это сложно. Имхо, чем ближе к Продукту - тем больше нужно думать. Сложных проблем в программировании достаточно немало, чтобы тем, кто разрабатывает Технологии фокусироваться на них, а не на бизнесе в популярном смысле слова. Иначе это потеря фокуса, распыление.

Да не, конечно, надо фокусироваться на продукте. Проблем с этим нет, и даже наоборот. И даже внутренние сервисы, инфраструктура - это все продукты для своей аудитории, и делаться должны по тем же принципам.