Перейти к основному содержанию

Антон Рожков

Руководитель отдела перформанс-маркетинга в IT-Agency.

Мой телеграмм-канал.

Как растить команду и зарабатывать в перформанс-маркетинге

Подпишись и узнай что происходит
в IT-Agency глазами Антона Рожкова.

Как растить команду и зарабатывать в перформанс-маркетинге

Подпишись и узнай что происходит
в IT-Agency глазами Антона Рожкова.

Роли и уровни ответственности в IT-Agency

Сегодня хочу рассказать про ответственность и как эта ответственность у нас делится по ролям.

У нас в компании есть линейка специалистов: младший (младший джедай) → мидл (джедай) → старший (старший джедай) → ведущий (ведущий джедай) → руководитель дивизиона.

У каждого ранга своя ответственность:
— Младший → отвечает за задачки на проекте. Его ответственность, чтоб задачи были сделаны хорошо и точно в срок.
— Мидл → отвечает за проект. Его ответственность, чтоб на проекте была позитивная динамика в показателях и чтоб проект продлялся. При этом мидл работает с задачами, но ему может помогать младший.
— Старший → отвечает за портфель проектов. Его ответственность — это портфель проектов.
— Ведущий → отвечает за портфель проектов, команду, процессы.
— Руководитель → отвечает за все портфели ведущих, команду, процессы, решает управленческие процессы, которые пока невозможно передать на ведущего.

Про ответственность старших

Вокруг «старшего» образуется команда, мини-юнит. Это еще не его команда, но это команда, с которой он уже может работать, и переходить из роли «управляю одним проектов» в «управляю несколькими проектами» и из роли «большую часть делаю руками сам» → «передаю часть ответственности более младшим сотрудникам».

Старший начинает меньше работать руками, и больше головой. Его главная задача, научиться использовать младших и мидлов, как рычаг. Для этого нужно научиться передавать ответственность и доверять исполнителю (исполнители подводят, всегда, тут и учимся решать проблемы как управленец и наставник).

Так же старший начинает активно работать с пресейлами → проводить первые встречи, готовить презентации, расчёты и презентовать итоговые расчёты.

Чем старше становится «старшее», тем больше он начинает работать с людьми. Потому что проектов становится больше, и он вынужден часть своей ответственности передавать на людей, которые делают работу априори хуже него (у них просто опыта меньше!). Тут начинается конфликт управленца: не доверяешь исполнителю → вязнешь в микроменеджменте → ведешь меньше проектов.

На 3 уровне старший начинает учиться подбирать себе команду. Он участвует вместе с ведущим или руководителем в интервью, проверяет тестовые и анкеты участников. Высказывает мнение руководителю или ведущего что ему нравится в кандидате, а что не нравится. Проводит стажировку, и принимает защиту на стажировке. Это и является этап подготовки старшего к тому, чтоб стать ведущим.

Про ответственность ведущих

Ведущие — это наставники (ведущий — от слова ведёт). Три важных задачи ведущего:

— Растить как можно больше мидлов, старших и ведущих → люди растут только тогда, когда берут большую ответственность и справляются с этой ответственность.
— Увеличивать портфели проектов старших → участвовать в продажах, помогать старшим в стратегиях.
— Улучшать продукты и процессы → продукт должен быть как можно дешевле и качественнее для клиентов. Мы должны зарабатывать для клиента больше, чем он тратит на нас.
— Участвовать в маркетинге и строить персональный бренд → Какие бы крутые мы ни были, как бы круто мы не работали, на определенном развитии компании сарафанного радио не хватает, поэтому компании для увеличения роста нужно помогать с маркетингом: выступать, вести блог, писать статьи и кейсы и т. д.

Поэтому в агентстве создаются условия очень близкие к предпринимательству. Сама среда создана таким образом, что подталкивает тебя пробовать новое, делать ошибки и получать новый опыт.

blog_links_near

Не упарываться в перфекционизм

Самая моя большая боль в прошлом — это перфекционизм.

Пока я не сделаю идеально, я не сдам работу. Доходило до того, что я до 2 ночи сидел над задачей и вылизывал её до идеального результата. Я был не прав.

Сделать лучше, чем никогда.

Сейчас я стараюсь делать работу поэтапно. Вначале реализовываю версию документа (или чего-либо еще), с которой можно работать. Так было с отчётностью для юнита, так было с бонусной системой, так было с критериями на повышение для сотрудников.

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

Документ с критериями на повышение для сотрудников и калькулятор проекта уже больше года висят под версией v.0.5. И они прекрасно работают и помогают сотрудникам с пресейлами и повышениями.

