10 идей из книги «Как управлять интеллектуалами»

    Жизнеспособна ли ваша команда? Должен ли руководитель кодить? Всегда ли инженеры ненавидят процессы? Какими должны быть регламенты? Как оценивать производительность инженеров? Почему так важны тет-а-теты? Как побыстрее «свалить» с совещания? Почему в Кремниевой долине так любят плоские организационные структуры? Если эти вопросы для вас актуальны, то вам стоит почитать книгу «Как управлять интеллектуалами. Я, нерды и гики» Майкла Лоппа. Книга будет полезна тем, кто хочет более осознанно заниматься управлением инженерными командами. Предлагаю подборку важных идей книги.

    amazon litres

    Книга «Как управлять интеллектуалами Я, нерды и гики» Майкла Лоппа  представляет собой сборник выдуманных и остроумных историй из профессиональной деятельности менеджеров по разработке софта. Майкл Лопп проработал более 20 лет в различных инновационных компаниях Кремниевой долины — Palantir, Apple, Borland, Slack и др. Всё это время параллельно со своей работой он вел блог под псевдонимом Рэндс. В итоге истории из блога перекочевали в его книгу. 

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

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

    • управление конфликтами,
    • найм и мотивация сотрудников,
    • понимание разных типов персоналий сотрудников-инженеров,
    • как создавать эффективные организационные структуры и инженерные команды,
    • эффективное ведение совещаний.

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

    Ниже предлагаю мою подборку важных идей из этой книги.

    Кстати, в начале этого года я также прочитал…

    Не менее интересную книгу на похожую тему — «Сначала нарушьте все правила: Что лучшие в мире менеджеры делают по-другому». Её написали Маркус Бакингемм и Курт Коффман. Мой обзор можно прочитать на Хабре. Если будет интересно, книгу Бакингема и Коффмана можно купить здесь.

    Ваша команда жизнеспособна?


    Пройдите простой «тест Рэндса», в котором вы можете набрать максимум 11 очков. Если вы набрали менее 8 очков, то у вас есть пара серьезных проблем. «Если вы получили от 8 до 10 очков, то у вас опасно низкий уровень коммуникации, стратегии или личностного роста. Чего именно? Это зависит от конкретных очков, которые вы не смогли заработать», — пишет Лопп.

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

    1. Проводятся ли у вас совещания тет-а-тет? +1 — да, 0 — нет

      «Цель тет-а-тета – провести что-то вроде беседы о сути деятельности команды».

      «Тет-а-тет – это еженедельное инвестирование в сотрудников, которые составляют вашу команду. Если ваши тет-а-теты нерегулярны или вы не считаете их особо ценными, то вы укрепляете миф о том, что руководители недоступны».
    2. Проводятся ли у вас общекомандные совещания? +1 — да, 0 — нет

      «Общекомандные совещания должны обладать такими же двумя основными признаками, что и тет-а-теты, а именно систематичностью и фокусом на сути деятельности команды, а не на текущем положении дел».

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

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

      «Отчеты о статусах проектов обычно появляются, когда руководитель чувствует, что он отдаляется от некоей части организации и верит, что сможет избавиться от этого ощущения, заставив своих сотрудников тщательно документировать свою рабочую деятельность. Но это не поможет! Девяносто процентов людей, которые обязаны направлять отчеты о статусе проектов по электронной почте, думают об одном и том же: ''Мой руководитель не ценит мое время''».
    4. Можете ли вы сказать своему боссу «нет»? +1 — да, 0 — нет

      Когда ваш босс «открывает рот и говорит какую-нибудь откровенную глупость, то ваше святое контрактное обязательство перед акционерами компании, в которой вы работаете, – поднять руку и возразить: ''Вы говорите глупости! И вот почему…''»

      Если вы этого сделать не можете, то в вашей компании что-то идет не так.
    5. Можете ли вы объяснить стратегию вашей компании незнакомцу? +1 — да, 0 — нет
    6. Можете ли вы рассказать о текущем состоянии дел в вашей компании? +1 — да, 0 — нет

      «Вы постоянно должны работать над составлением общей картины, отображающей состояние вашей компании». Хотя бы на уровне — она скорее растет или умирает.
    7. Ваши руководители регулярно выступают перед всеми сотрудниками и рассказывают о том, что они думают? Верите ли вы им? +1 — да, 0 — нет

      «Когда команда растет, требуются более серьезные инвестиции в организацию корпоративной коммуникации, особенно если речь идет о сотрудниках низшего звена. Директора, лидеры и руководители — это люди, которые обычно активно вовлечены во все основные события в компании, потому что в этом, собственно, и состоит их работа. Но помимо этого, их работа состоит в том, чтобы эффективно организовать обмен информацией».
    8. Вы знаете, что хотите делать дальше? +1 — да, 0 — нет. Бонусное очко: А ваш босс знает? +1 — да, 0 — нет.

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

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

      Бонусное очко — это если ваш босс знает о вашем карьерном плане. Он имеет больший доступ к корпоративной информации и может сильно помочь.
    9. У вас есть время на стратегическую деятельность? +1 — да, 0 — нет.

      Вы не просто должны представлять свои карьерные цели, но и реально двигаться в их сторону. Для этого у вас должно быть выделено время для стратегической деятельности.
    10. Вы активно боретесь с сарафанным радио? +1 — да, 0 — нет.

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

    Почему инженеры не любят процессы?


    Источник

    Все инженеры ненавидят процессы. Но почему? На самом деле инженеры — это структурированные люди, которые обожают порядок. На самом деле инженеры ненавидят не процессы, а если никто не может объяснить, почему процессы именно такие.

    Когда компания была маленькая, то все знали, как все работает, или знали, у кого можно спросить. Когда компания вырастает и волшебное число Данбара оказывается достигнутым, то начинаются проблемы: «старая гвардия» обычно ленится рассказывать «новой гвардии», как все устроено, а «новая гвардия» в какой-то момент устает пытаться разобраться, как правильно все делать. 

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

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

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

    Должен ли руководитель разрабатывать софт?


    Автор задается вопросом должен ли руководитель продолжать писать код. Когда-то автор думал, что нет, так как он считал, что если руководитель продолжает писать код, то это не позволяет ему доверять и делегировать своим разработчикам. Впоследствии он радикально изменил свое мнение. Теперь он считает, что руководителю писать код нужно обязательно. 

    Идея в том, что сфера разработки ПО меняется очень быстро. Для того, чтобы понимать вашу команду, вы должны оставаться в курсе того, как ваша команда создает софт. Это важно и для эффективных коммуникаций в команде (как вы сможете общаться с разработчиком, если не понимаете что он делает?), для поддержания эффективных процессов в команде (может быть, нужно не бороться с проблемами, а придумать способ как создать условия чтобы их не было совсем?) и для поддержания креативности в команде (рискнете ли вы использовать новую технологию вместо той, которую используете уже 5 лет?). 

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

    • работать в  среде разработки команды; 
    • нужно уметь нарисовать архитектурную схему вашего продукта любой детальности в любой момент времени;
    • взять на себя реализацию какой-нибудь маленькой функции ( крайнем случае — исправляете баги); 
    • писать модульные тесты.

    Зачем нужно учиться на своем опыте?


    Источник

    Совет автора о том, что надо иногда подумать, выглядит очевидным. Однако в реальной жизни я гораздо чаще сталкиваюсь с ситуациями, когда команды фокусируются только на getting-things-done и очень мало на том, чтобы проанализировать свой же предыдущий опыт и на его основе пополнить свой «колчан» стрел менеджерского опыта. 

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

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

    По Лоппу: «Стресс – это убийца креативности. Когда вы находитесь в состоянии стресса, у вас включается режим реагирования и выживания. В стрессе вы мыслите так: ''Как мне выжить?'', а вовсе не так: ''Что может стать элегантным решением этой проблемы?'' Элегантное решение проблемы требует наступательных действий и чем ниже уровень стресса, тем эффективнее ваше наступление».

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

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

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

    Об оценке производительности


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

    Автор предлагает использовать модель оценки сотрудников Skill vs. Will. На шкале Skill откладывается уровень навыков, на шкале Will — уровень намерений. 

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

    «Когда вы «распишете» кого-нибудь с помощью графика Skill vs Will, вы начнете понимать, в чем именно состоит ваша «работа на полную ставку» – в постоянном и неуклонном продвижении своих сотрудников в верхний правый квадрат. Высокий уровень навыков (я хорош в том, что я делаю) и высокий уровень намерений (мне нравится то, что я делаю)».

    Автор предлагает разделять обратную связь по положению на графике Skill vs. Will от обсуждения повышения з/п или бонусов, особенно, если обратная связь негативная, в этом случае сотрудник не сможет воспринять ее в одновременном обсуждении с денежными вопросами.

    Источник

    Описание пограничных ситуаций на графике:

    • «Высокий уровень навыков, низкий уровень намерений. 

      Надвигающаяся скука. Требуется поменять сценарий и зоны ответственности. Причем немедленно!»
    • «Высокий уровень намерений, низкий уровень навыков. 

      Требуется тренинг, требуется менторство. Требуется руководство! Хорошая новость состоит в том, что такие сотрудники действительно очень сильно мотивированы на выполнение своей работы. Наслаждайтесь этим прямо сейчас, потому что вскоре, когда они подтянут свои навыки, они начнут стремиться заполучить вашу должность. Так всегда бывает».
    • «Низкий уровень намерений, низкий уровень навыков. 

      Парень, ты лажаешь!»
    • «Высокий уровень навыков, высокий уровень намерений. 

      Великолепная работа, однако (гмммммм!)… Знаете что? Помните о том, что никто не способен удерживать это положение в течение длительного периода времени».

    О важности коммуникаций


    «Руководители – это коммуникационные «хабы». Чем эффективнее они коммуницируют вне своей среды, тем больше информации они могут собрать и тем к большему количеству людей они получают доступ, а это неизбежно приводит к принятию более качественных решений. Получается, что сильные коммуникаторы принимают качественные решения благодаря высокой информированности». У всех профессий есть свои жаргоны, у руководителей — тоже. Руководители разговаривают между собой на специальном «начальничьем» языке. Приметы «начальничьего» языка — словечки типа: «взять на контроль, углубиться в тему, запарковать решение, держатель контракта и т. д.». Однако, когда вы разговариваете со своими сотрудниками, вы должны отбрасывать начальничий язык и разговаривать просто и понятно для всех и каждого. Руководители, которые так не делают, ленятся.

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

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

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

    Команда может не понимать того, что вы ей транслируете. Рекомендации автора на этот счет — сопровождайте информацию поясняющими комментариями и прибегайте к уточняющему вопросу: «Что вы сейчас услышали?».

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

    «Ваша команда сама расскажет вам о своих потребностях!». Лопп рекомендует в ситуациях, когда он не чувствует отклика или понимания, просто замолкать — команда сама расскажет, что ей нужно.

    Зачем нужны тет-а-теты? Как их проводить?


    Один из важнейших инструментов в арсенале руководителя, по мнению автора, — тет-а-теты. Он к ним возвращается много раз во многих своих историях. Майкл считает, что: «Руководители, которые не проводят регулярных совещаний тет-а-тет с каждым членом своей команды, сами вводят себя в заблуждение. Они считают, что информация о том, что в данный момент происходит в их подразделении, волшебным образом придет к ним из космоса, но она не придет! Не возникнет новых идей, таланты будут зарыты в землю, а команда постепенно начнет думать, что их мнение никого не волнует. А команда – это компания!»

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

    Основные правила тет-а-тетов:

    • тет-а-теты должны быть регулярными и в определенные дни (автор считает, что тет-а-теты необходимо проводить еженедельно); 
    • «никогда не отменяйте тет-а-теты! Каждый раз, когда вы забиваете на тет-а-тет с человеком, которым руководите, он думает: «Значит, я не так важен»;
    • «отведите на тет-а-тет не менее 30 минут».

    Автор определил следующие типы тет-а-тетов: сводка текущих событий (все в порядке), жалоба (что-то случилось), катастрофа.

    Как правило тип тет-а-тета становится понятен сразу после ответа на вопрос открывашку «Как дела?».

    Рекомендации для «сводки текущих событий»:

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

    Рекомендации для «жалобы»

    • Замолчите, не пытайтесь успокоить или спорить — человеку нужно сначала выпустить пар. Иногда люди начинают повторяться и бесконечно повторять свою проблему, не пытаясь решить ее. 
    • Только потом уже переходите на конструктивный диалог.

    Рекомендации для «катастрофы»

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

    Как сделать более эффективным совещания?


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

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

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

     Предлагаемая последовательность действий, если вы попали на совещание.

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

    Об организационной структуре


    Автор считает, что в нашем тысячелетии самый эффективный способ создания здоровой команды – это максимальная «горизонтальность». Он выделяет всего три типа лидерства: 

    1. Лидеры, например, руководитель команды, тимлид;
    2. Лидеры Лидеров, например, старший менеджер, отвечающий за несколько команд;
    3. Директора.

    Лидеры максимально сфокусированы на своих командах. Лидер — тактик.

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

    По мнению Лоппа, Лидеры Лидеров в действительности управляют компанией.

    Лидер Лидеров совмещает как тактические, так и стратегические активности.

    «Директор сфокусирован в первую очередь на внешнем. Работа Директора состоит в том, чтобы выяснять, каким образом компания соотносится и взаимодействует с окружающим миром». «Он вполне может быть силен и в тактике, однако он должен руководить, опираясь в первую очередь на свою захватывающую стратегию, а не на эффективную тактику». Директоров часто не понимают, так как стратегию сложно воспринимать тактикам. Роль Лидеров Лидеров — доносить стратегию директора до команд.

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

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

    Нужно другое решение этой проблемы карьерного роста.

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

    У автора нет окончательного решения, но он предлагает внедрить в компаниях ДНК-совещания (ДНК — от англ. DNA, Design & Architecture). На это совещание приглашаются только самые крутые инженерные головы, и на этом совещании решаются важные технические и архитектурные проблемы. Участие в таком совещании должно быть очень почетно. Чистые менеджеры не приглашаются на такие совещания, так как «ДНК-совещание подразумевает идеально культивированное техническое лидерство».

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

    О типажах сотрудников


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

    «Стабильные инженеры – это инженеры, которые:

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

    «Взрывоопасные инженеры – это инженеры, которые:

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

    Взрывоопасные и стабильные ненавидят друг друга. Автор утверждает, что тем не менее этот конфликт — жизненно важный для компании, и задача руководителя состоит в том, чтобы подпитывать его. Если власть в компании займут только «стабильные», — это будет означать постепенный закат компании. Конечно, это не будет так явно, стабильные тоже будут привносить инновации, но это будут инновации совсем другого рода — в русле текущей главной линии. Ничего по-настоящему инновационного компания не сделает. Если власть займут «взрывоопасные», то компания может оторваться от реальности и ничего не будет доведено до конца. Пропадет всякая стабильность, повторяемость и надежность результатов.

    Автор также выделяет следующие типажи сотрудников — инкременталисты и комплеционисты. 

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

    Комплеционисты — те, кто может выработать «правильное» решение, но к которому нужно идти довольно долго, и которое они не знают, как реализовать. Комплеционисты считают, что все вокруг только лажают и делают халтуру. Им тяжело смотреть на инкременталистов, которые убедительно проталкивают свои тактические решения. Часто проблема комплеционистов, что они не чувствуют людей и не могут донести свое решение до других.

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

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

    Автор еще также оценивает типажи людей по тому, как они подходят к сбору и анализу информации, на механиков и органиков.

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

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

    «Запомните! Механические руководители собирают информацию структурированно. Они это делают, потому что плохо умеют общаться с людьми. Чтобы собрать необходимый контент, они пользуются только левым полушарием. Это означает, что если ваш руководитель — механик, то вам нужно выдавать ему информацию в структурированной, четкой и логичной форме».

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

    Бывают «двустволки» — органические механики и механические органики.

    Заключение


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

    Для меня «Истории Рэндса» были очень интересными и поучительными. Поработав в ЛАНИТ на разных проектах с разной культурой — как на стартаперских, так и на больших — я симпатизирую идеям автора об эффективных плоских организационных структурах, развитию инженерной ментальности и креатива. Книга заслуживает прочтения и каждый найдет в ней что-то актуальное для себя.

    ГК ЛАНИТ
    Ведущая многопрофильная группа ИТ-компаний в РФ

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

      0
      На самом деле инженеры — это структурированные люди, которые обожают порядок. На самом деле инженеры ненавидят не процессы, а если никто не может объяснить, почему процессы именно такие.
      Мысль правильная, но, поправьте немного, повторения убрать бы
        +1
        Обратил внимание, что очень мало компаний ответственно относятся к переводу сотрудника на руководящую должность. Просто дают в какой-то момент «человека в помощь», иногда вместе с новым титулом или грейдом. А вот как правильно делегировать, контролировать, мотивировать, помогать в саморазвитии, выстраивать дружеские, но не панибратские отношения — совершенно не ясно. И главное, как самому в процессе руководства поменьше стрессовать, получать по-максимуму удовольствия от менеджмента своей команды дабы не сгореть?

        Надеюсь, эта книга поможет. Может, посоветуете еще парочку хороших книжек на эту тему?
          +1
          вот недавно прочитал книгу хорошую по этой теме и сделал обзор также на хабре, посмотрите здесь
          +2
          Пройдите простой «тест Рэндса», в котором вы можете набрать максимум 11 очков. Если вы набрали менее 8 очков, то у вас есть пара серьезных проблем. «Если вы получили от 8 до 10 очков, то у вас опасно низкий уровень коммуникации, стратегии или личностного роста. Чего именно? Это зависит от конкретных очков, которые вы не смогли заработать»
          Звучит очень странно… 11 — это максимум, а 10 — это опасно низкий уровень…

          3. Есть ли у вас отчеты по статусу проекта? +1 — да, 0 — нет

          Автор считает, что письменные отчеты о статусе проектов — это зло.
          Какое-то противочречие… Видимо вопрос об устных отчётах?

          По поводу личных встреч (тет-а-тет): когда попал в команду, где они были приняты — обалдел от удобства и правильности, теперь с тоской вспоминаю о них.
            +1
            Звучит очень странно… 11 — это максимум, а 10 — это опасно низкий уровень…

            да, но так в источнике. Я так понял, что все пункты для автора важны и если где-то вы не добираете — значит в какой-то части у вас опасная просадка )
            Какое-то противочречие… Видимо вопрос об устных отчётах?

            Спасибо! мой косяк, перепутал +1 и -1.
              +1
              Я так понял, что все пункты для автора важны.
              Ну да, идею я понял… Просто между максимумом и опасно низким уровнем что-то должно быть, как мне казалось… В том смысле, что если есть максимум, то есть и что-то промежуточное…
              Возможно, это похоже на некий чеклист — все пункты должны быть выполнены (это говорит о том, что «всё в порядке»), а невыполненные пункты — это уже проблема…

              Спасибо! мой косяк, перепутал +1 и -1.
              Были же 0 и 1? Или там было вычитание? Я как-то не заметил…
                +1
                да, было 0/1, но я проверил в оригинале, там оказалось -1
            0
            должен ли руководитель продолжать писать код

            О руководителях какого уровня идет речь? О тимлиде или генеральном директоре?

              +1
              В книге автор пишет про то что по его мнению лучше всего работают плоские структуры максимум из 3-х уровне. Четко автор не отвечает на ваш вопрос. Я думаю, что имеется ввиду что точно должен писать код ТЛ, очень желательно — менеджер ТЛ. Про директора — не уверен, скорее всего, тут уже никак не получится это делать.
                0
                Мне кажется колчиество уровней должно зависеть больше от размера проекта. При 3 человеках странно иметь 3 уровня, а при 10000 для 3 уровней у одного руководителя будет порядка сотни подчиненных, что выглядит не очень жизнеспособным.
                По-моему мнению наиболее эффективны структуры с 5-10 прямых подчиненных(по крайней мере для управления девелоперами), при более 5 подчиненных ты уже уходишь в менеджмент вместо разработки, при 10+ подчиненных начинаются поблемы с коммуникациями и полным пониманием кто что делает, проблемы с коммуникациями и в случае аврала проблема с тем где что нужно тушить.
                  +2
                  там фишка немного другая, продвинутые конторы из Кремниевой долины стараются использовать всякие подходы при которых люди наделяются большими полномочиями и могут принимать много решения самостоятельно… т.е. они уходят от централизованного принятия решений, когда босс все решает и спускает решения вниз и тд. Например, сейчас читаю книгу про OKR и там упоминается, что Google переиначил «правило 7» 0- если раньше говорили, что менеджер может управлять не более 7 подчиненными, то Google считает, что менеджер должен управлять не менее 7 подчиненными ))).

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

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

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