Тимлид не должен знать ответы на все вопросы. Вполне достаточно знать тех, кто эти ответы знает.
Поток информации у тимлида огромный: своя команда, смежники, продукт, процессы, технические решения. Попытка найти и запомнить ответы на все вопросы быстро превращается в отдельную работу, которая всё равно обречена на провал.
Эта ситуация напоминает мне джунов, которые зачем-то заучивают сигнатуры библиотечных методов. Даже ностальгия пробивает: перед первыми собеседованиями по C# я сам зубрил сигнатуры методов Entity Framework. Абсолютно бесполезное занятие.
Гораздо важнее уметь сформулировать вопрос и быстро найти источник ответа.
Тимлид как API Gateway
В работе нужные знания часто хранятся не в документации, а в головах других людей. Поэтому тимлид может превратиться в подобие API Gateway: сам не содержит всей бизнес-логики, но знает, куда направить запрос.
Эта метафора не снимает с руководителя ответственность. Недостаточно ответить «спроси вон у того человека» и забыть о вопросе. Тимлиду нужно:
- понять, что именно пытается решить человек;
- дать нужный контекст обеим сторонам;
- выбрать правильный маршрут;
- убедиться, что вопрос не потерялся и результат получен.
Тимлид не обязан быть самой большой базой знаний в команде. Его задача — построить сеть, в которой знания находятся и передаются без него. Приятный бонус: люди выходят за рамки команды и постепенно учатся искать ответы самостоятельно.
С появлением AI-агентов эта модель получила ещё один маршрут. Я написал об этом продолжение: «С агентами „я не знаю“ перестало означать „я не могу“».