В задачи тимлида входило три круга вопросов: технические, организационные и психологические. Во-первых, тимлид был техническим специалистом, чаще всего разработчиком, и должен был принимать архитектурные решения в своем проекте, смотреть код, по возможности писать код, оптимизировать работу приложений, искать пути технического усовершенствования компонентов проекта, пристально следить за состоянием модели данных и взаимодействий приложений между собой и базами данных. Круг подобных вопросов был широк и здесь тимлид выступал как старший разработчик и архитектор. В рамках этого круга вопросов тимлид мог быть демократичен и принимать решения в совете с подчиненными или более авторитарен, навязывая свои решения коллективу. И здесь при любой более-менее большой команде начиналась «политическая» жизнь команды, на свет выходили вопросы власти и подчинения, конкуренции, мобилизации, пассивности и апатии. Если команда не доходила до подобной политики, это означало, что общение между участниками поверхностно, вовлечение в проект низкое, следствием была низкая продуктивность. Способность использовать «политическое» как инструмент, влияющий на эффективность команды, была опасным и редким навыком высококлассного тимлида.
Следующим набором вопросов, решаемым тимлидом, была организация процесса разработки внутри команды. Эти вопросы были связаны с предыдущими. При хорошей архитектуре проекта и высокой технической компетентности команды можно было организовать достаточный набор устойчивых стендов разработки, автоматический деплой на эти стенды из единого репозитория проекта любой ветки кода, прозрачную структуру самих проектов в репозитории, автоматическую работу статических анализаторов и прогон автотестов. Впрочем, были нередки проекты, где разработчики делали ручную сборку проекта и самостоятельно выкладывали каждый артефакт на стенд для тестирования, где покрытие тестами почти отсутствовало и где для любой операции с кодом требовалась вовлеченность нескольких участников. Сделать слаженный конвейер разработки от получения требований заказчика и фиксации их в таск-трекере через ревью этих задач командой, разработку, тестирование, код-ревью к выкатке релиза было нетривиальной задачей и не каждый тимлид был к ней готов. Эта была менеджерская, управленческая работа, требовавшая непрестанного контроля и исправления неэффективностей. Менеджер никогда не брал ее на себя, так как в сущности и не знал, что нужно технарям, и был заинтересован лишь в выполнении задач заказчика. Лидер технарей должен был взять на себя эту ношу.
Последним, замыкающим набором задач тимлида были вопросы психологические. Они также были связаны с вопросами организации и техники в команде. Психология команды юных новичков-студентов отличалась от психологии зрелых сеньоров с женами и ипотеками. Любое нестандартное в сравнении с среднеотраслевым распределение участников по гендеру, культурным особенностям, языку, навыкам, возрасту также накладывало свой отпечаток на работу тимлида с командой. Тимлид был обязан навязать коллегам общий стиль коммуникации и некое видение, объединяющее отдельных людей в единую команду. В случае, если такого не происходило, если команда была только на бумаге, эффективность работы была низка. Деятельность тимлида мало отличалась от работы тренера футбольной команды в этом аспекте. Если он не справлялся, по полю бегало одиннадцать не слаженных хулиганов без царя в голове. Если же ему удавалось сделать свою работу, то на поле выходила эффективная машина, где каждый знал и любил свою роль, четко взаимодействовал с другими, видел свою и общую цель. Взаимная поддержка при личной ответственности каждого делала разрозненных индивидов единым организмом.
Обычно тимлидами становились старшие программисты. Чтобы качественно руководить командой разработки надо было иметь большую насмотренность на проекты, команды, людей в отрасли. Для приобретения такого опыта нужно было побывать и в хороших, и в плохих проектах. Нужно было насмотреться на тимлидов и менеджеров, кричащих на подчиненных, неспособных к планированию даже на пару недель вперед, технически безграмотных и психологически незрелых чтобы четко понимать, как делать не стоит. Это было необходимо, чтобы знать установки травмированных предыдущим профессиональным опытом людей, приходящих в команду. Это было важным и чтобы видеть и правильным образом взаимодействовать уже с собственным руководством, которое зачастую рекрутировалось из тех самых кричащих и неспособных.
