Должен ли техлид кодить?

 Публичный пост

🤟 Всем хой и хорошей пятнички!

Собственно, зацепился я тут с одним человечком не на жизнь, а на смерть по вопросу "Должен ли техлид/IT Project Manager/CTO кодить?"

Таков путь

Начинал я как QA автоматизатор(Java) в банке, пилил нагрузочное тестирование. Довольно быстро мне стало скучно писать линейные тесты, и я подался во фронтенд разработчики, выбрал фреймворк за который тогда больше платили(AngularJS/2+Ionic) и пошел работать на Джонов. Попутно стало опять скучно, наверное это мое самодиагностированное СДВГ, и я начал пилить бекенды.

Все это время я попутно учил падаванов, отдавая им куски, которые мне начинали казаться скучными, собрал небольшую команду, и потихоньку начал трансформироваться в менеджера. На этот путь мне ушло порядка 5-6ти лет. Все это время я жестко кодил по 12 часов в день.

Потом мы нашли текущего фаундера, с которым работаем уже 5 лет, и я получил "титул" СТО, с 3 подопечными, ага. Я продолжил кодить.

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

Я долго охранял этот уголок спокойствия, но в какой то момент я понял, что я хреновый менеджер и хреновый программист. Где-то на 9-10 человек в команде.

И я отпустил программирование. Это случилось около 3х лет назад. С тех пор я кодил, разве что какие то простые скрипты для себя. На пике я управлял командой из 30 человек.

И знаете что, я не жалею... ну может быть иногда...

My take

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

Jack of all trades, master of none

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

Если я продолжу тратить по 1-2 часа в день на программирование, это не сделает меня лучшим программистом. Всегда будут люди, которые кодят по 8 часов и при этом еще уделяют по 1-2 часа в день на развитие скиллов.

Кстати, осознание этого помогает мне нанимать людей, которые лучше и умнее меня, и полагаться на них.

Нехватка времени

Это самая главная проблема. Тут вот исследование McKinsey говорит, что миддл менеджеры тратят 49% не на менеджмент, а на всякую операционку.

У нас остается всего 4 часа в день на реальный менеджмент, как из них выделить 1-2 часа на программирование?

Создание блокеров

Если я брал на себя важные задачи, очень часто я блокировал команду, когда сидел на каких то бизнесовых звонках или помогал другим.

А если не брать на себя важные задачи, тогда какой смысл СТО кодить?

Я упускал из виду очень много других веток развития

Я бы хотел раньше изучить проджект, продакт менеджмент, как проводить интервью. Раньше начать вкачивать софты. Это бы принесло компании больше пользы, чем написанные мной строчки кода.

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

Больше помогать другим

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

Лучше потратить час и помочь 4 людям, чем написать несколько строчек.

На пике мы тратили по $200к в месяц. Это $1250 за рабочий час компании. Сделать эту трату денег хотя бы на 1% эффективнее, гораздо важнее контрибуции меня как программиста в какой то один из десятков микросервисов.

Танцы с бубном

По моим скромным оценкам, минимум 50% работы программиста - это танцы с бубном.

Я недавно пытался собрать наш веб проект. Он использует определенную версию Angular, который в свою очередь требует определенную версию NodeJs, которая почему то не ставится на мой комп. Я потратил 2 дня, прочитал все треды гитхаба, стековерфлоу, задрочил chatGPT чтоб понять, что у меня не работает утилита tar, скорее всего из за того, что я переносил ОС с одной архитектуры процессора на другую. Переставить ее я не могу.

Как говорили классики:

Бой с тенью, или борьба с самим собой.
Паша Техник.

На самом деле я все еще программирую

Но я это делаю на другом уровне абстракции - программирую работу организации. Как нибудь напишу пост про то, как мы сокращали процесс, в котором участвовало порядка 30 человек с 2х месяцев до 2х недель, что вылилось в $0,5m сэкономленных денег.

Да, работа с группами людей и индивидуумами не подвержена строгой логике, как строчки кода, но ее тоже можно программировать, и это офигеть как интересно.

Что говорят другие

Мнения разнятся. Вот статья в форбс с мнениями больших дядь и теть.

Мой оппонент говорит

Не хочется негативить, но lead by example.

Ну такое. У меня были команды от 30+ людей и продолжаю писать код.

Работал еще с ex-директор Яндекс поиска (управлял лет 10), аналогично - писал код он и постоянно. Одно удовольствие.

Даже Цукерберг продолжает писать код, но редко об этом говорит.

Хороший сеньор и архитектор, проектировщик и оценщик задач.

