Вам придется в первую очередь воспитывать вчерашних студентов или перекраивать под нужды продукта вновь пришедших более опытных разработчиков. Техлидов редко нанимают: ими не приходят – ими становятся лучшие гибриды профессионала и руководителя. Вы староста группы, с легкостью входите в командную работу и эффективно советуете, как разделиться, чтобы выиграть? Тогда вам стоит взращивать эти качества и дальше. Легко находите выход из спорных ситуаций, сохраняя хорошие отношения с обеими сторонами?
Вы должны вызывать естественную веру людей в ваши знания. Каждый двоечник с трепетом подходит за помощью к отличнику, цепляясь как за соломинку за возможность списать. Он верит – там будут верные ответы и полученная информация спасет его от неминуемого провала. Точно так же разработчики потянутся к техлиду, когда его решения верны: совет ускорил реализацию фичи, упростил поддержку в дальнейшем, просветил о неизвестном методе, вызвал «вау-эффект» у пользователей и благосклонность начальства. Такой человек – умеющий принимать верные многофакторные решения – станет настоящим техлидом. Истина – она либо одна, либо внушаема. Учитесь видеть единую правду или убеждать в ней остальных. Или же – оставьте попытки стать тем, кем являться не в силах, и смиренно листайте дальше.
Техлид или руководитель группы всегда хранит в себе чуткость к межличностным отношениям. Способность понимать, что движет каждым, – фундамент успеха в этой роли. Важно уметь дать мотиватор любому – желанный ли проект, новую ли обязанность – всё индивидуально, но обязано быть ведомым и контролируемым фактором, иначе человек уйдет.
Лучший носитель данного портрета исследует психологию, учится общаться и ладить с людьми, находит компромиссы между технической и полезной для продукта составляющими. Он немного политик, готов пойти на риск, не боится где-то слукавить или нарушить правила, но так, что будет во благо и допустимо лишь потому, что сами правила не так гибки, как того требует ситуация.
Помню, однажды мне предложили выкатить релиз, заведомо содержащий довольно ощутимые баги. Первая реакция – непонимание: шутка, диверсия? Разрыв шаблона для разработчика – как может подняться рука отправить в продакшен очевидно сбойный код? Но у столь смелого предложения был свой расчет: перед выкладкой приложение тщательно ревьюилось и почти всегда возвращалось на доработку в силу бюрократического и слабо детерминированного процесса в сфере тогдашнего Smart TV. Объем изменений релиза был велик, а вероятность возврата – высока, в то же время было важно соблюсти срок сдачи для заказчика. А значит, мы могли отдать на апрув приложение уже сегодня, продолжить доработки, а затем внести их в продукт с прочими мелкими замечаниями, после почти гарантированного возврата. Тем самым ускорив попадание релиза к потребителям в конечном итоге. Ловкость ума и никакого мошенничества.
Я встречала немало крутых технических лидеров