Компания Geekfactor cовместно с Getmentor.dev проводит программу подготовки к трудоустройству в зарубежные стартапы (бесплатно помогаем подготовиться к интервью и показываем резюме классным компаниям) — почитать о ней подробней и зарегистрироваться можно тут.

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

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

Кто я такой?

Я работал:

• менеджером нескольких маленьких и средних проектных команд;

• техническом директором OnDeck;

• вице-президентом CoinList;

• руководителем по дистанционной работе в AngelList;

• и техническим директором Product Hunt.

Давайте начнём.

Если вы менеджер — вина всегда лежит на вас

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

• либо вы организовали процессы, которые привели к такому результату;

•  либо вы наняли (или не уволили) не тех людей.

Так или иначе, вы кругом виноваты.

Вы управляете процессами, а людей — направляете

По какой-то причине для многих «управлять людьми» — значит, контролировать их. Такие люди в итоге занимаются микроменеджментом сотрудников: следят, не только что и когда, но и как они делают. Если у вас есть на это время, то вы можете спокойно нанять людей попроще и подешевле.

Я думаю, корень проблемы в непонимании, какую роль менеджер играет в процессе:

• ваша задача состоит не в том, чтобы управлять людьми,

• а в том, чтобы управлять процессами, а людей — направлять.

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

Ведите себя так, как вы хотели бы, чтобы они вели себя на вашем месте.

Процессы — это чётко сформулированные ожидания

Многие воспринимают понятие «процессов» негативно. «Нам не нужно так много процессов» и так далее. Это, имхо, снова недопонимание.

Процессы — это не сложные цепочки действующих лиц, приводящие к катастрофическим расходам. Процессы — это конкретизированные ожидания. Формулировка может быть простой, по типу «каждое утро мы все делаем Х, чтобы остальные могли без проблем заняться Y». 

Сформулируйте пару предельно ясных процессов и установите их за правило.

Решения против мнений

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

В идеале решение принимает тот, кто возьмёт на себя всю дальнейшую работу.  Остальные — повторюсь — только делятся мнениями. Это касается и руководителей.

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

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

Если сомневаетесь, посмотрите, можете ли вы доверять тому, кто принимает решение,  по умолчанию.

Личная ответственность

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

Давайте сотрудникам обратную связь, помогайте им, доверяйте. И позволяйте им совершать ошибки (в рамках разумного). Воспринимайте их, как рост компетенции.

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

Если вы добиваетесь именно этого, нанимайте на работу людей попроще и подешевле. 

Избегайте челночного бега

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

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

Доверие

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

А ещё всегда легко доверять, когда дела идут хорошо. Гораздо сложнее — когда всё идет не так. Различайте, когда вас напрягает ситуация, а когда — человек

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

Доверие через открытость

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

Доверие не категорично

Мы часто думаем о доверии бинарно — я либо доверяю кому-то, либо нет. Но это не так. Разным людям мы со временем доверяем по-разному в зависимости от ситуации.

Думайте о доверии, как о материале для систематизации. Например, какой уровень доверия вы окажете новому сотруднику? Чего вы ждёте от него в первые недели работы? В первый месяц?

Не путайте автономность с пофигизмом

Я часто сталкиваюсь с людьми, которые нанимают новых сотрудников и «не мешают им работать». В принципе это верно, но это не значит, что вы не должны помогать им добиться успеха.

Наслаивание решений

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

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

Избегайте управления «на бегу»

Приведу пример. Стоит группа, что-то спокойно обсуждает. Менеджер пробегает мимо по своим делам и как бы мимоходом накидывает требований, вбрасывает идеи, перераспределяет полномочия, создаёт неразбериху и удаляется в закат. На сцене — сплошной бардак. Это я называю управлением «на бегу».

Не разбрасывайтесь мнениями и идеями на каждом совещании. Скорее всего, вы не владеете контекстом. И скорее всего, не вам потом придётся доводить дело до конца.

Чётко давайте понять, что это всего лишь мнение, а не решение. Но имейте в виду, как сотрудники воспринимают мнение основателя компании (или менеджера). Используйте тег FYI в рассылке — там обычно сложно передать нюансы тона.

Обратная связь

люди х контекст = результат

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

В фидбеке проще объективно обсудить контекст ситуации, нежели сотрудника. Что именно привело к текущим проблемам? Что изменилось? Что сейчас нужно сделать?

