Даём руководителю задачу "сделать Икс" и людей. В ходе декомпозиции руководитель, который сам умеет писать код, довольно часто выясняет, что небольшую по объему core-задачу игрек ему лучше всего сделать самостоятельно. А если он код писать не умеет, то и такого инструмента у него нет. Чем больше подразделение, тем менее это важно, конечно.

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

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

Нет

тогда я неправильно понял. Поясните?

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

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

По описанию больше похоже на техлида, чем на тимлида. Возможно, тут омонимия :)

Спорно. Плюс точно есть объёмы, когда просто управление становится фуллтайм джоб, не?

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

Мне так кажется.

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

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

Золотая середина индивидуальна для каждого тимлида, для каждой команды и проекта.

А с тимлида стоит требовать не “написания кода”, а качества и сроков.

Вот не знаю, по-моему, вполне универсальное правило. Не "25% времени код писать", а "25% времени заниматься примерно той же работой, что и подчиненные". Допустим, речь о руководителе подразделения из 20-30 человек. Его подчиненные -- руководители групп по 5-7 человек, у каждого некая область ответственности. Тогда ему полезно завести вчетверо меньшего объема, но свою лично, область ответственности аналогичного характера и одного-двух individual contributor-ов в прямые подчиненные. Конечно, так не всегда возможно устроить, но я вполне искренне считаю это хорошей конструкцией.

Ну может быть. Просто я сразу стал руководителем группы, да ещё не самой маленькой, и не разработки, а инфраструктуры.

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

Плюс предметное поле чуть разнообразнее и потребителей сильно больше в моём случае.

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

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

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

Я бы сказал, что это становится основной работой. А код — хобби.