Техлид или архитектор: где заканчивается команда и начинается система

Техлид стоит вплотную к коду и к команде и отвечает за качество исполнения внутри своего периметра. Архитектор мыслит системой целиком или крупным доменом: его предмет – связи между частями и их эволюция.

Разница в уровне, на котором человек работает.

🛠 Техлид: команда и её код

Периметр – одна команда и её сервисы, горизонт – недели и кварталы.

Предмет решений: структура модулей, выбор библиотеки из одобренного стека, стратегия тестирования, порядок рефакторинга.

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

Измеряется предсказуемостью поставки команды, DORA-метриками и ростом людей.

🌐 Архитектор: система целиком или крупный домен

Периметр – домен, который переживёт любую конкретную команду, горизонт – кварталы и годы.

Предмет решений: границы сервисов, контракты между доменами, эволюция модели данных, consistency-модель, где и как хранятся данные.

Влияние идёт через артефакты, которые работают, когда его нет в комнате: ADR доменного уровня, fitness-функции в CI, целевая картина эволюции.

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

По Ларсону этот архетип обычно проявляется, когда организация дорастает до сотни инженеров; до этого архитектурную работу делают техлиды.

🚪 Тест на обратимость

Уровень проверяется стоимостью отката.

Решение откатывается силами одной команды за спринт – оно техлидское, two-way door.

Нужно координировать три команды и мигрировать накопленное состояние – архитектурное, one-way door.

♻️ Правило Фаулера

Ценность архитектора обратно пропорциональна количеству решений, которые он принимает лично.

Архитектор, который централизует всё важное, потому что не доверяет командам, у Фаулера называется Architectus Reloadus.

Рабочая модель – растить команды до уровня, на котором они забирают сложные решения себе.

⚠️ Две ловушки перехода

Техлид пытается остаться самым сильным разработчиком команды: PR копятся в ожидании его ревью, дизайн-решения задерживаются, и через три месяца команда зависит от него сильнее, чем до назначения.

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

Признаки – разработчики тихо обходят рекомендации, кодовая база расходится с официальной архитектурой, команды перестают спрашивать про детали.

🎯 Свой уровень и следующий шаг

Разметьте решения месяца: периметр, горизонт, стоимость отката. Спринт и своя команда – техлид; годы и чужие команды – архитектор. Наверх ведёт кросс-командная задача, закрытая артефактом.

📆 Если разметка показала, что вы застряли между уровнями – 25 августа в 19:00 (GMT+3) проводим открытый митап [Рост после сеньора в эпоху ИИ], online.

Разбираем стеклянный потолок сеньора, диаграмму навыков и уровни компетенций, роли техлид / тимлид / архитектор, архитектора эпохи ИИ, рынок и зарплаты, пять навыков, которые ИИ не вымывает.

Ведёт Павел Вейник – Founding Architect Hard & Soft Skills, разработчик с 2003 года, ex-Architect Miro и EPAM, ex-CTO SplitMetrics, AmadoAd и Leverice. Обучил 1000+ разработчиков и 450+ архитекторов.

Матрицу компетенций пришлём письмом сразу после регистрации – на митап придёте уже с ней. Вопрос можно задать при регистрации или на самом митапе, Павел разбирает персонально.

👉 Регистрируйтесь и задавайте вопросы

📚 Что почитать:

"Who Needs an Architect?" – Martin Fowler, IEEE Software, 2003

"Staff Archetypes" – Will Larson, staffeng.com