После успеха 1.0 у вас появляется выбор: плыть дальше по течению и в итоге пойти ко дну или ломать систему. За всю историю еще никто ни разу не предпочел «плыть по течению и пойти ко дну»; всем кажется, что они выбирают опцию непрерывного взлома системы. Однако Стабильные ломают систему совсем не так, как Взрывоопасные. Стабильные делают это исключительно в контексте последней войны. Конечно, они тоже могут быть инновативными, но они всегда будут ломать систему исключительно в рамках того, во имя чего они истекали кровью в ходе последней войны. А Взрывоопасные второго поколения будут ехидно ухмыляться и напоминать вам: «Никаких рамок не существует!»
Многие невероятно успешные мультимиллиардные компании идут по пути, который я называю «плыть по течению и в итоге пойти ко дну». Они сидят сложа руки и удивительно успешно монетизируют свою великолепную версию 1.0 годами (и даже десятилетиями), но от них уже идет душок. Да, конечно, деньги все еще текут к ним рекой, но сделали ли они что-то новое? У них громадные отделы сбыта, блестящие рекламные кампании и легионы юристов, но вы не сможете назвать ничего нового, созданного ими за последние пять лет, ничего такого, глядя на что вы бы подумали: «Охренеть!» Этот уже явно ощутимый затхлый душок – и есть недостаток такого «Охренеть!». Он заставляет Взрывоопасных бежать оттуда без оглядки, потому что так пахнет стагнация. А Взрывоопасные не желают иметь ничего общего с людьми, которые не хотят рисковать; они считают, что стагнация – это смерть.
Будучи лидером, вы должны понять, как инвестировать во взлом системы, который, вообще-то, противоестествен, потому что по определению является деструктивным. Он разрушает вещи, которые другие мечтают построить.
Apple – это хороший пример компании, которой наплевать на прошлые войны. Amazon тоже кажется мне ярким примером компании, предпочитающей инвестировать в своих Взрывоопасных. В 2002 году они презентовали свои Amazon Web Services, и мы коллективно почесали в затылках: что? Компания, которая продает книги онлайн, зашла на рынок онлайн-сервисов для веб-сайтов? Какого черта?
Я только что вернулся из Ирландии с потрясающей конференции FUNCONF. Я стоял в зале, набитом девелоперами, и понимал, что большинство из них полностью зависят от огромного арсенала веб-сервисов Amazon. Я уверен, дело в том, что несколько лет назад один Взрывоопасный подумал: мы не должны просто продавать книги! Мы должны создавать технологии! Именно взрывоопасное мышление позволило Amazon начать конкурировать с Apple в совершенно новой для них сфере деятельности. Кто бы мог подумать, что Amazon возьмется за создание телефона? Раньше мне это казалось безумием!
Я не знаком с внутренними корпоративными процессами Amazon, но когда вижу стратегии, которые явно отходят от общепринятых норм, я понимаю, что тут поработали Взрывоопасные.
Я уверен в том, что здоровая компания, которая стремится расти и создавать новое, обязательно должна инвестировать как в Стабильных, так и во Взрывоопасных.
Стабильные нужны, чтобы напоминать вам о реальности и разрабатывать процессы, позволяющие координировать деятельность больших групп людей и доводить проекты до конца. Стабильные дадут прогнозируемость, повторяемость и надежность результатов, но вам нужно будет построить целый мир, в котором они смогут творить.
Взрывоопасные нужны для того, чтобы напоминать вам, что ничто не может длиться вечно и вокруг много других Взрывоопасных, которые уверены, что их миссия – бороться с неэффективностью, скукой и отсутствием вдохновения. Вам не надо строить для них мир, потому что они думают, что вы заинтересованы только в Стабильных. Вам нужно лишь отвести им угол в здании, где они смогут взрывать систему.
Эти два лагеря будут постоянно воевать друг с другом, потому что они обладают совершенно разными взглядами на вещи. Стабильным кажется, что они вечно нянчатся со Взрывоопасными и подчищают их косяки, а Взрывоопасные считают, что Стабильным не хватает креативности и что они боятся рисковать, а это сдерживает компанию и инновации в целом. Их углы зрения полностью противоположны, что жизненно важно для здорового бизнеса. Как руководитель команды инженеров вы постоянно должны вести переговоры о временном перемирии между этими двумя лагерями.
Да, в течение нескольких лет после взрывоопасной победы Стивена мы должны были подчищать его косяки, но при этом количество наших клиентов увеличилось с нуля до 30. Из горстки взрывоопасных инженеров мы превратились в стабильную компанию, состоящую из 200 сотрудников, что отчасти стало возможным именно благодаря тому, что однажды Стивен смог наконец-то продемонстрировать нам идею нашей будущей платформы.
Однако платформа так никогда и не была завершена. Мощный толчок Стивена позволил нам произвести ее на свет, но мы навсегда зависли в стадии функциональной незавершенности и архитектурной невыдержанности. Взрывоопасные второго поколения постоянно указывали на это, но Стабильные уверяли, что лучшее – враг хорошего.
В итоге мы начали работу над второй платформой. Сначала это был плод дремлющего вдохновения Взрывоопасных. Работа над стратегией создания платформы длилась несколько недель, мятеж Взрывоопасных начался слишком поздно. Один из наших клиентов, крупная корпорация, одним махом покончила с нами, когда всем стало ясно, что мы никогда не произведем того, что пытаемся продавать. Доверие было подорвано, Взрывоопасные удрали, и так в разгар доткомов мы оказались в том баре, утешая друг друга тем, что «это были макроэкономические силы, на которые мы никак не могли повлиять». Именно такие вещи произносят Стабильные, когда решают сдаться.
Трудно назвать лучшую работу Джоэла Спольски, но если бы мне пришлось это сделать, то я бы выбрал «Тест Джоэла: 12 шагов к лучшему коду»[4]. Это его собственный, ужасно несерьезный и нестрогий тест для оценки качества ПО. И если кто-нибудь спрашивает меня, что не так с его командой, то обычно я начинаю с этого теста. Давайте и в этот раз начнем с него.
В этом тесте можно набрать максимум 12 очков, и как говорит сам Джоэл, «12 очков – это идеально, 11 – терпимо, а 10 и ниже означают, что у вас серьезные проблемы». Но главное не очки, а то, что этот тест четко указывает на моменты, которые я называю аспектами жизнеспособности команды по разработке программного обеспечения. Впрочем, помимо упомянутых там пунктов существуют также другие аспекты жизнеспособности. В подражание тесту Джоэла я предлагаю вам тест Рэндса.
В своем первом стартапе я был двадцатым по счету сотрудником и первым руководителем по разработке. В течение двух лет команда и компания разрослись почти до 200 человек. Именно тогда я понял, что быстрый рост очень хорошо учит тебя одной вещи, а именно тому, как коммуникация постоянно находит новые и все более изощренные способы провала. Ключевая проблема заключается в «старичках», на которых обычно лежит большая часть ответственности. Поскольку эти люди считают, что даже после того, как группа увеличилась в два раза, их прежние привычные способы коммуникации остаются такими же эффективными и простыми.
Это не так! Растущая команда должна постоянно инвестировать в новые способы работы с коллективным мышлением, то есть любой сотрудник в любой момент времени должен быть в состоянии ответить на вопрос: «Знаю ли я, черт возьми, что сейчас происходит в компании?»
Давайте начнем с самой незатейливой версии теста, а затем я поясню каждый вопрос.
Проводятся ли у вас совещания тет-а-тет?
Проводятся ли у вас общекомандные совещания?
Есть ли у вас отчеты по статусу проекта?
Можете ли вы сказать своему боссу «нет»?
Можете ли вы объяснить стратегию вашей компании незнакомцу?
Можете ли вы рассказать о текущем состоянии дел в вашей компании?
Ваши руководители регулярно выступают перед всеми сотрудниками и рассказывают о том, что они думают? Вы «ведетесь» на это?
Вы знаете, что хотите делать дальше? А ваш босс знает?
У вас есть время на стратегическую деятельность?
Вы активно боретесь с сарафанным радио?
Примечание: далее я поясню каждый пункт с точки зрения лидера или руководителя, однако эти вопросы и комментарии в одинаковой мере применимы к любому сотруднику.
Я думаю, что вам трудно будет найти человека, который считает, что совещание тет-а-тет – это плохая идея, тем не менее именно тет-а-теты чаще всего переносят, когда дело пахнет жареным. Я же уверен, что когда дело пахнет жареным, последнее, что вы должны делать, – это переносить тет-а-теты с людьми, которые, во-первых, тоже несут ответственность за «жареное», а во-вторых, возможно, являются теми самыми наиболее квалифицированными специалистами, способными определить, как предотвратить «жареное» в будущем.
Более того, как я буду объяснять далее в главе 7 «Новейшие сводки. Жалобы. Катастрофа», транслирование статуса проекта не является целью тет-а-тета. Цель тет-а-тета – провести что-то вроде беседы о сути деятельности команды. Статус проекта может быть введением к такой беседе, он может быть фундаментом такой беседы, но он не может быть ее целью. Правильный тет-а-тет должен быть стратегическим, он не должен быть пересказом тактик, статусов и сведений, которые легко можно почерпнуть из других источников.
Тет-а-тет – это еженедельное инвестирование в сотрудников, которые составляют вашу команду. Если ваши тет-а-теты нерегулярны или вы не считаете их особо ценными, то вы укрепляете миф о том, что руководители недоступны.
Общекомандные совещания должны обладать такими же двумя основными признаками, что и тет-а-теты, а именно систематичностью и фокусом на сути деятельности команды, а не на текущем положении дел.
В общекомандном совещании статус проектов не играет особенной роли. Проще говоря, сарафанное радио – это главное зло в компании, и именно общекомандное совещание позволяет успешно бороться с ложью, которую оно распространяет в массах. В моей повестке дня есть типовой пункт – «Слухи, сплетни, ложь», и когда мы доходим до него в ходе совещания, каждый член команды получает возможность самостоятельно выяснить, какая информация является правдой, а какая ложью.
Следующий важный пункт повестки дня на общекомандном совещании звучит так: «Добились ли мы ощутимого прогресса в решении проблем нашей команды?» Я не знаю, чем именно вы занимаетесь, я не знаю, какие проблемы есть у вашей команды, но я точно знаю, что они есть; и общекомандное совещание – это самое подходящее время и место не только для того, чтобы выявить эти проблемы, но и чтобы обсудить, как вы можете их решить.
Если на регулярных общекомандных совещаниях вы боретесь со сплетнями и ложной информацией, а также решаете проблемы, возникающие в вашей команде, то вы заслужили плюс одно очко.
Если ваш ответ «да», то вы теряете одно очко. Данный опросник частично предназначен для того, чтобы оценить, насколько эффективно в вашей компании происходит обмен информацией. Это уже второй вопрос, который может забрать у вас одно очко. Почему я так ненавижу статусы? Вообще-то я ненавижу не статусы, я ненавижу отчеты о статусах.
Я уверен в том, что отчеты о статусах проектов, направляемые по электронной почте, – это один из самых явных и самых верных признаков некомпетентности и лени руководителя. Причины, по которым якобы необходимо генерировать эти еженедельные отчеты по электронной почте, есть всегда: мы крупная компания, и нашим сотрудникам необходимо перекрестное опыление! Подготовка отчета занимает не более 15 минут.
Чушь! Практика предоставления формализованных отчетов о статусе проектов по электронной почте приводит к утрате контроля над ситуацией, а у сотрудников – к недостатку воображения и снижению уровня доверия к руководителю.
Давайте посчитаем, сколько инструментов для совместной работы вы используете ежедневно. Электронные сообщения к ним не относятся! Если вы инженер по разработке ПО, то, я думаю, это примерно такая комбинация: система управления обновлениями, система отслеживания багов, вики, CRM, Slack и/или софт по управлению проектом. Все эти инструменты автоматически генерируют кучу статусов, по которым можно судить о тактических событиях недели.
Если некто (мой босс или кто-то другой выше меня по рангу) попросит меня предоставить отчет о статусе проектов, то моя первая мысль будет: «Я уже сгенерировал гору статусов на различных инструментах! Почему нельзя просто посмотреть там?»
Да, в подобных инструментах много лишнего. Нужен отчет, в котором не будет ничего лишнего. Все инструменты для совместной работы построены на отчетности. Информация о статусе в них отсутствует. В каком учебнике по менеджменту написано, что отслеживание работ нужно поручать людям, которые непосредственно эту работу выполняют? Разве это правильно? Вообще-то это ваша работа!
Итак, мне нужна лишь качественная оценка прошедшей недели. Это все, что я прошу! Три вещи, которые работают, три вещи, которые не работают, и что мы собираемся предпринять, чтобы они заработали. Окей, это просто разговоры. Да, я могу подготовить отчет, в котором будет стратегическая оценка прошедшей недели, но почему мы не можем просто поставить этот вопрос первым пунктом нашего еженедельного тет-а-тета? В таком случае, если у вас возникнут вопросы (а они возникнут), мы сразу же сможем как следует их обсудить.
Но я бы хотел, чтобы у меня была информация в письменном виде, чтобы позже я мог бы в любой момент ее просмотреть. Супер! Пожалуйста! Просто запишите всё, что обсуждалось.
Да, для меня отчет о статусе проектов – это больной вопрос. Я написал их сотни, и каждый раз, начиная новый отчет, я думал: «Почему, черт возьми, я не могу отделаться от мысли, что сейчас я выполняю бесполезную работу?» Отчеты о статусах проектов обычно появляются, когда руководитель чувствует, что он отдаляется от некоей части организации и верит, что сможет избавиться от этого ощущения, заставив своих сотрудников тщательно документировать свою рабочую деятельность. Но это не поможет! Девяносто процентов людей, которые обязаны направлять отчеты о статусе проектов по электронной почте, думают об одном и том же: «Мой руководитель не ценит мое время». А это приводит к следующему пункту…
Вероятно, лучше будет перефразировать этот пункт следующим образом: «Кажется ли вам, что тет-а-теты с вашим боссом проходят не так, как остальные регулярные совещания?» В здоровой коммуникативной среде в пределах команды, организации или компании информация курсирует легко и непринужденно. Однако если, заходя к своему боссу на тет-а-тет, вы превращаетесь в паиньку и боитесь высказывать свое мнение, то я хочу вам сообщить, что в вашей организации что-то идет не так.
Да, он ваш босс! Он делает ежегодный производственный анализ и может повлиять на вашу карьерную траекторию, но когда он открывает рот и говорит какую-нибудь откровенную глупость, то ваше святое контрактное обязательство перед акционерами компании, в которой вы работаете, – поднять руку и возразить: «Вы говорите глупости! И вот почему…»
Проще сказать, чем сделать, Рэндс!
Ну ок, не говорите слово «глупости».
Давайте так: я уверен, что лидеры, считающие себя непогрешимыми, медленно становятся неадекватами из-за своего ложного убеждения в том, что ошибаться – это признак слабости. Вот уже 20 лет, как я лажаю на работе, причем довольно регулярно и совершенно разными способами. И хотя мне до сих пор становится нестерпимо больно, когда я натыкаюсь на ту или иную лажу в своей работе, я всегда стремлюсь как можно скорее признать свой факап, чтобы как можно скорее выяснить, что конкретно я делал неправильно, а это обычно начинается с того, что кто-то говорит мне «нет».
Теперь давайте оставим корпоративную коммуникацию в покое. Следующий пункт теста относится к стратегии и контексту, в котором функционирует организация. Если бы я подошел к вам в баре и спросил, чем занимается ваша компания, смогли бы вы четко и ясно объяснить мне ее стратегию?
Это первый пункт в данном опроснике, который демонстрирует, есть ли у вас в голове ясная схема вашей компании. Возможно, вы недооцениваете значение подобной схемы. Если вы по своей натуре лидер, то велика вероятность того, что вы легко нарисуете схему вашей компании. Если вы – линейный сотрудник, то, вероятно, вы думаете, что рисовать такие схемы – это обязанность других людей, и фактически вы правы: разрабатывать схему компании – это действительно задача других людей, но понимать ее и быть способным ее воспроизвести – это целиком и полностью ваша обязанность.
О проекте
О подписке