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

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

Чем больше управляю проектами/портфелями на уровне нескольких команд, бизнес-юнитов, силевел или околосилевел стейкхолдеров, руководителей разного уровня со своими разными интересами, желаниями, целями личными и корпоративными, тем больше убеждаюсь в двух вещах:
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. ИТ-отрасль не такая уж и продвинутая, как многим хочется о нас думать. Огромное количество светлых и доказано полезных идей придуманы чуть ли не век назад, а мы какие-то кусочки перепридумываем или откапываем и дуем щеки от гордости.

Я принес. Стресс на работе не всегда связан с перегрузом

Вот вроде бы интуитивно понятно, но не всегда очевидно. Тут https://t.me/bvevvs/1570 Сережа Щербинин дает и выжимку из статьи, и ссылку на саму статью, а я, как это у меня бывает, поделюсь конкретными примерами.

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

Про перегрузку всё понятно, не мне вам рассказывать :)

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

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

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

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

Ритм и согласованность

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

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

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

Как же это сложно!
Вообще наше творчество получилось сложнее и развесистее, чем, к примеру, майндмэп для тимлида. Да я и не раз говорил и продолжу говорить, что менеджмент мультикомандных проектов дается сложнее на позиции ПМ / РП, нежели из позиции тимлида и даже тимлида тимлидов. По сути ответственность за результат та же, но административных рычагов меньше, и влияния на распределение ресурсов меньше.

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

А может и просто
Сегодня я хочу показать, что есть небольшое количество оооочень базовых вещей, которые могут дать 80% результата за 20% усилий, и не придется бояться мильёна развесистых инструментов.

Я раньше думал, что это мне просто везет, что такая топорная капитанщина срабатывает, а потом на тимлидкофе увидел доклад, где девушка рассказывала, как большие проекты на 5-10+ команд ведет практически таким же образом.

Ритм
Одна из важных штук в проектах с кучей людей, команд, процессов, отпусков, сторонних заказов — это ритм.

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

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

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

Согласованность
Часто нам ПМы говорят: «Стройте критический путь/цепь проекта». Это нужно, чтобы где-то распараллелиться, а где-то необходимо выполнять работы в необходимой последовательности, чтобы на полпути не оказалось, что часть исполнителей заблокирована и ждет работу от других, а те даже и не начинали начинать.

Так вот в мультикомандных проектах работа по поддержанию такой синхронизации между командами: какой критический путь в общем проекте, а не в конкретной команде, кто чего ждет, кто кому что обещает, кто где соломку подстилает товарищам на будущее — это невероятно важно. И по сути кроме ПМ / РП это на всём проекте никто не сделает. Каждый тимлид у себя в команде сделает по красоте (надеюсь), а вот как это всё на общую картину влияет, разбираться очень мало кто захочет (0% осуждения, у всех своя работа и свои заботы).

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

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