Собирая посты Saint TeamLeadConf-2019 в отчет обновил в памяти впечатления о конференции, вспомнил и заново оценил ту мозаику докладов, которые там услышал. Конференция собрала прекрасные доклады, но именно это от нее ожидаешь - ведь это уже четвертая конференция и ты был на предыдущих. При этом качество докладов - не упало, а ведь бывает и иначе: на первых конференциях все самое интересное было рассказано, и на последующих доклады не столь интересны. Здесь же появляются новые темы и новые спикеры, которые рассказывают не менее интересно, чем докладчики на первых конференциях. И это свидетельствует не только о потенциале самой темы конференции, которая посвящена тимлидам, но и о интенсивном развитии, которые происходит в этой области. Спектр изменений очень разнообразен, это было представлено на конференции, и участники могли соотнести свое представление с происходящим в отрасли. Вообще на конференции - очень крутой состав и спикеров и участников, и общение было было очень содержательным, часть слотов я пропустил, предпочтя общение.

Оригинал на FB

Для меня было интересно посмотреть, как перестраиваются крупные компании, такие как СКБ Контур, выстраивая свой путь - при том, что компания состоит из большого числа команд, развивающих свой продукт, автономных настолько, что руководство не может осуществлять прямое управление, а должно действовать косвенными методами. Именно об это рассказывал Игорь Луканин в своем докладе. И соотнося развитие Контура с эволюцией управления в Spotify, в ivi, о которых я слышал на предыдущих конференциях, можно увидеть общие закономерности и спектр разнообразия новых моделей управления. И, надо отметить, что несмотря на разнообразие, в этих моделях - много общего, связанного с самоорганизацией команд, которая является важной частью новой модели управления.

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

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

Ну а теперь - про доклады конференции.

Про мой доклад Планирование проекта от демонстраций для разворачивания партнерства с заказчиком организаторы написали такой пост на FB: "Вариантов планирования проектов масса. Максим Цепков рассказал о том, как планировать заказные проекты исходя не только из конечного результата в виде выполненной задачи, но и из того, как можно использовать проектное время для выстраивания отношений с заказчиком. Но в целом практики, которые были озвучены подходят и для инхаус-проектов." И это хорошо передает его содержание. Отмечу, что это - тоже часть новой модели управления, предполагающей партнерские отношения и совместное решение бизнес-проблем, а не исполнение требований. Такая практика сильно отличается от практикуемой в классическом enterprise изоляции IT-разработчиков от бизнеса и конечных пользователей через руководителя проекта у заказчика. При этом, после преодоления барьера необычности, она является весьма эффективным способом обеспечить успех проекта даже в условиях, когда реальная ситуация оказывается весьма далекой от зафиксированной в документах на старте.

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

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

Пост на FB Первый слот конференции поставил мне жесткую проблемы выбора - все доклады были очень вкусными. В результате я выбрал Игоря Луканина и получил возможность заглянуть внутрь большой компании, СКБ Контур, где работает 1200 человек инженеров, объединенных примерно в 100 автономных команд, полностью отвечающих за свой продукт и принимающих самостоятельные решения. Настолько автономных, что руководители компании не могут приказать им, и не могут даже настойчиво посоветовать, а лишь уговаривать и создавать условия. Об этом были истории. Первая - про перестройку найма персонала, начиналась 4 года назад, когда было 600 человек и 50 команд, из которых 25 быстро росли (рост компании 20% в год, продолжается и сейчас). Найм тогда был традиционный: собеседование HR, собеседование с разработчиками по hard skill, и собеседование в команду, в которую происходит найм. И, собственно, когда 25 команд хотят разработчика, то с этим возникают проблемы: какие команды ходят на собеседование. Были списки приоритетов команд, те, кто там на 10+ месте - без надежды, а на собеседование приходит по 5-7 человек из разных команд, и это очень некомфортно для кандидата.

