Основа технического лидерства

Какое-то время назад я понял, что несмотря на весь свой опыт, менторство и участие в проектах с открытым исходым кодом, я имею крайне скудное представление о том, как помогать другим людям в их работе. Я видел большое количество тимлидов и менеджеров часть из которых помогала развития команды и её участников, а часть из которых разваливала команду на части, но я не до конца осознал, что именно можно и нельзя делать. Поэтому я хочу дать ниже вольный перевод отличной статьи по этой теме The Foundation of Technical Leadership.

Я фронтенд архитектор, но я также известен как технический лидер, эксперт в предметной области и ещё десятком других титулов. Я пришел к этому после пяти лет дизайна и управления, и когда пришло время выбирать дальнейший путь, я выбрал техническую роль.

Я не имею точной уверенности, что на самом деле значит техническое лидерство. Технические эксперты не всегда являются техническими лидерами, хотя они оба обладают выдающими техническими навыками. Готовы ли люди следовать за тобой? Вот важный вопрос. Вот некоторые навыки которые отличают технического эксперта технического лидера.

Помогать как будто это твоя работа.

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

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

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

Моя работа, как frontend архитектора, часто включает в себя не только написание кода, но и рефакторинг кода других разработчиков. Большое количество функций лучше бы смотрелось в качестве одного объекта - это возможно было бы написано сразу, если больше заниматься обучением своей команды.

Обучение должно быть страстью. Опыт, полученный от обучения других, возможных самый важный фактор который задержал меня на позиции фронтенд архитектора. Написание документации также cкорее всего будет лежать на вас. Каждая техническая проблема, которая вам встретиться, должна рассматриваться, как возможность для обучения других людей.

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

Не бросайте матрас в бассейн

Известная шутка может научить нас кое-чему из технического лидерства. Матрас легко забросить в бассейн, но его очень сложно достать оттуда.

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

Использование нового фреймворка это отличная идея? Вам лучше надеяться на то, что каждый в вашей команде знает этот фреймворк. Нет времени для того, чтобы сделать рефакторинг кода этого сложного объекта? Тогда не удивляйтесь когда люди начнут писать свои оберки, потому что не понимают ваш код. Оставили свой код в состояние когда его сложно прочитать изменить? Тогда Вам следует вспомнить про матрас в которую вы сбросили в бассейн...

Это одно из самых больших различий между техническим экспертом и техническим лидером: технический эксперт легко может увидеть решение проблемы, а технический лидер должен увидеть такие шаги, которые не позволят проблеме произойти заново.

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

Жерри Вейнберг в книге "Психология комппьютерных программ" писал: "Если программист незаменим, освободите его как можно быстрее". Если вы незаменимы, исправления этого должно быть вашим приоритетом. Вы не должны быть связаны одним проектом только потому, что ваша экспертиза нужно всей команде.

До использования какого-то решения, спросите себя, что будет, если вы больше не будете работать над этим проектом. Если единственный ответ "они найдут кого-то, кто будет умнее вас", то не включайте это проект.

Как технический лидер, вы должны смотреть, чтобы и остальные не делали таких же ошибок. Помните, за все технические решения несет ответственность технический лидер.

Вы не единственный эксперт

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

Нужно достаточно много мужества, чтобы признать что ты был таким парнем и не один раз. Как умный парень, я построил себе на интеллекте. Поэтому, когда мои идеи критикуются, когда мой интеллект ставится под сомнение, Я ощущаю нападение на меня. Еще хуже когда кто-то знает меньше меня. Как они могут сомневаться в моих знаниях. Они что не знает, что я технический эксперт?

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

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

Интеллект требует ясности

Кажется заманчивым делать вещи сложнее, чем они должны быть. Но, на самом деле, не требуется большого ума чтобы сделать вещь очень сложной. Даже наоборот, требуется много интеллектуальных усилий, чтобы сделать вещь настолько простой, насколько она может быть.

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

И не считайте, что вы сможете объяснить лично каждому свое решение. Иногда вы никогда не увидите того, кто будет реализовать ваше решение, но все равно обязаны отправить email с объяснениями. Развивайте свои навыки письма. Заведите блог или начните писать статьи про вашу философию программирования.

Тот же принцип применим к коду. Если код сложно читать, то обычно его писал не очень умный человек, а как раз наоборот. Мартин Фаулер когда-то сказал: "Любой дурак может написать код, который поймёт компьютер, но только хороший программист сможет написать код, который поймут люди."

Вы задаёте тон

Представьте себе, что вы пришли к доктору и объясняете ему свои симптомы. Вы сидите на стуле и немного волнуетесь. По мере вашего объяснение, у доктора расширяются глаза и начинают трястись руки. Чем больше вы говорите, тем сильнее это. Когда вы заканчиваете доктор кричит: "Я не знаю что это!".Как вы будете себя чувствовать? Что вы станете делать? Я бы сказал ему пока и ушел к другому.

Теперь представьте, что менеджер пришел к вам и объясняют функциональность сложного проекта. По мере того как вы слушаете, вы понимаете что это абсолютно неизвестная область для вас и всей компании.Вы даже не уверены возможно ли это.Как вы отреагируете? Также Как доктор? Если да, тогда я уверен, что менеджер будет также напуган как и вы.

Я не говорю что нужно врать, так как это еще хуже. Но простые слова "Я не знаю" могут успокоить менеджер, команду, клиентов и вашего руководителя(подсказка: обычно после этих слов я добавляю "я разберусь").

Люди будут следить за ваши эмоциями как технического лидера. Они будут следить не только за вашим ответом, но и тем как вы его даете.

Настоящее техническое лидерство

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

Posted in Истории on Sep 04, 2016

comments powered by Disqus