Про найм
Совет для лидов, нанимающих в бигтех.
Или в другие компании, у которых есть стабильный процесс собеседований:
Классическая цепочка собеседований в бигтех проверяет отсутствие минусов, а не наличие плюсов.
К примеру, кандидат:
– Адекватен, умеет говорить (hr-скрин)
– Умеет писать код (секция с кодом)
– Не думает три дня над простой задачей (все секции)
– Не предлагает трешовых архитектурных решений (архитектурная секция)
Они придуманы не для того, чтобы найти подходящего кандидата, а для того, чтобы снизить количество неподходящих (с пачкой ошибок в обе стороны).
Всё, что ты знаешь после проведения стандартных секций: «передо мной – человек +- уровня X».
––
Если хочешь найти не просто «сотрудника +- уровня X», а человека, который:
– Супер-ориентирован на бизнес-результат ИЛИ
– Очень крут в выстраивании процессов ИЛИ
– Умеет быстро разбираться в сложных плоходокументированных технологиях ИЛИ
– Может за ночь из говна и палок построить космолёт,
Стандартные секции тебе не помогут.
Твоя команда, контекст и набор проблем – частично-уникальны, и таких команд – много. Стандартными интервью не проверить уникальные пожелания нанимающих. Значит, тебе нужно самостоятельно разглядеть специфическую компетенцию или её отсутствие.
––
Как это сделать?
1. Выписать для себя набор желаемых качеств
2. Попытаться за время беседы проверить их наличие
Иногда, спросив про космолёты из говна и палок, ты услышишь, что кандидат такие уже строил или что он их ненавидит.
Если человек с таким не сталкивался – проведи мысленный эксперимент. Спроси, как он подошёл бы к такой задаче, свались она на него завтра.
Да, за мэтч по уникальным компетенциям можно простить промах на стандартной секции!
Совет для лидов, нанимающих в бигтех.
Или в другие компании, у которых есть стабильный процесс собеседований:
Нанимай за уникальные плюсы, а не за отсутствие стандартных минусов.
Классическая цепочка собеседований в бигтех проверяет отсутствие минусов, а не наличие плюсов.
К примеру, кандидат:
– Адекватен, умеет говорить (hr-скрин)
– Умеет писать код (секция с кодом)
– Не думает три дня над простой задачей (все секции)
– Не предлагает трешовых архитектурных решений (архитектурная секция)
Они придуманы не для того, чтобы найти подходящего кандидата, а для того, чтобы снизить количество неподходящих (с пачкой ошибок в обе стороны).
Всё, что ты знаешь после проведения стандартных секций: «передо мной – человек +- уровня X».
––
Если хочешь найти не просто «сотрудника +- уровня X», а человека, который:
– Супер-ориентирован на бизнес-результат ИЛИ
– Очень крут в выстраивании процессов ИЛИ
– Умеет быстро разбираться в сложных плоходокументированных технологиях ИЛИ
– Может за ночь из говна и палок построить космолёт,
Стандартные секции тебе не помогут.
Твоя команда, контекст и набор проблем – частично-уникальны, и таких команд – много. Стандартными интервью не проверить уникальные пожелания нанимающих. Значит, тебе нужно самостоятельно разглядеть специфическую компетенцию или её отсутствие.
––
Как это сделать?
1. Выписать для себя набор желаемых качеств
2. Попытаться за время беседы проверить их наличие
Иногда, спросив про космолёты из говна и палок, ты услышишь, что кандидат такие уже строил или что он их ненавидит.
Если человек с таким не сталкивался – проведи мысленный эксперимент. Спроси, как он подошёл бы к такой задаче, свались она на него завтра.
Да, за мэтч по уникальным компетенциям можно простить промах на стандартной секции!
👍15❤7🔥5🎉1
Getting Shit Done
Есть выражение (и даже методология) «getting things done» – про доведение дел до конца, управление задачами, проектами, и тд.
Сегодня мы про него говорить не будем.
Сегодня – про ключевой навык, отличающий крутого менеджера от обычного. Я называю его Getting Shit Done.
––
Почему не «Things?».
Раскидать и решить обычные «дела» (или «вещи») может любой менеджер, более-менее компетентный в предметной области и вооруженный ежедневником.
Самые большие неприятности, при возникновении которых зовут крутого менеджера – это никакие не things. Это именно Shit, в котором ты ничего не понимаешь, к которому не готов и готовым быть не можешь:
– На машину сотрудника упало дерево
– Ключевые разработчики проекта подрались на корпоративе, один остался без зубов и не хочет помогать второму
– У тебя горит дедлайн по сделке с иностранными партнёрами, а единственный человек из их команды, нормально говорящий по-английски, заболел
– Ты готовился к важному запуску, но вышел подышать воздухом в обед и сломал две руки в пяти местах (не шутка, история из жизни)
– Ты запускаешь новый сервис, а на следующий день узнаешь о готовящемся законопроекте, который ставит под вопрос его существование
Обычный менеджер говорит, что столкнулся с обстоятельствами непреодолимой силы и надеется, что кто-то решит эти проблемы за него. Если эскалировать оказалось некуда, проекту конец.
Крутой менеджер – ищет решение с учетом новых вводных, даже если эскалировать некуда. Что удивительно – проекты при этом часто выживают (хоть и сильно меняются).
––
Будь крутым менеджером! Как минимум, это весело :)
Есть выражение (и даже методология) «getting things done» – про доведение дел до конца, управление задачами, проектами, и тд.
Сегодня мы про него говорить не будем.
Сегодня – про ключевой навык, отличающий крутого менеджера от обычного. Я называю его Getting Shit Done.
––
Почему не «Things?».
Раскидать и решить обычные «дела» (или «вещи») может любой менеджер, более-менее компетентный в предметной области и вооруженный ежедневником.
Самые большие неприятности, при возникновении которых зовут крутого менеджера – это никакие не things. Это именно Shit, в котором ты ничего не понимаешь, к которому не готов и готовым быть не можешь:
– На машину сотрудника упало дерево
– Ключевые разработчики проекта подрались на корпоративе, один остался без зубов и не хочет помогать второму
– У тебя горит дедлайн по сделке с иностранными партнёрами, а единственный человек из их команды, нормально говорящий по-английски, заболел
– Ты готовился к важному запуску, но вышел подышать воздухом в обед и сломал две руки в пяти местах (не шутка, история из жизни)
– Ты запускаешь новый сервис, а на следующий день узнаешь о готовящемся законопроекте, который ставит под вопрос его существование
Обычный менеджер говорит, что столкнулся с обстоятельствами непреодолимой силы и надеется, что кто-то решит эти проблемы за него. Если эскалировать оказалось некуда, проекту конец.
Крутой менеджер – ищет решение с учетом новых вводных, даже если эскалировать некуда. Что удивительно – проекты при этом часто выживают (хоть и сильно меняются).
––
Будь крутым менеджером! Как минимум, это весело :)
🔥30👍6❤5😁3😢1🥴1
Тестирование в продакшене!
В больших компаниях обычно есть «тестовое окружение» – среда, в которой разворачивается приложение и в него тыкают разрабы и QA.
Лиды порой приобретают привычку говорить (и, что страшнее – думать!), что код работает как надо, если в тестовой среде не нашлось багов, прошли модульные и интеграционные тесты и тд. В идеальном мире – так оно и есть, но в реальном..если ты работаешь над большим приложением, которому много лет: этот подход не работает!
––
Почти всегда найдется:
– 10 конфигов, расходящихся в проде и в тестинге
– Паттерны использования приложения, до которых дошли странные юзеры и не дошли qa
– Блоки кода твоих коллег, которые включены в проде и выключены в тестовой среде
– Разница по нагрузке и данным, проходящих через разные окружения (моё уважение людям, которые льют в тестинг часть данных и нагрузки из прода! К сожалению, этот подход не устраняет остальные обозначенные проблемы).
– Банально невнимательный участник команды, который забыл проверить какой-нибудь сценарий на себе
Как следствие – вместо ожидаемого запуска на пользователей («всё ведь протестировано и работает – выкатим да включим») в день X происходит..получение 10 баг-репортов из прода и изменение графика поставки.
Даже если продуктовые метрики не должны прокраситься. Даже если это – «просто большой рефакторинг» (или оптимизация времени ответов бэкенда на 20%). Во многих случаях, выкатив сделанное на процент пользователей (или на всех сотрудников компании; или на город) ты, внезапно, соберешь пачку багрепортов, а иногда – увидишь прокрасившуюся в неожиданную сторону метрику :)
После эксперимента в проде – функционал и правда протестирован и готов к включению 🙂
В больших компаниях обычно есть «тестовое окружение» – среда, в которой разворачивается приложение и в него тыкают разрабы и QA.
Лиды порой приобретают привычку говорить (и, что страшнее – думать!), что код работает как надо, если в тестовой среде не нашлось багов, прошли модульные и интеграционные тесты и тд. В идеальном мире – так оно и есть, но в реальном..если ты работаешь над большим приложением, которому много лет: этот подход не работает!
––
Почти всегда найдется:
– 10 конфигов, расходящихся в проде и в тестинге
– Паттерны использования приложения, до которых дошли странные юзеры и не дошли qa
– Блоки кода твоих коллег, которые включены в проде и выключены в тестовой среде
– Разница по нагрузке и данным, проходящих через разные окружения (моё уважение людям, которые льют в тестинг часть данных и нагрузки из прода! К сожалению, этот подход не устраняет остальные обозначенные проблемы).
– Банально невнимательный участник команды, который забыл проверить какой-нибудь сценарий на себе
Как следствие – вместо ожидаемого запуска на пользователей («всё ведь протестировано и работает – выкатим да включим») в день X происходит..получение 10 баг-репортов из прода и изменение графика поставки.
Решение: относиться к любому крупному изменению как к эксперименту
Даже если продуктовые метрики не должны прокраситься. Даже если это – «просто большой рефакторинг» (или оптимизация времени ответов бэкенда на 20%). Во многих случаях, выкатив сделанное на процент пользователей (или на всех сотрудников компании; или на город) ты, внезапно, соберешь пачку багрепортов, а иногда – увидишь прокрасившуюся в неожиданную сторону метрику :)
После эксперимента в проде – функционал и правда протестирован и готов к включению 🙂
👍10🔥5❤4😁2😱1
#Пятничное
Время контента в пятницу вечером!
1. https://hbr.org/2008/02/getting-the-best-employee-idea
Old but gold: про ценность «маленьких» идей по улучшению продукта, приходящих от команды, а не от менеджмента.
И про то, что успех продукта и компании – не только в стратегических проектах :)
2. https://kinzhal.media/la-chaise/
Подписчики канала не узнают ничего нового для себя из этой статьи. Но она – не для вас!
Это – бесплатная инструкция, которую можно дать джуну или миддлу в своей команде и понадеяться на изменение подхода к работе :)
––
Третьего пункта сегодня не будет, поздно ведь уже, а спать – тоже нужно:)
Зато вместо одного мема будет сразу два, запомнившихся мне за эту неделю.
Поделись своими в комментариях!
––
upd: к своему ужасу узнал, что пост при добавлении двух картинок разрезается на три последовательных сообщения! Вот это я понимаю – пользовательский опыт. Удалять я их, конечно же, не буду :(
Время контента в пятницу вечером!
1. https://hbr.org/2008/02/getting-the-best-employee-idea
Old but gold: про ценность «маленьких» идей по улучшению продукта, приходящих от команды, а не от менеджмента.
И про то, что успех продукта и компании – не только в стратегических проектах :)
2. https://kinzhal.media/la-chaise/
Подписчики канала не узнают ничего нового для себя из этой статьи. Но она – не для вас!
Это – бесплатная инструкция, которую можно дать джуну или миддлу в своей команде и понадеяться на изменение подхода к работе :)
––
Третьего пункта сегодня не будет, поздно ведь уже, а спать – тоже нужно:)
Зато вместо одного мема будет сразу два, запомнившихся мне за эту неделю.
Поделись своими в комментариях!
––
upd: к своему ужасу узнал, что пост при добавлении двух картинок разрезается на три последовательных сообщения! Вот это я понимаю – пользовательский опыт. Удалять я их, конечно же, не буду :(
Harvard Business Review
Getting the Best Employee Ideas
Five questions with Alan G. Robinson, Coauthor of Ideas Are Free (Berrett-Kohler, 2004)
👍5❤4🔥1🤯1
Не забудь подумать
Когда моя команда стала большой, у меня регулярно стали возникать недели, на 80-90% состоящие из встреч:
– Статусы по проектам
– 1х1-ы
– Встречи со стейкхолдерами
– Встречи с разборами проблем
– Обеды со смежниками
– ….
Всё, вроде, по делу.
Но есть две проблемы:
a. На встрече ты не можешь глубоко и спокойно подумать про большие проблемы или необходимые изменения. Как минимум потому, что нужно все время обрабатывать поток информации от других участников, говорить самому, спорить и тд
b. Качественно проводимые встречи сжигают энергию
Получается, если в день у тебя 10+ встреч – ты и на синках не можешь серьезно поразмышлять, и после них – тоже (энергии недостаточно!).
––
Осознав эту проблему, я пришел к практике, которой пользуюсь до сих пор:
Каждую неделю бронирую в календаре несколько часов времени для самостоятельной работы
Я использую их так:
– Думаю, что и почему мы делаем в рамках топ-N важных бизнесу проектов
– Пересматриваю оргструктуру и известные мне фидбеки на сотрудников в поисках точек для улучшения
– Пересматриваю технические цели/стратегию/стэк технологий и думаю, что могло бы измениться
– Выписываю вещи, которые меня беспокоят без сформулированной причины, и рассматриваю их с разных сторон, пока не пойму, что не так
– Размышляю о чем угодно еще, кажущемся важным
Часто это приводит к обнаружению проблем и полезных идей.
Если нет – использую оставшееся время для погружения в самые важные части системы.
––
Если ты – тот самый лид, который целыми днями сидит на встречах, советую тоже попробовать.
– Во-первых, чтобы освободить часть времени, тебе придётся прокачать делегирование.
– Во-вторых – у тебя по-другому заработает голова и ты найдёшь новое в привычных местах.
Важно, чтобы это время было зарезервировано как полноценная встреча в рабочем календаре (можно сделать её закрытой). Иначе кто-нибудь его отберёт 🙂
Когда моя команда стала большой, у меня регулярно стали возникать недели, на 80-90% состоящие из встреч:
– Статусы по проектам
– 1х1-ы
– Встречи со стейкхолдерами
– Встречи с разборами проблем
– Обеды со смежниками
– ….
Всё, вроде, по делу.
Но есть две проблемы:
a. На встрече ты не можешь глубоко и спокойно подумать про большие проблемы или необходимые изменения. Как минимум потому, что нужно все время обрабатывать поток информации от других участников, говорить самому, спорить и тд
b. Качественно проводимые встречи сжигают энергию
Получается, если в день у тебя 10+ встреч – ты и на синках не можешь серьезно поразмышлять, и после них – тоже (энергии недостаточно!).
––
Осознав эту проблему, я пришел к практике, которой пользуюсь до сих пор:
Каждую неделю бронирую в календаре несколько часов времени для самостоятельной работы
Я использую их так:
– Думаю, что и почему мы делаем в рамках топ-N важных бизнесу проектов
– Пересматриваю оргструктуру и известные мне фидбеки на сотрудников в поисках точек для улучшения
– Пересматриваю технические цели/стратегию/стэк технологий и думаю, что могло бы измениться
– Выписываю вещи, которые меня беспокоят без сформулированной причины, и рассматриваю их с разных сторон, пока не пойму, что не так
– Размышляю о чем угодно еще, кажущемся важным
Часто это приводит к обнаружению проблем и полезных идей.
Если нет – использую оставшееся время для погружения в самые важные части системы.
––
Если ты – тот самый лид, который целыми днями сидит на встречах, советую тоже попробовать.
– Во-первых, чтобы освободить часть времени, тебе придётся прокачать делегирование.
– Во-вторых – у тебя по-другому заработает голова и ты найдёшь новое в привычных местах.
Важно, чтобы это время было зарезервировано как полноценная встреча в рабочем календаре (можно сделать её закрытой). Иначе кто-нибудь его отберёт 🙂
👍29❤9🔥8🥰1
О консервах в собственном соку
Рано или поздно растущий управленец оказывается в интересной позиции: руководитель перестаёт быть более экспертным в его домене.
Иногда это происходит на должности CTO/CPO/C*O.
Иногда – раньше.
Большая проблема для специалиста в этой ситуации: пропадает регулярный фидбек руководителя о том, как лучше делать свою работу.
Делать из отсутствия фидбека вывод, что ты делаешь лучшее, что можешь – ошибка.
Если тебе доводилось встречать компанию, в которой практики разработки/дизайна/etc устроены «как 10 лет назад», надежно законсервированы – скорее всего, C*O как раз наступил на эти грабли.
––
Что с этим делать?
1. Общаться с людьми из других компаний.
Если фидбека в компании получить негде – поищи снаружи :) Теперь это – часть твоей работы.
Важно: люди не обязательно должны быть на одном уровне с тобой. Даже будучи руководителем 300 человек, поговорив с менеджером 15 человек из другой компании, ты можешь увидеть, что мир изменился, кто-то нашел новые подходы, решения и т.д.
Я сам, хоть и с усилием, но не реже раза в полугодие заставляю себя выбираться из берлоги и смотреть: «а чего там во внешнем мире?».
––
2. Хотя бы понемногу нанимать подчинённых-лидов извне
Практика «промоутить на управленческие позиции ребят из компании» – хорошая и имеет множество плюсов.
Но если все руководящие должности оказываются заняты «своими ребятами», повышаются риски застрять в локальном максимуме компетенций.
Чтобы не застаиваться, полезно иногда приглашать в коллектив экспертов с другим опытом и давать им право голоса (в том числе – право с тобой спорить).
––
А что ещё ты делаешь, чтобы не консервировать себя и компанию?
Рано или поздно растущий управленец оказывается в интересной позиции: руководитель перестаёт быть более экспертным в его домене.
Иногда это происходит на должности CTO/CPO/C*O.
Иногда – раньше.
Большая проблема для специалиста в этой ситуации: пропадает регулярный фидбек руководителя о том, как лучше делать свою работу.
Делать из отсутствия фидбека вывод, что ты делаешь лучшее, что можешь – ошибка.
Если тебе доводилось встречать компанию, в которой практики разработки/дизайна/etc устроены «как 10 лет назад», надежно законсервированы – скорее всего, C*O как раз наступил на эти грабли.
––
Что с этим делать?
1. Общаться с людьми из других компаний.
Если фидбека в компании получить негде – поищи снаружи :) Теперь это – часть твоей работы.
Важно: люди не обязательно должны быть на одном уровне с тобой. Даже будучи руководителем 300 человек, поговорив с менеджером 15 человек из другой компании, ты можешь увидеть, что мир изменился, кто-то нашел новые подходы, решения и т.д.
Я сам, хоть и с усилием, но не реже раза в полугодие заставляю себя выбираться из берлоги и смотреть: «а чего там во внешнем мире?».
––
2. Хотя бы понемногу нанимать подчинённых-лидов извне
Практика «промоутить на управленческие позиции ребят из компании» – хорошая и имеет множество плюсов.
Но если все руководящие должности оказываются заняты «своими ребятами», повышаются риски застрять в локальном максимуме компетенций.
Чтобы не застаиваться, полезно иногда приглашать в коллектив экспертов с другим опытом и давать им право голоса (в том числе – право с тобой спорить).
––
А что ещё ты делаешь, чтобы не консервировать себя и компанию?
👍23❤6🔥5🤔1
Советы для M1. Планирование
Возвращаемся к ответам на вопросы.
Что бы ты сейчас посоветовал себе, когда только начинал быть лидом М1?
Полноценный ответ требует статьи на хабр, она выйдет позже 🙂
А пока – про одну из частых проблем M1: планирование.
––
У начинающих лидов часто возникает один из двух интуитивных подходов к планированию:
1. Прикину, за какое время я сам бы сделал задачу. Отнормирую на уровень сотрудника
Например:
a. Синьор – сделает с такой же скоростью, как я.
b. Миддл – в два раза медленнее.
И т.д.
Внезапно, такие предсказания ломаются.
2. Спрошу у сотрудника, сколько времени у него уйдет на задачу. Если уровень невысокий – умножу на менеджерский коэффициент.
a. Синьор оценил задачу в три дня – добавлю денек на баги
b. Миддл оценил в три дня – умножу на два
c. Джун оценил в три дня – помоги мне бог, чтобы сошлось до конца месяца
И..такие предсказания тоже ломаются!
Люди слишком сложны, чтобы надёжно предсказывать их производительность по уровню или должности.
––
А что тогда делать с прогнозами?
Пользоваться историческими данными.
Во время планирования абстрагируйся от должности/внешней уверенности человека. Смотри на историю его работы с завершенными задачами:
– Если в предыдущих двух спринтах он закрывал задач на «5 сторипоинтов», не стоит ожидать, что в этом спринте он закроет 10, потому что «заказчикам очень нужно» или «ну я соберусь и затащу, честное слово!»
– Если в прошлый и позапрошлый раз у разработчика ушло по неделе на написание http-хэндлера, пишущего в базу, не стоит ожидать, что в этот раз он сделает то же самое за два дня
Тот же подход применим для ответа на вопрос: «сколько за итерацию сможет сделать команда?»
––
А как же рост эффективности? Люди что, не могут развиваться и учиться?
Могут. И в развитие команды нужно вкладывать своё время. Но:
Человек обучился и прокачался, если ты на данных видишь, что он стал делать больше / выше / лучше и т.д.
Планировать больше можно начинать только тогда, когда человек уже и так делает больше. Не наоборот!
Возвращаемся к ответам на вопросы.
Что бы ты сейчас посоветовал себе, когда только начинал быть лидом М1?
Полноценный ответ требует статьи на хабр, она выйдет позже 🙂
А пока – про одну из частых проблем M1: планирование.
––
У начинающих лидов часто возникает один из двух интуитивных подходов к планированию:
1. Прикину, за какое время я сам бы сделал задачу. Отнормирую на уровень сотрудника
Например:
a. Синьор – сделает с такой же скоростью, как я.
b. Миддл – в два раза медленнее.
И т.д.
Внезапно, такие предсказания ломаются.
2. Спрошу у сотрудника, сколько времени у него уйдет на задачу. Если уровень невысокий – умножу на менеджерский коэффициент.
a. Синьор оценил задачу в три дня – добавлю денек на баги
b. Миддл оценил в три дня – умножу на два
c. Джун оценил в три дня – помоги мне бог, чтобы сошлось до конца месяца
И..такие предсказания тоже ломаются!
Люди слишком сложны, чтобы надёжно предсказывать их производительность по уровню или должности.
––
А что тогда делать с прогнозами?
Пользоваться историческими данными.
Во время планирования абстрагируйся от должности/внешней уверенности человека. Смотри на историю его работы с завершенными задачами:
– Если в предыдущих двух спринтах он закрывал задач на «5 сторипоинтов», не стоит ожидать, что в этом спринте он закроет 10, потому что «заказчикам очень нужно» или «ну я соберусь и затащу, честное слово!»
– Если в прошлый и позапрошлый раз у разработчика ушло по неделе на написание http-хэндлера, пишущего в базу, не стоит ожидать, что в этот раз он сделает то же самое за два дня
Тот же подход применим для ответа на вопрос: «сколько за итерацию сможет сделать команда?»
––
А как же рост эффективности? Люди что, не могут развиваться и учиться?
Могут. И в развитие команды нужно вкладывать своё время. Но:
Человек обучился и прокачался, если ты на данных видишь, что он стал делать больше / выше / лучше и т.д.
Планировать больше можно начинать только тогда, когда человек уже и так делает больше. Не наоборот!
👍10❤8🔥5💯1🙈1
О дедлайнах
Если кто-то должен что-то для тебя сделать, обязательно нужен дедлайн и ответственный.
Зачем это нужно?
Во-первых, приоритизировать умеют не все. Твою «важную» задачу без дедлайна запросто могут задвинуть в пользу менее важных, но имеющих дедлайн. Ну а что – договорённость-то не нарушена :)
Во-вторых, без ответственного и дедлайна – непонятно кому и когда напоминать о себе, если задача не движется.
––
Когда в следующий раз договоришься о чём-то – обязательно проговори вслух и запиши ответственного и дедлайн. Иначе – можно было и не договариваться :)
Продуктивного понедельника и успешных переговоров!
Если кто-то должен что-то для тебя сделать, обязательно нужен дедлайн и ответственный.
– Запилите новый пуш? А когда? А кто лично сделает и проследит? Спасибо, записываем: Саша, до 19 июня
– Проведёте воспитательную беседу с андерперформером? А кто и когда? Спасибо, записываем: Андрей, завтра
– Прикинешь, сколько разработчиков тебе нужно на проект? Сколько времени тебе для этого нужно? Спасибо, записываю: Петя пришлёт оценку до конца недели
Зачем это нужно?
Во-первых, приоритизировать умеют не все. Твою «важную» задачу без дедлайна запросто могут задвинуть в пользу менее важных, но имеющих дедлайн. Ну а что – договорённость-то не нарушена :)
Во-вторых, без ответственного и дедлайна – непонятно кому и когда напоминать о себе, если задача не движется.
––
Когда в следующий раз договоришься о чём-то – обязательно проговори вслух и запиши ответственного и дедлайн. Иначе – можно было и не договариваться :)
Продуктивного понедельника и успешных переговоров!
👍24❤5🔥3😁1🤝1
О культуре дедлайнов
Иногда лиды, инженеры и менеджеры мысленно делят дедлайна на два типа:
1. Жесткие
Через неделю наш софт заблокируют в стране, если мы не поменяем X / завтра выйдет законопроект, требующий от нас Y / большой клиент расторгнет контракт, если не пофиксить баг Z…
Такой дедлайн ни в коем случае нельзя пропускать. Если кажется, что мы не попадём – мы напряжемся, порежем скоуп, поищем другие пути реализации и т.д.
2. Мягкие
«Мы прикинули, сколько времени нужно на проект и пообещали менеджменту выкатить его в следующем месяце»
«Я прикинул, сколько времени мне нужно на задачу, и пообещал руководителю закончить к понедельнику»
Такой дедлайн лучше не пропускать, но..никто ведь не умрет – если что, просто сдвинем
––
90% фичей, выпускаемых обычной продуктовой компанией, не подпираются внешними, объективными дедлайнами. Внешний дедлайн – это форс-мажор.
А дедлайн, который можно подвинуть – это вообще не дедлайн. Он не прибавляет людям ответственности, не заставляет «поднапрячься и дотащить», не мотивирует следить за сроками, заниматься качественным проектным управлением и быстро адаптироваться к проблемам. Если дедлайн у фичи мягкий – ты, вообще говоря, не можешь рассчитывать, что она будет выпущена.
Задача с мягким дедлайном будет сдана вовремя либо если у команды не возникнет никаких непредвиденных трудностей (а кто из нас видел серьёзные проекты без них?), либо если команда будет очень гореть проектом (а этого тоже может не случиться. Не все проекты – это что-то невероятное, красивое, захватывающее и тд).
Короче говоря – если тебе не повезёт, проект может занять непредсказуемо большое количество времени.
Если твои лиды и менеджеры живут в мире, в котором существуют «мягкие» дедлайны, выпуск бОльшего количества твоих задач – дело случая и божьей помощи. Если у твоих конкурентов не так – ты неизбежно отстанешь.
––
Что с этим делать?
Дедлайн есть дедлайн. Двигать его нельзя. Как только мы договорились о дедлайне, он стал жёстким. Проехать за дедлайн – форс-мажор; если он приближается, нужно эскалировать и обсуждать.
Такая культурная установка стимулирует людей доводить дела до конца, находить неочевидные решения, не забивать болт на работу в ответственные моменты и, вообще говоря, двигаться быстрее.
Важная дополнительная установка: в рабочей неделе по умолчанию – 40 часов. Она, с одной стороны, неизбежно приведет к срыву первых 5-10 дедлайнов, с другой – поможет не убить команду + научит людей быть эффективнее, а не тупо больше работать.
––
Совсем без профакапленных сроков и овертаймов на дистанции обойтись невозможно. Но увеличить вероятность успеха – в твоих руках 🙂
Иногда лиды, инженеры и менеджеры мысленно делят дедлайна на два типа:
1. Жесткие
Через неделю наш софт заблокируют в стране, если мы не поменяем X / завтра выйдет законопроект, требующий от нас Y / большой клиент расторгнет контракт, если не пофиксить баг Z…
Такой дедлайн ни в коем случае нельзя пропускать. Если кажется, что мы не попадём – мы напряжемся, порежем скоуп, поищем другие пути реализации и т.д.
2. Мягкие
«Мы прикинули, сколько времени нужно на проект и пообещали менеджменту выкатить его в следующем месяце»
«Я прикинул, сколько времени мне нужно на задачу, и пообещал руководителю закончить к понедельнику»
Такой дедлайн лучше не пропускать, но..никто ведь не умрет – если что, просто сдвинем
––
90% фичей, выпускаемых обычной продуктовой компанией, не подпираются внешними, объективными дедлайнами. Внешний дедлайн – это форс-мажор.
А дедлайн, который можно подвинуть – это вообще не дедлайн. Он не прибавляет людям ответственности, не заставляет «поднапрячься и дотащить», не мотивирует следить за сроками, заниматься качественным проектным управлением и быстро адаптироваться к проблемам. Если дедлайн у фичи мягкий – ты, вообще говоря, не можешь рассчитывать, что она будет выпущена.
Задача с мягким дедлайном будет сдана вовремя либо если у команды не возникнет никаких непредвиденных трудностей (а кто из нас видел серьёзные проекты без них?), либо если команда будет очень гореть проектом (а этого тоже может не случиться. Не все проекты – это что-то невероятное, красивое, захватывающее и тд).
Короче говоря – если тебе не повезёт, проект может занять непредсказуемо большое количество времени.
Если твои лиды и менеджеры живут в мире, в котором существуют «мягкие» дедлайны, выпуск бОльшего количества твоих задач – дело случая и божьей помощи. Если у твоих конкурентов не так – ты неизбежно отстанешь.
––
Что с этим делать?
Устранять «не-жесткие» дедлайны как концепцию в культуре команды.
Дедлайн есть дедлайн. Двигать его нельзя. Как только мы договорились о дедлайне, он стал жёстким. Проехать за дедлайн – форс-мажор; если он приближается, нужно эскалировать и обсуждать.
Такая культурная установка стимулирует людей доводить дела до конца, находить неочевидные решения, не забивать болт на работу в ответственные моменты и, вообще говоря, двигаться быстрее.
Важная дополнительная установка: в рабочей неделе по умолчанию – 40 часов. Она, с одной стороны, неизбежно приведет к срыву первых 5-10 дедлайнов, с другой – поможет не убить команду + научит людей быть эффективнее, а не тупо больше работать.
––
Совсем без профакапленных сроков и овертаймов на дистанции обойтись невозможно. Но увеличить вероятность успеха – в твоих руках 🙂
👍22❤4🔥4🤔3💯2💊2✍1
Как договариваться с менеджерами высокого уровня
Порой топам что-то нужно от тебя: узнать планы команды на квартал / понять статус проблемы или проекта и т.д;
Иногда – тебе что-то нужно от больших начальников: получить ресурс / заставить других их подчинённых что-то сделать / получить одобрение на смену курса / …
Как вести эти разговоры эффективно?
––
При общении в переписке
1. Если задаёшь вопрос:
Вся нужная для ответа инфа и явно сформулированный вопрос должны находиться в одном сообщении.
2. Если отвечаешь на вопрос:
В начале – как можно более ёмкий ответ, за ним – все нужные детали. Обязательно в одном сообщении.
––
Не допускай долгой переписки! К решению нужно прийти за единицы сообщений. На уточняющие вопросы отвечай со всеми деталями в одном сообщении + сразу возвращайся к исходному вопросу;
Если договариваешься на встрече
Всю нужную для принятия решения информацию нужно принести в максимально разжёванном виде.
Если дело дошло до встречи, значит, переписка не сработала. Значит, деталей и картинок нужно больше, чем влезает в стандартное сообщение в телеге
Ответ или решение нужно обязательно получить на той же встрече.
––
Почему так? Топы вообще не держат контекст и не умеют читать?
Да.
(Шутка)
На самом деле, у менеджера высокого уровня чудовищная плотность коммуникаций и контекстов. Как только закончится ваш разговор, начнется другой. Настолько сложный, что человек не сможет параллельно продолжить обдумывать твою проблему. И так – до конца дня. Или недели.
Что из этого следует?
Правильно: если вы не договорились сразу, контекст на стороне менеджера будет размыт и высока вероятность, что тебе придётся начинать сначала.
Заводить разговор: «помнишь, мы позавчера начали обсуждать X? Так вот..» – бесполезно. Нет, собеседник не помнит и да – тебе придётся начинать сначала. Короче, контекст между транзакциями обычно не сохраняется.
Так что работай над формулировками и договаривайся быстро :)
Порой топам что-то нужно от тебя: узнать планы команды на квартал / понять статус проблемы или проекта и т.д;
Иногда – тебе что-то нужно от больших начальников: получить ресурс / заставить других их подчинённых что-то сделать / получить одобрение на смену курса / …
Как вести эти разговоры эффективно?
––
При общении в переписке
1. Если задаёшь вопрос:
Вся нужная для ответа инфа и явно сформулированный вопрос должны находиться в одном сообщении.
2. Если отвечаешь на вопрос:
В начале – как можно более ёмкий ответ, за ним – все нужные детали. Обязательно в одном сообщении.
––
Не допускай долгой переписки! К решению нужно прийти за единицы сообщений. На уточняющие вопросы отвечай со всеми деталями в одном сообщении + сразу возвращайся к исходному вопросу;
Если договариваешься на встрече
Всю нужную для принятия решения информацию нужно принести в максимально разжёванном виде.
Если дело дошло до встречи, значит, переписка не сработала. Значит, деталей и картинок нужно больше, чем влезает в стандартное сообщение в телеге
Ответ или решение нужно обязательно получить на той же встрече.
––
Почему так? Топы вообще не держат контекст и не умеют читать?
Да.
(Шутка)
На самом деле, у менеджера высокого уровня чудовищная плотность коммуникаций и контекстов. Как только закончится ваш разговор, начнется другой. Настолько сложный, что человек не сможет параллельно продолжить обдумывать твою проблему. И так – до конца дня. Или недели.
Что из этого следует?
Правильно: если вы не договорились сразу, контекст на стороне менеджера будет размыт и высока вероятность, что тебе придётся начинать сначала.
Заводить разговор: «помнишь, мы позавчера начали обсуждать X? Так вот..» – бесполезно. Нет, собеседник не помнит и да – тебе придётся начинать сначала. Короче, контекст между транзакциями обычно не сохраняется.
Так что работай над формулировками и договаривайся быстро :)
👍26🔥9❤8❤🔥1🤔1😢1
Decision-review
У разрабов в бигтехе часто обязательной является практика код-ревью.
Ревью даёт тонну полезного фидбека, причем не только от руководителя, у которого может не быть времени, но и от пиров. Это помогает не совершать ошибок (порой – жутких) и прокачивает скиллы.
Я встречал людей из небольших компаний, приходивших к нам в поисках работы как раз потому, что регулярного ревью и фидбека у них не было. И почти не встречал людей из корпораций, не разделявших ценности этого процесса.
А есть ли аналогичный механизм у руководителей для своих задач?
––
К сожалению, не у всех. Многие неэффективные управленческие решения приняты менеджерами только потому, что какие-то детали ситуации или пути решения от них ускользнули. Их можно было бы избежать, «поревьюив» решение свежим взглядом.
– Неподходящие назначения на должности. И наоборот – отказ в продвижениях подходящим людям, для которых это важно
– Увольнения людей, которые могли быть эффективны при другой работе. И наоборот – попытки всеми силами сохранить человека, которого держать незачем
– Кросс-функциональные команды там, где они не нужны. И наоборот
– Продолжи список своим опытом
––
А какой выход? Управленческие решения – это же не код, на ревью не отправишь..
– Я хочу сделать X. Вот такая мотивация, вот такой эффект ожидаю. Чего думаете?
– Не, смотри, у тебя вот эти люди могут разбежаться от такого. Я делал – вот что вышло. <и другой поток обратной связи…>
Если не веришь, что сработает – позови пару людей, которым доверяешь, попить пива в следующую пятницу после работы, и попроси их почелленджить 5 твоих последних управленческих решений. Эффект обычно интересный 🙂
––
P.S.
Тут тред для небольших вопросов – мы время от времени публично их разбираем в канале
Здесь можно записаться и лично детально пообсуждать свои кейсы
А здесь – можно поискать уже вышедший совет на нужную тему
У разрабов в бигтехе часто обязательной является практика код-ревью.
Ревью даёт тонну полезного фидбека, причем не только от руководителя, у которого может не быть времени, но и от пиров. Это помогает не совершать ошибок (порой – жутких) и прокачивает скиллы.
Я встречал людей из небольших компаний, приходивших к нам в поисках работы как раз потому, что регулярного ревью и фидбека у них не было. И почти не встречал людей из корпораций, не разделявших ценности этого процесса.
А есть ли аналогичный механизм у руководителей для своих задач?
––
К сожалению, не у всех. Многие неэффективные управленческие решения приняты менеджерами только потому, что какие-то детали ситуации или пути решения от них ускользнули. Их можно было бы избежать, «поревьюив» решение свежим взглядом.
– Неподходящие назначения на должности. И наоборот – отказ в продвижениях подходящим людям, для которых это важно
– Увольнения людей, которые могли быть эффективны при другой работе. И наоборот – попытки всеми силами сохранить человека, которого держать незачем
– Кросс-функциональные команды там, где они не нужны. И наоборот
– Продолжи список своим опытом
––
А какой выход? Управленческие решения – это же не код, на ревью не отправишь..
На самом деле – запросто отправишь! Рабочая практика – организовать регулярные встречи руководителей одного уровня и начать на них «ревьюить» решения. Буквально:
– Я хочу сделать X. Вот такая мотивация, вот такой эффект ожидаю. Чего думаете?
– Не, смотри, у тебя вот эти люди могут разбежаться от такого. Я делал – вот что вышло. <и другой поток обратной связи…>
Если не веришь, что сработает – позови пару людей, которым доверяешь, попить пива в следующую пятницу после работы, и попроси их почелленджить 5 твоих последних управленческих решений. Эффект обычно интересный 🙂
––
P.S.
Тут тред для небольших вопросов – мы время от времени публично их разбираем в канале
Здесь можно записаться и лично детально пообсуждать свои кейсы
А здесь – можно поискать уже вышедший совет на нужную тему
👍17❤6🔥6💯1
О метриках для лидов любого уровня:
1. Самый осмысленный и ценный результат – это измеримый результат
– буллшит, оставь для своей избирательной компании.
– хорошая цель.
– буллшит, расскажешь на дне открытых дверей для школьников (студентам уже нужно посложнее).
– крутые показатели.
––
2. Если умные люди регулярно думают про метрику, она меняется в желаемую сторону
Не знаешь, как сдвинуть важную метрику?
Поставь в центре комнаты монитор, на который она выведена и начни раз в неделю собирать вокруг него лучших людей на 30 минут.
– Кто считает, что метрика бредовая и нам нужна другая?
– Как метрика менялась за последние полгода? Кто знает, почему? Кто узнает и расскажет через неделю?
– Кто прямо сейчас пытается на нее повлиять? А что ты для этого делаешь? Расскажи всем, пусть тоже попробуют
– В порядке бреда: какие у кого есть идеи экспериментов, влияющих на нашу метрику?
При регулярном повторении начинает происходить магия
––
3. Набор ключевых метрик нужно регулярно пересматривать
Повесили на монитор метрику скорости загрузки главной страницы приложения. Начали смотреть на неё командой лучших людей раз в неделю:
1 квартал: 5 секунд -> 2 секунды
2 квартал: 2 секунды -> 1 секунда
3 квартал: 1 секунда -> 0.8 секунд
4 квартал: 0.8 секунд -> 0.75
…
Стоп!
Может быть, 1 секунда – это уже хорошо? Правда ли 1 -> 0.8 – это лучшее, что можно было сделать за 3 квартал? Может быть, где-то рядом есть другая метрика, теперь уже с бОльшим value, за которую мы не взялись?
––
Ценность некоторой работы и правда тяжело оцифровать. Но если такой работы у тебя много – подумай ещё раз, чем вы с командой занимаетесь :)
1. Самый осмысленный и ценный результат – это измеримый результат
Мы сделаем сервис надёжным и отказоустойчивым
– буллшит, оставь для своей избирательной компании.
В прошлом году у нас было два часа даунтайма. В этом году мы не допустим даунтайма более, чем на 15 минут
– хорошая цель.
Я классно развиваю специалистов
– буллшит, расскажешь на дне открытых дверей для школьников (студентам уже нужно посложнее).
Джун в моей команде за полгода растёт до миддла; миддлы имеют стабильный перформанс не ниже X; миддлы за два года превращатся в синьоров; людей из моей команды пытаются переманить конкуренты в среднем на X2 зп и + 2 грейда
– крутые показатели.
––
2. Если умные люди регулярно думают про метрику, она меняется в желаемую сторону
Не знаешь, как сдвинуть важную метрику?
Поставь в центре комнаты монитор, на который она выведена и начни раз в неделю собирать вокруг него лучших людей на 30 минут.
– Кто считает, что метрика бредовая и нам нужна другая?
– Как метрика менялась за последние полгода? Кто знает, почему? Кто узнает и расскажет через неделю?
– Кто прямо сейчас пытается на нее повлиять? А что ты для этого делаешь? Расскажи всем, пусть тоже попробуют
– В порядке бреда: какие у кого есть идеи экспериментов, влияющих на нашу метрику?
При регулярном повторении начинает происходить магия
––
3. Набор ключевых метрик нужно регулярно пересматривать
Повесили на монитор метрику скорости загрузки главной страницы приложения. Начали смотреть на неё командой лучших людей раз в неделю:
1 квартал: 5 секунд -> 2 секунды
2 квартал: 2 секунды -> 1 секунда
3 квартал: 1 секунда -> 0.8 секунд
4 квартал: 0.8 секунд -> 0.75
…
Стоп!
Может быть, 1 секунда – это уже хорошо? Правда ли 1 -> 0.8 – это лучшее, что можно было сделать за 3 квартал? Может быть, где-то рядом есть другая метрика, теперь уже с бОльшим value, за которую мы не взялись?
––
Ценность некоторой работы и правда тяжело оцифровать. Но если такой работы у тебя много – подумай ещё раз, чем вы с командой занимаетесь :)
🔥13👍11❤5🤔1
Основной ресурс для успеха команды
О каком ресурсе важнее всего позаботиться руководителю?
– Новые ноутбуки для всех членов команды?
Nice to have. Работать за новым ноутом, конечно, приятнее, чем за старым. Иногда – удобнее, чем за стандартным PC.
Но если человек очень хочет сделать задачу – он сделает, даже если любимый ноут останется далеко.
//я пару раз писал код с удаленным доступом с телефона, а ты?)
––
– Корпоративный мессенджер, зум, слак, тасктрекер?
Nice to have. С ними действительно сильно удобнее. Но у каждого из нас ведь есть знакомый-стартапер, который не пользовался ничем кроме экселя и телеграма, поднимая первые раунды инвестиций?
Люди, которые очень хотят работать, порой потерпят и неидеальную систему
––
– Все необходимые компетенции у тех.специалистов в команде?
Nice to have. Если люди умеют все, что нужно для разработки продукта, он и правда запустится быстрее.
Если не умеют, но при этом очень хотят..я видел мобильных разработчиков, освоивших C++. И бэкендеров, научившихся верстать интерфейсы, когда это стало очень нужно
––
– Отлаженные процессы, дейли-митинги, ретро, …?
Nice to have. Процесс и правда делает работу стабильнее, прозрачнее, проще, в конце-концов.
Однако..если руководитель и команда очень заряжены, они могут деливерить и без спринтов.
––
– Мотивация
А вот если мотивации нет, все остальные пункты бесполезны.
Сколько ценности принесёт сотрудник, не вовлечённый в свою работу и проект? Ровно столько, сколько будет достаточно, чтобы его не уволили.
Решит ли он сложную задачу, если что-то пойдет не так? Вряд ли.
А если выдать ему железо подороже?
А если скрам поменять на канбан?
А если лицензию зума купить?
Неважно. Без мотивации остальное не имеет значения.
О каком ресурсе важнее всего позаботиться руководителю?
– Новые ноутбуки для всех членов команды?
Nice to have. Работать за новым ноутом, конечно, приятнее, чем за старым. Иногда – удобнее, чем за стандартным PC.
Но если человек очень хочет сделать задачу – он сделает, даже если любимый ноут останется далеко.
//я пару раз писал код с удаленным доступом с телефона, а ты?)
––
– Корпоративный мессенджер, зум, слак, тасктрекер?
Nice to have. С ними действительно сильно удобнее. Но у каждого из нас ведь есть знакомый-стартапер, который не пользовался ничем кроме экселя и телеграма, поднимая первые раунды инвестиций?
Люди, которые очень хотят работать, порой потерпят и неидеальную систему
––
– Все необходимые компетенции у тех.специалистов в команде?
Nice to have. Если люди умеют все, что нужно для разработки продукта, он и правда запустится быстрее.
Если не умеют, но при этом очень хотят..я видел мобильных разработчиков, освоивших C++. И бэкендеров, научившихся верстать интерфейсы, когда это стало очень нужно
––
– Отлаженные процессы, дейли-митинги, ретро, …?
Nice to have. Процесс и правда делает работу стабильнее, прозрачнее, проще, в конце-концов.
Однако..если руководитель и команда очень заряжены, они могут деливерить и без спринтов.
––
– Мотивация
А вот если мотивации нет, все остальные пункты бесполезны.
Сколько ценности принесёт сотрудник, не вовлечённый в свою работу и проект? Ровно столько, сколько будет достаточно, чтобы его не уволили.
Решит ли он сложную задачу, если что-то пойдет не так? Вряд ли.
А если выдать ему железо подороже?
А если скрам поменять на канбан?
А если лицензию зума купить?
Неважно. Без мотивации остальное не имеет значения.
Мотивация – базовый ресурс команды и компании. Начинать нужно с неё.
👍23❤7🔥3👀1
Возвращаемся с длиннопостами на хабр!
Сегодня – про делегирование.
Лайк, репост и комментарий – помогают 🙂
https://habr.com/ru/articles/825918/
Сегодня – про делегирование.
Лайк, репост и комментарий – помогают 🙂
https://habr.com/ru/articles/825918/
Хабр
Делегируй это
Знакомо ли тебе слово "делегирование" ? На первый взгляд, с ним всё понятно: одной рукой хватаешь задачу, другой – счастливчика из своей команды и запихиваешь делегируешь! Сотрудник – с бесценным...
👍18❤7🔥3
Как перестать бояться переговоров.
На самом деле, переговоры – это очень просто. Это как ездить на велосипеде. Который горит. И ты горишь. И всё горит.
Когда я был начинающим специалистом, переговоры часто заставляли меня нервничать.
Не обычные разговоры, а именно переговоры: когда нужно о чём-то договориться или принять решение, причем моё предложение могут не принять.
– «Время ведь ограничено – всего полчаса на встречу»
– «А если меня не поймут?»
– «С другой стороны стола – человек не в лучших со мной отношениях. Что, если мы поругаемся?»
– «Собеседники, скорее всего, будут поддерживать другое решение. Придется спорить, причем очень плотно»
– «Моё предложение будет эмоционально тяжело принять собеседнику. Что, если он перевернёт стол и откажется разговаривать?»
– Добавь к списку своих любимых тревожных мыслей :)
––
А потом я осознал кое-что, изменившее мою жизнь:
Если вы, встретившись, не можете договориться – это не повод сдаваться или принимать «плохое» решение. Просто выпиши все пункты, по которым вы не сошлись (с аргументами и вопросами) + возьми таймаут + сделай ещё один заход.
– Мы не сможем договориться сегодня. На столе у нас: предложение 1, в нем хорошо X и плохо Y; предложение 2 – в нем хорошо K и плохо Z; предложение 3 – … Я заберу себе домашнее задание подумать, что делать с минусами предложения 2 (оно мне больше всех нравится) + еще раз посмотрю на альтернативы. Подумайте, пожалуйста, о своих вариантах, и давайте встретимся завтра вечером
Готовишься, думаешь, собираешь новое решение и аргументы и повторяешь.
Защита от бесконечного цикла – дедлайн на принятие решения. Только не «к концу встречи», а «не позже, чем в день X».
Как только ты разрешаешь себе ошибаться и пробовать снова, страх провала пропадает и появляется возможность подходить к переговорам как к «ещё одной» интеллектуальной задаче (вроде проектирования).
Кстати, применимо не только на работе!
––
Успешных переговоров на этой неделе!
На самом деле, переговоры – это очень просто. Это как ездить на велосипеде. Который горит. И ты горишь. И всё горит.
Когда я был начинающим специалистом, переговоры часто заставляли меня нервничать.
Не обычные разговоры, а именно переговоры: когда нужно о чём-то договориться или принять решение, причем моё предложение могут не принять.
– «Время ведь ограничено – всего полчаса на встречу»
– «А если меня не поймут?»
– «С другой стороны стола – человек не в лучших со мной отношениях. Что, если мы поругаемся?»
– «Собеседники, скорее всего, будут поддерживать другое решение. Придется спорить, причем очень плотно»
– «Моё предложение будет эмоционально тяжело принять собеседнику. Что, если он перевернёт стол и откажется разговаривать?»
– Добавь к списку своих любимых тревожных мыслей :)
––
А потом я осознал кое-что, изменившее мою жизнь:
Договариваться с первой попытки – не обязательно!
Если вы, встретившись, не можете договориться – это не повод сдаваться или принимать «плохое» решение. Просто выпиши все пункты, по которым вы не сошлись (с аргументами и вопросами) + возьми таймаут + сделай ещё один заход.
– Мы не сможем договориться сегодня. На столе у нас: предложение 1, в нем хорошо X и плохо Y; предложение 2 – в нем хорошо K и плохо Z; предложение 3 – … Я заберу себе домашнее задание подумать, что делать с минусами предложения 2 (оно мне больше всех нравится) + еще раз посмотрю на альтернативы. Подумайте, пожалуйста, о своих вариантах, и давайте встретимся завтра вечером
Готовишься, думаешь, собираешь новое решение и аргументы и повторяешь.
Защита от бесконечного цикла – дедлайн на принятие решения. Только не «к концу встречи», а «не позже, чем в день X».
Как только ты разрешаешь себе ошибаться и пробовать снова, страх провала пропадает и появляется возможность подходить к переговорам как к «ещё одной» интеллектуальной задаче (вроде проектирования).
Кстати, применимо не только на работе!
––
Успешных переговоров на этой неделе!
👍37❤18🔥7
Продолжаем тему переговоров
– Пытаешься убедить в чем-то группу людей, а они не принимают твою идею?
– Собираешься «продавать» что-то команде и ожидаешь сопротивления?
Есть приём, который очень сильно повышает шансы на успех:
1. Перенеси встречу по «продаже» идеи на неделю.
2. Предварительно встреться лично по отдельности с каждым, чей голос важен.
Сопротивление группы людей – это всегда тяжело. Даже если возражения неконструктивны и эмоциональны. Сопротивляющиеся активно поддерживают друг друга, насыпают новые и новые контраргументы и переспорить их, порой, не может даже опытный менеджер.
Вступать в такую неравную конфронтацию – абсолютно незачем. Просто сделай то, что должен уметь любой руководитель: проведи серию встреч 1х1. Во время личной встречи нужно по-максимуму вытащить из собеседника его мысли по теме, отработать возражения (особенно – эмоциональные) и в идеале – показать, какую выгоду лично ему может принести внедрение новой идеи.
Если 1х1-ы хорошо пройдут не с каждым – не страшно. Во-первых, ты получишь союзников на общей встрече в лице тех, кто сходу согласится, а во-вторых – заранее узнаешь о возражениях и подготовишься к работе с ними. Или даже успеешь отбить все до встречи.
––
Тред для публичных разборов.
Ссылка для личных консультаций :)
– Пытаешься убедить в чем-то группу людей, а они не принимают твою идею?
– Собираешься «продавать» что-то команде и ожидаешь сопротивления?
Есть приём, который очень сильно повышает шансы на успех:
1. Перенеси встречу по «продаже» идеи на неделю.
2. Предварительно встреться лично по отдельности с каждым, чей голос важен.
Сопротивление группы людей – это всегда тяжело. Даже если возражения неконструктивны и эмоциональны. Сопротивляющиеся активно поддерживают друг друга, насыпают новые и новые контраргументы и переспорить их, порой, не может даже опытный менеджер.
Вступать в такую неравную конфронтацию – абсолютно незачем. Просто сделай то, что должен уметь любой руководитель: проведи серию встреч 1х1. Во время личной встречи нужно по-максимуму вытащить из собеседника его мысли по теме, отработать возражения (особенно – эмоциональные) и в идеале – показать, какую выгоду лично ему может принести внедрение новой идеи.
Если 1х1-ы хорошо пройдут не с каждым – не страшно. Во-первых, ты получишь союзников на общей встрече в лице тех, кто сходу согласится, а во-вторых – заранее узнаешь о возражениях и подготовишься к работе с ними. Или даже успеешь отбить все до встречи.
Убеждай лично, закрепляй публично.
––
Тред для публичных разборов.
Ссылка для личных консультаций :)
👍28🔥7❤4
О конференциях
Какая, на твой взгляд, самая полезная часть технической конференции?
По-моему – перерыв с пивом между докладами.
Доклад можно и на ютубе посмотреть. Это намного удобнее, чем куда-то ехать и сидеть на стуле в толпе людей. Я бы в жизни не посетил мероприятие ради того, чтобы послушать доклад – серьёзно, у нас ведь есть интернет!
А то, что происходит между докладами, за пивом – ютубом уже не заменишь. Люди знакомятся друг с другом и со спикерами, задают вопросы, обсуждают решения проблем. Доклад полезен постольку, поскольку выполняет роль ice-breaker-а и дает конкретный контекст для обсуждения.
Наибольшую пользу я, как спикер, дал слушателям, которые подошли ко мне после докладов и задали вопрос про свою проблему (а не про мою, уже решенную, и показаную на сцене).
––
Так уж вышло, что в этом году я оказался в составе руководителей ПК YACAMP.
Так что мы, наконец, ставим эксперимент 10-го августа в Москве: тусовка с минимумом докладов и максимальным фокусом на нетворкинге и совместном решении задач в реальном времени. И, конечно, вечеринка в конце.
Регистрация уже открыта. Она бесплатна, но с ограничением на количество мест (больше тысячи участников мы вряд ли провернём) и модерацией заявок.
Буду рад увидеть подписчиков и друзей :)
Какая, на твой взгляд, самая полезная часть технической конференции?
По-моему – перерыв с пивом между докладами.
Доклад можно и на ютубе посмотреть. Это намного удобнее, чем куда-то ехать и сидеть на стуле в толпе людей. Я бы в жизни не посетил мероприятие ради того, чтобы послушать доклад – серьёзно, у нас ведь есть интернет!
А то, что происходит между докладами, за пивом – ютубом уже не заменишь. Люди знакомятся друг с другом и со спикерами, задают вопросы, обсуждают решения проблем. Доклад полезен постольку, поскольку выполняет роль ice-breaker-а и дает конкретный контекст для обсуждения.
Наибольшую пользу я, как спикер, дал слушателям, которые подошли ко мне после докладов и задали вопрос про свою проблему (а не про мою, уже решенную, и показаную на сцене).
––
Так уж вышло, что в этом году я оказался в составе руководителей ПК YACAMP.
Так что мы, наконец, ставим эксперимент 10-го августа в Москве: тусовка с минимумом докладов и максимальным фокусом на нетворкинге и совместном решении задач в реальном времени. И, конечно, вечеринка в конце.
Регистрация уже открыта. Она бесплатна, но с ограничением на количество мест (больше тысячи участников мы вряд ли провернём) и модерацией заявок.
Буду рад увидеть подписчиков и друзей :)
🔥19❤9👍4
О переработках
Переработки руководителей неэффективны.
Когда работаешь руками и дела идут недостаточно быстро, начать работать больше – интуитивный выход. В два раза больше сделаешь – в два раза больше результатов, больше пользы для бизнеса, выше вероятность хорошей оценки на перформанс-ревью и так далее. Стратегически, конечно, подход небезопасный (выгорание, хроническая усталость и прочее), но в моменте все мы так делали.
При управлении командой порой тоже возникает ощущение, что результатов недостаточно. И интуитивно хочется начать работать больше – раньше ведь это помогало.
Однако это – ошибка. Твои личные результаты теперь не очень важны. Что на самом деле важно – это перформанс всей команды. Если в команде 10 человек и один из них (ты) начинает работать в два раза больше работы, прирост перформанса составляет вовсе не X2. И даже не X1.5. И не X1.25…
А твоё внимание и качество коммуникаций (которые влияют на всех в команде) – ухудшается, причем быстро. Получается, что большие овертаймы для руководителя не работают не только стратегически, но и тактически.
А что же делать, если мы катастрофически не успеваем?
Думать о том, что поменять в работе команды, чтобы подтянуть тех десятерых человек, а не себя.
– Откачать или заменить андерперформеров?
– Сделать в два раза меньше встреч?
– Начать писать тесты раньше?
– Попробовать другой стэк?
– Что еще ускоряет всех, а не лично тебя?
Ищи точки повышения эффективности. Причем командной, а не своей. Личные овертаймы больше не действуют.
Переработки руководителей неэффективны.
Когда работаешь руками и дела идут недостаточно быстро, начать работать больше – интуитивный выход. В два раза больше сделаешь – в два раза больше результатов, больше пользы для бизнеса, выше вероятность хорошей оценки на перформанс-ревью и так далее. Стратегически, конечно, подход небезопасный (выгорание, хроническая усталость и прочее), но в моменте все мы так делали.
При управлении командой порой тоже возникает ощущение, что результатов недостаточно. И интуитивно хочется начать работать больше – раньше ведь это помогало.
Однако это – ошибка. Твои личные результаты теперь не очень важны. Что на самом деле важно – это перформанс всей команды. Если в команде 10 человек и один из них (ты) начинает работать в два раза больше работы, прирост перформанса составляет вовсе не X2. И даже не X1.5. И не X1.25…
А твоё внимание и качество коммуникаций (которые влияют на всех в команде) – ухудшается, причем быстро. Получается, что большие овертаймы для руководителя не работают не только стратегически, но и тактически.
А что же делать, если мы катастрофически не успеваем?
Думать о том, что поменять в работе команды, чтобы подтянуть тех десятерых человек, а не себя.
– Откачать или заменить андерперформеров?
– Сделать в два раза меньше встреч?
– Начать писать тесты раньше?
– Попробовать другой стэк?
– Что еще ускоряет всех, а не лично тебя?
Ищи точки повышения эффективности. Причем командной, а не своей. Личные овертаймы больше не действуют.
❤32👍22🔥11
О выгорании
Выгорание – не миф. Человек действительно может «доработаться» до черты, после которой желание и способность работать отпадёт с гарантией и надолго.
Не претендуя на научное обоснование, делюсь методом защиты, который помогает лично мне.
––
Степень выгорания более-менее коррелирует с количеством рабочих часов в день. Но не всегда.
С чем она кореллирует всегда – так это с соотношением «количество дерьмовой работы в день» / «количество приятной работы в день».
––
Что я делаю с этим выводом?
Размечаю задачи на день не только по степени сложности и продолжительности, а еще и по эмоциональной окраске. И выстраиваю день так, чтобы не иметь сильного перекоса в дерьмо.
Если «завтра» у меня свободно 6 часов времени в календаре, а в личном бэклоге – 6 хардкорных, потенциально конфликтных переговоров – я не подумаю планировать их все на этот день.
Я постараюсь реорганизовать график так, чтобы провести две-три хардовых встречи, а остальное время – использовать для более приятных дел (возможно, переместив их с других дней недели). Это помогает в конце дня не чувствовать себя прошедшим через ад. Именно «адские» дни заставляют меня и мой организм «думать», что работа – это что-то вредное (и постепенно выгорать и эмоционально дистанцироваться от неё).
––
Что делать, если дерьмовых задач не 6, а 60, и все нужно решить за эту неделю?
Экспериментировать со способами решения. Попробовать новую стратегию в переговорах. По-новому организовать архитектуру сервиса. Построить презентацию в стиле, на который ты не решался раньше (например, нарисовать ручкой на бумаге, отфоткать и слепить в слайд-шоу).
Если задача становится не только дерьмовой, но еще и интересной или экспериментальной, отношение к ней может поменяться. Ты, внезапно, начинаешь не только продираться через что-то невыносимое, но и учиться/пробовать новое, расширять своё понимание мира. А это – уже совсем другой опыт. Внезапно, он бывает намного приятнее и интереснее.
А что помогает тебе?
Выгорание – не миф. Человек действительно может «доработаться» до черты, после которой желание и способность работать отпадёт с гарантией и надолго.
Не претендуя на научное обоснование, делюсь методом защиты, который помогает лично мне.
––
Степень выгорания более-менее коррелирует с количеством рабочих часов в день. Но не всегда.
С чем она кореллирует всегда – так это с соотношением «количество дерьмовой работы в день» / «количество приятной работы в день».
––
Что я делаю с этим выводом?
Размечаю задачи на день не только по степени сложности и продолжительности, а еще и по эмоциональной окраске. И выстраиваю день так, чтобы не иметь сильного перекоса в дерьмо.
Если «завтра» у меня свободно 6 часов времени в календаре, а в личном бэклоге – 6 хардкорных, потенциально конфликтных переговоров – я не подумаю планировать их все на этот день.
Я постараюсь реорганизовать график так, чтобы провести две-три хардовых встречи, а остальное время – использовать для более приятных дел (возможно, переместив их с других дней недели). Это помогает в конце дня не чувствовать себя прошедшим через ад. Именно «адские» дни заставляют меня и мой организм «думать», что работа – это что-то вредное (и постепенно выгорать и эмоционально дистанцироваться от неё).
––
Что делать, если дерьмовых задач не 6, а 60, и все нужно решить за эту неделю?
Экспериментировать со способами решения. Попробовать новую стратегию в переговорах. По-новому организовать архитектуру сервиса. Построить презентацию в стиле, на который ты не решался раньше (например, нарисовать ручкой на бумаге, отфоткать и слепить в слайд-шоу).
Если задача становится не только дерьмовой, но еще и интересной или экспериментальной, отношение к ней может поменяться. Ты, внезапно, начинаешь не только продираться через что-то невыносимое, но и учиться/пробовать новое, расширять своё понимание мира. А это – уже совсем другой опыт. Внезапно, он бывает намного приятнее и интереснее.
А что помогает тебе?
❤30👍9🔥5