Решение, следом за facebook - BootCamp, мы нанимаем не в команду, а в компанию. 2 недели - можно учиться, а за оставшиеся время от 2 месяцев вы должны выбрать команду. А команды должны понравится. Правда, кандидатам не слишком комфортно: "мы не знаем, чем вы будете заниматься". Это непростой вопрос, но они научились отвечать: собеседования с технарями остались, есть секция вопросов кандидата и отвечая, они рассказывают, как у них в команде, и что-то про другие. А дальше есть список команд с контактами, к которым обратиться кандидату, и есть дозированный (чтоб не захлебнулся) поток информации во время испытательного срока.

А вот для команд ситуация поменялась: не вы команда первого приоритета и задавали каверзные вопросы, отсеивали людей, то теперь наоборот, надо было понравится разработчику, чтобы он выбрал команду для стажировке. При том, что причины выбора команды люди не слишком понимают - на слайдах были примеры. Они запилили web-сервис для информации о соискателях, страницу о командах. И после этого команды осознали самобытность, и научились выражать. "Мы - питонисты, сейчас подвинем C#", "у нас аналитики пишут код, а разработчики ревьюят", "собираемся делиться - есть перспективы роста", и так далее. И, интересно - не потребовалось строить процесс, команды примерно за 3 месяца научились.

Почему команду научились. Тут была ссылка на Пол Хейне. "Экономический образ мышления" - учебник, который помог ему разобраться. Экономика устроена просто: события складываются из актов выбора, а выбор делают индивидуумы - отдельные конкретные люди. Именно это и сработало, экономика буткампа основана на том, что Стажеры хотят найти команду и остаться, Ребята из команд хотят, чтобы было полегче, а Организаторы хотят, чтобы не было бунта.

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

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

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

Я тут хочу заметить, что обе истории - ограниченные, и применять стоит с учетом ограничений. Не все люди будут гоняться за своим рейтингами, более того, культура такой погони может быть частью сотрудников негативно воспринята, поэтому тут важна умеренность: дать инструмент, чтобы желающие, которых это мотивирует, могли заняться. Собственно, прямая аналогий с публичными таблицами online-игр: те, кого это мотивирует - соревнуются, но часть игроков приходит совсем за другим, и надо устроить так, чтобы их не оттолкнуть. А с антирейтингом важно, чтобы было социальное согласие о том, чтобы вопрос по которому идет антирейтинг - действительно важный, без этого возникает много негативных социальных последствий, таких как контркультура хулиганов или протест против власти. В рассказе не было акцента на этих аспектах, но, с другой стороны, разумная осторожность инженеров при проведении эксперимента на людях должна тут помочь.

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

Синхронизация с руководителем: :

• назначь митинг
• подготовь показатели и важные проекты
• обсуди
• руководитель что-то предложит сам
• зафиксируй
• и регулярно повторяй

Намерения становятся прозрачными и достижения - измеримыми.

Самое важное: когда много дел, остановись, не пробуй успеть все. Дальше посмотри: что помогает достигнуть цели и что мешает. Визуализация целей. Не представление-медитация утром, а прогресс-бар проекта.

• Каждый проект - в отдельном dashboard, чтобы отделить от текучки. Основа - на тегах/лейблах.
• Лимиты по багам. График открытых и закрытых багов, замечательно оценивает динамику.
• Про инструменты - не всегда есть готовое, чтобы на одном экране список со ссылками, которые откроют нужные графики - тоже работает.

Препятствия.

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

Настройка почты и мессенджеров - фактически, применение матрицы важное-срочное, но с конкретными деталями - как сделать.

Личные карточки для развития команды. Решать сложные проблемы, быстрее справляться с простыми, уменьшать bus-фактор... Карточки - позволяют опираться на данные, а не только на интуицию и память. И дальше - конкретный формат. Секции: навыки, планы развития, фидбэки и 1:1.

• Навыки - только вашей компании и проекта. Не все. Там конкретный список с 10 позиций
• План развития: крупными мазками описать, что должен представлять собой сотрудник. В виде маркеров доказанного опыта (Изучить фреймворк, Самостоятельно деплоить небольшие фичи)

Фидбэк

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

И тоже на инструментальную часть - до часа в месяц на команду.

Систематизируй свое развитие

• Используй разные источники физбэка и источники информации
• Спрашивай, как ты вырос. Можно поставить напоминалку раз в 3 месяца.
• Teamlead Roadmap - крутые ребята запилили варианты

