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

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

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

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

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

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

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

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

На прошлой неделе ездили на стратсессию. Вся стратсессия была посвящена правилам игры. В каких ситуациях и как действуем. Как распределяется ответственность.

И что самое интересное, во всех ситуациях была одна и та же проблема. Мы не научились общаться друг с другом и договариваться.

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

Почему-то мы хорошо умеем общаться с клиентами, но не научились договариваться внутри компании. 🤷‍♂️ Нашли где ошибались, теперь должны гораздо быстрее договариваться и согласовывать сложные вещи и идти вперед.

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

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

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

А сейчас, будучи руководителем, я понимаю, что я уже очень далёк от производства. За первые полгода 2024 года практически ничего не появилось нового из процессов. А некоторые отмерли, т.к. не были зафиксированы регламентами.

Очень долго не мог понять, что регламенты и процессы должны формироваться снизу. То есть так же как делал я, когда был старшим и ведущим. Я сам находил возможности для улучшения, улучшал и передавал знания следующим поколениям.

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

А в ближайшие недели, команда покажет новый план обучения младших джедаев. Жду с предвкушением. Там лично моей работы уже не так много будет, все сделала команда самостоятельно. Кайфую, когда штуки происходят уже без твоего участия.

Понял, что многие путают аккаунтов, проджект-менеджеров и специалистов на проекте. Сейчас разберёмся.

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

Проджект-менеджер —это человек, который организует работу команды на проекте. Если в команде интернет-маркетологи, smm-щики, дизайнеры, разработчики, то именно проджект-менеджер их объединяет. При этом,

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

Гантт на проекте делает не проджект-менеджер. Делают специалисты, а проджект-менеджер объединяет их под ту цель, которую заявлял заказчик. Аккаунт вообще может не знать что делают специалисты на проекте, он не проджект-менеджер.

Поэтому когда аккаунт продает без участия специалиста, то обычно он продает фигню (завышают ожидания, потому что так легче продать → это снижает LTV). У нас в ITA аккаунты и специалисты вместе ходят на пресейлы, и специалисты сами защищают своё решение перед заказчиком. Ведь им потом это реализовывать. А аккаунт помогает допилить решение под запрос заказчика.

Вчера было 7 лет как я в агентстве в штате (на стажировке с июля).

За эти семь лет я дорос с мидла до руководителя одного из юнитов.

Впереди нас ждёт еще много интересных поворотов. И я надеюсь быть на этих поворотах вместе с командой.

Сегодня пятничный пост!

Еще до того как я пришёл в компанию (в 2017 году), в IT-Agency были джедаи. Раньше это были люди, которые умели всё. Эдакие директора по маркетингу, но работающие руками.

На проекте есть возможность сделать SEO и получить +40% лидов? Круто идём в это! На проекте есть возможность изменить лендинг, увеличить конверсию и таким образом получить +30% лидов? Тратим силы на это!

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

Когда я пришёл в компанию, SEO уже был отдельным юнитом. Его создал Костя Солодянников. Потом джедаи перестали работать с лендингами и остановились на перформанс-инструментах.

До сих пор наш подход ближе к инхаусу, чем к другим агентствам. Но сейчас мы работаем с перформом, медийкой, посевами, аналитикой и тестируем новые инструменты. От «старых» джедаев ушли достаточно далеко.

Вне IT-Agency, я стараюсь джедаев называть как перформ-специалистов. Потому что клиентам уже сложно понимать, что это за джедаи такие. :)

Байку, откуда взялись джедаи, вспомнить не смог. Видимо Сева Устинов в рамках какой-то концепции обозвал так людей, которые могут во всё и показывают результат, и приравнял их к джедаям. Может Сева когда-то в своём блоге расскажет и эту историю :).

Недавно я писал о процессе, который у нас происходит при повышении. Сегодня хочу поделиться кусочком документа самой защиты.

Сегодня два младших-2 защищались на младших-3. Оба подготовили документы и рассказывали о своих достижениях по этим документам.

Очень крутые и сильные защиты. Кирилл, к примеру уже защищал разработку собственной отчётности до ключевых фраз н PowerQuery. Скрин части документа его защиты прикрепил. Смотрите какая красота.

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

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

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

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

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

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

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

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

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

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

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

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

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

У нас расходы в экономике юнита выстроены таким образом:

— Расходы на зарплаты (зарплата на руки + НДФЛ + соцвзносы).
— Расходы на инфраструктуру (в неё попадают общие расходы: бекофис, бухгалтерия, юристы, ноуты+техника, ДМС и т. п.)
— Расходы на обучение (не постоянные и под запрос).
— Расходы на командировки (к примеру, летим на подписание договора или пролонгацию).
— Расходы на сервисы по проектам (пишем как транзакционный, словно клиент нам заплатил меньше на эту сумму).

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

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

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

Почему не будут покупать? Потому что этот расход может резать маржу, а если его не будет, то ничего катастрофического не произойдет (то есть ценности нет, либо она мала).

Когда записываем расход напрямую, появляется ответственность за этот расход. Когда расход попадает в инфраструктуру, то эта ответственность размывается.

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

PS. Мы Кайтен в итоге вывели из инфры, и в итоге часть юнитов отказались от работы в нём, найдя более дешевые аналоги (или бесплатный опенсорс).

Иногда мы с людьми расстаёмся по нашей причине. Вот несколько причин, за что мы можем уволить человека:

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

Намеренный вред клиенту или команде. От действий человека компания теряет деньги или репутацию.

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

Нет пользы. Наняли сотрудника, а он не может окупить свою зарплату. И если так будет продолжаться на протяжении 3-6 месяцев, то мы с ним расстанемся.

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