Тимлид Очевидность | Евгений Антонов

Я принес. Настырный менеджер и как им стать

Чем больше управляю проектами/портфелями на уровне нескольких команд, бизнес-юнитов, силевел или околосилевел стейкхолдеров, руководителей разного уровня со своими разными интересами, желаниями, целями личными и корпоративными, тем больше убеждаюсь в двух вещах:
1. Когда я вел ряд проектов, будучи тимлидом, было сильно проще.
2. Настойчивость и неотвратимость менеджера значат очень многое. Смотрели старый шуточный ролик про самого медленного в мире убийцу с ложкой? Ну или хотя бы фильм «Оно следует»? )

Сегодня я вам принес про это два последовательных поста, чтобы не только меня с моим небольшим (19 лет) опытом послушали, но и многоопытного (20+) менеджера-РПшника:
• https://t.me/morkovka_speredi_morkovka_szadi/595
• https://t.me/morkovka_speredi_morkovka_szadi/596

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

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

Я принес. Нужно работать больше?

Принес вам очередное вдохновляюще-познавательное видео от Александра Клименко https://www.youtube.com/watch?v=uK8GyvDXm3c, где он объясняет и приводит конкретные примеры на тему того, что повышения производительности труда можно добиться не обязательно через «больше доить и меньше кормить».

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

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

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

Стандарты качества и сплоченность команды

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

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

Интересное открытие №1
Часто всякие гуманные менеджеры, типа меня, говорят о важности сплоченности. Мол, сплотите команду, будете хорошо работать, и результаты будут ого-го. По таблице они и правда ого-го.

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

А вот если стандарты низкие и сплоченность высокая, то все вместе придумывают, как бы им хорошенько продолбаться. Вспоминается фраза из сплоченного коллектива на срочной службе: «Кто не шарит, тот х*ярит».😁️️️

Интересное открытие №2
Становится чуть более понятно, почему в некоторых компаниях заботятся о высоких стандартах качества (читай «больше спроса с людей»).
Ведь установить критерии как по строгости спрашивать с людей сильно легче, чем заниматься сплочением коллектива из десятков, сотен и тысяч очень разных людей. Да и компетенции руководителей на местах могут быть ниже. А результат-то всё равно «хороший». Да, он не максимально возможный, но хороший при этом за небольшое количество управленческих усилий.

Экономически как будто бы выгодно для компании даже в среднем. Ну а в мире победившего капитализма что выгодно (а в нынешние времена что сиюминутно выгодно), то и применяют.

Хочу, чтобы душевно!
Возможно, скажете вы. И я хочу. Но надо учесть, что вот это душевное сплочение и высокое качество — оно не делается быстро и очень сложно масштабируется. Поэтому надо иметь в виду, за то, чтобы ваша команда или набор из нескольких команд становились такими, и вам всем работалось любо-дорого, вы должны будете заплатить временем и карьерным ростом.

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

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

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

Я принес. Однозначно финансово неэффективная ситуация. Или не однозначно?

Наткнулся на пост про то, как человеку не подняли зарплату и он ушел, а взамен нового наняли с повышением х2 от того, что хотел ушедший, + потратили денег на рекрутерские услуги https://t.me/ctorecords/4510.

Дурость несусветная
С одной моей знакомой еще давно произошла подобная ситуация. Она работала в небольшой компании на простой, но нетиповой должности в компании. Работала за 15к, но покрывала 2 типа работ. Попросила прибавку до 20к, но ей сказали, что не дадут. Она уволилась сразу на 25-30к, а на её старой работе наняли двоих сотрудников по 15к плюс потом относительно быстро апнули до 20к. Экономически неэффективное решение х2.

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

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

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

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

Автор еще задается вопросом «Кто именно в итоге несёт ответственность? Из кого вычитают эти дополнительные косты?». Честно признаться, ни разу не видел, чтобы на уровне тимлидов, мидл-менеджеров, эйчаров кого-то за такое действие наказывали и хвалили. Просто все вспоминали дежурную то ли шутку, то ли правду «бюджета на удержание нет, а бюджет на наём есть».

Ролевая неопределенность, SMART и базовый минимум

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

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

Но что же с этим делать?

Поможет SMART! (нет)
Сказал бы вам какой-нибудь коуч и бизнес-тренер. Казалось бы, ставите конкретные, измеримые, достижимые, релевантные цели с четкими дедлайнами, и спина болеть не будет. Но в реальности вы столкнетесь с чертовой горой препятствий.
Где-то не сильно очевидна измеримость и конкретные значения метрик на этапе постановки, где-то конкретика не такая уж и конкретная (привет RnD задачам), где-то дедлайны не получается на старте оценить идеально, и требуется итеративный метод набегающей волны.

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

Так а с этим что же делать?

Базовый минимум

Хочется дать вам свою версию базового минимума по целеполаганию, с которой справится споткнувшийся об эти ваши смарты среднестатистический руководитель.
– Зачем мы это делаем? Какую проблему решаем и почему это важно сейчас?