Заметим, что доклад ориентирован на классического руководителя (тимлида), который полностью управляет командой. А в комментариях к моему посту писал о практиках agile, которые обеспечивают те же самые цели: планирование, демо, ретроспектива, приоритеты и дейли митинг.

Пост на FB Компания реально растет в два раза в год, сейчас их около 250 и они готовятся еще вдвое вырасти точно. Корпоративной культурой они занялись, когда найм персонала стал узким местом. Исторически решение принимал CEO, который строил компанию для себя, а собеседовало довольно много народа - и пока компания была маленькой, это было оправдано. Стояла задача расшить это узкое горло, но сохранить идентичность компании, и корпоративная культура была выбрана средством.

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

Подошли они к этому фундаментально и системно, ориентируясь на опыт других компаний. Но при этом делали ценности как продукт: MVP, test&debug, release. Сбор формулировок от сотрудников, проверка, что ценности важны - через истории, где они проявляются. Их получилось очень много, 660(!) и первая кластеризация дала 22 кластера, что тоже не обозримо. Дальше был еще такт, когда их объединили в группы

• Create of better version of yourself every day
• Dare to dream big and work hard
• Drive change and be open
• Embrace trust to turn to failures into wins
• Play, as a team, to win the world
• Yes to passion, no to bullshit

Итого - трехуровневый список ценностей, подтвержденный поведением, историями и мемами.

А в целом Culture Code - слова и картинки

• Контекст - миссия + видение + пояснения (версия, что наружу, что внутрь, какие различия) + история основателя и компании. У них: какие глобальные тренды с изменением работы, и какой вклад команда может внести. Их миссия - лучшие решения для распределенной коллаборации, такие, чтобы было распределенные команды были не хуже локальных
• Определение - что есть культура. Разные компании определяют разное. Их определение: принятие решений + отношение к людям + как любим работать + успешное поведение.
• Почему заботимся о культуре - трассировка от нее к бизнесу. Конкретно, как культура помогает достижению целей компании

Для найма описание ценностей было дополнено идеями для вопросов, как интерпретировать ответы. Интересно, что оценку по ценностям на собеседовании ведет не HR, его на первом собеседовании вообще нет, его ведет hiring manager и два эксперта. hiring manager - роль, которую сотрудник выполняет по совмещению, он знает процесс, приоритеты, ведет до offer. И там есть оценка культуры и риски при приеме конкретного человека по совпадению культуры, а не только по профессионализму. Hiring manager смотрят разброс оценок от разных людей - и разбирается. Дальше идет onboarding, через 2 месяца ревью, в том числе - включение в культуру по самооценке и по проявлениям.

В результате проблему у них решили, у них - 4 команды найма, снова будет 9, масштабирование. А еще именно благодаря вниманию к культуре у них взлетели и реально работают OKR и Scrum, и они борются с silo-эффектом (разобщенности подразделений).

Пост на FB Самая соль доклада была в конце, в метафорах. Задача - как мышка, но без нее нет репки назначения компании. Идеальная задача - как суслик, его никто никогда не видел. Но можно договорить о приемлемом приближении.

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

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

А еще был интересный набор шаблонов плохих постановок, которым начинался доклад.

• Готовое решение, без цели: "Заменить ID на GUID". Часто решение - ложное, и, оказывается, не достигает цели.
• Инверсия, тоже антипаттерн - цель без средства.
• Птичий язык: поднять clickrate продуктовок из native stores. Решение - длинные определения. Но надо не уйти в антипаттерн "советская энциклопедия"
• Взаимоисключащие требования
• Задачи в стол
• Рутинные задачи (сотни однотипных задач, что интересно - понимание реальной ценности рутинной задачи может менять отношение)
• бесконечные задачи, например, улучшение
• отсутствие критерия приемки

Пост на FB В IT руководителями становятся двумя путями: выбирают лучшего разработчика (и тогда команда теряет хорошего разработчика, и приобретает плохого менеджера) или выбирают того, у кого со всеми хорошие отношения. Это - разные люди, и дальше был подробный разбор этой разницы.

