Как глубоко CTO должен разбираться в технологиях проекта? Мы спросили людей из 5 компаний

Можно ли хоть в чем-то разбираться, когда у тебя 20-40 команд с зоопарком из PHP, Go, Angular, React’а и не только? Кто умеет сделать запрос к базе данных, а кто потерял этот навык? Кто и сколько лет уже не писал продакшн-код?

Пока не утихают споры, должен ли тимлид писать код, deusdeorum задался вопросом, что должен знать, уметь или хотя бы помнить лидер тимлидов — руководитель разработки. Собрал коллег из Додо Пиццы, Тинькофф, Мос.ру, Plesk и других компаний — и обсудил с ними этот вопрос. А мы расшифровали самое интересное. Разговор состоялся в сентябре на митапе CTO. Если хотите посмотреть в полной версии, пишите в личку — есть видеозапись, но не лучшего качества, так что.

Андрей Шелёхин, руководитель собственной разработки в Тинькофф

Я года 3 продакшн-код не пишу. Максимум — свои скрипты автоматизирую. Став лидом, ты уже погружаешься в менеджмент. Но все еще держишься в струе. А когда у тебя уже сотни человек, то это практически 100% менеджмент. Пока ты рефлексируешь, то совсем забиваешь на технологии. А программист в это время изучает новые стеки.


Андрей — крайний у доски справа. Фото с личной Facebook-страницы.

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

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

Если команда ждет, пока он что-то нарисует, а у него куча встреч, то это проблема. Нужно делегировать. Надо почувствовать этот момент и отпустить.


Текст слайда очень в тему. Фото с личной Facebook-страницы.

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

---

Алексей Паршуков, руководит разработкой Business Unit (английский для взрослых и детей, математика) в Skyeng

Я проповедую такую историю — ты должен быть в курсе кода, который у тебя пишут. Особенно там, где болит. Мне кажется, для техдира важно знать структуру данных, компоненты, которые у него есть. Знать, на каком языке они общаются.


Когда помнишь, как писать запросы к базе. Фото с личной Facebook-страницы.

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

---

Сергей Лысцев, вице-президент по R&D в Plesk

Сильный снимок, и надпись на бочке тематичная. Фото с личной Facebook-страницы.

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

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

---

Роман Ивлиев, CTO в Мос.ру

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


Спасибо Роману за тимлид-конфы. Фото со страницы TeamleadConference в Facebook.

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

Я старый С-разработчик, мне очень тяжело — я на всем пишу как на си.

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

---

Александр Андронов, СТО «Додо Пиццы»

Спокойствие, только спокойствие. Фото со страницы РИТ на Facebook.

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