– Что должно измениться в результате? Не обязательно знать точную метрику. Можно описать ожидаемый эффект или признаки того, что мы движемся в правильную сторону.

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

– Как поймём, что пора пересмотреть план? Это вообще шок-контент! Надо периодически смотреть на текущие реалии, результаты и тюнить дальнейшие планы (по заранее оговоренным критериям), а не просто фигачить полгода-год со словами «задача изначально была, на ревью надо отчитаться».

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

А если и это сложно, то…

Совсем маленький минимум, жесть
– Что делаем? С хоть каким-то контекстом, или мыслями, или артефактами, лишь бы больше чем одна стока названия задачи в таск-трекере.

– Зачем делаем? Это ОЧЕНЬ важно.

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

Финальный штрих
Для руководителей и прочих менеджеров еще добавляем пункт

– Ответственность и влияние. За что конкретно он несет ответственность. Кем он напрямую управляет, а кем нет. Если в его зоне ответственности те, кем он не управляет (привет проджектам!), то кому и как нужно эскалировать. Какие решения он может принимать самостоятельно, а какие нужно согласовать со своим руководством.

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

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

И уж тем более это в сто раз лучше, чем (это реальная цитата) «я не умею / тут не подходит цель по смарту, поэтому я ставлю задачу РАЗОБРАТЬСЯ С ПРОЕКТОМ».

Я принес. Почему начальство отказывает разработчикам: экономика, риски и ответственность.

https://www.youtube.com/watch?v=-XAWWoxHfpo

Недавно сходил в гости к Кириллу Мокевнину. Лет 10-12 назад смотрел на него только «в телевизоре», тут вот сразу как-то поперло. И в Коду к нам удалось заманить, и на летнем тимлид-конфе лично познакомиться, и теперь еще пообщатся у него в подкасте
Очень рад и горд тем, что удалось развиртуализироваться и лично пообщаться!

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

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

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

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

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

Ведь куча статей «как построить ИПР для линейного сотрудника», «как развивать и мотивировать разработчиков», «как построить матрицу компетенций для разработчиков». А что касаемо руководителей? Кто и как их развивает? Какие ИПРы строит? Да хотя бы как онбодит в должность? Ответ вы, скорее всего, представляете сами.

Ну и не забывайте ВНЕДРЯТЬ ИИ, тогда-то уж всё точно станет хорошо! (сарказм о том, что ИИ — это мультипликатор, и не обладая глубинными знаниями, компетентным менеджментом, понятно, что вы будете мультиплицировать).

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

В очередном голосовании нашего книжного клуба победила книга Уильяма Эдвардса Деминга «Менеджмент нового времени», и это очень вдохновляющее меня чтиво. Хочу с вами поделиться некоторыми идеями от прочтения.

Что за Деминг такой?
Это американский статистик и апологет качества. Он внедрял статистический контроль и непрерывные улучшения (PDCA / PDSA), помог послевоенной Японии повысить качество и конкурентоспособность её продукции, а через некоторое время после большого успеха в Японии его признали и в Америке.
Его подходы применяли Toyota, Sony, Ford, Xerox, General Motors и другие.

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

Продвинутое (или не очень?) ИТ
В ИТ принято думать, что мы тут с вами такие продвинутые и современные, у нас тут всякие аджайлы, пипл-менеджмент прокачан, процессы, знаете ли. А вот господин Деминг уже лет 70-80 назад всё это формулировал и внедрял. А строил он свои идеи на базе контрольных карт и цикла Уолтера Шухарта, которому 90 лет стукнуло.

Аджайл
Аджайл манифест был сформулирован в 2001-м году, и пошел аджайл по кочкам ИТ-мира. В это время в 1939-1950 годах Шухарт и Деминг сформулировали и применяли PDCA (Plan-Do-Check-Act) или PDSA (Plan-Do-Study-Act) цикл, который брал атомарные изменения, потом анализировал их и тюнил дальнейшую работу исходя из результатов этих коротких итераций. Такой вот «аджайл».

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

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

Передаю привет подразделениям Quality Assurance и компаниям, в которых таковых нет и для которых QA — это значит «просто тестов надо написать? Каких тестов? Давайте созвончик сделаем и решим, юниты или e2e».

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

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

Итог
Всё это я вел к трем мыслям.
1. Важность регулярного обучения руководителей. Начиная с онбординга в должность и заканчивая… да не заканчивая, а просто регулярно учить руководителей, чтобы они регулярно улучшали систему.
2. В построенной по подобным идеям команде очень комфортно, радостно работать, и при этом продуктивнее, чем там, где тебя регулярно погоняют и наказывают, а ты регулярно ставишь формальные галочки, чтобы от тебя отстали.
3. ИТ-отрасль не такая уж и продвинутая, как многим хочется о нас думать. Огромное количество светлых и доказано полезных идей придуманы чуть ли не век назад, а мы какие-то кусочки перепридумываем или откапываем и дуем щеки от гордости.