Лучшие программисты:

• Задевает, когда кто-то работает хуже, чем он
• Убеждение: работу надо делать хорошо или не делать вовсе. -- это не ко всему имеет отношение
• Любимые книги - технические Дрэгон бук и Кнут.

Те, кто умеет налаживать отношения

• Задевает, когда кто-то в их присутствии наезжает на коллег
• Конфликты в команде - это плохо
• Книги: ДеМарко (Человеческий фактор) и Спольски. О том, что надо погладить.

Первых Орлов назвал отличником (сделать все на отлично), а вторых - хорошистом (сделать всем хорошо).

Крайности вроде разные, но реально - похожие.

• Оба работают больше других. Первый потому что дольше объяснять, чем сделать самому, а второй - потому что не умеют отказывать.
• Отнимают права других: первые - право на незнание (начинающий project сразу должен стать идеальным, как она с 10 годами опыта, потому что делать идеально или никак), второй - право на негатив (я не называю заказчика дебилом, и ты не называй).
• Оба считают, что нет права на ошибку. Ошибка - недостаточно толковый или недостаточно ориентированный на людей
• Быстрое обесценивание: не профессионал / не командный игрок
• Оба считают, что идеальная команда - это все такие, как ты.

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

В заключении отмечу, что эта типология в целом соответствует дихотомии Thinking - Feeling в MBTI, в преломлении к IT-руководителям. Но Саша не отталкивался от дихотомии, а делился своими наблюдениями и опытом.

Да, а начиналось все с того, от чего бомбит на работе по опросам. Ответы разные.

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

Но в целом все разделилось на два кластера

• некомпетентность
• невнимание к людям

Из них и появилась типология.

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

Пост на FB Любопытный доклад про гендерные темы от мужчины, который не только разработчик JetBrains, но еще активно интересуется психологией. И это - личная точка зрения, а не компании. Гендерные темы - сложные, особенно если обсуждение идет из моральной точки зрения или с политическими соображениями - они разобщают, потому что у каждого своя точка зрения на правильное. И поэтому он строит разговор совершенно на других основаниях - экономических. Женщины в IT дают два преимущества: во-первых, это расширение рынка персонала а, во-вторых, разработчицы улучшают климат в коллективе в целом. И дальше было достаточно подробный разбор преимуществ. А также разбор конкретных деталей, изменений культурного климата для выравнивание культуры в гендерном отношении и устранения разобщенности. Кому интересны подробности - послушайте. От себя хочу сказать, что у нас в компании женщин достаточно много, и особых проблем это не вызывает. Правда, разработчиц не так много, больше аналитиков и тестовщиц, что в целом отражает ситуацию на рынке, но команды-то смешанные. Кстати, из зала тоже много реплик о том, что проблема не наблюдается, если профи - все ОК, а если нет - начинаются всякие разговоры. Правда, надо учитывать ошибку выжившего: женщины на конференции прошли такой отбор.

Но в целом позиция - взвешенная, речь идет не о преимуществе, а о выравнивании. Потому что по статистике участия олимпиад гендерное неравенство появляется между 5 и 7 классом.

А еще хочу отметить, что летом на STEPIR было включение Андрея Станченко с впечатлениями с международной конференции ATD-2019 о современных трендах лидерства. И там был тезис о том, что за женским лидерством — будущее. Потому что лидерство всегда связано с нагрузкой и стрессом, а у женщин есть физиологические механизмы, которые дофаминовый стресс гасят через окситоцин, как раз ответственный за эмпатию и взаимопонимание и налаживающий командную работу. А вот у мужчин дофаминовый стресс гасится через тестостерон, что полезно в битве и преодолении препятствий, но не слишком подходит для современного поддерживающего лидерства.

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

Андрей Бреслав Спасибо за внимание к моему докладу! Раньше никто таких выжимок не постил, а это крутая штука. Я хочу для справедливости отметить две вещи:

• я не психолог, просто занимаюсь стартапом про психотерапию: Alter - поиск и подбор психолога
• я не говорил, что "разработчицы улучшают климат к коллективе в целом," думаю, такое высказывание легко понять в довольно негативном смысле. Я говорил, что меры по привлечению женщин в IT, улучшат климат в нашей индустрии для всех, кто в ней работает.

