Я продолжаю брать интервью у русскоязычных IT-специалистов из Кремниевой долины. На этот раз мне посчастливилось пообщаться с Денисом Давыденко, Software Developer Manager из Amazon.

— Я учился на прикладной математике в Белорусском государственном университете и закончил его без красных дипломов и выдающихся заслуг. Одним словом, обычный программист, – так охарактеризовал свое образование менеджер из Кремниевой долины.

— Что было после университета?

— Первая работа у меня была не совсем программистской. После университета я устроился в Беларусбанк, занимался банкоматами, обслуживал отделения, тягал компьютеры туда-сюда – обычная работа для свеженьких выпускников университетов. Потом друг стал звать меня в Epam (американская аутстаффинговая компания с белорусскими корнями – прим. автора). Мне всегда было интересно заниматься программированием, просто не сложилось начать сразу, поэтому решил попробовать и ушел из банка. В Epam началась моя настоящая программистская карьера. Там я проработал около года, и потом еще один друг перетянул нас в Москву, где стал заниматься над сайтом для платежей, юзерского портала и абонентского обслуживания в крупной компании сотовой связи. Работа была довольно скучно и я решил искать дальше. Совершенно случайно нашел стартап и присоединился к команде разработчиков (главный офис находился в Лос-Анджелесе, а все девелоперы сидели в Москве). Стартап стремительно рос и СТО, который находился в США и был вынужден все больше уделять времени развитию бизнеса, решил перевезти себе в помощь несколько разработчиков из Москвы. Я стал одним из них.

— Чем занимался стартап?

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

— Когда произошел твой переход из программирования в менеджмент?

— По приезду в США я, как и предполагалось, стал заниматься технической стороной стартапа, но поскольку вся разработка по-прежнему была в Москве, кому-то нужно было заполнять пустоту между product-менеджментом и технической частью – девелоперами. Собственно, этим я и занимался, поэтому пришлось перейти в более менеджерскую деятельность.

— Получается это было вынужденным решением?

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

— С какими сложностями ты столкнулся во время «превращения» из программиста в менеджеры?

— Самые большие трудности были в том, чтобы научиться работать с трудными программистами. Это такие rock-stars, которые просто перформят на 120% постоянно, но при этом жуткие интроверты. Они не хотят общаться, и очень слабо подвергаются управлению. Как правило, эти девелоперы устанавливают собственный курс действий, который может мешать проекту и срывать все дедлайны. Вот сложность работы с ними заключалась в том, чтобы научиться «подвигать» их в сторону интересов проекта, чаще всего это значит пожертвовать качеством кода ради скорости.

— Вернемся к твоей истории: ты работал сначала в Лос-Анджелесе в стартапе, но потом переехал в Нью-Йорк. Что произошло?

— Наш стартап купила компания Viacom. Какое-то время мы еще работали из офиса в Лос-Анджелесе, но потом всю команду перевезли в Нью-Йорк, где находился главный офис Viacom. Там я вырос с позиции Technical Project Manager до Software Engineering Sr Director, но через 5 лет у компании начались сложности на сток-маркете – начались сокращения, в одну из волн которого попал и я.

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

— Это и так, и не так. Обычно в контракте действительно написано, что наниматель может устранить работника, не предупреждая заблаговременно и без объяснения причин, но и работник можешь уйти точно так же в любой момент. На деле же, по крайней мере в IT-компаниях, работодатель обычно предупреждает сотрудника заранее (не за 2 месяца, конечно, а примерно за неделю) и выплачивает ему выходное пособие, которое может быть от месяца и до года экстравыплат. Американское законодательство так устроено, что судить можно всех и за все, поэтому компаниям проще выплатить сокращаемому сотруднику компенсацию, чем ходить по судам и платить немаленькие деньги за адвокатов. В моем случае мне выплатили очень хорошие деньги, которые я спокойно забрал, сказал спасибо и уехал в Кремниевую долину, где живу до сих пор.

— Расскажи про свой путь в Amazon?
— Совершенно обычная история: когда меня сократили из Viacom в Нью-Йорке, я начал поиски работы, в результате которых получил оффер из Amazon. Мне понравился проект, на который меня приглашали, и, конечно, меня устроили цифрами в оффере, поэтому я, не долго думая, переехал работать в Кремниевую долину. Сначала я стал работать над голосовым помощником Alexa, а через полтора года перешёл в команду, которая занимается улучшением рекламы в поиске Amazon. Вообще при желании можно менять команды внутри Amazon можно хоть каждый год.

— В интернете встречается много разных отзывов об Amazon, часть которых о том, что из программистов и менеджеров выжимают все соки. Насколько высокий стресс на самом деле?

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

— Насколько менеджер в Amazon должен быть погружён в задачи программистов?

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

— Приходилось ли тебе увольнять людей?

— Да, на моей памяти было 3 таких ситуации. Основная проблема заключалась в том, чтобы принять решение об увольнении человека. Когда решение принято, дальше всё делается по инструкции на раз-два-три. Однако принятие решения всегда давалось довольно сложно.
Вообще я стараюсь предвидеть такие ситуации заранее и использую правило 90 дней: cначала даю человеку знать о том, что у него performance не такой, какой должен быть; потом мы обсуждаем варианты, как можно исправить ситуацию, составляем план действий. Все это происходит в режиме обычного разговора, мы не подписываем никаких официальных бумаг. А дальше каждые 1-2 недели в течение трех месяцев я мониторю, есть ли улучшения. Если после 90 дней улучшений не наблюдается, то либо человек уходит сам (например, находит другую работу), либо я отдаю его дело в отдел кадров, где для него формируют компенсационный пакет, и сокращают. К счастью, последние три года мне не приходилось никого увольнять, но если бы пришлось, то было бы уже проще. Я понял для себя, что, не увольняя человека, которого нужно уволить, я делаю хуже ему, себе и компании.

