Про разницу тимлида и техлида

Есть значит две очень похожие позиции, между которыми определенно есть разница. Но какая? Если в голову приходит что-то вроде: «тимлид большо про команду, а техлид про технологии», то этот пост для вас!

Когда я думаю про этот вопрос, то сразу вспоминаю про один довольно старый видос (уж не помню, кто автор), в котором говорилось примерно следующее: «Даже если в команде вас двое, разделите зоны ответственности. Пусть один отвечает за планирование и задачи, а второй за техническую часть реализации». Это довольно логичное разделение зон ответственности. Важно понимать, что решения в любом случае лучше принимать сообща (две головы лучше и все дела), суть разделения в том, что оба человека имеют право на окончательное принятие решения. Теперь про каждую роль отдельно:

Тимлид По сути является микроменеджером, кто-то скажет, что это прослойка между разработчиками и бизнесом, но это не всегда так и правда лишь отчасти. Занимается в основном распределением человеко-ресурсов для достижения целей бизнеса, помогает команде правильно распределять и планировать нагрузку.

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

Суровая реальность На практике все звучит хорошо: техлид принимает технические решения, тимлид больше работает с командой, но в реальности все совсем не так. У всех свои представления о роли лида разработки, поэтому и задачи для них могут различаться: Где-то от тимлида просят и принятие технических решений, а где-то техлид, это тот же тимлид, но называется иначе. У руководителей разные представления об этих ролях, которые они и транслируют на подчиненных, отсюда и разница в обязанностях и зоне ответственности.

Хорошо это или плохо? Считаю, что это нормально. При собеседовании на должность важно уточнять свои интересы и синхронизироваться в представлениях о работе. В конце концов вы сами решаете, соглашаться с чем-то или нет.

О своем опыте Так уж получилось, что я выполнял несколько ролей на одном из мест работы: тимлид, техлид, архитектор. Звучит как полная дичь, но все не так плохо, и тут стоит пояснить почему: Во-первых нагрузка по этим ролям неравномерная. Например, если мы берем роль тимлида, то наибольшая нагрузка будет на этапах планирования, когда требуется оценить и распределить задачи или на роли техлида при проработки большой фичи, когда требуется решить множество технических нюансов. Во-вторых тут сильная зависимость от зрелости команды, проекта и процессов. Если команда достаточно зрелая, то потребуется сильно меньше времени, чтобы распределить задачи или разжевать технические детали реализации. Я бы не стал разжевывать рекомендации по разработке бэкграунд-задачи для senior-разработчика в проекте, где таких задач уже достаточное количество. В-третьих важно понимать общее количество активностей для разных проектов. Для проекта на поддержке не требуется много времени для принятия технических решений, так как новой функциональности практически не добавляется.

Итог Реальность как обычно расходится с миром грез и розовых пони. Бизнес не всегда разделяет техническое и командное лидерство. Где-то потому что не понимает разницу, где-то потому что это не требуется. К этому не стоит относиться как к чему-то плохому. В конце концов мы сами решаем чем будем заниматься, главное уметь об этом договориться.