Ещё раз спасибо!

Пост на FB Рассказ разворачивал схему, как управлять своим развитием. В основе - интересная пирамида компетенций: фундаментальные скилы - личная эффективность - soft - hard core (архитектурные) - hard конкретный (языки). В фундаметальные входят Ответственность, нацеленность на результат, парадигмы общения, увлеченность делом, и они дают наибольший потенциал, служат основой для остальных, и они разбирались достаточно подробно: были даны шкалы нет - средняя - высокая с поведенческими маркерами, разбирали детали и способв прокачки. В ответственности высокая компетенция - это принятие ответственности команды, в работе на результат - готовность к изменениям способа достижения цели, наличие плана-Б, в общении - поиск решения win-win.

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

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

Пост на FB Тут я слушал кусочек доклада, где Владимир рассказывал про организацию разных исследований. Обычно исследования поручают самым опытным, а реально можно поручать и не слишком опытным, если опытные люди будут в доступе для вопросов и будут вести ревью результата, и такой подход обеспечивает и масштабирование возможностей и рост новичков. Проблема - патологический оптимизм исследователей. Мы не понимаем, но уверены в своих силах, уверены, что понимаем. Дефицит квалифицированных специалистов этому способствует, особенно в высокотехнологичных проектах. А еще многие IT-шники уверены, что они все запомнят, записывают на доске или на клочках бумаги. А потом их отвлекли - и оказывается, что все забыли ,исследование сгнило. Поэтому организация фиксации результата - тоже существенная важная проблема, хотя кажется технической.

Пост на FB В докладе в самом деле было шесть советов, которые гарантированно гробят командную работу. Проблема в том, что все эти советы - это определенные практики, доведенные до своего абсурдного предела. Проблема в том, что люди, которые их применяют вовсе не считают, что действуют нерационально, что этим своим поведением ведут к разрушению. По разным причинам, Александра говорила почему люди так поступают, какие поведенческие стереотипы и когнитивные искажения лежат в основе. Такие как неверие в сотрудничество, нежелание ответственности, жажда серебряной пули или волшебной таблетки. Как тренер и коуч Александра с этим работает в своей практике, и, в общем, понимает, что просто знать о всех этих проблемах - недостаточно. Решения для компаний, которые предлагала Александра основаны на доверии и сотрудничестве, выстраивании командной работы - понятны. Но проблема в том, что при реализации будут срабатывать те же проблемы, которые привели к текущей ситуации с командной работой. Собственно, Александра именно с этого начала доклад: она работает с замечательными инициативными командами, но руководители зовут ее потому что считают людей из команд негодными и просят их изменить. Проблема у менеджера - а менять почему-то надо людей, которых этот менеджер сам нанял - само по себе прикольная ситуация. И Александра пробует ее вскрывать, и это - помогает, тем более что менеджеры часто говорят об этих проблемах кому угодно, только не команде, и открытый разговор уже изменяет ситуацию в ряде случаев.

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

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

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

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

На входе сразу был вопрос о том, нужна ли вообще работа с токсичными членами команды, есть много советов типа "не терпите великолепных придурков - цена для работы команды слишком высока" (Ричард Гастингс из Netflix). Но дальше есть разные мнения о том, что токсично. Если человек требователен - он может вести к результату несмотря на трудности, а может разрушать. Где граница? А еще токсичных людей обычно все-таки не нанимают, или отвергают на испытательном сроке, но бывает, что токсичность зарождается постепенно, и вот тут вполне можно заметить и устроить профилактику.

Дальше было определение команды: у нее есть общие ценности (value) + цели (vision) + ресурсы + система разделения труда. И фазы по Такману: Forming Storming Norming Performing adjouring (расформинг). А дальше - утверждение, что Команда без ценностей - это Руководитель + Группа, а Команда без Ценности и Целей - иерархия. И вот с этим я не согласен: у католической церкви не было и нет команд, она образует именно иерархическую структуру, но при этом было миссионерское видение и цели. А, с другой стороны, есть различные сообщества по интересам, в том числе в IT, далеко не все из которых имеют собственные ценности и цели (ценности коммуникации и сотрудничества - общечеловеческие), и при этом у них плоская структура, а вовсе не иерархия. Вообще из команды иерархии не получить, она слишком маленькая.

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

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

