Самый громкий разработчик не обязательно гений

0
454
views

Перевод статьи «Your loudest engineer is not a genius».

Люди склонны всячески приветствовать уверенность. На собеседованиях мы больше благоволим людям, выражающимся громко и смело, с высоко поднятой головой. Эта тенденция особенно характерна для американцев, наиболее очевидным свидетельством чего является нынешний президент Соединенных Штатов Дональд Трамп. В конечном итоге, большинство психологов сходятся во мнении, что он чрезвычайно самоуверен. Несмотря на свои неудачи в бизнесе и сфере недвижимости, он продолжает считать себя умнейшим человеком на Земле. К сожалению, есть много областей, где люди, подобные Трампу, получают повышение по службе, и разработка ПО не является исключением.

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

Громкие разработчики

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

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

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

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

В чем проблема продвижения более громких сотрудников

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

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

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

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

Что же делать?

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

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

И еще одно. Возможно, вы читаете это и думаете: «Это все, конечно, хорошо. Но что, если мой самый громкий разработчик действительно гений?». Может, у него докторская степень по физике или четыре степени магистра, или он написал собственный игровой движок и продал его Bethesda. Даже если все это так, подумайте, действительно ли он будет хорош именно в качестве лидера.

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

Итоги

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