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