Типология токсичного поведения была размечена на кривой transition curve из психологии изменений, показывающий зависимость счастья/тревоги от времени, которая нарисована совпадающей с кривой Даннинга-Крюгера уверенности в зависимости от опыта. Тут, правда, возникает вопрос о правомерности совпадения этих кривых, они же описывают динамику разных процессов, но, на первый взгляд, если говорить об изменениях, связанных с получением новых знаний, то должно быть похоже. На кривой есть два пика - первый связан с переоценкой своих знаний и возможностей, затем идет спад с провалом в яму разочарования, а затем - снова подъем в экспертную позицию, за которым спад с потерей интереса к давно знакомому.

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

• На первом пике - переоценка своего знания. В каждой команде (от 50 человек) есть тот, кто всегда знает, как надо. При этом он сам не пробовал - он прочитал. У такого поведения есть биологические предпосылки - это заявка на лидерство молодого, когда он дерется с вожаком. При этом он неопытный. И таких людей всегда надо грузить задачами и требовать результат. Задачи - на пределе возможностей. И это будет рост. А руководитель должен давать достаточно большое давление.
• Человек на провале, долина смерти в бизнесе и яма страданий у человека. И тут как раз нужно принципиально другое поведение руководителя - потому ято под давлением может не хватить энергии, и он придет к тому, что неспособен, не тем занимается и так далее. И тогда идет выход в позицию "бедный родственник" с выученной беспомощностью, с нытьем о помощи, да еще способный переключиться в мстительно-манипулирующий. В то время как выход - в непрерывном труде и преодолении трудностей. Профилактика: если чувствуем такие тенденции - надо понять, какие для человека были значимые победы, quick win. И давать задачи. Как ребенок учится рисовать или что-то еще. Тогда от результатов будет расти эмоциональная энергия. При этом коучить, давать performance review - нет смысла, потому что у него и так эмоциональной энергии нет. Из своего опыта. Он работает с одним коллегой, она приходила за помощью, с кем поработать. А потом прилетало "ты даешь неправильный совет". Она это осознавала.
• Третий вид - на спаде после экспертности. Ядовитая мать: "те меня слушай, я плохого не посоветую". Это эксперт, который долго работает в компании, и ему все надоело. И получается пара. Шура из Служебного романа - явный пример. Такие люди коллег-сотрудников вытаскивают не в деятельность, а в неуверенность. И потому их надо изолировать от коллектива, отправлять на свое место. Давать обратную связь бесполезно - будет агрессия.
• Еще есть Эксперт-бирюк.Волк-одиночка, вне стаи. Изгнанный из стаи, проигравший борьбу молодой волк, который живет в одиночку. Характерны грубость, заявления, что "это работать не будет". Работа с такими - включить его в командную работу. Вот здесь как раз 360 и performance review - способ вывести на командную работу. А если не смогли вывести на командную работу - пусть идет работать один. Отсадить, направить на другой проект. И тогда он выйдет на новую фазу развития, перестанет быть экспертом и начнет расти.
• И еще бывает сверхсамоуверенность эксперта, которого наделили властью. Крыша поехала. Огромное количество фильмов про амбициозных психопатов. Главный переворот: все созданное - не потому, что у него была рыночная ситуация и команда, а потому что он гениальный. Отрыв от земли. Все что у меня есть - потому что Я такой, измерение количеством денег. Но проблема чаще не в этом ,а в ограничивающих убеждениях. Такому человеку нужна обратная связь, Но! выше него никого нет, и связь дать некому. И там - Executive коучинг. И где-то внедрено нормативно, 30% времени руководитель должен быть в коучинге. А так - от психопатов лучше бежать.

Место лидеру и тимлидеру - в провале между горбами. А добежав до экспертной зоны - перескакивать на следующий уровень развития.

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