Маркус Бланкеншип написал колонку на Medium, где рассуждает о том, что программисты должны не только создавать код, но и заботиться о ценности продукта и бизнеса в целом — но чаще всего компании сами отбивают у них это желание.
Когда я нанял программиста Джейми в компанию ZenTech, он казался полным энтузиазма инженером. С прекрасными техническими навыками, идеями для улучшения процессов и продуктов, а также умением строить отношения внутри команды, он был очевидным выбором. Но буквально два года спустя Джейми уже был «тем самым парнем», который ничего не хочет, кроме как кодить — и чтобы его оставили в покое.
Видимо, я должен был заметить «дурные знаки». Он давно не вносил никаких технологических или продуктовых идей, как я ожидал, а его способность комфортно взаимодействовать в команде выродилась в основном с саркастические реплики. Он нередко говорил об отсутствии у нас инноваций и о «глупых» решениях, которые тормозили компанию, в основном с подтекстом «я же говорил».
Джейми, вероятно, думал об уходе из компании. Не исключено, что я даже хотел, чтобы он это сделал. Однако мы были ограничены в ресурсах, и никакая помощь не была лишней.
Так в команде появился очередной «стереотипный» программист, который «просто хочет кодить». В чём причина? Слишком много руководителей считают, что проблема кроется в самом Джейми. Если бы он был более эффективным сотрудником, трудоголиком — или хотя бы просто не таким «пофигистом» — этого не случилось бы. Так ли это? К сожалению, нет. Переход от программиста-энтузиаста к программисту, которому всё равно, не происходит в одночасье. И он начинается раньше, чем вы думаете.
Первые идеи имеют большое значение
То, как именно вы обрабатываете идеи и предложения новых программистов, посылает очень важный сигнал и создаёт предпосылки для их дальнейших ожиданий. Это определяет, будут ли они генерировать идеи в будущем или предпочтут держать язык за зубами и кодить. Конечно, некоторые идеи могут оказаться невыполнимыми в вашей среде и ситуации, некоторые могут уйти на задний план («обсудим в свободное время»), некоторые окажутся великолепными, но противоречащими внутренним нормам — скажем, корпоративной культуры.
Независимо от причин, отклонение или обесценивание идей программиста, особенно в первые несколько месяцев, — это плохой ход. Вероятно, он попробует ещё несколько раз по-разному представить свои идеи, но в конце концов придёт к выводу, что единственный способ выиграть — это не играть. Полагаю, вы не хотите, чтобы ваши программисты это усвоили. В этот момент разработчик перестаёт представлять идеи, просить о встрече с клиентами и пытаться понять, как устроен бизнес. В конечном счете, это lose-lose.
Все фокусируются на успехе, и разработчики тоже
Как и любой другой человек, разработчик стремится делать то, в чём успешен: создание кода, — если его энтузиазм насчёт изменения мира, креатива, инноваций и развития утерян. Его интерес, скажем, к доле рынка сменяется беспокоойством о том, сколько он зарабатывает, каков его тайтл и как он выглядит на LinkedIn.
Хуже всего, когда посыл «Мы не строим правильную вещь» сменится посылом «Мы не строим вещь правильно». Он научился не делать вклад в продукт, который строит компания, и беспокоится только о том, как этот продукт реализован технически.
Чему вы учите разработчиков?
Хотя вы никогда не скажете об этом напрямую, ваша внутренняя культура может транслировать установки вроде «Наша компания не любит большие идеи от маленьких людей», «Сосредоточьтесь на разработке. Мы сами выясним, что нужно клиенту», «Делай свою обезьянью работу, code monkey», «Хм, почему ты задаёшь столько вопросов, тебе нечего делать?».
Культура — это не лозунг на вашей стене и не описание миссии компании во время собеседования. Культура — это то, как люди действуют и о чём они на самом деле заботятся. Если вам интересно, какая у вас культура, посмотрите, как ведут себя люди. Если вам не нравится увиденное, измените это. Культура не диктуется, она изучается, моделируется, имитируется. Установки лидера будут копироваться на всех уровнях. Поэтому культура — не вина Джейми. Её формируют руководители команд, менеджеры, технический директор. Поэтому перестаньте обвинять Джейми и приступайте к изменения, в которых нуждается ваша культура. Чем скорее, тем лучше.
Дискуссия: а чем плохо хотеть «строить вещь правильно»?
В комментариях автору колонки возражают: замечания наподобие «мы не строим вещь правильно» совершенно нормальны — ведь, возможно, вы действительно строите вещь неправильно.
— Это правда! — подтверждает Маркус Бланкеншип. — Я хочу, чтобы мои команды создали высококачественное программное обеспечение. Но вполне можно создать высококачественное, надёжное, масштабируемое, поддерживаемое ПО, которое не добавляет никакой ценности пользователям или компании. На самом деле, не просто возможно: это происходит постоянно.
Когда инженер присоединяется к компании, он обычно заинтересован в понимании ценности того, что эта компания строит. Он хочет знать, какие факторы влияют на бизнес, что думают пользователи и т.д. Я считаю, что обсуждения таких тем очень важны для инженеров по многим причинам. Это то, что я назвал заботой о «построении правильной вещи». Если же инженеры замечают, что их голос не слышат, их идеи игнорируют или говорят «это не ваше дело», они переходят на позицию заботы только о «правильном построении». Хотя оба эти аспекта важны, и когда один из них выпадает из поля зрения инженера — это плохо.
Компании постоянно отправляют инженерам посыл, что их единственная забота — это писать код. А затем жалуются, что их команда не заботится о создании реальной ценности, резюмирует Бланкеншип.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.