Нанимать действительно лучших: советы от фаундера StackOverflow
Какой совет стартаперы получают чаще всего? Нанимайте только лучших. Никогда нельзя в процессе приема сотрудников идти на компромиссы. Все это верно — отличная команда может взять средненькую идею и трансформировать ее в лучший в мире продукт. Однако, кофаундер Stack Overflow и автор блога Coding Horror Джефф Этвуд считает, что во всем этом есть кое-какое слабое место. Ведь по факту, совет звучит как "нанимайте лучших специалистов, что есть в вашем городе" — а это уже совсем другое дело.
Возьмите любой город — везде одно и то же. Мы подменяем понятие найма лучших из лучших получением в команду лучших людей из тех, что находятся неподалеку.
Назовите меня психом, но я считаю, что раз уж речь идет о том, чтобы правда брать на работу только самых лучших сотрудников, то неплохо бы именно так и поступать. А значит, стоит (по крайней мере, в сфере IT) уже забыть идею о том, что для выполнения любой мало-мальски важной работы люди должны физически сидеть в офисе. Есть путь получше.
Когда мы с кофаундером запускали StackOverflow (ныне StackExchange) в 2008 году, компания состояла из меня в офисе в Беркли, проводящего ежеденельные созвоны с Джоелем Спольски, сидящим в Нью-Йорке. Затем команда расширилась, к нам присоединились разработчики из Северной Каролины, Орегона и Техаса. Потом появился коммьюнити-менеджер из Флориды, еще пара разработчиков из Великобритании и Германии. Я больше не часть компании (в 2012 году Этвуд покинул StackExchange, чтобы проводить больше времени с семьей - прим. ред.), но в последний раз, когда я там был, размер команды составлял примерно 150 человек.
Все это научило меня одной простой вещи — куча просто восхитительных разработчиков живут далеко за пределами Кремниевой Долины. Если вы нанимаете людей со всего мира, а не только тех, что живут в конкретном городе (пусть даже забитом талантами Сан-Франциско) или готовых переехать, то только тогда вы можете действительно сказать, что берете на работу лучших из лучших.
Мой нынешний стартап Discourse — это платформа для общения, в которой неважно, где конкретно находятся участники дискуссии. Я уверен, что внутренняя структура современных компаний должна соответствовать аудитории проекта. Если вы хотите аудиторию со всего мира, почему у вас работают только люди из одного города?
Привлечение удаленных сотрудиков может показаться какой-то прорывной идеей, может, так оно и есть. Но, как однажды сказал основатель киберпанка Уильям Гибсон, будущее уже наступило, просто оно еще не очень широко распространено. Взгляните на GitHub, где как минимум две трети всех сотрудников работают удаленно, или на WordPress, где большинство из 225+ работников также не сидят в офисе. Эти компании изменили ландшафт веба, и удаленная работа — это часть их ДНК.
"Покажи работу" vs "покажись на работе"
Тот факт, что кто-то светит лицом в офисе каждый день, еще не значит, что он работает. Это бизнес, а не уроки физкультуры в старших классах — никто не должен получать хорошую отметку только за то, что не прогуливает.
Гораздо продуктивнее оценивать работу по результату:
- Как много фич реализовал работник на этой неделе?
- Как много багов он исправил?
- Как много раз общался с клиентами?
- Насколько быстр написанный им код? Насколько он компактен? Легко ли его поддерживать?
В Discource мы всегда смотрим логи коммитов на GitHub, чтобы понимать, насколько качественная была проделана работа. Это не значит, что мы прямо изучаем каждую строчку, чтобы обнаружить какой-то косяк, но идея такова, что вы должны проводить мониторинг, чтобы на практике знать о крутости своих работников.
Может быть, вы используете Asana или Basecamp, сами средства не так важны. Важно лишь одно:
Дайте людям возможность отметить тот факт, что они сделали полезное дело. Не список задач, а список выполненных задач.
Мне плевать, когда наши сотрудники приходят на работу или какой у них распорядок дня. Мне совершенно безразлично, где в мире они живут (лишь бы там был хороший интернет). Меня даже не интересует, как именно они работают. Я не фанат микроменеджмента. Если вы наняли лучших, так дайте им доказать этот факт своей работой и ее результатом.
Как узнать, что при таком подходе все идет как надо? Когда тот, кого вы наняли, видит какую-то проблему (небольшую неполадку или крупный баг) и сам проявляет инициативу в ее исправлении — вот тогда все верно. Когда вы спокойны, давая людям свободу действий (а значит, и простор для совершения ошибок) — только тогда все будет работать.
Нанимайте по результатам тестового проекта
Скажем, кандидат прошел базовые тесты, у него отличное портфолио, он культурно вам близок, и вы даже созвонились по скайпу. Похоже, надо брать?
Но я видел кандидатов, которые были как из примера выше, все было чудесно, но, попав в компанию, они не могли выполнить свою роль.
Если вы действительно хотите понять, насколько вам будет комфортно работаться с конкретным кандидатом, насколько он крут, то есть смысл дать ему тестовый проект. Это можно сделать еще до того, как дать человеку возможность пообщаться с кем-то из вашей команды. Мы говорим не о какой-то абстрактной проблеме, а о реальном мире, когда у вас наверняка есть какая-то задача, которую надо сделать "вот прямо сейчас". То, что вы бы дали своим сотрудникам, если б они не были и так завалены работой.
В идеале, ваш тестовый проект должен быть реальной консалтинговой задачей с почасовой оплатой, определенными задачами и целями. Выберите проект, который можно сделать за пару дней, или за неделю-две. Предоставьте кандидату выбор — работать в офисе или удаленно.
Наверное, не у каждого бизнеса найдутся подходящие задачи, но надо понимать одну важную вещь:
Если вы не можете придумать тестовый проект для перспективного кандидата, возможно у вас неправильно выстроена структура работы в компании даже для текущих сотрудников.
В StackOverflow у нас были некоторые открытые компоненты, так что мы давали кандидатам возможность поработать над идеями из нашего вишлиста. В итоге мерилом успеха была способность работать независимо, четко и ясно общаться с нами и выдавать нужную функциональность в установленные сроки.
Если тестовый проект проходит хорошо, то круто — теперь у вас есть высококвалифицированный кандидат, который может реально делать какие-то вещи. До сегодняшнего дня я не видел ни разу, чтобы кандидат, выполнивший тестовый проект, потом провалился в дальнейшей работе. Если же все прошло не очень, то радуйтесь тому, что плата за возможную неудачу при найме сотрудника была бы куда выше, чем то, что вы почасово ему заплатили за мини-проект. Самое плохое, что с вами может в таком случае произойти, так это придется провернуть все еще раз с другим кандидатом.
Нанимайте из своего сообщества
Я много раз убеждался в том, что культурная совместимость куда важнее для конечного успеха, чем абстрактные навыки. Но как создать эту культуру, если ваша команда физически находится в разных местах?
Не у каждого бизнеса есть сообщество пользователей и последователей того, что они делают, но если у вас все-таки такое сообщество есть, то вы должны стараться как не знаю кто, чтобы нанимать людей только оттуда. Это ребята, которые разбираются в том, что вы делаете, чуть ли не лучше вас самих, они уже лояльны к компании и разделяют ее философию. Шансы на то, что кандидаты из такой среды окажутся правильными людьми, крайне высоки, а это именно то, что вам нужно.
Парочка пользователей сделала мод к вашей игре? Опытные пользователи форума отвечают на вопросы новичков на форуме? Какой-то инженер нашел дыру в безопасности и сообщил вам об этом? Вот те люди, которых вам надо нанять. Чтобы повысить шансы на успешную сделку, начните поддерживать таких растущих звезд с самого начала, уделяя им больше внимания, предлагая какие-то специальные плюшки, оцените их заслуги публично.
Мы наняли первого инженера в Discource, основываясь на результатах open source-проектов, доступных на GitHub, как и планировалось. В StackOverflow мы наняли целый список "желанных людей", которые были вовлечены во взаимодействие с коммьюнити.
Даже если у вас маленький стартап или вы еще не вывели продукт на рынок, шансы все равно остаются. Наверняка существуют и другие сообщества, которые соответствуют вашим представлениям о том, каким должен быть продукт, что за люди будут им пользоваться. Попробуйте найти такое сообщество и пообщаться с его членами, рассказав о том, что вы делаете, как это может быть им полезно, и чем именно они могут помочь.
Есть и довольно неожиданная мысль — попытайтесь найти сообщества, участники которых крайне не удовлетворены тем, как идут дела в индустрии или в вашей области в текущий момент. Тут может быть тяжеловато войти в контакт, но если вам удастся объяснить, что ваш продукт — это именно та штука, которой им не хватало на рынке, — то вас сразу же поддержат.
Ежедневно используйте публичные средства связи
Когда у вас есть удаленные работники, то вы можете использовать средства связи только тогда, когда того требует ход проекта, в который они вовлечены. На самом же деле, общаться надо все время, это часть работы.
Не ограничивайте важную информацию разговорами у кулера и проходными беседами, профит от которых могут получить только непосредственные их участники.
Есть несколько фундаментальных вещей, которые должны быть реализованы в любой компании с удаленными сотрудниками:
Онлайн-чат
Если ваш сотрудник живет в Южной Африке, вряд ли вы сможете пройтись до его стола и задать парочку быстрых вопросов или указать на баги в недавнем коммите. Вам нужно средство, с помощью которого вы могли бы вскользь давать комментарии удаленным сотрудникам и так же быстро получать ответ. Это средство должно быть легким в использовании и доступным всем членам команды в любое время дня и ночи. Hipchat, Slack, IM, IRC, какие-то веб-средства, лазерные указки, дымовые сигналы, почтовые голуби, телефон из баночек со шнурком — неважно. Главное, чтобы это средство использовали все.
В Discource мы экспериментируем со , который нам очень нравится, но это средство работает лишь потому, что им пользуется каждый из нас каждый день. Чат — это наиболее важная и всеобъемлющая форма коммуникации в том случае, когда люди работают удаленно, так что, прежде чем двигаться дальше, вы должны подобрать себе самый лучший вариант чата.
Онлайн-доска объявлений
Понятное дело, ваши удаленные сотрудники знают детали своих проектов, но как насчет всего остального, происходящего в компании? Как они узнают новости, информацию об апдейтах, каких-то объявлениях, где им прочитать саммари встреч, прошедших в офисе? Для всего этого нужна виртуальная доска объявлений. Вам нужно нечто, что заполнит пробел между почтовой рассылкой и чатом, там должна быть возможность подписаться для получения оповещений о каждом посте или просматривать обсуждения в вебе. Также каждый член команды должен получать автоматические недельные/дневные отчеты.
Важный момент — все эти оповещения и рассылки должны реально содержать важную информацию. В тот момент, как сотрудник подумает что-то типа "прочитаю эту фигню, когда будет время", это средство перестанет работать. Так что пресекайте флуд: все, что публикуется в таком публичном пространстве, должно быть важным и интересным.
Голосовой и видеочат
Как бы я ни любил ASCII, иногда символов на экране недостаточно, чтобы передать всю полноту чувств и эмоций человека, стоящего за ними. Когда вы обнаружите, что пишете и читаете килобайты текста, но все равно не удовлетворены четкостью и ясностью общения, то стоит прибегнуть к звуковому общению.
Никогда не стоит недооценивать силу обычного разговора с другим человеком. Понятное дело, что большинство тех, кто идет в программирование, терпеть не могут говорить с другими людьми, но факт остается фактом. Вы можете оказаться лицом к лицу с членами своей удаленной команды без необходимости лететь к ним 6 часов, так что надо этим пользоваться.
Следующий этап — созвоны в Skype или Google Hangouts, где вы сможете видеть друг друга. Это позволит вам "считывать" все нюансы, теряющиеся в случае чата — язык тела и мимику еще никто не отменял. Я рекомендую устраивать видеочаты хотя бы раз в неделю, не нужно растягивать их по времени, но это очень важное средство для сохранения понимания с другими членами команды.
Нет в мире человека, который бы ненавидел встречи и прочую чепуху больше меня, но для сохранения эффективности работы удаленных сотрудников есть какой-то минимум необходимых действий.
Командные отчеты по понедельникам
Каждый понедельник каждая команда в вашей компании (даже если команда у вас всего одна) должна представлять краткий бриф, включающий информацию о следующих вещах:
- Что мы сделали на прошлой неделе.
- Что мы планируем сделать на этой.
- Какие есть преграды, мешающие достижению целей.
Это не должен быть длинный доклад, нет. Чем короче, тем лучше, но надо охватить все важные моменты. Эту информацию стоит публиковать в виде еженедельных email-дайджестов. Если у вас толком нет команд, такую работу можно осуществлять на уровне каждого разработчика, хотя тут уже возникают сомнения в целесообразности.
Так бывает совершенно всегда — с ростом компании люди разъединяются, они не знают о том, что делают другие люди, в чем смысл их работы.
Конспекты встреч
Каждый раз, как вы участвуете в чем-то, что можно назвать "встречей" или "совещанием", протоколируйте все, что на ней говорится. Да-да, просто записывайте на листок список из буллитов с важными тезисами, которые затем можно будет передать тем удаленным работникам, кто прямо сейчас не может быть рядом с вами.
Опять же, записи не должны быть многословными, и если для вас проблема кратко записать все, что обсуждалось на встрече — значит, это была какая-то неправильная встреча. Небольшого списка обычно бывает достаточно. Не надо записывать все мелочи, только основные моменты. Какие темы обсуждались? Какие приняты решения? Каковы следующие шаги?
Естественно, все это надо опубликовать в чат или на доску объявлений, чтобы все могли прочитать информацию.
Мы обсудили много важных вещей, теперь пора поговорить о моментах, когда, по моему мнению, удаленная работа не совсем оптимальна.
Брейнсторминг
Это, пожалуй, самое главное. Если у вас часто проходят встречи для поиска идей, то подключаться к ним в удаленном режиме — не лучший вариант. Физическое присутствие в комнате, где люди придумывают новые штуки, возможность видеть лица коллег, слышать их голоса — все это крайне важно для генерации идей.
Положительный момент здесь в том, что такие встречи (хотя бы по опыту Stack Overflow и Discource) обычно крайне редки. А когда их-таки надо провести, то это можно сделать в режиме "раз в год на природе всей командой", собрав в кой-то веки всю команду вместе.
Например, на ежегодной встрече в StackOverflow в 2010 году мы расставляли приоритеты для компании с помощью веселого голосования, и в качестве цели номер один ("Большой волосатой амбициозной цели", как мы ее назвали) выбрали "войти в число топ-50 сайтов в интернете". С тех пор эта цель была достигнута, и каждый чувствует, что внес в ее реализацию свой вклад.
Менторство
Процесс обучения младшего сотрудника старшим, включает кучу вопросов со стороны первого. Старшему товарищу приходится часто на него отвлекаться и давать обратную связь. В удаленном режиме делать это очень трудно.
Мы "решали" этот вопрос, избегая нанимать таких людей, к которым надо приставлять ментора. В StackOverflow и Discourse мы нанимаем людей с высоким уровнем экспертизы не потому что не верим в таланты молодежи (верим-верим), но потому что учить их удаленно — это непрактично. Если вы нанимаете удаленных сотрудников, то это должны быть самодостаточные ребята, либо нанимать их не надо. Менее опытный человек может прекрасно справляться с самим фактом удаленной работы, быть ответственным и так далее, но если между сотрудниками удаленной команды есть разрыв в уровне навыков, то это неизбежно приведет к падению продуктивности.
Если ваша стратегия заключается в выращивании из джуниор-разработчиков сениоров, то необходимо выделять время, когда они будут работать вместе. Парное программирование — отличный вариант.
Теперь, когда мы обсудили все недостатки и достоинства удаленной работы, представьте себе, как будет выглядить "цифровая работа" через 20, 40 или 60 лет? Неужто вы думаете, что ее будут делать люди, по несколько часов в день сидящие в пробках, чтобы добраться до офиса?
Неужели вы думаете, что нанимать следует, основываясь на представлениях десятилетней давности, а не на том, как люди будут работать десять лет спустя?
В случае моих компаний StackOverflow и Discource, найм людей со всего мира давал стратегическое преимущество. Я уверен, что удаленная разработка — это будущее работы. Если мы потратим немного времени на то, чтобы понять, как лучше реализовать такой режим в каждой конкретной компании — оно того стоит. Будущее уже наступило. Так чего же мы ждем?