Saturday Night Hack

2021-10-28 10:00:46 Эволюция мотивации менеджера

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

Когда я был разработчиком, меня всегда заряжали оживающие системы. Я мог уйти в состояние потока, нацепить наушники, включить звук на всю и за день или ночь закончить большой проект. В итоге я понимал – it's alive! Что-то можно увидеть, потрогать руками, оценить. Ложился спать с чувством выполненного долга, а утром уже искал новую задачу, чтобы снова это испытать. И так по кругу.

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

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

Как менять мышление?

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

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

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

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

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

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

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

---

Поразмышлять о том, как менеджерам мотивировать себя мы договорились с Александром Кузовлевым, автором канала На шаг впереди, у которого в этом большой опыт – он руководил в качестве PM и CTO в нескольких стартапах. Его пост на эту тему читайте тут:

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

2021-10-21 09:00:12 ​​28 октября, в следующий четверг, пройдет митап Team NSK Lead.

Ребята будут говорить про Discovery — «как понять, что нам нужно построить?» и Delivery — «как мы будем строить, чтобы оно не сломалось»?

В программе два доклада:

— «Инженеры требуют четких ТЗ, блеймят требования и придираются? Как подружить инженеров с ПМ-ми и вовлечь команду в решение задач пользователя», Алексей Филатьев, Unit manager, Plesk

— «TeamLead отвечает за time-to-market и качество. А делать-то что?» Олег Неумывакин, TeamLead, Plesk

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

Формат: онлайн + офлайн (в Новосибирске)
Когда: 28 октября, 15:00 МСК.

Страница митапа Открыть/Комментировать

2021-10-20 16:15:00 ​​Про неопределённость

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

Например, опытные product-менеджеры не просто приоритезируют новые фичи и гипотезы по их важности/деньгам/тону, с которым гипотеза была озвучена начальством. Они учитывают свою же уверенность в этих оценках (см. confidence в RICE).

Опытные разработчики чаще стараются удалять код, чем писать, чтобы уменьшать сложность систем и увеличивать их предсказуемость, а когда добавляют что-то новое – со всех сторон обкладываются мониторингами и алертами, ведь за свои 5/10/15 лет в разработке они поняли, что даже идеально написанный и протестированный код может сломаться у клиента и часто даже не по их вине.

Неопытный проджект-менеджер закидывает разработчикам новую фичу на оценку и ожидает точного срока, при несоблюдении которого будет приходить и спрашивать, а почему не уложились в свою же оценку? Опытный же понимает, что разработчики сами могут не знать, сколько может занять эта новая фича и узнает не срок, когда фича будет на продакшене, а срок, когда у разработчика будет достаточно данных, чтобы дать более-менее правильную оценку (а ещё лучше – работает без оценок). Кстати, некоторые системы ведения проектов построены вокруг идеи того, что на первой стадии работы над проектом мы не делаем ничего «осязаемого», мы просто уменьшаем количество unknowns о проекте, а во второй уже что-то делаем (см. hill charts в Basecamp).

В общем, не ожидайте, что всё, что вы делаете – правильно. Лучше заранее подумайте, как вы сможете как можно раньше понять, что сделали что-то неправильно? Открыть/Комментировать

2021-10-07 19:15:00 ​​22 октября Тинькофф приглашает на Tinkoff Agile Conference. Обсуждать будут лидерство, инженерные подходы и практики управления. Тема этого года — «Масштабирование изменений от команд до организации».

Эксперты отрасли и agile-тренеры расскажут о менеджменте инноваций, командообразовании, практическом опыте построения компаний. Всего — 16 докладов от спикеров из Авито, Альфа-Банка, Тинькофф, Циана, Scrumtrek и других компаний. Будут воркшопы и, разумеется, афтепати.

Онлайн-трансляция главного зала бесплатна для всех, нужна только регистрация. Участие в конференции офлайн в Москве — пожертвование 2000 ₽ в Фонд борьбы с лейкемией. Регистрируйтесь и переходите по ссылке для оплаты в ответном письме. Очное участие возможно только с QR-кодом.

Подробная программа и регистрация по ссылке: https://w.tinkoff.ru/tac-2021 Открыть/Комментировать

2021-10-05 09:00:02 Про башню из слоновой кости и окно в реальность

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

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

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

Для менеджеров даже существует специальный термин – ivory tower syndrome, синдром «башни из слоновой кости». Такие менеджеры отдаляются от команды/подчинённых, и принимают решения основываясь только на своей картине мира, но не понимают, как всё работает в реальности, почему и с какими трудностями сталкиваются люди. Таким менеджерам нужно чаще «выходить в поля», собирать фидбек и получать информацию о том, как же работает реальность.

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

2021-09-28 12:00:57 Про подмену понятий

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

– «Я не смогу этим заняться – у меня нет времени». Почти любая книжка по тайм-менеджменту начинается с того, что напоминает, что у всех в сутках 24 часа. Так вот часто, когда мы говорим, что у нас нет времени, то на самом деле у нас нет желания/мотивации/энергии («мыслетоплива», в терминах «Джедайских техник» Дорофеева)
– «Давайте не будем это пробовать – это не удобно». Моё любимое – всем лень разбираться в чём-то новом. Конечно, чтобы новый инструмент начал приносить пользу – в нём нужно разобраться и потратить на это время, а пока этого не сделаешь – этот инструмент будет непривычным. Но главное помнить: непривычно – не значит неудобно.
– «Давайте не будем это делать – это слишком сложно!». Конечно, намного проще найти самое сложное решение задачи и оправдаться этой самой сложностью, чем потратить время, найти баланс между ленью и сложностью решения и что-то сделать (а искать простые решения – сложно).

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

2021-09-21 16:15:00 Найм 2.0

Пару недель назад вышла очередная HR-аналитика от NewHR. Как мне кажется, там много чего драматизировано и преувеличено (если рассматривать это как исследование рынка РФ в целом), но там есть фраза, точно описывающая текущую ситуацию: «рынок найма превратился в рынок кандидата».

И это, конечно, нужно учитывать и адаптировать процесс найма под кандидатов. Вот что, например, можно попробовать:

– Подчеркивать свои отличия от остальных. Уже у всех есть удалёнка, свободный график и «дружный коллектив». А что отличает именно вашу компанию? Четкие регламенты и систематизация всего или наоборот, высокая гибкость и уровень свободы? Наличие харизматичных лидеров или возможность им стать?
– Адаптироваться под кандидата. Если ему удобнее созваниваться после рабочего дня – придётся найти время. Если не удобно с камерой – можно и без неё (вы же человека на удалёнку собеседуете?). Если человек заикается – можно перевести собеседование в текстовый, более удобный для него формат (заодно и сами такой формат потестируете).
– Не пытаться нанять любого, только ради закрытия вакансии. Вообще на рынке действует правило «любой сотрудник может получить оффер лучше текущего, а любой работодатель может найти сотрудника, который тот же объем работы будет делать за меньшие деньги. Вопрос только в методах поиска и времени». Так что рано или поздно вы найдете своего кандидата (ну только если ваша компания доживет до этого момента).
– Сделать собеседования полезными для кандидата, а не только для вас. Помните, что собеседование – двусторонний процесс. Давайте подробный фидбек, делитесь своим опытом, рекомендуйте книги/курсы/лекции – пусть кандидат уйдет от вас лучше, чем пришел, даже если уйдет без оффера.

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

2021-09-21 10:00:23 ​​“Путь генерального директора”
Когда еще тебе представится возможность лично задать вопрос генеральному директору самой крупной EdTech компании в России?
Узнать, какая IT профессия будет приносить реальный доход в 2к22, сколько ты будешь зарабатывать в первый, второй, третий год - если начнешь кодить прямо сейчас, и правда ли, что 60% разработчиков гуманитарии?

Спроси всё что хочешь, и даже больше 22 сентября!

Александр Волчек, гендир GeekBrains расскажет о том, какой путь он прошел, от простого программиста - до первого лица GeekBrains, поделится секретами индустрии. Будет много инсайтов о профессиях в IT, - и никакой воды.

Выступление начнется в 19:00 не пропусти, остался 1 день до окончания регистрации!
Вход бесплатный --> https://gb.ru/link/VMKOA8 Открыть/Комментировать

2021-09-17 13:42:17 Time-to метрики

Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product-market fit. Но почему-то редко анализируются другие time-to метрики, а чем меньше нужно времени (и мозговых ресурсов) на какое-то действие, тем больше времени остаётся для других дел.

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

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

На какое ещё время можно обращать внимание?

– Time-to-data – время на доступ к информации. Как сложно найти нужную информацию? Например, почему сделали изменение в коде? Где взять логин и пароль в админку аналитического сервиса? Какие были договорённости на прошлом планировании? Где и как мы можем хранить эту информацию? Как сделать так, чтобы её можно было легко и быстро найти?
– Time-to-action – время для действия. Сколько времени нужно, чтобы начать что-то делать? Например, к вам на проект пришел новый разработчик – сколько проходит времени до его первого коммита? Как можно это ускорить? Завернуть всё в докер? Предоставить компьютер с предустановленным и настроенным проектом? Потратить час на поверхностное объяснение проекта или скинуть ссылку на подробнейшую документацию на 500 страниц?
– Time-to-decision – время для принятия решения. Сколько времени уходит на принятие решения в команде? Если вы каждый свой шаг согласовываете, то дела у вас наверняка идут очень медленно, а большой процент начатых активностей просто глохнет. Может можно что-то просто взять и сделать без апрува сверху или от всей команды? Или заранее всем вместе решить, кто какие решения принимает и в каких вопросах хочет принимать участие, например с помощью delegation poker?
– Time-to-interaction – время на взаимодействие с другими людьми. Сколько времени ждать code-review? А сколько времени уйдёт у другого разработчика на этот code-review? На что из этого вы можете повлиять? Как это время уменьшить?
– Time-to-small-things - время на разные мелочи. Наверняка, в день вы делаете сотни и тысячи мелких действий и небольшое ускорение в них может освободить вам голову и время. Как быстро вы печатаете? Как быстро навигируетесь в проекте/коде? Используете шорткаты? А time-to-coffee у вас какой?

В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта? Открыть/Комментировать

2021-09-07 18:00:12 Про муравьёв и шаринг знаний

Задача коммивояжера – классическая математическая задача. Как оптимальным способом обойти несколько городов и вернуться обратно? Один из популярных алгоритмов решения – так называемый муравьиный алгоритм. Это отсылка к реальному поведению муравьев при поиске еды: они идут от гнезда в поисках еды в случайном направлении и если находят – то возвращаются назад, выделяя феромоны. Следующие муравьи уже с бóльшей вероятностью (но не в 100% случаев) выбирают путь с феромонами зная, что кто-то вернулся по этому пути с едой. Причем феромоны постепенно испаряются, из-за чего длинные пути «остывают» (ведь на поход от гнезда до еды и обратно уходит много времени), а короткие становятся всё более привлекательными.

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

– Лучше рассказывать даже про неоптимальные решения, чем не рассказывать совсем. Кому-то рано или поздно это облегчит жизнь и ему не придётся начинать поиски с нуля.
– Чем больше участников будут вкладываться в общее дело, тем оптимальнее будут решения. Привлекайте людей создавать общие системы, а не плодить свои.
– Если «ходить по тропе в одну сторону» и только использовать чужие знания, но не делиться своими, то тропа будет выветриваться (а документация будет становиться неактуальной). Поддерживайте актуальность знаний, которые вы используете.
- Самые «натоптанные» тропы, о которых говорят больше всего будут чаще всего использоваться.

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