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

Ну мне для этого не нужно админить серверы. Достаточно в общем знать их новые возможности. Не нужно строить лабу с LAPS каким-нибудь самому, чтобы мои ребята его настроили на всю компанию. Я вот и пытаюсь понять в итоге, почему разработка так отчаянно цепляется за кодирование всех, от тимлидов до CTO. То ли специфика своя, то ли просто легче, чем в инфраструктуре, оставаться в поле. Или еще что.

Может разработка интереснее?
Часто встречаю утверждение что хороший админ - ленивый админ, у которого все само работает. А вот у разработчика всегда руки чешутся

Это фольклорное заблуждение :)

Но всё может быть :)

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

Это я был:) Админю я, кстати, чуть более осознанно, чем хелло-ворд. В моменте так получилось, что надо было срочно забирать систему, а плеч свободных с нужной квалификацией не было. Пришлось стать промежуточным носителем знаний и умений. Я могу ошибаться, но такие манёвры хороши своей регулярностью. Если ты кодишь или админишь регулярно, то ценность будь ценностью, а если раз в год что-то решил налабать, то есть вероятность того, что получится не очень хорошо:)) Хотя опять же в чатиках проскакивало, что для профессионального разработчика год без практики вообще фигня. Мол в крови вот это все.
Кстати. Мы для конференции даже искали того, кто поработал СТО без программирования пару лет, а потом вернулся и снова заточил клавиатуру и бросил эти ваши менеджменты. Пока что-то не нашли:))) Если есть кого порекомендовать - буду благодарен за контакты.

Рома отдельный случай. :) и мы с ним по некоторым вопросам не так, чтобы согласны :)

Ну и для меня «более ценное, чем хеллоуворлд» это как раз научить ребят делатьбольше, чем я

У меня похожая ситуация, хоть я и не CTO но код не пишу уже года полтора и в основном занимаюсь административными и поцессными вещами.
По началу пытался писать но времени хватало только чтобы начать, потом приходилось отдавать разработчику, что оказалось еще хуже.
Экспертиза, конечно, теряется и читая чужой код уже далеко не всегда втыкаю, что там к чему.
Но, пару месяцев назад на меня вышли с прошлой работы с просьбой помочь с одним проектом и мне пришлось "засучить рукава". Могу сказать, что быстро все вспоминаешь.
Это как с английским на котором год не разговаривал и поехал в отпуск, основы вспоминаешь сразу а через несколько дней уже свободно разговариваешь.

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

Взвешенно :)

Коллеги, давайте не путать позиции тимлида, VP of engineering и CTO. Как мне кажется, основное отличие тимлида именно в том, что он продолжает писать код, идущий в продакшн.

Ну, если требование написания кода, идущего в продакшен, включить в определение тимлида, то, конечно, вопрос о том, надо ли ему писать код, отпадает сам собой

Но с таким определением, думаю, не все согласятся

А вообще вроде бы не странно, если в разных компаниях содержание позиций CTO, тимлида, engineering manager'а и т.п. могут отличаться

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

Я, в свою очередь, примерно такой же (в техническом аспекте вопроса) человек для своего начальства

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

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