— Как устроен процесс собеседований для менеджеров в американских компаниях?

— Процесс собеседования достаточно стандартный для менеджеров и для программистов. Отличается только в соотношении технических собеседований к собеседованиям на менеджерские скилы. Конечно, у менеджеров фокус делается на управленческие навыки, а у инженеров на технические. Когда я собеседовался в Amazon, то мне пришлось пройти 6 интервью в один день, 4 из которых были на управленческие аспекты и 2 на технические. У инженеров наоборот.
Уже несколько лет я вижу собеседования в Amazon с другой стороны – со стороны интервьюера. Обычно я задаю кандидатам на менеджерскую позицию вполне стандартные вопросы и смотрю на 3 аспекта: как человек может разрулить проблемные ситуации, как человек управляет рисками и как коммуницирует. Что касается технических собеседований для менеджеров, то они более высокоуровневые: во время интервью в Amazon вас не станут просить решить какой-нибудь алгоритм, скорее задание будет, например, задизайнить систему для библиотеки.

— Ты назвал 3 управленческих аспекта, которые проверяешь у кандидатов во время собеседований. Какие вопросы ты задаешь?

— Пример вопроса, который я могу задать: «Расскажите нам о ситуации в Вашем личном опыте, когда у Вас горели сроки и Ваш проект зависел от какую-либо другой команды. Что Вы делали?» В менеджерской практике это довольно частая ситуация, поэтому очень важно, как потенциальный работник себя в ней ведет, что именно он рассказывает, какие приводит доводы, пытается ли он рассказать о том, что делала команда или может вычленить свой взнос в общее дело. Конечно же, предпочтение отдаётся тем, кто может рассказать о том, что он сам сделал. Как он сам повлиял на ситуацию.

— Все вокруг говорят о дефиците сотрудников в IT-индустрии. Как Amazon удерживает работников в компании?

— Конкретными зарплатами, довольно легким процессом смены команд (стало скучно работать на одним проектом, всегда можно найти что-то более интересное) и вниманием к развитию карьеры. Например, одна из важных обязанностей менеджера – планирование карьеры своих сотрудников. У нас есть еженедельные митинги тет-а-тет с каждым программистом, и мы используем их в том числе для обсуждений возможного карьерного роста. Разговариваем о том, видит ли программист себя в будущем в менеджером или хочет развиваться в программировании, в зависимости от желания планируем путь к переходу в менеджеры или на следующий программистский уровень. Это всегда очень индивидуальный процесс: одному нужно вырасти в плане коммуникации, другому не хватает design скилов, третий просто очень интровертен и не может показать всему миру, какой он классный программист и как много всего он сделал. К сожалению, в больших компаниях недостаточно просто хорошо работать. Необходимо ещё и показать всем, что ты хорошо работаешь.

— Расскажи о методологиях, которые используют в Amazon?

— Я встречал минимум две методологии, которые используют в Amazon. Первая – это Scrum, вторая – Kanban. Конечно, в основном, вижу, что используется S.C.R.U.M., потому что она позволяет дать видимость менеджерам в том какие проекты и когда будут сделаны. Соответственно можно планировать развитие бизнеса, можно объявлять сроки и устанавливать ожидания. Но мне приходилось работать и с Kanban. Когда на проекте полный аврал, все кричат, бегают, выдирают волосы на себе, мы переключаемся на 3 месяца на Kanban, чтобы разгрести проблемы и выплыть на поверхность. Waterfall я не видел, по крайней мере, в Amazon, и стараюсь не прибегать к этой методологии. А других я не знаю.

— Как в Amazon оценивают performance программистов?

— Вообще performance-оценка происходит не только для программистов, но а вообще для каждого сотрудника, даже для VP есть оценка performance, и имеет одинаковый формат.
В конце каждого года каждый человек в команде анонимно пишет небольшой отзыв о работе остальных членов команды c точки зрения трех критериев: value delivery (насколько много пользы привносит человек в работу), communication (насколько с человеком легко коммуницировать в работе) и visibility (видимость того, что человек делает).
На основание всех отзывов составляется такой агрегированный подсчёт того, насколько хорошо каждый из членов команды сработал, и выставляется некий рейтинг, который даётся каждому программисту. Вот собственно и всё.

— Какие советы ты можешь дать менеджерам, которые хотя попробовать свои профессиональные силы в США?

— Совет номер один – убедиться в том, что хорошо умеете общаться по-английски. Это означает, что вы можете быстро подключиться к любому рабочему разговору с любым англоговорящим человеком и свободно общаться. Конечно, иногда можно и переспросить, но не открывать словарь по каждому слову. Второй совет – максимально разузнайте о менталитете и культуре страны, в которую вы едете. Это намного важнее, чем кажется, потому что культурные различия могут разрушить любые профессиональные планы. И последнее – попытайтесь понять, чего ждете от переезда до того, как окажетесь в новой стране, и оставьте за собой право на ошибку. Если вы едете с намерением оставаться, то установите для себя чёткие рамки, что значит для вас «оставаться» и в каком случае вы готовы вернуться обратно.