Круглый стол: техлид и развитие в Individual Contributor

Ведущий начинает с того, что тема редкая: техлид вроде бы выделенная роль, но чем именно рулить, обычно не объяснено, и чаще его функции выполняет тимлид — тот самый играющий тренер, мифологическое существо. Бывает и наоборот: хорошему разработчику между делом предлагают заняться командой, нарезать задачки и помогать грумить. Максим хотел бы, чтобы техлид не занимался people-менеджментом, а формулировал локальный технологический ландшафт команды, управлял зависимостями и вдохновлял людей изучать технологии: в менеджерском треке отчаяние от невозможности хоть немного попрограммировать почти бесконечно. Зал проходит быстрый квиз — кто знает, что такое individual contributor, кто встречал такого на практике, кто считает себя таким. Александр вспоминает, что в маленьких компаниях верхняя точка — синьор, а дальше предлагают команду; так он и ушёл в менеджерский трек. Он же вспоминает доклады прошлых лет — как перестать быть инженером и стать тимлидом, а через два года как снова стать нормальным инженером, — и «обманутых дольщиков», из которых хорошие разработчики превращались в дрянных менеджеров.

В крупной компании, продолжает он, всё иначе: много команд, сложный ландшафт, платформенные инструменты, коробочные решения, которые надо заместить новым стеком, — задачи, которые не закидать обычными инженерами, а на рынке таких людей мало, поэтому их растят внутри и объясняют бизнесу, зачем менять ролевую матрицу. Бизнес спрашивает прямо: почему разработчик без единого подчинённого стоит как человек с парой сотен людей, и если он ведущий инженер, то где его команда? Технический директор Делимобиля отвечает метафорой: такой инженер — это Месси, Леброн, первая позиция в Доте, кэрри, который тащит команду; лидерство нельзя делегировать, эти люди вырастают сами, на внутреннем авторитете и экспертизе. Ведущий возражает: пока это серый кардинал, «самый умный чувак в комнате», рыночного стандарта компетенций нет — такого не нанять и не провалидировать, потому что конечный список знаний не описать.

Матрица грейдов, рассказывает Александр, общая для software development инженера, а не отдельная под каждый стек; её долго драйвил коллега, который уже не работает в компании. Критерии привязаны не к знанию инструментов, а к влиянию: scope — масштаб, на котором ты работаешь; impact — к чему приводят твои действия и сколько пользы приносят; leadership — умение разрулить на отношениях и координации, без «я начальник, ты дурак»; improvements, для которых у него есть образ паладина из ролевой игры, вокруг которого распространяется бафф и люди начинают работать лучше. По этим критериям он ревьюит заявки на промо, и не так важно, на чём человек писал код. Влияние выглядит по-разному: кому-то достаточно прийти на ревью архитектурного документа, кто-то работает наставником, кто-то автоматизирует процессы, а кто-то предлагает заменить разнородный зоопарк одной библиотекой, чтобы команды не переезжали децентрализованно целый год.

Запрос на таких людей приходит от бизнеса и звучит почти всегда одинаково: прототип и MVP собрать умеем, а на скейлапе ломаются надёжность и производительность, команду увеличили вдвое — скорость поставки фич прежняя. Растят их планомерно: находят внутри проактивных, дают больше не людей, а сложных технических зон ответственности, промотируют и показывают результат публично — раз Вася смог, значит, путь реальный. Уровни привязаны к масштабу: начинающий индивидуальный контрибьютор стоит на грейде синьора, продвинутый тимлид «в полный фарш» — на грейде staff, а staff редко работает в одной команде, обычно это несколько команд домена, условно отдел человек на пятьдесят. Следующая ступень — от двухсот до двухсот пятидесяти человек, дальше — компания больше чем на десять тысяч инженеров, а fellow — уже про признание в индустрии. Вдобавок такие инженеры ведут профессии: тулинг, унификация стека, ревью чужих заявок, собеседования, деврел. С рынка их нанимают через отдельные секции: язык и код, системный дизайн и разбор кейсов кандидата, который назвали архитектурой процесса разработки.

Как понять, что в проекте завёлся такой инженер? Глеб перечисляет симптомы: сборка внезапно стала быстрее, реже флапает, лучше катится, а через полгода вся команда живёт в TBD, — и называет таких агентами изменений. Собеседник отшучивается, что слово неудачное, и предлагает вместо него правило бойскаута: идёшь по парковке, видишь окурок — донеси до урны, потому что обычно рассуждают иначе: плохой код лежал тут пять лет, пусть гниёт дальше. Один из участников говорит, что суть в неравнодушии: если в соседней команде плохо, можно смириться, а можно взять ответственность и нести импакт через инициативу, а не через «я сказал — так сделали». Ведущий добавляет отличие: техлид не только понимает вглубь, но и объясняет, что внедряет, — его внедрение технологий одновременно коучинг по ним, а не «сконфигурил сборщик и забыл».

Риск обратный: инженер никому ничего не говорит и просто делает — это партизанщина, которая однажды переходит грань. Зал бьёт по больному: пул-реквест на тысячи файлов в понедельник — отличный способ причинить добро, ускорив сборку и обвалив скорость разработки фич. Александр, который сам рассказал про 2600 изменённых файлов, объясняет контекст: около десяти команд, банк для юрлиц, стадия после первого MVP; в прод это шло не сразу, в паре команд поломки были неизбежны, зато код разложился по библиотекам и доменам и спутанность ответственности снизилась, а он предупредил, попросил и был готов извиниться. Лучше, соглашаются участники, описать проблему до пул-реквеста и легитимизировать инициативу через профессию или гильдию, скажем по скорости сборки: непрошеное добро легко превращается в зло. Зал спрашивает и про инфляцию грейдов — она есть, но, на взгляд отвечающего, во благо. А на последний вопрос, про матрицу компетенций и формулу scope, impact и leadership, отвечают деньгами: импакт пересчитывают в заработанном и сэкономленном — как миграция платформенной команды Uber с Java на Kotlin за восемнадцать месяцев вместо десяти лет децентрализованного переезда.