Посты в блог я делаю за 10-15 минут. На следующий день прохожу глазами, и переписываю те моменты, где мне что-то не нравится. А иногда публикую в тот же день. Потому что сделать что-то, лучше, чем никогда ничего не сделать.

blog_links_near

Как не проваливать дедлайны

У нас remote-frst команда. Remote-first — это когда офис/коворкинг по желанию, а изначально мы ориентируем, что работа будет удаленной. Remote-first держится на ответственности и сдерживании обещаний.

Про ответственность я уже много раз писал (и буду писать), сегодня хочу поговорить про дедлайны. У нас сотрудники самостоятельно выбирают дедлайны для задач. Потому что именно они обещают клиенту сделать определенные задачи к какому-либо времени. И срыв дедлайнов крайне редкое событие в компании. Сейчас расскажу каким правилам мы придерживаемся, чтоб не срывать дедлайны.

  1. Всегда можно передоговориться. Иногда что-то случается, и становится понятно, что дедлайн не будет соблюдён. В таком случае мы стараемся как можно раньше передоговориться с клиентов. Если времени до дедлайна останется немного, то можем ограничить функционал задачи или её объем. К примеру, делаем анализ конкурентов, и первой итерацией только 3-5 основных конкурентов, а второй всех остальных. Это важно, потому что наш ЛПР тоже мог кому-то пообещать показать нашу работу.
  2. Создаем внутренние дедлайны. Чтоб не делать всё в последний день, мы создаем внутренние дедлайны. Дизайнеры готовят креативы к такому числу, мы готовим посадочные к такому числу. А в такой то день согласовываем с клиентом. В идеале если после всего этого еще остается 2 дня, если что-то пойдет не так.
  3. Создаем буфер. Это от 2 до 6 часов в неделю, которые отводятся для срочных задач или если что-то пойдет не так. Если срочных задач нет, то делаем что-то сверху.
  4. Еженедельная встреча с клиентом. Сложно говорить клиенту, что ты не сделал какую-то задачу. Еженедельная встреча с клиентом для нас обязательна. Там мы обещаем клиенту что-то сделать на следующую неделю. И через неделю отчитываемся о проделанной работе с результатами в цифрах.
  5. Дедлайн от согласования. Если для выполнения задачи нужно согласования третьего лица, то мы делаем плавающий дедлайн от дня согласования. К примеру, мы подготовим КП за неделю, после того как получим доступы в рекламные кабинеты и метрику от вас.

А вы что делаете, чтоб не срывать дедлайны?

blog_links_near

Почему мы указываем проект или имя вначале документа, письма, задачи

В IT-Agency есть правило, мы всегда вначале документа пишем проект или имя. Этот «тег» показывает про кого этот документ.

Аналогично поступаем и для email, чатов и задач. К примеру:

yandex.ru: Еженедельный план-факт за 08.07.2024 — 14.07.2024
Антон Рожков: заявление на отпуск с 08.07.2024 — 14.07.2024
yandex.ru: подготовить ретаргетинговые аудитории по недошедшим до продажи клиентам

Это сильно упрощает, сразу видно про какой проект документ. Гораздо легче искать документ в поиске Google Drive или Yandex Disk или письмо в почтовом ящике.

blog_links_near

Почему не нужно вводить трекинг времени насильно

Я застал еще времена, когда трекинг времени был обязательным в IT-AGENCY. В те времена, отделы «продавали» своё время. Поработал больше часов → заработал больше.

Сейчас мы продаем команды, людей и трекинг времени стал обязательным только для внештата. Если взялся сделать задачу к Y дню — делай, а за сколько часов ты её сделаешь — вторично.

Для младших и мидлов я рекомендую самостоятельно следить за своим временем. Это помогает натренировать насмотренность. Сколько может занимать та или иная задача? А можно ли как-то оптимизировать выполнение этой задачи?

Но вот самая главная причина:
Когда мидл станет старшим, одной из задач по старту нового проекта будет разработка гантта. Выполнять работу по запуску проекта будут мидлы и младшие. Если ты не трекал сам своё время, то как ты поймешь сколько времени займет запуск проекта у мидла и младшего?

Заставлять трекать время — это микроменеджмент. Рекомендовать трекать время — основа для роста для самого специалиста.

blog_links_near

Про ответственность и право на ошибку для джунов

