Сколько менеджеров нужно на встрече?

В книге Джеффа Паттона есть короткий абзац-история про компанию ThoughWorks (в печатной книге страница 138). Суть такая, что команде нужно было обсудить бэклог, но при этом в продукте было 25 людей, принимающих решение и попытка собрать их в одной комнате обернулась сущим кошмаром для команды и она не смогла нормально запланироваться. Решение, которое предлагает Джефф очевидное и на поверхности — дробиться на небольшие группы и прорабатывать частички бэклога уже в них. Не так эффективно по времени, но эффективно по результату.

Казалось бы это элементарно, Ватсон. В доковидную эпоху это работало само собой, благодаря ограничениям размера переговорок, когда в маленькую переговорку не позовёшь 20 человек. Но в эпоху Zoom’митингов мы вернулись к формату похожих монстровстреч и соответствующих проблем. Сравните картинку из шедеврума и скриншот из зума (взято отсюда). Лично у меня нет ощущения во втором случае что когда я начну говорить то меня будут слушать 50 человек.

Итак, о чём я?
Вводная 1: надо собрать встречу, чтобы что-то обсудить
Вводная 2: все начинают звать всех кто мало-мальски заинтересован в любой теме, которая может быть поднята на встрече
Итог: на встречу приходит 30 человек и вместо обсуждения, автор встречи ведет плохой монолог-доклад-презентацию, все не довольны, потому что обсуждения не получается, а на выходе ощущение что всех поставили перед фактом.

Знакомо?

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

Остальные встречи на 10+ человек — это всегда презентации и монологи, к которым нужно готовиться заранее. Не стройте ложных иллюзий, что получится что-то типа беседы или что-то иное. В лучшем случае пара человек выскажется, и чаще всего это будет или рядовая похвала, или неприятная критика (публичная, к слову). Зачем вам оно?

Хочется обсудить — собираете до 10 человек и обсуждаете. Затесался 11? Увы, это уже презентация 😉 (табличка «sarcasm»)

Как всегда комментарии можно писать под этим сообщением. Поддержка не отвечает что происходит и почему в длинных постах нет ссылок на комменты.

О, чёрт, я кажется догадался в чём дело и почему под постами нет ссылок на обсуждение.

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

За сим вопрос к сообществу: подскажите хороших спам-ботов?

Сколько менеджеров нужно на встрече? Часть 2.

Друзья, ну я прямо удивлён. Ни один человек не написал мне, что я намеренно вас всех обманул, несмотря на то что у Паттона про дискуссии на встречах всё написано. Итак, процитирую Джеффа:

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

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

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

Let small groups work together to make decisions, and then use continued conversations to share the results with everyone else.

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

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

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

Но допустим у вас не так, есть дискуссии, тимлид постоянно что-то спрашивает и уточняет у ребят. Я вас расстрою, это всё ещё плохой открытый микрофон. В хороший качественный процесс обсуждения должны быть вовлечены все члены команды, потому что в хорошей команде все должны быть заинтересованы в том, чтобы спринт сошелся, релиз состоялся, GMV росло и т.д. А если это волнует только тимлида, который бегает между разработчиками и пытается их расшевелить, то это всё ещё нифига не командная работа. «Я свои компоненты сделал, это тестирование не протестировало и поэтому релиза не будет» ничем не отличается от «Защитник отдал пас вперёд, но там никого не было». И это уже было обшучено 20 лет назад в КВНе моими любимыми Уральскими Пельменями.

Cколько менеджеров нужно на встрече? Часть 3

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

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

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

Как действовать если календарь кишит регулярными встречами? map-reduce! Проходимся по списку встреч и задаём три вопроса про каждую из них:
1. Участвовал ли я активно в последних 3-х регулярках?
2. Что произойдет если я не приду на эту встречу?
3. Нужно ли мне знать что было на той встрече, и если да то каким образом мне комфортнее всего получать информацию о происходившем на ней?

Третье — это самое интересное. Менеджеры на столько обленились, что, вместо того чтобы писать follow up’ы, зовут на встречи всех подряд, чтобы «просто послушать». Ну уж нет уж господа менеджеры. Встреча — это тикет, а follow up — это пулл реквест с последующим мерджем в транк, поэтому давайте не будем игнорировать важность фиксации договорённостей после встречи. Собственно вы, как участник этой встречи, можете подсказать организатору как именно хотели бы получать follow up.

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

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

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

В конце хочу ответить на ещё один не заданный вопрос, почему мои посты называются «сколько менеджеров нужно на встрече?» Менеджер — это управленец, руководитель, а не только люди с M в названии должности (TPM, PM, Продакты). Руководителем можно быть не только группы, службы, отдела, но и функциональности, проекта, и даже эпика. И когда вы вступаете на эту дорогу руководства (если вы мидл, то уже наверняка бывали feature lead), то сразу же получаете кучу встреч впридачу, что сильно размывает ваш фокус, несмотря на то что подавляющее количество встреч вам посещать не обязательно.

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

Ходите только на полезные для вас встречи.

Право на работу

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

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

Я, особенно в преддверии выходных, хочу сегодня написать на другую тему — право на работу.

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

Недавно я прочитал книгу Nordic dads. Книга эта скорее вдохновляющая и развлекающая, но автор делает явный акцент на том что в северных странах есть право на отцовский декрет. Это право даёт отцам при рождении ребёнка уйти в декрет, который они не могут* пошарить с мамой ребёнка. Это не то же самое, что просто уйти в декрет — такое есть и в России. А это именно оплачиваемый государством декретный отпуск отца.

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

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

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

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

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

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

Ну что ж, а мой рабочий день закончился, всем отличных выходных! :)

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

** Выходной день оплачивается либо х2, либо х1 и дополнительный отгул. Даже если ваш самолёт приземляется в субботу в 00:05 — это уже считается полностью оплачиваемым выходным. Именно это я подразумеваю под «захватывать выходные»

p2p feedback
и как его улучшить в рамках ревью?

Ревью, как процесс, есть во многих IT-компаниях. Обычно ревью проходит так: отзывы -> оценки -> калибровки -> изменения (пересмотр зарплат, премии и другие плюшки). Я в системе ревью уже 10 лет и за это время появились разные мысли, которыми хочется поделиться. Начнём с отзывов.

Отзывы — это старт, а для многих уже и финиш, ревью. Нужно запросить отзывы на себя у коллег, написать отзывы самому и сделать самоотзыв. У кого запросить? Где-то пользуются 360 degree feedback, где-то в полуавтоматическом режиме, где-то сам человек решает. Различается так же и то как фидбек даётся: в свободном стиле, или подробные опросники, или даже шкалы оценки. Все полученные фидбеки руководитель аггрегирует и ставит оценку перфоманса.

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

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

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

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

Складывается ощущение что отзывы от смежников не нужны совсем (ну, кроме негативных). Это не совсем так. Первый инсайд, который меня осенил совсем недавно, это то что при прочих равных даже отзыв вида «Вася мне очень помог» от автора, который обычно пишет «С Петей/Машей/Витей норм работается» — это вполне сильный сигнал о Васе.

Т.е важно не то какой отзыв написан на Васю. А какой это отзыв среди других отзывов того же автора. Иными словами из 30 отзывов, где 29 являются простынями про то что «всё норм» и один сухой отзыв «Вася крутой» от определённого автора — именно этот один отзыв должен сильнее всего влиять на оценку человека.

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

А пока давайте пообщаемся про то как у вас устроено ревью?

p2p feedback. Часть 2
и как его улучшить в рамках ревью?

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

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

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

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

Топ-рейтинга не может быть бесконечным, допустим у каждого будет по три голоса, которые он может распределить в рамках одного ревью. Голосовать за себя, или за руководителя нельзя, в остальном распределять можно как угодно, хоть все голоса одному, хоть всё оставить при себе. Важно что голосов всего три. Каждый голос за тебя даёт тебе какую-то плюшку (например, прибавку к премии). Больше голосов — больше плюшка.

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

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

p2p feedback. Часть 3

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

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

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

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

Как калибровать людей?

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

С удовольствием подискутирую в комментариях о других подходах.

Дальше начинаются калибровки. За почти 10 лет ревью в Яндексе я видел разное. От супержестких калибровок имени Миши Парахина (самая длинная наша калибровка длилась 16 часов, причем последние 6 мы решали задачу «понизить 4 оценки»), до формальных «поставь че-нибудь, лишь бы не всем максимальные оценки».

У любой калибровки должна быть цель. Не важно калибруются 5 человек, или 500. Целью не может быть «просто посмотреть». Глупо для того чтобы «просто посмотреть» собираться в одной комнате, закрывать шторы и тратить 8 часов на то чтобы пробежаться по списку ни на что не ориентируясь.

Вспоминается цитата из фильма ДМБ:
«Жизнь без армии — все равно что любовь в резинке: движение есть, прогресса нет».
Так и тут, если у вас на калибровку нет цели, то это бессмысленная трата времени.

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

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

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

А зачем вообще калибровать людей? Часть 1

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

Когда в организации работает 50 человек, то ответ на вопрос: кому премию выплатить, а с кем стоит попрощаться? — почти всегда очевиден, все люди на виду, все всех могут увидеть и ± понимают кто чего стоит. Забавно, но мой опыт при этом показывает, что системности там чаще всего всё равно нет. Повышают зарплату или самым требующим (можно сказать наглым, можно сказать знающим себе цену), или тем кто ходит в кальянные с директором, а премии платят всем вне зависимости от качества работы раз в год, если компания в целом хорошо себя чувствует.

Чем больше организация, тем сложнее ответить на вопрос выше системно. Нужен какой-то понятный механизм. В Советском Союзе для многих профессий были введены разряды и единый тарифно-квалификационный справочник (ЕТКС). Чтобы повысить разряд нужно было ему соответствовать и сдать аттестацию. Похожий механизм до сих пор успешно существует, например, на многих заводах. Почему же в IT такого до сих пор нет?

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

Проводя аналогии с разработкой, представим что разработчики бэкенда будут иметь подвиды: разработчик-багофиксер, разработчик-нагрузочник, разработчик-CI/CD'шник или разработчик-скрам мастер. Фигня же?

Во-вторых, если копнуть в разряды и должностные обязанности, то, например, электромонтер 5-го разраяда должен знать:

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

Попробуете примерить такой способ описания должностных инструкций к разработчикам?

Хочется немного даже поиронизировать на этот счёт, так как если всё же формализовывать профессию разработчика, то первым же пунктом там должно встать знание алгоритмов. Смех в том, что Яндекс очень часто упрекают именно за алгоритмическую секцию собеседований, как за якобы бессмысленную. Что уж говорить про другие пункты?

Самое интересное что попытки формализовать были и есть. У всех этих попыток сильно бросается в глаза то что список должностных инструкций для лаконичности восприятия сжимается для 3-4 однословных пунктов и многие, примеряя их к себе, видят себя чуть ли не CTO. Картинка к этому посту — это пример подобной разметки от Андрея Смирнова, руководителя в X5, про который он рассказывал в докладе «Карьерная лестница как дорога в ад».

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

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

А зачем вообще калибровать людей? Часть 2

Итак, практически не возможно описать должностную инструкцию разработчика, но я был уверен что кто-то это сделал и в комментариях мне привели пример SWEBOK. Это прекрасный и исчерпывающий пример того, куда может улучшаться разработчик, но это всё ещё не аналог ЕТКС, то есть того что хотят получить разработчики. А именно ответа на вопрос: что мне сделать чтобы получить больше зарплату следующий грейд?

И все-таки в каком-то виде сопоставление скиллов грейдам существует. Тут важно понимать, что любая конкретика неизбежно приводит к формализму, поэтому тут действуют общие принципы: чем выше грейд — тем больше скиллов и самостоятельности. Как именно далее формализовать эти два параметра уже решает каждый руководитель сам. Сениоры бывают как уже готовые тимлиды-переговорщики, но средние по навыкам программирования, так и интроверты-хардкорщики, которые за пять минут найдут баг, не найденный до этого месяцами. Ещё раз повторюсь, что мне не известно, чтобы кто-то в Big Tech ориентировался на строгий чеклист навыков. Тут мы подходим к главному. Зачем калибровать людей? Если в целом Perfomance Review — это подведение итогов полугодия (или года), то калибровки это уравновешивание чаш весов результатов каждого из сотрудников и, соответственно, бенефитов. Потому что строгой функции «f(результат) = оценка» — не существует.

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

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

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

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

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

Так вот, удачи! :)

Изображение к посту защищено © Warner Bros., фильм «Космический джем».

Всегда действуй в интересах команды

В книге «Никаких правил. Уникальная культура Netflix» рассказывается история о политике расходов в Netflix. Один из сотрудников поехал в командировку и, чтобы сэкономить деньги компании, использовал каршеринг вместо такси. После делового ужина с парой бокалов вина он вызвал такси до отеля, но потом ему пришлось компенсировать расходы, так как это не вписывалось в политику компании. Чем был очень возмущён, он же ездил для решение задач компании.

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

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

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

Когда я организовывал конференцию FrontTalks, политика Яндекса запрещала оплачивать афтепати. В 2018 году я очень хотел, чтобы там выступала кавер-группа и, не имея достаточных обоснований кроме «хочу», оплатил ее самостоятельно. Получилось классно. На фото, кстати, мы с ребятами из группы Everybody Dance.

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

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

Когда-то Лёша Башкеев (CEO Яндекс Клауда) говорил, что для привлечения первоклассного кандидата нужно водить его в лучшие рестораны за свой счёт. У меня есть похожая история как-то нам нужно было за 2 месяца нанять почти 10 человек. И я сказал рекрутерам: если получится, всех свожу в ресторан. Влетело мне это тогда в копеечку, но я не жалею, ведь мы достигли результата.

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

А еще говорят что айтишники не танцуют :)

Blind-калибровки

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

Суть метода очень простая и похожа на Planning Poker. Калибровка проводится в формате: сначала читаются только отзывы без оценок и каждый участник ставит оценки. Затем все оценки раскрываются, и, если обнаруживается значительное расхождение между оценкой руководителя и оценками остальных, обсуждается, почему так произошло.

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

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

Картинка взяла из статьи. ©

Я забыл еще одно супер важное, а ведь это почти самое главное.

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

Про то как помочь себе ответить на вопрос «Чего я хочу?» я писал в посте про Икигай

Книга «Никаких правил. Уникальная культура Netflix». Главы 1 и 2.

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

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

В первой главе рассказывается про концентрацию талантов в Netflix. Netflix нанимает лучших из лучших, платит им зарплату выше рыночной и тем самым в команде Netflix работают только звёзды. Одним из этапов, как Netflix пришел к этому, стал кризис, когда пришлось уволить треть сотрудников. Читая всё это невольно вспоминаешь Винни Пуха: «Делай так как нужно, а как не нужно делать не нужно». Т.е эта часть книги веет лукавством за три версты. Моё имхо, Netflix когда-то совершил ошибку выжившего, и, говоря по-простому, им повезло, что уволив треть, оставшиеся две трети не свалили и при этом смогли выстоять.

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

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

Во второй главе рассказывается про культуру откровенности. На мой взгляд это одна из интереснейших частей первого раздела, правда ещё один ключ к тому как это должно работать будет дан аж в 8-й главе. В этой главе декларируется, что надо культивировать культуру открытости. Имхо это звучит с нотками фальши как будто бы надо просто начать всем говорить всё в лицо. Так точно не сработает, нужно готовить команду к этому. Как? Для этого публикуются 4 правила откровенности в Netflix:

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

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

2. Предлагай конкретные меры. Дополнение пункта 1.

3. Будь благодарен услышав критику. Не важно нравится она вам или нет, но то что человек в целом решил вам что-то сказать заслуживает благодарности.

4. Прими или отклони. Не всякую критику нужно воспринимать как план к действию. Только вы решаете как именно ей распорядиться.

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

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

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

Все обзоры по тегу #книгобзор@teamleading

Книга «Никаких правил. Уникальная культура Netflix». Глава 3

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


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

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

Мне кажется что за этими словами скрывается лукавство, ведь компания — это не только C-level и высокогрейдовые личности, даже несмотря на то что в книге постоянно делается акцент, что в Netflix нанимают только таких. Охранник, таксист, уборщица — все они тоже работают в компании, и ассоциируют себя с ней. Вряд они могут свободно распоряжаться финансами, точно так же как СЕО или мидлы. Даже в интересах компании.

Теперь к первому пункту. В Netflix отказались от графика отпусков. Берите отпуск когда надо и на сколько надо. Главное чтобы задачи делались. Иными словами не зависеть от рабочего расписания, работать на 200%, но мочь делать передышки тогда, когда тебе это нужно — работа мечты.

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

Книга призывает руководителей показывать своим примером как надо ходить в отпуск и почаще обсуждать отпуска за обедами, чтобы у сотрудников устойчиво складывалась картинка о том, что и руководители позволяют себе не только работать днями и ночами. И снова, прекрасные мысли, но с оговорками. Если в беседе C-level и мидла один будет рассказывать о шикарных отдыхах в 5-ти звездочных отелях на Бали, а второй об (не менее шикарных) отдыхах на 0 звездочной даче родителей, то такой разговор быстро заглохнет, так как между ними пропасть. Лучше опускать финансовые подробности (даже косвенные, все понимают что отпуск на Бали в 5* — это не дешево) и сосредотачиваться на эмоциях и предметах — вкусная еда, красиво, восторг.

Чтобы ввести свободный график отпусков не обязательно зарабатывать как Netflix. Я давно заметил, что не всем достаточно положенных по ТК 28-ми дней отпуска в год, чтобы работать оставшееся время с высокой самоотдачей. Можно правильно настроить отпускную бюрократию. Вполне допустимо сделать так: устный ОК от руководителя и несколько дней можно не приходить на работу, а затем левым числом написать заявление на отпуск, если нужно сжечь какое-то количество дней.

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

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

Все обзоры по тегу #книгобзор@teamleading

Soft Weekend — самая мягкая конференция этого года

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

Итак, 23 ноября в Москве состоится конференция Soft Weekend — первая конференция про софт-скиллс. Андрей почти всё организует сам, поэтому цена билета на конференцию может удивить — всего 7000₽. Надо ли вообще говорить что Андрей — это человек который умеет, любит, может и рассказывает про софты регулярно на разных площадках и конференциях. То есть он точно знает кого звать выступать. Поэтому докладчики все топовые.

До конференции ровно 20 дней, сама конференция будет идти всего один день. Этот пост не реклама, я искренне желаю Андрею удачи. Если тема софт-скиллс вам интересна, то регистрируйтесь на конференцию Soft Weekend.

upd. Этот пост был написан до появления в программе Антона Назарова. К его «творчеству» я отношусь резко негативно и осуждаю.

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

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