Интервью с СЕО DeckRobot Антоном Урбанасом: одинокие самураи, противодействие цунами и другие инсайты

Интервью с СЕО первого ИИ-движка для создания презентаций о его команде, разбросанной по разным континентам и часовым поясам. Оказалось, для DeckRobot это не сложности, а сплошные преимущества: не страшны ни цунами, ни Трамп, а разработка ведется 24 на 7.

Антон Урбанас семь лет проработал в консалтинге, делал тысячи слайдов, пока однажды не решил, что тратить жизнь, двигая текстовые блоки в PowerPoint, — не лучшая затея.

Понимая боль миллионов сотрудников крупных корпораций, в 2017 году Антон создал DeckRobot — первый в мире ИИ-движок для дизайна и форматирования сложных презентационных слайдов.

Компания базируется в Сан-Франциско, еще три офиса — в Киеве, Лондоне и Макати (Филиппины). Антон уже писал о запуске своего стартапа, о пути от идеи до международной b2b-компании, мы же расспросили его о том, что интересно нам, евангелистам удаленной работы, — о создании команды, разбросанной по разным континентам и часовым поясам.

Оказалось, для DeckRobot это не сложности, а сплошные преимущества: не страшны ни цунами, ни Трамп, а разработка ведется 24 на 7.

— Антон, расскажи о своей команде. Сколько вас сейчас?

— Пока мы не распространяемся о том, сколько человек в команде и кто чем занимается, потому что закрываем второй раунд инвестиций, и картина сильно изменится. Но могу сказать, что команда инженерная, основная ее часть — это ML-инженеры, а сейлзов, например, у нас совсем мало.

Мы представлены в США, Украине, Филиппинах и Великобритании.

— Как вы решили собирать команду за пределами Штатов, да еще и в разных странах? В чем была основная мотивация? В том, что в Штатах сложно конкурировать за разработчиков? Или сокращение затрат на специалистов?

— Что касается Machine Learning и Data Science, конкурировать в Долине не просто сложно, а практически невозможно. Это и было основной мотивацией.

Что до расходов на специалистов, то десять посредственных дешевых пианистов не лучше одного дорогого и талантливого, дело в первую очередь не в экономии. В Долине нанять ИТ-специалистов крайне сложно. Непросто даже для Google, не то что для стартапа.

Частая история здесь: проект из другого штата или страны привлекает большие инвестиции, а потом полгода не может нанять специалистов в Долине, в итоге возится с релокацией.

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

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

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

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

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

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

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

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

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

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

— Ты говоришь про большой пул разработчиков, который для вас открылся, про организацию процессов, позволяющих разработке работать 24 на 7. Но тем не менее от полностью распределенной команды по всему миру вы отказались и открыли офисы на Украине и в Филиппинах. Разве тем самым вы не ограничиваете себя?

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

Искать таких сотрудников — все равно что ставить критерий «голубоглазый, одноногий брюнет ростом два метра». Можно, конечно, искать таких одиноких самураев, но зачем? (Фильтра по цвету глаз пока нет, но одиноких самураев уже нашли и отобрали на 6nomads.com — прим. 6nomads.)

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

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

Мы к тому же считаем важным, чтобы люди вписывались по культуре. У нас много самостоятельности, практически нет начальства, флэт структура, не всем это нравится и не всем подходит.

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

Нас пара выбранных городов не сильно ограничивают, это удобные хабы для талантов: в Киев готовы переехать разработчики со всей Украины, из Белоруссии и часто из России. Это не сравнится по сложности с релокацией в Калифорнию. То же самое касается Филиппин, это удобный хаб для всей Юго-Восточной Азии.

Для нас нет смысла искать таланты в Западной Европе: там пул специалистов не такой конкурентный, как в Восточной Европе или Калифорнии. В Калифорнии очень дорого и очень хорошо, в Восточной Европе не так дорого, но очень хорошо, а в Западной — и дорого, и не очень хорошо, плюс там много бюрократических сложностей с наймом.

— Расскажи, как вы выстроили процесс привлечения, отбора, найма? Какие ошибки допустили, какие выводы сделали?

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

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

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

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

У нас был кандидат с очень слабым CV, без какого-либо образования в области Computer Science, из региона, где в последнюю очередь подумаешь искать сильного инженера. Если бы мы начали с просмотра его резюме, то посчитали бы бессмысленным тратить время.

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

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

В Google по многим направлениям тоже отказались от просмотра СV и нанимают по результатам тестового.

— Легко ли было привлекать сильных спецов в свой проект?

— Мы меняем то, что работает плохо последние 30 лет. Есть полмиллиарда пользователей PowerPoint со всего мира, которые мучаются с созданием презентаций почти каждый день.

Это гигантское количество человекочасов, на которое мы можем повлиять, — и уже сильно влияем. В этом есть огромный потенциал, продукт имеет вау-эффект.

Отсев по целям кандидатов происходит еще на этапе отклика на вакансию. Если кандидаты хотят спасать редкие виды зайцев от вымирания, они просто не откликаются на вакансию и не занимаются слайдами.

— Несмотря на офисы, насколько «свободно» вашим сотрудникам? И как вы научились поддерживать баланс свободы и контроля?

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

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

— А как наладить качественное взаимодействие сотрудников из совершенно разных культур? Накладывает это свои сложности?

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

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

Американских коллег можно поставить в тупик просьбой поработать на выходных, но они щепетильнее к срокам.

— Что было главным открытием лично для тебя? О чем ты не подозревал, когда брался за организацию работы распределенной команды?

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

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

#наём #удаленнаяработа