У нас в компании мы очень внимательно подходим к ответственности. Фактически рост сотрудника напрямую связан с объемом ответственности, которую тот может «прожевать». Так младший берёт ответственность за задачи; мидл — берёт ответственность за проект; старший — за портфель проектов; ведущий — за команду и производственный процесс.

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

Допустим, у нас есть джун, которому поставили задачу подобрать семантическое ядро по процедуре УЗИ. Ставить такую задачу будет либо старший, либо мидл. В момент постановки задачи, они опишут понимание (для джуна понимание сформировать сложно, не хватает насмотренности), и отдают его на джуна. Если джун говорит: «Я всё понял, пошёл делать», значит ответственность за задачу делегирована, теперь это ответственность на джуне.

Для джуна в этот момент может происходить противоположный процесс. Он получил понимание задачи от мидла или старшего. Они знают как правильно стоит делать, поэтому они мне и объяснили. И они потом будут проверять мою задачу, что она сходится с их пониманием. То есть ответственность за правильно сделанную задачу на них, а не на мне.

В этот момент и происходят проблемы на проекте. Джун не относится ко своей ответственностью со всей серьезностью. Делает ошибки в задании и отдает слабую работу на мидла или старшего, чтоб те его проверили. Но мидл и старший не смогут проверять все задачи, и когда-то эта задача с ошибками может попасть к клиенту. Все это приводит к тому, что с джуном мы распрощаемся (он не может отвечать за свою ответственность).

Пока я вижу только такой путь как избежать этой ситуации:

— Явно указывать, что ответственность на джуне и за ним никто не будет проверять его работу.
— Напомнить, что он всегда может прийти к мидлу и старшему и проконсультироваться по сложным вопросам.
— Напомнить, что в агентстве есть принцип работы в «четыре руки», для задач, которые сложно выполнять.
— Разбирать ошибки, и слушать что думал джун, когда отдавал задачу с ошибкой.
— Дать право на ошибку (обсуждать это явно), но если ошибки будут повторяются, явно сказать, что мы с ним прекратим работать.

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

blog_links_near

Открытость повышает конкуренцию

В IT-Agency есть принцип и ценность — открытость. Мы всю работу ведём открыто, что любой, кто интересуется, может узнать подробно что этот человек делает. Аналогично, мы не особо скрываем информацию про то как работает агентство изнутри.

Внутри эта ценность повышает конкуренцию между специалистами, а внешне повышает уверенность в нас, как исполнителе.

В книжке The Social Leap есть интересный фрагмент, как открытость могла сыграть негативно.

В 1960-ых годах отношение зарплаты генерального директора к средней зарплате работника была 20 к 1.

В 1990-ых годах это отношение выросло до 100 к 1.

В итоге акционеры решили, что нужно пристыдить генеральных директоров и начал сообщать об их зарплатах публично (ведь тогда они эти зарплаты снизят).

К сожалению, это имело неприятные последствия. Так как эти знания стали открытыми, то конкуренция резко выросла. Лучшие руководители знали меньше какой зарплаты им не стоит соглашаться. И в итоге разрыв зарплаты увеличился и дошёл до 130 к 1 к 2017 году.

blog_links_near

Роли и уровни ответственности в IT-Agency

На выступлении Mind-15 мне задали вопрос: «Как у вас в компании мотивируют людей заниматься HR деятельностью?».

Я ответил кратко, что в IT-Agency это поощряется, в том числе и финансово (не напрямую, но итоговым числом). Но тема очень обширная, на которую можно отдельный доклад делать. Сегодня хочу рассказать про ответственность и как эта ответственность у нас делится по ролям.

У нас в компании есть линейка специалистов: младший (младший джедай) → мидл (джедай) → старший (старший джедай) → ведущий (ведущий джедай) → руководитель дивизиона.

У каждого ранга своя ответственность:

— Младший → отвечает за задачки на проекте. Его ответственность, чтоб задачи были сделаны хорошо и точно в срок. Чем старше «младший», тем больше зон он может брать, но отвечает все равно на уровне задачи. У младшего 3 уровня.
— Мидл → отвечает за проект. Его ответственность, чтоб на проекте была позитивная динамика в показателях и чтоб проект продлялся. При этом мидл работает с задачами, но ему может помогать младший. Чем старше становится «мидл», тем больше задач он берёт, связанными с продажами (начинает получать опыт на пресейлах, выступает с семинарами, присутствует на первых встречах). У мидла 2 уровня.
— Старший → отвечает за портфель проектов. Его ответственность — это портфель проектов. У старших 3 уровня, зависит от портфеля проектов.
— Ведущий → отвечает за портфель проектов, команду, процессы. У ведущих 3 уровня, зависит от портфеля проектов.
— Руководитель → отвечает за все портфели ведущих, команду, процессы, ищет проторенную дорожку, как сформироваться лучший продукт/процесс и потом передает его на ведущего.