Джун не справляется с работой. Это его вина? Или сейчас команда не может объяснить ему, что к чему? Это обычная проблема, но нужно признать её существование и решить её. Возможно, через увольнение.

Кто-то сломал продакшн. Как такое могло случиться? Куда смотрела команда? Были ли инструкции на этот случай? Не стоит ли составить их сейчас? 

Человек, который всё сломал, тут не виноват. Вся команда фокусировалась на других задачах. По правильной ли причине (например, разгрузить бэклог)? Или по неправильной (не хватило квалификации)?

Всегда исходите из того, что люди, которых вы наняли, мотивированы и хотят сделать как лучше. А тех, кто не хочет — увольняйте.

Увольнение никогда не должно быть сюрпризом

Увольнение не должно быть сюрпризом. Контекст изменился, и должны были быть озвучены новые требования.

Когда вы кого-то увольняете, как правило, вы делаете это из-за контекста:

• изменилась компания;

• изменились ожидания от роли сотрудника;

• вы поняли, что наняли человека не с той квалификацией, которая вам нужна.

• и скорее всего, это по большей части ваша вина, а не его.

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

Никогда не затягивайте с увольнением

Зачастую сотрудников держат в компании в состоянии зомби. Все думают: «Нам нужно уволить их». Но вы этого не делаете. И не ради них. Их-то, скорее всего, такая ситуация не устраивает — их не ценят, у них нет возможности выполнять работу качественно.

Нет, вы делаете это для себя. Потому что вам не нравится увольнять людей.

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

Назначьте встречу и увольте. Не болтайте на отвлечённые темы в начале разговора — сразу переходите к делу и чётко следуйте этим правилам:

1. Ясно донесите мысль о том, что они уволены;

2. Помните, что сейчас речь идёт не о ваших чувствах и проблемах.

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

Чётко > Нечётко

Нужны чёткие решения после совещаний. Нет чёткого решения? Поднимите вопрос.

Нужно чёткое понимание того, кто за что несёт ответственность. Нет чёткого распределения ответственности? Поднимите вопрос.

Определите, кто принимает решение, и какое решение в итоге принимается.

И так далее.

Лучшие приёмы: обозначить то, что уже есть

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

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

Будьте готовы к тому, что компанию придется перестраивать каждые несколько месяцев

Быстрорастущие стартапы должны перестраивать внутреннюю структуру каждые 3–6 месяцев. Поэтому вносите минимальные изменения, нужные прямо сейчас. Идеала вы никогда не достигнете:
— вы всегда будете недовольны процессами в компании;
— вам будет нелегко и больно расти, пока не достигнете застоя.

Руководствуйтесь теми же принципами, которыми пользовались бы при рефакторинге кода:

• проводите тестирование на изолированном участке;

• оценивайте происходящее с коллегами;

• не меняйте всё сразу;

• не усложняйте;

• и так далее.

Выгорание

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

Помните, что довести себя/сотрудников до выгорания можно и не работая/мало работая.

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

Хаос не ощущает тот, кто его создает

Основатели бизнесов часто бывают недовольны тем, что команда не поспевает за сменой курса.

Как основатель, вы, скорее всего, лучше понимаете контекст изменений, вы узнаёте о них раньше остальных и, что самое важное, вы их контролируете.

У сотрудников этого нет.

Больше ожидайте от менеджеров в подчинении

По умолчанию ответственность за ошибки несут они, а не их команды. Честно делитесь с ними своим мнением наедине.

По умолчанию всегда доверяйте им в принятии необходимых решений.

Они несут ответственность за результат. Они отвечают за неудачи, но не за успех. Это — достижение команды.

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

Начали на радостной ноте — и закончили ей же.

Читайте также:

• За два года стать разработчиком и устроиться в Tesla. Рассказываем историю Сергея

• 7 вопросов, которые стоит задать на собеседовании: советы разработчикам

• Эйджизм, утечка мозгов и растущие запросы. Поговорим про тяготы найма в IT

Компания Geekfactor cовместно с Getmentor.dev проводит программу подготовки к трудоустройству в зарубежные стартапы (бесплатно помогаем подготовиться к интервью и показываем резюме классным компаниям) — почитать о ней подробней и зарегистрироваться можно тут.