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