Подробней про ответственность старших

Вокруг «старшего» образуется команда, мини-юнит. Это еще не его команда, но это команда, с которой он уже может работать, и переходить из роли «управляю одним проектов» в «управляю несколькими проектами» и из роли «большую часть делаю руками сам» → «передаю часть ответственности более младшим сотрудникам».

Старший начинает меньше работать руками, и больше головой. Его главная задача, научиться использовать младших и мидлов, как рычаг. Для этого нужно научиться передавать ответственность и доверять исполнителю (исполнители подводят, всегда, тут и учимся решать проблемы как управленец и наставник).

Так же старший начинает активно работать с пресейлами → проводить первые встречи, готовить презентации, расчёты и презентовать итоговые расчёты. Тут всплывают проблемы на каждом из этих этапов, и по каждому из них ведётся работа над ошибками.

Чем старше становится «старший», тем больше он начинает работать с людьми. Потому что проектов становится больше, и он вынужден часть своей ответственности передавать на людей, которые делают работу априори хуже него (у них просто опыта меньше!). Тут начинается конфликт управленца: не доверяешь исполнителю → вязнешь в микроменеджменте → ведешь меньше проектов.

На 3 уровне старший начинает учиться подбирать себе команду. Он участвует вместе с ведущим или руководителем в интервью, проверяет тестовые и анкеты участников. Высказывает мнение руководителю или ведущего что ему нравится в кандидате, а что не нравится. Проводит стажировку, и принимает защиту на стажировке. Это и является этап подготовки старшего к тому, чтоб стать ведущим.

Подробней про ответственность ведущих

Ведущие — это наставники (ведущий — от слова ведёт). Три важных задачи ведущего:

— Растить как можно больше мидлов, старших и ведущих → люди растут только тогда, когда берут большую ответственность и справляются с этой ответственность. Для агентства и акционеров — это увеличение выручки и объема прибыли, потому что реализация большей ответственности, приносит бо́льшую пользу для клиентов, что приводит больше денег агентству.
— Увеличивать портфели проектов старших → участвовать в продажах, помогать старшим в стратегиях.
— Улучшать продукты и процессы → продукт должен быть как можно дешевле и качественнее для клиентов. Мы должны зарабатывать для клиента больше, чем он тратит на нас, иначе проект для нас считается провальным.
— Участвовать в маркетинге и строить персональный бренд → Маркетинг, позволяет делать так, чтоб о компании узнало как можно больше людей. Какие бы крутые мы не были, как бы круто мы не работали, на определенном развитии компании сарафанного радио не хватает, поэтому компании для увеличения роста нужно помогать с маркетингом: выступать, вести блог, писать статьи и кейсы и т. д.

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

blog_links_near

Просить клиента рассказывать о проблемах

Ничто так не укрепляет отношения с клиентом, как разговор о том, что «у него болит» сейчас. Это очень хороший навык спрашивать клиента обратную связь:

— Что делаем хорошо?
— Что мы можем делать лучше?

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

Где можно встретится неформально?

  1. Аккаунт приедет в гости и соберёт обратную связь по команде (так должен делать аккаунт, если он заботиться о росте навыков команды).
  2. Организовать стратсессию.
  3. Пригласить на мероприятие.
  4. Бизнес-завтрак.

Даже если все хорошо, и никаких особых проблем нет, то пусть пишет к тебе в личку, если с чем-то нужно будет помочь в будущем.

blog_links_near

Шаблон: Справочник проекта

Сегодня хочу поделиться публикацией Есимхана Жалелова и Паши Злобина про справочник на проекте.

Раньше на проектах мы использовали «Карточку проекта» в виде докса, но его постоянно забывали пополнять (нужно было много текста писать). А чем дольше проект шёл, тем сложнее становилось разбираться что и где находится.

Так Паша Злобин придумал сделать Google Sheet документ, в котором просто добавлял все рабочие документы, относящиеся к проекту. Если что-то надо, заходит в него, нажимает Ctrl+F и быстро находит необходимый документ со ссылкой. В этом же доксе он добавляет важную информацию о проекте.

Шаблон можно взять тут. Ну и подписывайтесь на ребят, я не так много руками работаю в последние годы, а ребята с решением таких проблем сталкиваются ежедневно.

blog_links_near
Подписаться на Управление проектами