В самые тяжелые времена и большими командами, то не меньше 4ч. Также я вводил день без встреч и звонков раз в неделю, где только писал код весь день. Собственно эту фишку мне показал ex-директор Яндекс поиска.
Также когда наведывался в bookings.com в свое время был приятно удивлен,что всякие лиды тоже делились фишками как они находят время кодить.

Ну и т.д - думаю у каждого примеров сплошь и рядом.Если нужно менеджить постоянно и что-то делать с задачами - что-то скорее всего не так. Очень хрупкая структура.

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

Я пошуршал по своим контактам в Яндексе, говорят, что тимлидов настойчиво просят писать код, но только до уровня 7 человек в команде, что стыкуется с моим видением. Мне сложно представить, как можно управлять командой в 30 человек и 4 часа в день писать код.

Призыв к действию

Во-первых, делитесь своим мнением, особенно если оно противоположно моему. Хочу прям хорошую прожарку well done. Как у вас происходит в команде? Если вы разработчик, как для вас выглядит техлид мечты?

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

19 комментариев 👇

Я придерживаюсь того, что чем выше позиция - тем больше agency и тем больше специалист должен делать вещей, которые important, but not urgent. Тушение пожаров слабо помогает уменьшать количество пожаров в будущем. С повышением ответственности это императив: отклонять срочную и неважную хуйню в пользу несрочной и важной.
Отсюда думаю так:

Должен ли техлид кодить?

Абсолютно должен, но это уже мультипликативный кодинг: чтобы оставаться свежим, это реюзабл компоненты, библиотечки, это пейринги и так далее. Часто техлидом делают сильного инженера с большими доменными знаниями. В идеале, он должен привести команду к состоянию, когда его можно выдернуть из неё - и она не посыпется. То есть он должен много делегировать и обучать, с тем чтобы тянуть всю команду вверх. Если техлид только продолжает углублять свои знания и при этом не обучает людей - он только понижает bus factor.

Должен ли IT Project Manager кодить?

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

Должен ли CTO кодить?

Если уже речь о позиции СТО - кодинг пиздец какая роскошь. http://www.paulgraham.com/makersschedule.html Вместо тысячи слов, скину тысячу слов другого человека. Я могу понять позицию "кодинг помогает оставаться в теме", с этой точки зрения посидеть пофиксить баг - это целенаправленная инвестиция, а не проёбанное время. Но я не уверен, что кодинг есть лучшее решение задачи "остаться в теме". Также я сомневаюсь, что кодинг - это хорошее решение задачи "поддерживать авторитет". У СТО есть его собственные задачи, и его авторитет зависит от того, как он решает эти задачи, а не от того, может ли он делать то же самое, что делают разработчики.

  Развернуть 1 комментарий

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

  1. Кодить часто гораздо проще и понятнее, чем делать что-то другое из лидских обязанностей. Для меня лично кодинг иногда выступал такой формой продуктивной прокрастниации: решать командные проблемы не хочу, пойду лучше заперформлю.
  2. Программирование для меня часто связано с погружением глубоко в одну специфичную проблему. Не очень понятно какую ценность команде приносит такое лидское погружение. А вот умение видеть общую картину, без вникания в детали, часто может быть очень ценным для всей команды, т.к. все разработчики как раз обычно чрезмерно погружены в детали, и им не хватает общей перспективы.
  3. Для того чтобы хорошо выполняться обязанности лида не нужно знать все что и члены команды. Нужно быть способным понять о чем люди говорят, и не ссать задавать вопросы когда не понятно.
  Развернуть 1 комментарий

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

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

Решение: беру не срочные, но интересные и важные на средней/долгой перспективе задачи: оптимизации, рефакторинги, важные и несрочные фичи. Багами, даже мелкими, тоже иногда не брезгую. Это все держит в курсе и тонусе, а также привлекает респекты от команды. Как-то так.

  Развернуть 1 комментарий

@v9v, сколько часов у тебя получается кодить в неделю и сколько человек в команде?

Мой главный консерн - в программировании тоже нужно развиваться. Условно девелопер, который кодит 8 часов в день, может один час в день уделять развитию этого скилла.

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

Тут вот еще исследование McKinsey, что миддл менеджеры тратят 49% не на менеджмент, а на всякую операционку

https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/stop-wasting-your-most-precious-resource-middle-managers

  Развернуть 1 комментарий

