Блиц-масштабирование

Сначала нанимайте нового управляющего на более низкие по уровню должности и позвольте ему или ей проявить себя. Приходя в компании, Джон вначале занимал место директора по развитию бизнеса и оперативной деятельности и переходил на более солидные должности лишь после того, как доказывал командам, в которых работал, свою компетентность и значимость. Тот же прием он применил, когда принимал на работу Шрепа, привлекая его в команду в качестве директора инжинирингового отдела. Как только у Шрепа возникла возможность проявить себя, то, по словам Джона, «всем довольно быстро стало ясно, что Шреп невероятно уверен в себе и улучшает все, к чему прикасается». Благодаря этому явному успеху его повышение до вице-президента технологического отдела стало очевидным и бесспорным.

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

По мере того как компания продвигается от стадии Деревни к стадии Города или даже Государства, вам по-прежнему нужно будет нанимать управляющих не только потому, что увеличение масштабов потребует добавления в структуру компании нескольких уровней над менеджерами, напрямую взаимодействующими с рядовыми сотрудниками, но и потому, что ваши управляющие не всегда будут обладать необходимыми навыками, чтобы проводить масштабирование до следующей стадии. Но как только в вашей организации появится эффективный управляющий, который может выступать в качестве наставника и примера для подражания, вы сможете приступить к продвижению по карьерной лестнице собственных подающих надежды менеджеров, имеющих теперь личный опыт работы с эффективным управляющим. Когда Facebook развивался, крайне важное значение имело привлечение в команду опытного управляющего вроде Шерил Сэндберг, но практически все сегодняшние руководители ключевых продуктов Facebook были «взращены» внутри компании.

Несмотря на то что предприниматели часто выступают против создания иерархии путем подразделения своих сотрудников на управляющих, менеджеров и помощников, такой тип формальной структуры крайне важен для роста, как утверждают Рейнджей Гулати и Алисия Де Сантола, которые в 2016 году писали в Harvard Business Review:

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

Гулати и Де Сантола приводят в качестве примера Cloudflare, чьи основатели официально объявили о создании полностью плоской организации без какой-либо иерархии или должностей. Несмотря на то что это решение было принято из благородных побуждений (генеральный директор Мэттью Принц считал, что отказ от должностей позволит избежать проблемного восприятия «ранними» сотрудниками новых управляющих), результаты его попали в кейс учебного курса Гарвардской школы бизнеса, проводимого Томом Эйзенманном и Алексой Годден, как неутешительные: «Спустя три месяца, к июлю 2012 года, пятеро из тридцати пяти сотрудников компании уволились и некоторые из них ссылались на отсутствие внятной структуры отчетности среднего звена и признаков работы HR-отдела. Они рассказывали о ситуациях, когда не знали, к кому обратиться (немного донимая основателей), если считали, что некоторые действия, связанные с программным обеспечением и стандартами кодирования, требуют изменений».