Меняй или беги

Я в МИФе 4 года. В моей команде уже 21 человек, а коллеги из других отделов до сих пор не понимают, чем мы занимаемся.

— Маркетинг?

— Да, но не маркетинг книг.

— IT?

— Много, но не все наши проекты завязаны на IT.

— Аналитика? Дизайн?

— Почти всегда, но не всегда.

— Тексты?

— Нам нужны тексты, но 95% того, что делают копирайтеры МИФа — не касается нашего отдела.

— Так что вы делаете?

— Мы смотрим в цифры, ищем точки роста и создаем проекты, которые бы их закрывали.

— Ааа. Это вроде внутренней дизайн-студии?

— Нет.

— :-(

Хакеры роста

Пару лет назад нам казалось, что мы разобрались, кто мы. Тогда стал популярным термин growth hacking, который появился еще в 2010 году. Мы думали, что это про нас.

Growth hacking — это тенденция в современном маркетинге, которая отвечает за рост (growth), расширение и продвижение компании, как правило, стартапов, за счет необычных решений и инновационных разработок (hack).

Источник: LP Generator

Тогда термин growth hacking сильно колбасило — что только им не называли. Когда все более-менее устаканилось, показалось, что в этом понятии больше копания в данных и меньше работы над проектами, чем у нас. Все чаще стали писать, что ты не можешь называть себя гроус хакером, если не владеешь хотя бы одним языком программирования, на котором удобно работать с данными, например Python или R. Большинство из нас не владеет.

Change команда

Бимодальную модель придумали в 2014 году аналитики из Gartner. В 2016-ом о бимодальных организациях активно заговорил Греф. Он объяснил, в чем суть разделения функций run и change.

«В организации люди занимаются либо business run, либо business change. Первое — это поддержание текущего бизнеса, который дает копеечку. Коровка должна быть ухожена, накормлена, почищена и вовремя подоена. А второе — это постоянные изменения, создание инноваций. Мы выделим две эти функции во всех подразделениях банка и решим, какие менеджеры будут их выполнять.»

Герман Греф в интервью HBR.

В нашем отделе есть run задачи. Но как только мы узнали о бимодальных организациях, поняли, что УТП нашего отдела в change, многое встало на свои места.

В этом посте мои наблюдения о том, как это работает и выводы, которые удалось сделать за это время.

Цепочка change

Предположим команда change изобрела и запустила продукт. Ребята поставили «флажок» и делают селфи.

Амундсен, Хансен, Хассель и Вистинг перед палаткой на Южном полюсе под норвежским флагом.

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

Придумал → Сделал → Настроил процесс → Вышел

Вокруг нового продукта важно настроить процессы и вписать его в работу команды run. Например, вы запустили новый сайт, молодцы. Но важно сделать так, чтобы предложения на нем обновлялись, фотки заливались по гайдам, на телефоны отвечали и так далее. Только тогда вы работали не зря.

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

В конце проекта у человека change всегда дилемма «тащить vs. бросить». Каждое из решений ужасно по-своему.

1. Тащить. Это решение плохо, потому что рано или поздно поддержка запущенных когда-то проектов начнет занимать все ваше время. Вы не сможете заниматься тем, что у вас лучше всего получается, — придумывать и запускать новые проекты.

Так чувствует себя человек change, когда ему нужно поддерживать собственный проект после запуска.

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

Все ведет к тому, что правильное решение — кропотливо передать проект в правильные руки. Донести все, что вы в проект заложили, понаблюдать, посаппортить, а потом выйти. Найти человека run, распознать, правильно мотивировать и передать задачу.

Люди run и люди change

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

Людям run нравится работать в настроенном процессе. По Адизесу, это люди с большим А (administrator) и маленькой P (producer). Людям change нравится создавать то, чего не было. Причем не по кайдзен, а большими шагами. По Адизесу у них все наоборот — большая P и маленькая А.

Людям свойственно мерить по себе. Поэтому люди change допускают как минимум две большие ошибки в понимании run.

1. Они считают, что у run скучные задачи. Иногда люди change стесняются нанимать людей на run-задачи. Чтобы компенсировать неудобства, они обещают «развитие» в виде change проектов или пытаются время от времени подбросить им change задачку. От обоих видов «поощрения» мотивация человека run падает. Он попадает в слишком неопределенную для него среду.

Отстаньте от людей run, им и так хорошо.

2. Люди change считают, что люди run не способны к переменам. Отчасти это правда, для них большие изменения=проблемы. На самом они они тоже меняются, но их изменения другие. Часто они шлифуют до блеска камень, который вы им откололи. И в этом их ценность.

Команде change, важно находить правильных run-людей, которые не законсервируют процессы, а будут развивать их медленно, по кайдзен.

Ошибки в change

Отношение к ошибкам в run такое: «Где мой кнут?». Это логично, потому что никакой пользы в ошибках run нет. Если ты проспал и не подоил корову, тебя надо наказать, чтобы это не повторялось.

«У каждой ошибки есть имя и фамилия.»

Иосиф Сталин

В change к ошибкам важно применять другой подход.

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

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

Видишь ошибку — сделай две вещи.

1. Исправь. Срочно минимизируй негативные последствия.
2. Выучи урок. Например перестрой процесс так, чтобы в следующей подобной ситуации ее не повторять.

Что не надо сделать с ошибками.

1. Испытывать чувство вины.
2. Находить виновных и наказывать.
3. Чего бы то ни было еще.

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

Итого

Мы еще в самом начале пути change. Сейчас я готовлю пост про особенности change проектов и change процессов, как мы их сейчас видим.

→ Как следить за Бабаевой и Школой ченджеров

Рассылка Школы ченджеров (что это?). Соцсети Наташи Бабаевой: Facebook — личное и лучшее из рабочего, Telegram — маркетинг, чендж, продукт, задачки, YouTube — ставлю эксперименты в видеоформате, Instagram — красота процесса и ideas worth spreading, Медиум — вообще огонь ;-)