@roman09, у меня получается в среднем много - 50-60% где-то. В команде я + 3 разработчика. Вообще, мое эмпирическое правило - каждый падаван - это -20% времени кодинга. То есть, если их 5+ - то про кодинг можно плюс-минус забыть. Зависит, конечно, еще от компании. В большом энтерпрайзе заебут митингами насмерть, в стартапе с этим куда проще. Поэтому я в стартапе :)

Не очень понимаю как ты разделяешь кодинг и развитие в программировании. Если только ты развиваешься в чем-то не относящемся совсем к твоему текущему проекту. Я всю жизнь развиваюсь в процессе работы над проектами, и убежден, что более эффективного способа развития нет. Аналогично и с менеджерскими скилами.

  Развернуть 1 комментарий

@v9v, это примерно стыкуется с моим представлением, про 5+ правило.

Под развитием скиллов программирования я имею в виду - изучение новых инструментов, новых подходов, книжку по микросервисным паттернам еще разок перечитать в конце концов ну и тд

  Развернуть 1 комментарий

Техлид, IT Project Manager и CTO это же 3 разные роли :) Непонятно как отвечать на вопрос, когда он охватывает бОльшую область управления разработкой.

Я вот, например, считаю, что IT PM точно может вообще не кодить ) CTO тоже может не кодить, если компания вышла на IPO и у вас в борде 25 человек. Там можно ходить по встречам, прорабатывать стратегию, светить лицом в интернете и всё такое. И всё-таки СТО в не очень больших командах это скорее Founding Engineer )

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

Если техлид может не кодить, и при этом не терять своей ценности и авторитета у команды, то это вообще великолепно, но не уверен насколько реально.

  Развернуть 1 комментарий

@VladAbramov, в маленьких стартапах СТО это обычно все вместе взятое. Постепенно, с ростом компании добавляются новые роли. Я как раз перестал прогать, когда появились техлиды направлений.

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

Даже у нас в компании из 50 человек, как минимум половина времени у меня уходила на звонки с клиентами, инвесторами, партнерами, бизнесом, собеседование новых разрабов.

Вот ни разу не было такого, что у меня в моем личном беклоге не было целого паровоза горящих задач и я такой "ну теперь можно покодить для души".

У нас бернаут в месяц был под $200к. Это $1250 за рабочий час компании. И у меня всегда была дилемма сделать эту трату хотя бы на 1% эффективнее на долгосрочной перспективе или поработать программистом за $50 в час. Для меня выбор был очевиден.

И это я не говорю про то, что у меня был ненормированный рабочий день.

  Развернуть 1 комментарий

@roman09, хотел сказать о том, что до появления хотя бы нескольких инженеров в команде, СТО не занимается тем, что ты описал. Но я излишне гиперболизировал, согласен. Времени у СТО на кодинг перестаёт хватать гораздо раньше IPO

  Развернуть 1 комментарий
Evgeniy Petukhov Фулл-стек TypeScript разработчик 15 декабря 2023

Все CTO/техлиды, которых я знал, кодили. Или как минимум превосходно разбирались в архитектуре продукта, и знали как соединены его потроха. Причем, это было не одномоментно полученное знание, а рука на пульсе.

Чем, собственно, поддерживали высокий авторитет и уважение.

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

Впрочем, я допускаю подобный переход в продуктовую область, но это немного другая профессия.

  Развернуть 1 комментарий

@evgeniyp, хорошо, про архитектуру и потроха никто не спорит.

Но можешь сказать более конкретно, что именно должен кодить техлид/СТО? Фронтенд? бекенд? может быть деплоймент пайплайны? писать запросы к БД?

И интересно о каком размере команды идет речь?

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

Роль же не сводится к двум состояниям "кодить" и "Водить рукой и раздавать эпики". Я приложил огромную карту компетенций. Ты ее смотрел?

  Развернуть 1 комментарий
🕵️ Юзер скрыл свои комментарии от публичного просмотра...

@dottedmag, а кто должен этим заниматься? Проджект менеджмент - это одна из компетенций на дереве https://github.com/tlbootcamp/tlroadmap

И я это делал. Даже когда у нас был проджект.

Вы, пожалуйста, указывайте сразу размер команды. Я ж писал, что кодил до размера команды в 10 человек, но когда у тебя появляются техлиды, которые менеджат других людей, то уровень задач/проблем меняется.

И кто сказал, что я теряю контакт с реальностью? Я все еще могу залезть в чужой код и найти там багу, даже не запуская его, на платформе, на которой я никогда не кодил.

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

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

А вот другой вопрос. Должен ли архитектор кодить?

  Развернуть 1 комментарий

Краткий ответ - ДА.

