Шаг 3. Принять окончательное решение
Несмотря на то что в процесс найма сотрудников вовлечено множество людей, окончательное решение СЕО всегда принимает в одиночку. Только он имеет всю необходимую информацию о том, что собой представляет система критериев отбора и на чем они основаны, ему известны данные интервьюеров и рекомендателей, а кроме того, он может оценить сравнительную важность отзывов различных заинтересованных лиц. Решения на основе консенсуса практически всегда принимаются по критерию отсутствия видимых недостатков, а не наличия необходимых достоинств, поэтому СЕО следует принимать эти решения в одиночку — должен же кто-то взять на себя эту ответственность.
ЕСЛИ СОТРУДНИКИ НЕ ПОНИМАЮТ МЕНЕДЖЕРОВ
В первое время работы в Loudcloud многие сотрудники делали много глупостей, объясняя это так: «Бен сказал». Зачастую оказывалось, что ничего подобного я не говорил, а еще чаще — говорил, но не в том смысле, в каком это было понято. Принципы управления, о которых пойдет речь далее, основаны как раз на этих случаях из практики.
Когда я руководил компанией Opsware, у нас часто в конце квартала возникала проблема с количеством продаж, ласково называемая «закономерность хоккейной клюшки». Такое название она получила потому, что график продаж за квартал приобретает именно форму хоккейной клюшки. Наша «клюшка» оказывалась настолько крутой, что в один из кварталов мы получили 90% всей выручки в самый последний день. Подобная динамика продаж очень затрудняет планирование деятельности компании и вызывает особую тревогу, если ваша компания акционирована (как наша на тот момент).
Естественно, я был полон решимости выпрямить нашу «хоккейную клюшку» и сделать деятельность компании более предсказуемой и ритмичной. С этой целью агентам по продажам были предложены специальные премиальные бонусы за сделки, заключенные в первые два месяца квартала. В результате в следующем квартале наш график приобрел более линейную форму, а объем продаж немного уменьшился за счет того, что сделки третьего месяца плавно переместились на первые месяцы следующего квартала.
Руководя большой командой программистов в Netscape, я оценивал один из наших программных продуктов по показателям качества, потребительским свойствам и соблюдению сроков выпуска. Моя группа вовремя выпустила обладающий всеми необходимыми качествами и с очень небольшим количеством багов программный продукт. К сожалению, он оказался довольно посредственным, поскольку не обладал ни одним выдающимся потребительским свойством.
Во времена моей работы в HP там существовали очень жесткие требования к выполнению плана по показателям объема продаж и валовой прибыли. Некоторые подразделения выполняли эти планы ценой систематического недофинансирования исследований и разработок. Они сильно ослабили свои конкурентные позиции в долгосрочном аспекте, что и привело их в конце концов к катастрофе. Во всех трех случаях менеджеры обеспечили требуемый, но отнюдь не желаемый результат. Как это могло случиться? Давайте посмотрим.