Глупость и излишняя уверенность. 13 качеств хорошего руководителя



    Я инженер и дизайнер. Мне нравится представляться людям именно так, особенно в Европе. Слово «инженер» там носит интересный налёт загадочности, интеллектуальности и богатства. В общем, очень помогает заводить новых знакомых.

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

    А ещё я почти 10 лет руковожу небольшой организацией. Но при этом всегда продолжал программировать и дизайнить как минимум в виде хобби.

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

    В очередной раз планируя проект, поймал себя на мысли «Ну, архитектуру REST API я-то и сам могу сделать. Заодно функциональные требования напишу и нарисую дизайн для MVP. Там же немного совсем». И тут в голове захохотал голос:
    — Сказочный ты руководитель, раз самому приходится всё делать.

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




    1. Глупость


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

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

    Вот ещё три исследования в пользу отказа от чрезмерных умствований.
    1. Введение дополнительной информации может увеличить вероятность принятия неверного решения.
    2. Для принятия решений люди используют гораздо меньше сведений, чем они думают.
    3. Когда ты считаешь себя самым умным, сложно доверять работу другим. А работа, выполненная под твоей опекой, кажется тебе более значимой, даже если на самом деле это не так.



    2. Излишняя уверенность


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

    Мало того, недостаточно просто чувствовать уверенность внутри себя. Нужно её демонстрировать. А это уже отдельный навык. У кого-то есть к нему талант, а кому-то нужно специально тренироваться.

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

    В одной из статей я встречал определение «de-facto leader». Это когда при наличии формального начальника, реальные решения в организации принимает один из его подчинённых, которого просто больше слушают из-за того, что тот увереннее действует.


    3. Энергичность


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

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

    Есть одно простое правило: никогда, ни за что и ни при каких обстоятельствах не общайся с командой, если у тебя плохое, вялое настроение.

    Проспись, выпей кофе, погуляй, пожамкай антистресс, выпей кофе, посмотри на птичек, послушай музыку, выпей кофе. Если ничего не помогает, лучше перенести встречу.


    4. Честно о плохом


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

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

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

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


    5. Делегировать, а не командовать


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

    Как вам определение «полная личная ответственность»? Мы не просто расплывчато и неопределённо делегируем, мы передаём задачи под полную личную ответственность. После такой передачи у менеджера появляются:

    • Полная свобода действий
    • Безусловный авторитет перед сотрудниками
    • Единоличный контроль над своими сотрудниками


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

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


    6. Не работать без плана


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

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

    Планирование может занимать много времени. Чтобы ресурсы компании не простаивали, стоит заранее обговорить с людьми, что они должны делать, когда нет постановки. Это может быть:
    • Закрыть 10 тикетов из бэклога внутренних проектов
    • Сходить на конференцию и сделать доклад о том, что нового узнал
    • Самые крутые ребята сами с удовольствием придумывают себе задачи и пилят их на благо компании
    • По договорённости можно дать человеку дополнительный выходной за счёт того, что он отработает его во время активной фазы проекта



    7. Не брать чужую работу


    Все, кто не читал знаменитую статью «Менеджер и его время, или Кому достанется обезьяна» — скорее читайте её. С 1974 г. это самая популярная публикация Harvard Business Review. Менеджеры по-прежнему наступают на старые грабли, позволяя подчинённым ставить себе задачи.

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

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

    В отношениях с начальством можно выделить 5 уровней инициативности:
    1. Сотрудник ждёт, пока поступит прямое указание
    2. Сотрудник спрашивает, что нужно делать
    3. Сотрудник предлагает свой план, который затем реализует
    4. Сотрудник действует самостоятельно, по ходу дела спрашивая совета
    5. Сотрудник действует совершенно самостоятельно и в конце представляет отчет о проделанной работе


    Признаюсь, не встречал руководителей в ИТ, которые хотели бы видеть в команде хотя бы одного человека, действующего по принципу №1. Я бы сказал, что нужен как минимум 3-й уровень инициативности.


    8. Не критиковать за инициативу


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

    Да и вообще всяческие наказания стоит убрать из своего арсенала. Я ради интереса пробовал подход «Я — начальник, ты — дурак», это давало очень кратковременные результаты и всегда заканчивалось уходом человека из команды.


    9. Давать и выполнять обещания


    Люди перестают доверять тем, кто забывает свои обещания. Но это работает и в обратную сторону. Если планомерно следовать за своим словом, тебе начинают больше доверять.

    И то и другое применимо даже к микрообещаниям по самым пустяковым поводам. «Вечером пришлю тебе ссылку на ту книжку, о которой говорил», «Да, давай сходим в столовку, освобожусь через 15 минут». А минус в карму тебе принесёт даже передвинутая встреча. Нужно следить, чтобы выполненных обещаний всегда было больше, чем невыполненных.

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


    10. Единоначалие


    О принципе единоначалия в менеджменте писал ещё Анри Файоль (батя современного менеджмента). Это правило актуально до сих пор. Если сотрудник получает задания и отчитывается о результатах перед несколькими менеджерами, ни к чему хорошему это не приводит.

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


    11. Оценивать по результатам


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

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


    12. Не тянуть с расставанием


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

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

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

    В конце концов, с адекватными людьми всегда можно сойтись снова. И я так не раз делал.


    13. Благодарить вслух


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

    Мне очень сложно с этим. Думаю «восхитительно», а говорю «норм». Для людей с такими же проблемами есть несколько советов:

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

    Статью написал Денис Элиановский.

    Спасибо Станиславу Лушину и Татьяне Китаевой за помощь и редактуру, Елене Ефимовой — за картинку в хедере.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 15

      +1
      Человеческое настроение, оно как герпес, заразно.

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


      обсуждать задержки зарплаты и переработки

      Вот тут согласен на все 100%, лучше о таком узнать на пороге, чтобы время не терять. Ещё лучше, конечно, сразу в описании вакансии.


      А так у вас конечно забавный портрет хорошего руководителя вырисовался — туповатый самоуверенный чувак, который не решает твоих проблем, а только задалбывает всех своей энергичной беготней с ободряющими речами с "прямой спиной", слава богу хоть иногда отстаёт, отвлекаясь на птичек и кофе.

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

        Мне зашло все. Буду трансформироваться в этом направлении.
        Пункт первый даже не спорный, примерил на себя и действительно — когда ставлю задачу тут же прокручиваю риски.
        В итоге вместо «иди и делай!» получается «ну вот попробуй, тут конечно есть нюансы, но вдруг получится». Так что даже первый пункт верен, хотя сформулирован конечно спорно :)
          +3
          Хотелось бы поподробнее обсудить пункт 7… Понятна проблема, непонятно что же предлагается в качестве решения :)
          Работаю в продуктовой компании 5000+ чел, у нас четкая установка «задача менеджера — по максимуму помогать подчиненным и коллегам».
          Коллеги, подчиненные, начальство — у всех есть проблемы, все просят тебя помочь.
          Хорошо когда есть в наличии достаточное количество сильных, независимых сотрудников которые и сами знают что делать, и на которых можно много делегировать, но обычно таких людей немного.
          Растить «ответственных-инициативных» из тех кто есть? Это блин не натаскать джуниора на С++, сложная задача :)
          Пока застрял в режиме «днем помогаю другим, вечером делаю свою работу», как и в прошлую свою попытку захода в менеджмент/тимлидство. Выгорание машет из-за угла :)
            0
            Помогать можно по-разному же. Кому-то просто нужно пнуть соседнего менеджера или подписать замену компа на более мощный или разобраться с приоритетом задач. Не всегда же помощь — это выполнение работы подчиненного.
              0
              Судя по тому, что статья про обезьян уже 46 лет в топе, эта проблема терзает многих. Вот несколько советов из самой статьи:

              Следует изложить сотрудникам новые правила игры.

              1) Пока я помогаю вам решить эту или какую-либо иную проблему, она ни на секунду не перестает быть вашей

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

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

              Тут ниже в комментариях есть ссылка на бесплатно доступный полный текст.

              Мне ещё помогает деление проблем на 2 части: те, что в компетенции человека и те, что за пределами его компетенции.

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

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

              Давать ссылки на платные статьи — приём не в стиле хабра, как мне кажется. «Менеджер и его время, или Кому достанется обезьяна?» с hr-portal, как вариант:
              https://yandex.ru/turbo/hr-portal.ru/s/article/menedzher-i-ego-vremya-ili-komu-dostanetsya-obezyana


              В остальном, кратко, но очень информативно подан материал

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

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

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

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

                  — Это из статьи про обезьяну. Мне кажется полезным такой вариант трактовки: время, потраченное на сотрудников, лучше направлять не на прямую помощь им, а на то, чтобы они становились более самостоятельными. Или на то, чтобы сама система, в которой они находятся, была бы для них более понятна и лучше работала. А это в дальнейшем освободит время на свои инициативы
                    +1
                    +1, работаю в сторону улучшения документации/вики (вместо email с инструкциями — сразу страницу в Confluence, а еще лучше Васю/Раджеша попросить ее написать), стараюсь больше давать общих рекомендаций а не лезть самому разбираться (пока тяжело дается, привычка «все сам, все сам» :))) С соседними менеджерами и начальством сложнее. Тут утонуть запросто можно — если начальство фонтанирует идеями, а downstream команды стремятся переложить побольше на твои плечи. Но это уже про копоративную борьбу, вне рамок статьи по сути.
                      0
                      я просил примеры. мой опыт как то сильно расходится с тем, что написано в статье. Ниже VFaland написал, что он человек-оркестр, который затыкает дыры, хотя это и плохой пример, но более жизненный и близкий мне.
                        0
                        пример придумал. есть отличный разработчик, который качественно и быстро разрабатывает, но отвратительно пишет формальные тексты, а на английском и того хуже. Но надо написать документацию к той функциональности, которую он несколько месяцев делал. Ваши действия?
                          0
                          Если бы мы писали симулятор работы начальника, я бы предложил вам попробовать свои силы в этом)

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

                          И в зависимости от этого контекста менеджер может решить, что:

                          1) Сотрудник не может или не хочет делать свою работу. Нужно разбираться с сотрудником.

                          2) Кто-то поручил ему работу, которую он заведомо не может или не должен делать. Нужно разбираться с поручившим.

                          3) В компании вообще не предусмотрено, что кто-то будет писать документацию. Нужно разбираться с процессами внутри компании.

                          4) А надо ли тратить силы на документацию? Может этот проект был тестовым и уже сейчас другой командой пилится новое решение.

                          В статье есть два посыла на эту тему:

                          1) Изначально нанимать лучше такого человека, который придёт с более конструктивной формулировкой. Например «Я не очень люблю писать документацию, но Вася любит. Я с ним поговорил, он не против. Мы можем с ним поменяться задачами?». И в текущих сотрудниках поощрять именно такой подход к проблемам

                          2) Каким бы ни было решение, оно не должно быть «Ну ок, документацию я сам напишу»
                            0
                            мы с вами очень по разному видим как все устроено, я уже задал контекст описав, что документация нужна и у вас есть очень хороший разработчик. Вам уже повезло, очень маловероятно найти такого же только с перламутровыми пуговицами. Я считаю, что в этом контексте нет «хорошего» решения при котором разработчик разрулит ситуацию сам. Когда вы обязываете его самого найти решение проблемы, вы теряете. А как раз задача руководителя минимизировать потери, повысить эффективность и далее по списку. Накину, вы плохой руководитель, т.к. рост производительности команды ограничен догмами, которые вы приняли на веру только потому что источник имеет громкое название.
                      0
                      Зачастую позиция тимлида подразумевает и управление людьми, презентации, встречи с клиентами, и некоторую техническую работу — архитектура, код ревью, некоторые сложные или специфические задачи, или наоборот — разгружаешь людей, даешь им возможность сосредоточится на важных фичах а сам прикрываешь на багах. Особенно если команда небольшая. У нас многие линейные менеджеры (не проджекты и продакты, которые сбоку) в development командах пишут код, и такое наблюдаю во всех американских компаниях где работал… Есть свои плюсы и минусы в этом подходе.
                      +1
                      Спасибо за статью. Мне, как человеку, который только только попал в IT после госслужбы была удивительна атмосфера, когда начальник и подчиненный говорят на одном языке, когда тебя слушают и слышат, а не просто отдают указиловки. С таким руководителем хочется работать.

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

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

                      Самое читаемое