TechLead-ы как способ остановки в развитии

Данная статья представляет мое личное мнение по теме необходимости техлидов.

Для начала определимся со стеком обязанностей/требований к техлиду:

1. Большой опыт

2. Инициатива (Проактивность)

3. Особый склад ума

4. Ответственность

5. Навыки лидера

Это основные качества которыми должен обладать техлид в понимании больших компаний.

Рассмотрим каждый пункт.

1. Опыт

Как известно, IT мир достаточно активен и меняется все быстрее и быстрее. Знания, актуальные сегодня, могут стать неоптимальными завтра. Всегда есть что-то, что может ускользнуть от глаз человека. Почему вообще опыт на каком-то другом проекте при решении других задач может как-то помочь в решении текущих задач. Понятно что многие задачи похожи, вот только для всех похожих задач уже давно есть публичные решения которые с легкостью можно найти в интернете.

Рассмотрим ситуацию. Есть два кандидата:

• 20 лет опыта. java 6,7,8; j2ee; jdbc and so on.

• 5 лет опыта. java 11; spring jpa; kubernetes; kafka

Если верить опыту, то брать нужно первого кандидата, ведь у него 20 лет опыта и куча решеных проблем за плечами, которые можно применить в текущем проекте. Но стоп. 2021 год. Некоторые решения давно устарели. Возможности языка принесли новые фичи. А нужен ли такой человек который по факту должен будет переобучать свои шаблоны решения проблем на новые реалии? (хотя тут больше вопрос что 20 лет опыта - человек техлид). У второго кандидата опыта меньше и человек не решал какие-то проблемы. Однако! В этом его плюс. Кто знает, что может придумать человек только пришедший в проект, у которого нет шаблонного мышления? Новые продукты, новые технологии, новые фичи, новые решения(новый велосипед, но велосипед велосипеду рознь).

Не замечай ошибки старца: старое дерево бесполезно пересаживать. Антисфен.

2. Инициатива

Почему считается, что инициативный человек всегда приводит к чему-то хорошему? Инициатива - это способ предоставить свою идею. У всех программистов есть свои идеи и своё видение(если нет то вы статист (статист для меня программист который пришел в сферу ради денег и в гробу видел саморазвитие и ап скиллов)). Просто не все могут их высказать в красивой/продаваемой форме. Выходит что чем красноречивей человек тем скорее его идею примут и назначат техлидом? Возьмите искусного оратора, дайте ему год опыта работы в программировании и его начнут слушать. Вам нужен такой техлид?

Мы пойдем через Морию. Фродо

3. Особый склад ума

Склад ума === навязывание образа мыслей.

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

Второй вариант - критикуемый техлид. Все выносится на обсуждение и происходит демократия. А при чем тут техлидство собственно? Получается все техлиды. Получается никто не техлид.

Наши враги тупые. Они думают, что это мы враги, хотя, на самом деле, враги - они.

4. Ответственность

Человек, готовый принять на себя удар в случае неверного решения. Щит команды. С какой целью? Чтобы команда ощущала себя не при делах? Без осознанной общей ответственности хорошей команды не получится. Каждый программист должен понимать и *сочувствовать* своему продукту.

- Почему вы это сделали?

- Мне велели голоса...

5. Навыки лидера

Лидер на уровне команды должен быть человек способный решать конфликты, сплачивать команду, поддерживать рабочий настрой. Стоп. Это же scrum-мастер.

Итого

Все эти качества в одном флаконе приведут к появлению сферического TeachLead-а в вакууме. Если техлид будет изучать технологии/искать лучшие подходы/заниматься исследованиями, то

1. Он быстро выгорит.

2. Все знания будут сосредоточены в одном месте.

Почему бы не разделить зоны ответственности между членами команды и не хранить все в одной куче? Всегда можно проводить сессии по шарингу знаниями и поднимать общий уровень команд, распараллеливать процесс. Зачем прокси в виде техлида?

Рассмотрим работу в АйТи с немного философской точки зрения.

1. Неопределенность.

   Если существует неопределенность, то вы не можете быть готовы ко всему и знать что определенный человек сможет все решить. Вы ищете пророка который знает что делать при любом раскладе.

2. Детерминированность.

   Мы знаем куда идем и знаем что будет. Но если мы знаем куда идем и знаем что будет, мы можем ко всему подготовиться заранее. Смысл в техлидстве?

Не вошедшие в статью скиллы техлида.

1. Быстрое принятие долгосрочных решений. Если проблема новая - быстро принять долгосрочное решение не получится никак. Если проблема старая - ее уже давно решили и описали в соответствующих статьях.

2. Умеет видеть проблемы - возложить всю внимательность на одного человека? Чем будут заниматься другие?

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

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

В сухом остатке. IT сфера - это сфера живых умом. А людям с живым умом не нужно техлидство. Им нужна свобода и шаринг знаний. Хватит набирать/иметь техлидов. Начните набирать/обучать активных джунов/мидлов.