Техлид должен кодить. Или "кодить". Зависит от профиля, то есть может не буквально кодить, но например что-то делать в инфраструктуре, и тп.

Но это краткий ответ. Как манагер со стажем, своим опытом подтверждаю, что у меня времени нет про код вообще думать, когда у меня стало 30+ человек в работе. Но я себя техлидом уже и не называл. В итоге ~300 у меня было.

Я одним наймом и развитием эффективной оргструктуры занимался 2 года. Какой тут кодинг или деливери.

И тут есть проблема. Потому что я отошёл не столько от кодинга, сколько от ПРОДА, и стал эдаким эйчаром с инжиниринговым бэкграундом.

Мне всё нравилось... пока не аукнулось.

Работа с заказчиком. Работа с продуктом. Работа с деливери. В глазах боссов компании - деньги.

А менеджить пул людей... ну такое.

Ну а если СТО набрал команду уже не в 5-7 человек, и хочет кодить, то варианты как быть вполне себе есть.

Опять же, махать/водить руками, вдохновлять и лицом торговать (утрированно) - это как-то больше про СЕО обычно.

СОО - про всякие процессы, SAFe и операционку.

А СТО на то и "технический", чтобы в вопросе разбираться, а проще всего поддерживать форму путём hands-on участия в процессе.

Мне и сейчас больше нравится с людьми работать. Я перепрофилируюсь в работу с заказчиком (люди) и деливери (прод).

  Развернуть 1 комментарий

@dmkPEICxgeGgbB8D, спасибо за то что поделился.
Но, прости, не очень понятно чем именно аукнулось?
Типа, что ценность твоей работы не была видена бизнесу?

  Развернуть 1 комментарий

@roman09,

И да и не совсем.

В хорошие времена в компанию бесконечно приходил поток деманда (работы).
Деньги зарабатываются путём "продажи" человека на проект - билабизация.

В те времена (2018-2022) людей надо было бесконечно. Их надо было нанимать/учить/мотивировать, перекидывать между проектами и прочее.

То есть перекос на рынке в сторону рабочей силы (саплай)

И вдруг случился перекос в сторону проектов (деманд)

До лета 2023 я ещё как-то выкручивался, но уже искал.
Но вот мне намекнули, что люди и без меня проживут, а ты товарищ давай-ка в ПРОД.
А я 5 лет вот этим всем занимался.

Назад в разработку... я уже там старый джун.
В ПМы - не нужны. Нужны ДМы (деливери менеджеры) - чтобы и в технике и менеджер.

В общем, как не поверни, все претензии в моём случае сводятся к долгому отсутствию опыта работы в продакшене.

И теперь ищу свою нишу. Грызу гранит страшной науки силой.

В будущем может опять позовут в хайринг и орг развитие, но вряд ли вернусь на такую роль. А вот овмещать буду с радостью.

  Развернуть 1 комментарий

@dmkPEICxgeGgbB8D, я понял, у меня нечто похожее. Мы полтора года назад не закрыли раунд инвестиций, сократили команду с 50 до 10.

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

Но как? уже и не так интересно(я там был), и джуном, как ты говоришь, быть не хочется.

Мне нравятся стартапы, но все стартапы ищут Founding Engineer, который им и код напишет, и перед клиентами и инвесторами потанцует, и команду соберет, если бабок дадут.

Lead/Staff Software Engineer at Agoda

  • 7+ years of experience building large-scale web applications.
  • Strong proficiency in both client-side technologies & frameworks(JavaScript/TypeScript, React) and modern server-side ones (C# .NET, Kotlin, Java)
  • Experience leading and designing large tech projects, including defining the roadmap for complex projects spanning multiple teams and functions.
  • Experience mentoring and growing senior engineers as their technical leaders.

Вот такие вакансии у меня убивают - фулстек девелопер с опытом управления большими проектами. Если он управлял большими проектами, нахер ему к вам идти фронтенды на реакте пилить?

  Развернуть 1 комментарий
Evgenii Kochanov Анализирую данные 20 декабря 2023

Взгляд из аналитики — установка «руководитель должен/может кодить, если в подчинении 7 или меньше человек» вполне подтверждается практикой. Руководители/лиды групп или главный по аналитике в стартапе (аналитиков вместе с ним 6) выполняли часть аналитических задач (включая написание скриптов, SQL запросов, рисование дэшбордов). В туту ровно то же самое — "большое" начальство погибает на встречах, руководители групп-направлений вполне себе че-то кодят-прогают.

  Развернуть 1 комментарий

Может и не кодить, но очень скоро станет плохим техлидом.

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб