В среднем по айти мнение такое, что техлид - это просто самый опытный программист, который еще и умеет управлять командой. На самом деле, это немного узкие рамки. Переходя на эту роль, задача техлида переключиться с индивидуальности на общее и стать мультипликатором для остальных (и немного быть играющим тренером).
Технологии и инструменты уже не для прокачки себя самого. Они только для реализации стратегии. И вот как это может поменять наше видение работы:
1️⃣"Закрывать таски" ➡️ "создавать рычаги"
Даже если мы будем закрывать х2 больше тасок от среднестатистического работяги, то в целом командой не станем эффективнее другой, где копателей на одного больше. Давайте решать не узкие, а общие проблемы. Допустим:
▫️Пишем первую реализацию нового паттерна сами. Просто шаблончик или верхнеуровневая архитектура, к которому команда или гпт смогут возвращаться. Буквально на своем примере - хоп, и набросали
▫️Снижаем риски через Proof of Concept. Команда сомневается в каком-то решении? Берем и
▫️Прыгнуть в самый сложный баг или рефакторинг, который все боятся трогать. Необязательно даже полностью самому решить его, важно просто найти узкие моменты и предложить варианты решения проблемы
▫️Растить коллег через правильно выстроенный Code Review. Через него мы менторим и обеспечиваем качество
2️⃣"То, что модно и молодежно" ➡️ "То, что выгодно"
Кстати, тут небольшая поправка - иногда стоит брать ответственность и пробовать то, что модно и молодежно. Стажер предлагает новую технологию, потому что она крутая. Синьор предложит то, что работает. Техлид, как инвестор в технологию, оценивает потенциал через призму общей стоимости владения и через попытки разобраться:
▫️Решает ли новая таска бизнес-задачу или уменьшает техдолг?
▫️Сколько это стоит на самом деле? С учетом найма, обучения, поддержки в 3 часа ночи и сложности интеграции?
▫️Как это вписывается в наш технологический стек?
Также напомню про техрадар, чтобы управлять стеком чуть более осознанно. Сюда же напомню про ADR, чтобы записывать важные решения в маленьких документах.
3️⃣"Глубинное знание" ➡️ "Широкое понимание"
Синьор знает свою область очень глубоко (I-shaped). Техлид должен иметь широкое понимание всей системы и связей между ее частями, чтобы предвидеть проблемы на стыках компонентов: тут скорее T-shaped или M-shaped. В современном мире я думаю мы все потихоньку становимся M-shaped. Как прокачивать широту:
▫️Держим архитектурную диаграмму (C4 Model) в актуальном состоянии
▫️Держим себя в курсе инцидентов (Post-mortems)
▫️Почитываем чужие ADR-ы в разных частях системы (либо слушаем на демо), даже если мы не ревьюим эту часть
Техлид, который не пишет код, превращается в оторванного от реальности архитектора из башни. Но техлид, который только и делает, что пишет код, это просто дорогой синьор. Можно просто добавить немного стратегической щепотки для понимания из чего строить и зачем - и развиваться намного лучше
@teamleadosh
#career