Должен ли техлид кодить?
Публичный пост
Тех
🤟 Всем хой и хорошей пятнички!
Собственно, зацепился я тут с одним человечком не на жизнь, а на смерть по вопросу "Должен ли техлид/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. Как у вас происходит в команде? Если вы разработчик, как для вас выглядит техлид мечты?
👉 А во-вторых, если вам понравились мои излияния, то подписывайтесь на мой телеграм там я пишу коротко и по делу про бизуху, айтишечку, нетворкинг и будни СТО
Я придерживаюсь того, что чем выше позиция - тем больше agency и тем больше специалист должен делать вещей, которые important, but not urgent. Тушение пожаров слабо помогает уменьшать количество пожаров в будущем. С повышением ответственности это императив: отклонять срочную и неважную хуйню в пользу несрочной и важной.
Отсюда думаю так:
Абсолютно должен, но это уже мультипликативный кодинг: чтобы оставаться свежим, это реюзабл компоненты, библиотечки, это пейринги и так далее. Часто техлидом делают сильного инженера с большими доменными знаниями. В идеале, он должен привести команду к состоянию, когда его можно выдернуть из неё - и она не посыпется. То есть он должен много делегировать и обучать, с тем чтобы тянуть всю команду вверх. Если техлид только продолжает углублять свои знания и при этом не обучает людей - он только понижает bus factor.
Вообще не должен, это же кабанчик, который сводит нужных людей с нужными людьми и выбивает коммитменты и ресурсы. Как въёбанные полдня в кодинг помогут ему кабанячить лучше?
Если уже речь о позиции СТО - кодинг пиздец какая роскошь. http://www.paulgraham.com/makersschedule.html Вместо тысячи слов, скину тысячу слов другого человека. Я могу понять позицию "кодинг помогает оставаться в теме", с этой точки зрения посидеть пофиксить баг - это целенаправленная инвестиция, а не проёбанное время. Но я не уверен, что кодинг есть лучшее решение задачи "остаться в теме". Также я сомневаюсь, что кодинг - это хорошее решение задачи "поддерживать авторитет". У СТО есть его собственные задачи, и его авторитет зависит от того, как он решает эти задачи, а не от того, может ли он делать то же самое, что делают разработчики.
Не буду пытаться ответить на догматично поставленный вопрос, а поделюсь личными наблюдениями.
Очень понимаю проблему, сам не раз фрустрировал от того, что люблю и хочу кодить, но менеджерская позиция неизбежно ставит помощь падаванам и прочим на первое место. Ведь наша задача - в первую очередь сделать их работу максимально эффективной, пропушить все блоки, увязать где развязалось, и отменторить где неотменторено. А уже потом, если осталось время и силы - что-нибудь покодить.
В итоге, я выработал правило - никогда не вешать на себя задачи, которые блочат других или находятся в фокусе у лидершипа, то есть ожидаются ASAP. Потому что с такой задачей в зубах я или забью на менеджмент, или просру сроки, или буду хуячить в две смены. Ни один из вариантов меня не устраивает.
Решение: беру не срочные, но интересные и важные на средней/долгой перспективе задачи: оптимизации, рефакторинги, важные и несрочные фичи. Багами, даже мелкими, тоже иногда не брезгую. Это все держит в курсе и тонусе, а также привлекает респекты от команды. Как-то так.
Техлид, IT Project Manager и CTO это же 3 разные роли :) Непонятно как отвечать на вопрос, когда он охватывает бОльшую область управления разработкой.
Я вот, например, считаю, что IT PM точно может вообще не кодить ) CTO тоже может не кодить, если компания вышла на IPO и у вас в борде 25 человек. Там можно ходить по встречам, прорабатывать стратегию, светить лицом в интернете и всё такое. И всё-таки СТО в не очень больших командах это скорее Founding Engineer )
Техлид совершенно точно должен кодить на постоянной основе, т.к. одними из его обязанностей являются: формирование технологического радара, обеспечение качества и построение архитектуры. И здесь всё чужими руками не сделать, и одним опытом тоже не обойтись. Предполагается что он своей экспертизой будет затыкать дыры у команды.
Будет сильно медленнее, если в моменты, когда надо быстро понять почему запрос долго обрабатывается на проде, техлид пойдет "вспоминать" как оно чо там было устроено, а команда в это время докопается до правды и всё пофиксит.
Если техлид может не кодить, и при этом не терять своей ценности и авторитета у команды, то это вообще великолепно, но не уверен насколько реально.
Все CTO/техлиды, которых я знал, кодили. Или как минимум превосходно разбирались в архитектуре продукта, и знали как соединены его потроха. Причем, это было не одномоментно полученное знание, а рука на пульсе.
Чем, собственно, поддерживали высокий авторитет и уважение.
Человек, который решил перестать кодить совсем, на мой взгляд выглядит странно. А в чем тогда лидерство? Водить рукой и раздавать эпики? А как можно "лидировать" и вообще управлять, если ты уже не петаешь, и завтра будешь разговаривать устаревшими терминами и технологиями? Инженеры за спиной смеяться будут.
Впрочем, я допускаю подобный переход в продуктовую область, но это немного другая профессия.
Краткий ответ - ДА.
Техлид должен кодить. Или "кодить". Зависит от профиля, то есть может не буквально кодить, но например что-то делать в инфраструктуре, и тп.
Но это краткий ответ. Как манагер со стажем, своим опытом подтверждаю, что у меня времени нет про код вообще думать, когда у меня стало 30+ человек в работе. Но я себя техлидом уже и не называл. В итоге ~300 у меня было.
Я одним наймом и развитием эффективной оргструктуры занимался 2 года. Какой тут кодинг или деливери.
И тут есть проблема. Потому что я отошёл не столько от кодинга, сколько от ПРОДА, и стал эдаким эйчаром с инжиниринговым бэкграундом.
Мне всё нравилось... пока не аукнулось.
Работа с заказчиком. Работа с продуктом. Работа с деливери. В глазах боссов компании - деньги.
А менеджить пул людей... ну такое.
Ну а если СТО набрал команду уже не в 5-7 человек, и хочет кодить, то варианты как быть вполне себе есть.
Опять же, махать/водить руками, вдохновлять и лицом торговать (утрированно) - это как-то больше про СЕО обычно.
СОО - про всякие процессы, SAFe и операционку.
А СТО на то и "технический", чтобы в вопросе разбираться, а проще всего поддерживать форму путём hands-on участия в процессе.
Мне и сейчас больше нравится с людьми работать. Я перепрофилируюсь в работу с заказчиком (люди) и деливери (прод).
Взгляд из аналитики — установка «руководитель должен/может кодить, если в подчинении 7 или меньше человек» вполне подтверждается практикой. Руководители/лиды групп или главный по аналитике в стартапе (аналитиков вместе с ним 6) выполняли часть аналитических задач (включая написание скриптов, SQL запросов, рисование дэшбордов). В туту ровно то же самое — "большое" начальство погибает на встречах, руководители групп-направлений вполне себе че-то кодят-прогают.
Может и не кодить, но очень скоро станет плохим техлидом.