#ОтветыНаВопросы
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 1
Начнём с M1-руководителя:
1. Сколько времени тратить на людей
Каждым подчинённым нужно заниматься. Не просто спрашивать «а какой статус по проектам?». Надо погружаться до некоторой степени в проекты, которые они ведут, и помогать обратной связью по технике и процессам. Ещё – следить за эмоциональным состоянием. Ещё – людям, не достигшим своего потолка развития нужны планы развития. Ещё есть их отношения с другими людьми в команде
Я не думаю, что возможно эффективно выполнять работу руководителя, инвестируя меньше 10% времени в одного подчинённого.
На всякий случай: ты инвестируешь время в человека не только когда говоришь с ним, но и когда разбираешься в его проектах и думаешь, что ещё можно было бы сделать / улучшить и тд.
Получается, если в команде 3 человека – на работу с ними нужно 30% ресурса. Если людей у тебя 7 – 70%. Поэтому больше 6-7 подчинённых иметь не рекомендуется
2. Процессы и работа со стейкхолдерами
Помимо работы с подчинёнными у тебя есть процессы – планирования/дейлики/груминги и тд. Ну и, собственно, взаимодействие с менеджерами и другими заказчиками. Если команда не огромная и ты с ней не первый день – в 15-20% времени будешь укладываться
Процессы идут хорошо, если перформанс команды растёт, сходимость проектов растёт (или достигла уровня 70%+ и держится там) и люди в команде и за её пределами хорошо понимают, что происходит. Если это не верно – ты либо воюешь своими процессами не в ту сторону, либо недостаточно в них инвестируешь. По личному опыту – процессы идут хорошо не более, чем у 50% команд в компании просто потому, что это – сложно. А ещё – я ни разу не видел, чтобы процессы шли хорошо, если лид команды самоустранялся от них и всё отдавал продакту/проджекту/скрам-мастеру. Не потому, что люди – плохие, а потому, что надо уметь не только строить пайплайн работы и набор встреч, а ещё и сутево хорошо понимать, что делают ребята, вовлечённые в процесс.
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 1
Начнём с M1-руководителя:
1. Сколько времени тратить на людей
Каждым подчинённым нужно заниматься. Не просто спрашивать «а какой статус по проектам?». Надо погружаться до некоторой степени в проекты, которые они ведут, и помогать обратной связью по технике и процессам. Ещё – следить за эмоциональным состоянием. Ещё – людям, не достигшим своего потолка развития нужны планы развития. Ещё есть их отношения с другими людьми в команде
Я не думаю, что возможно эффективно выполнять работу руководителя, инвестируя меньше 10% времени в одного подчинённого.
На всякий случай: ты инвестируешь время в человека не только когда говоришь с ним, но и когда разбираешься в его проектах и думаешь, что ещё можно было бы сделать / улучшить и тд.
Получается, если в команде 3 человека – на работу с ними нужно 30% ресурса. Если людей у тебя 7 – 70%. Поэтому больше 6-7 подчинённых иметь не рекомендуется
2. Процессы и работа со стейкхолдерами
Помимо работы с подчинёнными у тебя есть процессы – планирования/дейлики/груминги и тд. Ну и, собственно, взаимодействие с менеджерами и другими заказчиками. Если команда не огромная и ты с ней не первый день – в 15-20% времени будешь укладываться
Процессы идут хорошо, если перформанс команды растёт, сходимость проектов растёт (или достигла уровня 70%+ и держится там) и люди в команде и за её пределами хорошо понимают, что происходит. Если это не верно – ты либо воюешь своими процессами не в ту сторону, либо недостаточно в них инвестируешь. По личному опыту – процессы идут хорошо не более, чем у 50% команд в компании просто потому, что это – сложно. А ещё – я ни разу не видел, чтобы процессы шли хорошо, если лид команды самоустранялся от них и всё отдавал продакту/проджекту/скрам-мастеру. Не потому, что люди – плохие, а потому, что надо уметь не только строить пайплайн работы и набор встреч, а ещё и сутево хорошо понимать, что делают ребята, вовлечённые в процесс.
❤12👍3🤗1
#ОтветыНаВопросы
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 2
3. Технические вопросы
Грубыми подсчетами получаем, что около 30% времени должно оставаться на технические задачи у лида первого уровня с командой в ~5 человек. И, до тех пор, пока ты находишься на таком уровне, это время стоит правда инвестировать в технику. Просто потому, что в противном случае ты по квалификации быстро отстанешь от своих прямых подчинённых и превратишься из руководителя команды в руководителя проектов
To Sum Up
50-20-30 люди-процессы-техника у лида средней команды первого уровня
––
Завтра выйдет продолжение про M2+ руководителей
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 2
3. Технические вопросы
Грубыми подсчетами получаем, что около 30% времени должно оставаться на технические задачи у лида первого уровня с командой в ~5 человек. И, до тех пор, пока ты находишься на таком уровне, это время стоит правда инвестировать в технику. Просто потому, что в противном случае ты по квалификации быстро отстанешь от своих прямых подчинённых и превратишься из руководителя команды в руководителя проектов
To Sum Up
50-20-30 люди-процессы-техника у лида средней команды первого уровня
––
Завтра выйдет продолжение про M2+ руководителей
🔥8👍4❤3😇1
#ОтветыНаВопросы
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 3
M2+ руководитель:
1. Сколько времени нужно тратить на людей
Для начала – 10% на прямого подчинённого, как у M1.
А ещё – у твоих прямых подчинённых теперь есть команды. И туда надо заглядывать, измерять температуру, помогать своим подчиненным-лидам находить проблемы, отмечать быстрорастущих непрямых подчинённых и т.д.
Добавим 3-5% налога на работу с командой. Итого – 15% на директ-репорта
2. Процессы и работа со стейкхолдерами
Процессная работа на этом уровне становится сложнее. В отличие от M1, где ты знаешь всех людей в команде и можешь быстро перепроверить подозрительные места / интуитивно «почувствовать», что у кого-то начались проблемы – на уровне M2 это больше не работает. Стейкхолдеров – много, команд – много, перепроверить каждого – невозможно.
А ещё – ты больше не можешь менять процесс за один день со словами: «ребята, с завтрашнего дня вот этот митинг проводим по-другому, а здесь меняем вот эту штуку; всем, у кого не выйдет – я помогу». Теперь у каждого твоего подчиненного есть свой процесс и своё сильное мнение о том, как правильно жить команде. Начиная с уровня M2 и выше тюнинг процессов – это переговоры и с подчиненными, не только со стейкхолдерами
Накидываем 5-10% на процессы к цифрам M1. По крайней мере, до тех пор, пока вы с командой очень плотно не сработались и не начали понимать друг друга с полуслова (а это – займёт время).
Итого – 25-30% на процессы
3. Техника
Всё оставшееся время, если оно есть.
Важно: нельзя оставлять 0. Тебе нужно хотя бы примерно понимать работу прямых подчинённых. Они уже – не разработчики, т. что ревьюить код не нужно. Но нужно успевать отсматривать архитектурные решения и успевать вместе с ними поговорить про большие стройки. Если ты этого не успеваешь – ты, опять же, из руководителя постепенно превращаешься в проджекта
To Sum Up:
У M2 руководителя, который не выстроил команду до идеального состояния, с четырьмя direct-reports:
60-30-10 люди-процессы-техника
Различные форс-мажоры могут перекашивать одну из цифр на несколько недель, но в среднем, когда дела идут ровно, соотношение примерно такое
Важно: 5 прямых подчиненных дадут тебе загрузку больше 100%. Я не встречал хороших M2, которые работают с текущей командой меньше года, имеют 5 прямых подчиненных и укладываются в 40-часовую рабочую неделю. Это примерно невозможно
Как следствие: норма прямых подчиненных у M2 всегда меньше – чем у M1. Выше по лестнице – правило сохраняется
––
Схемы M1 и M2 намеренно упрощены, тк на самом деле есть ещё найм, публичные активности, пятничное пиво с командой и тд. Они ситуативно отъедают проценты. Но с ними пост превратился бы в очень-много-буков-и-сложные-формулы или..в часовой подкаст, которых я пока не выпускаю)
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 3
M2+ руководитель:
1. Сколько времени нужно тратить на людей
Для начала – 10% на прямого подчинённого, как у M1.
А ещё – у твоих прямых подчинённых теперь есть команды. И туда надо заглядывать, измерять температуру, помогать своим подчиненным-лидам находить проблемы, отмечать быстрорастущих непрямых подчинённых и т.д.
Добавим 3-5% налога на работу с командой. Итого – 15% на директ-репорта
2. Процессы и работа со стейкхолдерами
Процессная работа на этом уровне становится сложнее. В отличие от M1, где ты знаешь всех людей в команде и можешь быстро перепроверить подозрительные места / интуитивно «почувствовать», что у кого-то начались проблемы – на уровне M2 это больше не работает. Стейкхолдеров – много, команд – много, перепроверить каждого – невозможно.
А ещё – ты больше не можешь менять процесс за один день со словами: «ребята, с завтрашнего дня вот этот митинг проводим по-другому, а здесь меняем вот эту штуку; всем, у кого не выйдет – я помогу». Теперь у каждого твоего подчиненного есть свой процесс и своё сильное мнение о том, как правильно жить команде. Начиная с уровня M2 и выше тюнинг процессов – это переговоры и с подчиненными, не только со стейкхолдерами
Накидываем 5-10% на процессы к цифрам M1. По крайней мере, до тех пор, пока вы с командой очень плотно не сработались и не начали понимать друг друга с полуслова (а это – займёт время).
Итого – 25-30% на процессы
3. Техника
Всё оставшееся время, если оно есть.
Важно: нельзя оставлять 0. Тебе нужно хотя бы примерно понимать работу прямых подчинённых. Они уже – не разработчики, т. что ревьюить код не нужно. Но нужно успевать отсматривать архитектурные решения и успевать вместе с ними поговорить про большие стройки. Если ты этого не успеваешь – ты, опять же, из руководителя постепенно превращаешься в проджекта
To Sum Up:
У M2 руководителя, который не выстроил команду до идеального состояния, с четырьмя direct-reports:
60-30-10 люди-процессы-техника
Различные форс-мажоры могут перекашивать одну из цифр на несколько недель, но в среднем, когда дела идут ровно, соотношение примерно такое
Важно: 5 прямых подчиненных дадут тебе загрузку больше 100%. Я не встречал хороших M2, которые работают с текущей командой меньше года, имеют 5 прямых подчиненных и укладываются в 40-часовую рабочую неделю. Это примерно невозможно
Как следствие: норма прямых подчиненных у M2 всегда меньше – чем у M1. Выше по лестнице – правило сохраняется
––
Схемы M1 и M2 намеренно упрощены, тк на самом деле есть ещё найм, публичные активности, пятничное пиво с командой и тд. Они ситуативно отъедают проценты. Но с ними пост превратился бы в очень-много-буков-и-сложные-формулы или..в часовой подкаст, которых я пока не выпускаю)
Telegram
Lead’s Notes
#ОтветыНаВопросы
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 1
Начнём с M1-руководителя:
1. Сколько времени тратить на людей
Каждым подчинённым нужно заниматься. Не просто спрашивать «а какой статус по проектам?». Надо погружаться…
Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 1
Начнём с M1-руководителя:
1. Сколько времени тратить на людей
Каждым подчинённым нужно заниматься. Не просто спрашивать «а какой статус по проектам?». Надо погружаться…
❤8🔥6👍1🎃1
Я устал от ограничений на размер поста и накатал статью на хабр: https://habr.com/ru/articles/813731/
Будем делить контент на два вида: покороче – в телеге, подлиннее – в журнале)
Кстати, говорят, лайки и комменты на хабре тоже помогают)
Будем делить контент на два вида: покороче – в телеге, подлиннее – в журнале)
Кстати, говорят, лайки и комменты на хабре тоже помогают)
Хабр
Совет руководителям
говорят, посты с картинками – веселее! Привет! Меня зовут Андрей и я руковожу IT-подразделением. Около 5 последних лет я работаю в бигтехе с командами от единиц до сотен инженеров. Так сложилось, что...
👍8🔥5❤4👏1👨💻1
Очевидное и не очень
Случалось ли тебе разозлиться на человека (или даже решить, что он, возможно, зря находится на своей позиции) из-за того, что он не понимает или не делает что-то, «очевидно» необходимое?
Например:
– Руководитель не проводит регулярные 1x1 с подчинёнными
– Разработчик отдаёт на ревью код без тестов
– Продакт приносит в команду задачи в последний момент, а в описании – только ссылка на фигму
– Проджект делает круглые глаза, когда ты спрашиваешь у него, где посмотреть гант по важному проекту
––
Мне и многим моим знакомым – случалось! Я даже слышал, что это влияло и влияет на оценки людей на ревью :)
Есть подход, который, во-первых, помогает больше любить людей, а во-вторых – повышает эффективность команды, улучшает отношения в коллективе и даёт пачку других плюсов:
––
Люди не рождаются с необходимым набором знаний. Бывают разработчики, которым ни один руководитель не сказал, что код без тестов – это опасно. Бывают тимлиды, которых не учили проводить 1х1-ы (правда, бывают!). Бывают продакты, которые всю предыдущую карьеру провели в стартапах, где все знали и понимали друг друга с полуслова и тикеты правда можно было оформлять картинками
У всех из нас, и у тебя – тоже, очень разный бэкграунд и вещи, которые тебе очевидны – запросто могут быть неочевидны другим людям. Более того, не исключено, что ты попал на управленческую позицию в текущей компании быстрее коллег отчасти потому, что набор «очевидных» тебе вещей идеально совпал с тем, что нужно в данной компании в данный момент времени. При смене работы ты легко можешь оказаться на месте сотрудника, не выполняющего «очевидных» вещей
Мне осознание этого очень помогло в развитии команды и отношениях с людьми. Надеюсь, поможет и тебе :)
Случалось ли тебе разозлиться на человека (или даже решить, что он, возможно, зря находится на своей позиции) из-за того, что он не понимает или не делает что-то, «очевидно» необходимое?
Например:
– Руководитель не проводит регулярные 1x1 с подчинёнными
– Разработчик отдаёт на ревью код без тестов
– Продакт приносит в команду задачи в последний момент, а в описании – только ссылка на фигму
– Проджект делает круглые глаза, когда ты спрашиваешь у него, где посмотреть гант по важному проекту
––
Мне и многим моим знакомым – случалось! Я даже слышал, что это влияло и влияет на оценки людей на ревью :)
Есть подход, который, во-первых, помогает больше любить людей, а во-вторых – повышает эффективность команды, улучшает отношения в коллективе и даёт пачку других плюсов:
Очевидным стоит считать только то, о чём ты явно рассказал человеку. Независимо от того, насколько базовым тебе кажется навык
––
Люди не рождаются с необходимым набором знаний. Бывают разработчики, которым ни один руководитель не сказал, что код без тестов – это опасно. Бывают тимлиды, которых не учили проводить 1х1-ы (правда, бывают!). Бывают продакты, которые всю предыдущую карьеру провели в стартапах, где все знали и понимали друг друга с полуслова и тикеты правда можно было оформлять картинками
У всех из нас, и у тебя – тоже, очень разный бэкграунд и вещи, которые тебе очевидны – запросто могут быть неочевидны другим людям. Более того, не исключено, что ты попал на управленческую позицию в текущей компании быстрее коллег отчасти потому, что набор «очевидных» тебе вещей идеально совпал с тем, что нужно в данной компании в данный момент времени. При смене работы ты легко можешь оказаться на месте сотрудника, не выполняющего «очевидных» вещей
Мне осознание этого очень помогло в развитии команды и отношениях с людьми. Надеюсь, поможет и тебе :)
👍16❤7🔥5👻1
#ОтветыНаВопросы
Как лиду растить людей? Как не быть боттлнеком в развитии своей команды?
Классные руководители всегда думают, как развивать команду. Один из базовых инструментов – обратная связь. Чем чаще – тем лучше. Для джуна или миддла – её можно эффективно давать каждую неделю и человек будет меняться.
Если успеваешь отсмотреть, что сделал сотрудник за последнее время, с ОС всё просто: насыпаешь комментов в код или дизайн-ревью + записываешь важные темы, о которых лучше детально поговорить голосом, и относишь их на 1х1.
Но бывают ситуации сложнее:
– Команда почти полностью состоит из джунов, детально отревьюить всех – ты не можешь (как я понимаю, кейс автора вопроса)
– В команде есть люди, разбирающиеся в своём стэке лучше руководителя. Так бывает, например, в кросс-функциональных командах.
––
Что делать?
Внедрять практику менторства
Менторство – это когда человек, не являющийся твоим руководителем, ревьюит твои решения и даёт обратную связь.
Запустить его можно быстро. Пройдись по другим лидам и поспрашивай, есть ли у них хорошие инженеры, которым интересно пообучать людей в обмен на твою (и твоей команды) положительную рекомендацию к перформанс-ревью. Часто такие люди находятся:
– Кто-то хочет вырасти в лида и ищет возможность набрать практику развития людей
– Кто-то вообще подумывает начать продавать платные консультации вовне, но хочет перед этим где-то потренироваться
– Кому-то – просто приятно помогать людям. Или человек для себя закрепляет уже усвоенное, объясняя это другим
Важно, что ментор не обязательно должен быть синьором или ведущим. Достаточно – чтобы он был опытнее обучаемого человека.
Найдя ментора, помоги ему выстроить коммуникацию со своим разработчиком + внеси в свой календарь периодические чекапы с самим ментором, чтобы узнавать о проблемах и прогрессе сотрудника.
А человек примет обратную связь не от руководителя?
1. В большинстве случаев – примет, если правильно и честно объяснить мотивацию: «Я хочу помочь тебе вырасти, но моего ресурса на это сейчас не хватает. А вот у Васи – есть возможность и он успешно работает в компании на позиции X. Переняв его экспертизу, ты сможешь вырасти. Более того – Вася может тебе помогать, а уволить тебя за косяки – не может, он же не руководитель) Как тебе идея?»
2. Если по какой-то причине сотрудник всё же идет в полный отказ – можно запроксировать обратную связь через себя.
––
На дистанции – конечно, стоит растить менторов и из людей в своей команде, если сейчас их нет 🙂
Делитесь в комментариях своими практиками!
Как лиду растить людей? Как не быть боттлнеком в развитии своей команды?
Классные руководители всегда думают, как развивать команду. Один из базовых инструментов – обратная связь. Чем чаще – тем лучше. Для джуна или миддла – её можно эффективно давать каждую неделю и человек будет меняться.
Если успеваешь отсмотреть, что сделал сотрудник за последнее время, с ОС всё просто: насыпаешь комментов в код или дизайн-ревью + записываешь важные темы, о которых лучше детально поговорить голосом, и относишь их на 1х1.
Но бывают ситуации сложнее:
– Команда почти полностью состоит из джунов, детально отревьюить всех – ты не можешь (как я понимаю, кейс автора вопроса)
– В команде есть люди, разбирающиеся в своём стэке лучше руководителя. Так бывает, например, в кросс-функциональных командах.
––
Что делать?
Внедрять практику менторства
Менторство – это когда человек, не являющийся твоим руководителем, ревьюит твои решения и даёт обратную связь.
Запустить его можно быстро. Пройдись по другим лидам и поспрашивай, есть ли у них хорошие инженеры, которым интересно пообучать людей в обмен на твою (и твоей команды) положительную рекомендацию к перформанс-ревью. Часто такие люди находятся:
– Кто-то хочет вырасти в лида и ищет возможность набрать практику развития людей
– Кто-то вообще подумывает начать продавать платные консультации вовне, но хочет перед этим где-то потренироваться
– Кому-то – просто приятно помогать людям. Или человек для себя закрепляет уже усвоенное, объясняя это другим
Важно, что ментор не обязательно должен быть синьором или ведущим. Достаточно – чтобы он был опытнее обучаемого человека.
Найдя ментора, помоги ему выстроить коммуникацию со своим разработчиком + внеси в свой календарь периодические чекапы с самим ментором, чтобы узнавать о проблемах и прогрессе сотрудника.
А человек примет обратную связь не от руководителя?
1. В большинстве случаев – примет, если правильно и честно объяснить мотивацию: «Я хочу помочь тебе вырасти, но моего ресурса на это сейчас не хватает. А вот у Васи – есть возможность и он успешно работает в компании на позиции X. Переняв его экспертизу, ты сможешь вырасти. Более того – Вася может тебе помогать, а уволить тебя за косяки – не может, он же не руководитель) Как тебе идея?»
2. Если по какой-то причине сотрудник всё же идет в полный отказ – можно запроксировать обратную связь через себя.
––
На дистанции – конечно, стоит растить менторов и из людей в своей команде, если сейчас их нет 🙂
Делитесь в комментариях своими практиками!
Telegram
Ivan Tankaev in Lead’s Notes Chat
Как Лиду растить людей?
Например в команде, где уже есть старшие сильные разработчики, такие разработчики могут помогать расти человеку и ему есть на кого посмотреть и соориентироваться. А что делать в команде, где самый опытный разработчик - это лид? Лид…
Например в команде, где уже есть старшие сильные разработчики, такие разработчики могут помогать расти человеку и ему есть на кого посмотреть и соориентироваться. А что делать в команде, где самый опытный разработчик - это лид? Лид…
👍4❤2🔥1🤓1
#ОтветыНаВопросы
Как синьору стать лидом? В какие навыки инвестировать?
Моё мнение про харды M1:
Нужно понимать, чем занимаются все твои люди. Иметь харды миддла и руководить синьорами – трэш. Быть миддл+ и руководить миддлами и джунами – норм. Поэтому иногда случаются промоушны в лиды небольших команд прямо из крепких миддлов
Если ты уже синьор – хардов тебе хватает.
Синьора от лида отличают управленческие скиллы. В них входят навыки:
– Переговоров
– Проектного управления
– Организации процессов
– Выдачи обратной связи людям
Как приобрести эти навыки и стать лидом
Прийти к своему лиду с запросом:
– Я хочу перейти в управление. Думаю, я достаточно компетентный инженер (скажи, пожалуйста, если не так и я доучусь) и я хотел бы приобрести другие недостающие для позиции навыки. Давай обсудим, как мне это сделать и на каких проектах себя проявить?
Вам с лидом нужно сделать две вещи:
1. Выбрать несколько подходящих проектов, которые ты сможешь провести «под ключ», забрав на себя менеджмент
2. Обсудить, как может выглядеть твоя первая команда потом, если ты справишься
Шаг 1 обычно прост: у лидов параллельно идет множество проектов, в каждом из которых нужны управленческие навыки. Если ты снимешь с руководителя часть работы и будешь прозрачно показывать, как она продвигается + принимать обратную связь, он обрадуется
Шаг 2 бывает сложным. Если размер команды твоего лида позволяет, он может отрезать тебе кусочек – пару инженеров в подчинение и зону ответственности. Я начинал с такой команды
Если команда маленькая – ему понадобится найти людей где-то ещё. Чтобы решить эту задачу, лучше привлечь руководителя следующего уровня (у которого много команд, людей, и, поверь, в этих командах есть проблемы).
Твоему прямому руководителю выгодно это сделать – он, запромоутив тебя, расширит свою зону ответственности и вырастет.
Если с шагом (1) всё ок, а в шаге (2) железно отказывают без конкретных претензий к навыкам, у меня плохие новости: пора искать другую работу. Кто-то же должен был тебе честно это сказать)
Как синьору стать лидом? В какие навыки инвестировать?
Моё мнение про харды M1:
Нужно понимать, чем занимаются все твои люди. Иметь харды миддла и руководить синьорами – трэш. Быть миддл+ и руководить миддлами и джунами – норм. Поэтому иногда случаются промоушны в лиды небольших команд прямо из крепких миддлов
Если ты уже синьор – хардов тебе хватает.
Синьора от лида отличают управленческие скиллы. В них входят навыки:
– Переговоров
– Проектного управления
– Организации процессов
– Выдачи обратной связи людям
Как приобрести эти навыки и стать лидом
Прийти к своему лиду с запросом:
– Я хочу перейти в управление. Думаю, я достаточно компетентный инженер (скажи, пожалуйста, если не так и я доучусь) и я хотел бы приобрести другие недостающие для позиции навыки. Давай обсудим, как мне это сделать и на каких проектах себя проявить?
Вам с лидом нужно сделать две вещи:
1. Выбрать несколько подходящих проектов, которые ты сможешь провести «под ключ», забрав на себя менеджмент
2. Обсудить, как может выглядеть твоя первая команда потом, если ты справишься
Шаг 1 обычно прост: у лидов параллельно идет множество проектов, в каждом из которых нужны управленческие навыки. Если ты снимешь с руководителя часть работы и будешь прозрачно показывать, как она продвигается + принимать обратную связь, он обрадуется
Шаг 2 бывает сложным. Если размер команды твоего лида позволяет, он может отрезать тебе кусочек – пару инженеров в подчинение и зону ответственности. Я начинал с такой команды
Если команда маленькая – ему понадобится найти людей где-то ещё. Чтобы решить эту задачу, лучше привлечь руководителя следующего уровня (у которого много команд, людей, и, поверь, в этих командах есть проблемы).
Твоему прямому руководителю выгодно это сделать – он, запромоутив тебя, расширит свою зону ответственности и вырастет.
Если с шагом (1) всё ок, а в шаге (2) железно отказывают без конкретных претензий к навыкам, у меня плохие новости: пора искать другую работу. Кто-то же должен был тебе честно это сказать)
🔥10👍7❤5😭1
Обещал пост про мотивацию перехода в управленческий трек и людей, которым стоит (или не стоит) это делать.
Сказано – сделано: https://habr.com/ru/articles/814911/
Лайки на хабре помогают не меньше лайков в канале – менеджерский контент там не всегда жалуют 🙂
Сказано – сделано: https://habr.com/ru/articles/814911/
Лайки на хабре помогают не меньше лайков в канале – менеджерский контент там не всегда жалуют 🙂
Хабр
Работа руководителя — а она правда тебе нужна?
У руководителей, как и у обычных специалистов, бывают самые разные проблемы: с хардами, софтами, мотивацией и прочим. Самая неприятная ситуация возникает, когда личные...
🔥19👍9❤7😴1
#ЧтоПосмотреть
Наступил вечер пятницы, так что..развлекательный контент!
За не-развлекательным – просто полистай канал вверх 🙂
Пост про книги уже был, теперь – про кино.
Айтишного, думаю, тебе хватило и за неделю, так что вечером будет не-айтишное.
––
Одержимость – анти-инструкция про работу с топ-перформерами и выгоранием. И в целом очень крутой фильм. А тебе доводилось сталкиваться с такими руководителями?)
Нефть – эпическая история про бизнес, неочевидные взаимоотношения с контрагентами, влияние всего этого на личность и..многое другое. Наткнулся случайно и получил много удовольствия и эмоций от просмотра.
Тёмные времена – фильм представляет собой долгое и тяжелое описание эпизода из жизни Черчилля. В нём, по сути, описан путь к принятию одного (одного, Карл!) решения. Если думаешь, что с тобой что-то не так и тебе очень тяжело договариваться с людьми – возможно, ты узнаешь, что не одинок в этой проблеме 🙂
Наступил вечер пятницы, так что..развлекательный контент!
За не-развлекательным – просто полистай канал вверх 🙂
Пост про книги уже был, теперь – про кино.
Айтишного, думаю, тебе хватило и за неделю, так что вечером будет не-айтишное.
––
Одержимость – анти-инструкция про работу с топ-перформерами и выгоранием. И в целом очень крутой фильм. А тебе доводилось сталкиваться с такими руководителями?)
Нефть – эпическая история про бизнес, неочевидные взаимоотношения с контрагентами, влияние всего этого на личность и..многое другое. Наткнулся случайно и получил много удовольствия и эмоций от просмотра.
Тёмные времена – фильм представляет собой долгое и тяжелое описание эпизода из жизни Черчилля. В нём, по сути, описан путь к принятию одного (одного, Карл!) решения. Если думаешь, что с тобой что-то не так и тебе очень тяжело договариваться с людьми – возможно, ты узнаешь, что не одинок в этой проблеме 🙂
Telegram
Lead’s Notes
#ЧтоПочитать
«Если б про управление было что-нибудь хорошее почитать – я бы уже и сам давно почитал!» (с)
––
Я не читал ни одной очень крутой книги по управлению.
Но есть несколько не совсем кринжовых / содержащих полезные мысли.
По пятницам я ленюсь,…
«Если б про управление было что-нибудь хорошее почитать – я бы уже и сам давно почитал!» (с)
––
Я не читал ни одной очень крутой книги по управлению.
Но есть несколько не совсем кринжовых / содержащих полезные мысли.
По пятницам я ленюсь,…
👍9❤3🔥2💋1
Как провести 1х1 с человеком, перекладывающим ответственность
Часть 1.
Продолжаем отвечать на вопросы.
Бывает, что сотрудник затягивает сроки, проваливает проекты, а потом говорит:
Cоветую прозрачно сказать сотруднику, что его работа – не просто написать свою часть кода. Его работа – это:
a. Писать свою часть кода
b. Поддерживать у заказчиков актуальную информацию о времени сходимости
c. Сделать всё возможное, чтобы код оказался в продакшене
d. Если внешние обстоятельства мешают пункту (c), настойчиво потыкать в них палочкой. Если не действует – звать на помощь руководителя, чтобы он помог пробить стену
Пункт (а) – cамый простой.
(b) – сложнее. Надо ежедневно проверять, уверен ли ты, что задача доедет в срок. Если нет, стоит сразу поговорить со стейкхолдерами.
Здесь важно донести, что продолб сроков, озвученный за день до дедлайна – это косяк. Продолб сроков, озвученный за две недели – не косяк, а нормальная работа в условиях изменяющегося мира.
Пункты (c) и (d) обязательно объяснять на примерах. Для этого нужно вместе с инженером рассмотреть несколько свежих кейсов и показать, как можно было поступить:
Разобрав примеры, договорись с человеком поменять подход к работе и обсудить новые проблемы на следующей встрече.
Иногда – человек окажет сопротивление и договариваться об этом не захочет.
Значит, надо разбираться в причинах.
Часть 1.
Продолжаем отвечать на вопросы.
Бывает, что сотрудник затягивает сроки, проваливает проекты, а потом говорит:
Тут смежники задачу вовремя не сдали. А здесь – в библиотеке баг нашёлся, я его две недели дебажил. А потом у меня похмелье было. Затем – ноутбук в озеро уронил. А после – дизайнера автобус сбил. Так что мне не лещ, а орден мужества полагается. Скажи спасибо, что я живым выбрался!
Cоветую прозрачно сказать сотруднику, что его работа – не просто написать свою часть кода. Его работа – это:
a. Писать свою часть кода
b. Поддерживать у заказчиков актуальную информацию о времени сходимости
c. Сделать всё возможное, чтобы код оказался в продакшене
d. Если внешние обстоятельства мешают пункту (c), настойчиво потыкать в них палочкой. Если не действует – звать на помощь руководителя, чтобы он помог пробить стену
Пункт (а) – cамый простой.
(b) – сложнее. Надо ежедневно проверять, уверен ли ты, что задача доедет в срок. Если нет, стоит сразу поговорить со стейкхолдерами.
Здесь важно донести, что продолб сроков, озвученный за день до дедлайна – это косяк. Продолб сроков, озвученный за две недели – не косяк, а нормальная работа в условиях изменяющегося мира.
Пункты (c) и (d) обязательно объяснять на примерах. Для этого нужно вместе с инженером рассмотреть несколько свежих кейсов и показать, как можно было поступить:
1. Здесь – стоило прийти и попинать Петю, напомнить ему про дедлайн и вашу договорённость. Не сработало – эскалируешь в меня
2. Тут, как только ты понял, что библиотека не работает, стоило остановиться, часик потратить на описание вариантов выхода из ситуации и альтернатив, и в тот же день прийти со мной об этом поговорить
3. Здесь – можно было написать дизайнеру. Не помогло – эскалируешь
Разобрав примеры, договорись с человеком поменять подход к работе и обсудить новые проблемы на следующей встрече.
Иногда – человек окажет сопротивление и договариваться об этом не захочет.
Значит, надо разбираться в причинах.
👍11🔥9❤6🍾1
Как провести 1х1 с человеком, перекладывающим ответственность
Часть 2.
Если при разговоре, описанном в предыдущем посте, возникло сопротивление, разберись в мотивации сотрудника:
Пообещай любую необходимую помощь и поддержку, если такое начнется. Ещё, если такого не было: пообещай проговорить на всю команду, что горизонтально приходить друг к другу, напоминать о договоренностях и т.д. – нормально и правильно. И скажи, что даже если человек где-то разок/другой словит кривой взгляд от людей, которым придется из-за него работать, это не отразится негативно на перформанс-ревью.
В большинстве известных мне корпораций это – физически невозможно. Людей и взаимосвязей слишком много, технических моментов – тоже. Если лиды будут пытаться догадываться о всех возможных проблемах и затыках, они просто сойдут с ума и не смогут ничем и никому помочь. Может звучать грустно, но это – реальность. И об этом ты можешь честно рассказывать.
Исход, к которому нужно быть морально готовым. Если в твоей команде просто писать код – нельзя, а человек хочет только этого, вы не сможете работать вместе.
Если разраб технически очень крутой и в компании есть глубокие инфраструктурные команды с небольшой численностью сотрудников и малым количеством коммуникаций – можно предложить ротацию.
Если нет – придется, рано или поздно, искать другую работу. Иначе профита не будет ни для кого: ты не сможешь положиться на сотрудника и ожидать, что он будет приносить результат (закончится или безумным микроменеджментом, или провалами всех порученных проектов), а сотрудник – не сможет получить положительную оценку на перформанс ревью, нормальную зарплату/премию и тд. Если договориться никак не выходит – надо готовить план расставания.
Часть 2.
Если при разговоре, описанном в предыдущем посте, возникло сопротивление, разберись в мотивации сотрудника:
Боюсь, что смежники пошлют меня куда подальше
Пообещай любую необходимую помощь и поддержку, если такое начнется. Ещё, если такого не было: пообещай проговорить на всю команду, что горизонтально приходить друг к другу, напоминать о договоренностях и т.д. – нормально и правильно. И скажи, что даже если человек где-то разок/другой словит кривой взгляд от людей, которым придется из-за него работать, это не отразится негативно на перформанс-ревью.
А почему менеджеры/руководители сами не могут отследить все проблемы всех сотрудников. Можно я только код буду писать, и всё?
В большинстве известных мне корпораций это – физически невозможно. Людей и взаимосвязей слишком много, технических моментов – тоже. Если лиды будут пытаться догадываться о всех возможных проблемах и затыках, они просто сойдут с ума и не смогут ничем и никому помочь. Может звучать грустно, но это – реальность. И об этом ты можешь честно рассказывать.
Нет, все равно не буду. Я согласен только писать код и ничего кроме этого
Исход, к которому нужно быть морально готовым. Если в твоей команде просто писать код – нельзя, а человек хочет только этого, вы не сможете работать вместе.
Если разраб технически очень крутой и в компании есть глубокие инфраструктурные команды с небольшой численностью сотрудников и малым количеством коммуникаций – можно предложить ротацию.
Если нет – придется, рано или поздно, искать другую работу. Иначе профита не будет ни для кого: ты не сможешь положиться на сотрудника и ожидать, что он будет приносить результат (закончится или безумным микроменеджментом, или провалами всех порученных проектов), а сотрудник – не сможет получить положительную оценку на перформанс ревью, нормальную зарплату/премию и тд. Если договориться никак не выходит – надо готовить план расставания.
Telegram
Lead’s Notes
Как провести 1х1 с человеком, перекладывающим ответственность
Часть 1.
Продолжаем отвечать на вопросы.
Бывает, что сотрудник затягивает сроки, проваливает проекты, а потом говорит:
Тут смежники задачу вовремя не сдали. А здесь – в библиотеке баг нашёлся…
Часть 1.
Продолжаем отвечать на вопросы.
Бывает, что сотрудник затягивает сроки, проваливает проекты, а потом говорит:
Тут смежники задачу вовремя не сдали. А здесь – в библиотеке баг нашёлся…
🔥8👍7❤4🍓1
Отличие сильного руководителя от слабого
Доброе утро!
Не любишь понедельники? Вот тебе инсайт вместо кофе:
– Когда я впервые увольнял сотрудника, я не спал всю ночь. Встреча прошла ужасно и закончилась чуть ли не истерикой (человек был непростой), но она закончилась и команда, очистившись, вздохнула с облегчением.
– Когда я впервые шел спорить с директором по поводу курса компании, я не спал всю ночь. Встреча прошла безрезультатно, но меня не уволили и я дважды повторил – результат появился.
– Когда я впервые закрывал продукт и распускал команду, я не спал всю ночь. Кто-то принял новости стойко, а у кого-то за время встречи дважды менялся цвет лица. Но по итогу – у большинства людей всё хорошо с карьерой и мы поддерживаем отношения.
Если успешный человек говорит со сцены, что он всегда уверен в себе, знает, что делать и тебе надо быть таким же – он либо психически нездоров, либо врёт. Нельзя быть уверенным, когда всё вокруг взрывается. Но быть уверенным – не обязательно. Если не можешь действовать с уверенностью, действуй без неё. Это – нормально. Кроме тебя – некому.
Ты больше, чем твои эмоции. Команда их забудет или простит. Команда запомнит твои действия.
А теперь – делай то, что правильно. Удачной недели!
Доброе утро!
Не любишь понедельники? Вот тебе инсайт вместо кофе:
Сильные руководители в сложных ситуациях чувствуют себя точно так же, как слабые.
Отличие только в том, следуют ли за эмоциями действия.
– Когда я впервые увольнял сотрудника, я не спал всю ночь. Встреча прошла ужасно и закончилась чуть ли не истерикой (человек был непростой), но она закончилась и команда, очистившись, вздохнула с облегчением.
– Когда я впервые шел спорить с директором по поводу курса компании, я не спал всю ночь. Встреча прошла безрезультатно, но меня не уволили и я дважды повторил – результат появился.
– Когда я впервые закрывал продукт и распускал команду, я не спал всю ночь. Кто-то принял новости стойко, а у кого-то за время встречи дважды менялся цвет лица. Но по итогу – у большинства людей всё хорошо с карьерой и мы поддерживаем отношения.
Если успешный человек говорит со сцены, что он всегда уверен в себе, знает, что делать и тебе надо быть таким же – он либо психически нездоров, либо врёт. Нельзя быть уверенным, когда всё вокруг взрывается. Но быть уверенным – не обязательно. Если не можешь действовать с уверенностью, действуй без неё. Это – нормально. Кроме тебя – некому.
Ты больше, чем твои эмоции. Команда их забудет или простит. Команда запомнит твои действия.
А теперь – делай то, что правильно. Удачной недели!
🔥36❤13👍8🏆1
Экспериментируем с форматами
Сегодня – играем в сарказм!
Инвертируем содержимое и идём к успеху :)
https://habr.com/ru/articles/815923/
Ваши лайки на хабре – согревают и помогают)
Сегодня – играем в сарказм!
Инвертируем содержимое и идём к успеху :)
https://habr.com/ru/articles/815923/
Ваши лайки на хабре – согревают и помогают)
Хабр
Как руководителю превратить жизнь команды в ад и надёжно заблокировать себе дальнейший рост. Пошаговый гайд
Статья является шуткой и представляет собой анти-стратегию к успеху для тимлида. Если читателям понравится, выпущу анти-гайд для управленцев более высоких уровней (руководителей тимлидов). Если ты уже...
🔥9👍7❤2👏2⚡1
#ОтветыНаВопросы
Как поддерживать отношения в распределённой команде?
Удалёнка – вызов для менеджера и отношений в команде.
Заменить коммуникации и отношения, возникающие между людьми, по 8 часов в день проводящих рядом, тяжело, но побороться за них – можно 🙂
Вот, что помогало мне:
Пятничное пиво
Я раньше думал, что выпить и пообщаться можно только лично в баре или в офисе. По зуму – странно.
А потом наступил ковид и..знаете – не так и плохо. Я потестировал на себе и друзьях, потом на команде – и сработало. Начало пережить непросто, но, если не дать разговорам провиснуть и взять с собой любимые напитки, всё будет в порядке. Через 30-60 минут расстояние ощущается не так остро и барьеры частично растворяются. А ещё – в конце не нужно ехать домой на такси 🙂
Важно: в компании должен быть хотя бы один человек, который на старте пофасилитирует беседы, расскажет забавную личную историю и тд. А дальше – всё получится
Онлайн-игры
Какая игра – не очень важно, главное – найти человека, который возьмет на себя задачу пообщаться с командой и предложить во что сыграть.
Некоторые ребята могут бодро и весело порубиться в CS или доту после работы.
Кому-то заходят аналоги классических настолок вроде codenames, шпиона или мафии.
Можно выбрать игру исходя из знаний об участниках команды или банально – устроить голосование.
Пространство для неформального общения
Если в команде ещё нет чатика, в который по средам кидают жаб, по вторникам – обмениваются лучшими событиями за прошедшую неделю (я не шучу, практика называется «happy tuesday»), а каждый второй понедельник – постят своих домашних животных – стоит попробовать
В нём же можно делиться впечатлениями про кино/книги/whatever
Если чатик стабильно живёт – можно прицепить к нему зум/дискорд/whatever-комнату, в которую можно зайти, например, каждый день во время обеда/ужина и поболтать с теми, кто на связи
Локальные хабы
Если в одном городе у тебя несколько человек (например, треть команды), будет классно организовать ребят встречаться хотя бы пару раз в неделю. Например, понедельник – день планирования и брейншторма, пятница – день, перетекающий в очную тусовку
Чтобы работало хорошо, надо выбрать проактивного человека «на месте», который поможет пофасилитировать мероприятия.
Быть ближе к дезинтегрированным людям
Этим советом не нужно насиловать лютых интровертов, которые специально уехали далеко, чтобы не видеть людей. Такого человека полноценно не интегрируешь. Если возможно – подбери ему зону ответственности, не требующую регулярных коммуникаций, и дай спокойно жить 🙂
Иногда в команду приходят новички
Иногда – старички дистанцируются
Если кто-то «откалывается», лучшее, что можно сделать – начать лично больше общаться с человеком: говорить о происходящем вокруг, делиться проблемами команды и компании, рассказывать личные истории и интересоваться, как у него идут дела. В идеале – созваниваться, чтобы это обсудить
Некоторые руководители в первый месяц общаются с новичками каждый день. По 15-20 минут, но всё время на связи, причём голосом.
В среднем, если человек чувствует, что люди в команде ценят его мнение по насущным вопросам и доверяют ему достаточно, чтобы говорить о своей жизни за пределами работы, он постепенно открывается команде
Общение лучше начинать руководителю или ментору, а позже – постепенно включать сотрудника в более широкие круги коммуникаций
А какие практики работают у вас?
Как поддерживать отношения в распределённой команде?
Удалёнка – вызов для менеджера и отношений в команде.
Заменить коммуникации и отношения, возникающие между людьми, по 8 часов в день проводящих рядом, тяжело, но побороться за них – можно 🙂
Вот, что помогало мне:
Пятничное пиво
Я раньше думал, что выпить и пообщаться можно только лично в баре или в офисе. По зуму – странно.
А потом наступил ковид и..знаете – не так и плохо. Я потестировал на себе и друзьях, потом на команде – и сработало. Начало пережить непросто, но, если не дать разговорам провиснуть и взять с собой любимые напитки, всё будет в порядке. Через 30-60 минут расстояние ощущается не так остро и барьеры частично растворяются. А ещё – в конце не нужно ехать домой на такси 🙂
Важно: в компании должен быть хотя бы один человек, который на старте пофасилитирует беседы, расскажет забавную личную историю и тд. А дальше – всё получится
Онлайн-игры
Какая игра – не очень важно, главное – найти человека, который возьмет на себя задачу пообщаться с командой и предложить во что сыграть.
Некоторые ребята могут бодро и весело порубиться в CS или доту после работы.
Кому-то заходят аналоги классических настолок вроде codenames, шпиона или мафии.
Можно выбрать игру исходя из знаний об участниках команды или банально – устроить голосование.
Пространство для неформального общения
Если в команде ещё нет чатика, в который по средам кидают жаб, по вторникам – обмениваются лучшими событиями за прошедшую неделю (я не шучу, практика называется «happy tuesday»), а каждый второй понедельник – постят своих домашних животных – стоит попробовать
В нём же можно делиться впечатлениями про кино/книги/whatever
Если чатик стабильно живёт – можно прицепить к нему зум/дискорд/whatever-комнату, в которую можно зайти, например, каждый день во время обеда/ужина и поболтать с теми, кто на связи
Локальные хабы
Если в одном городе у тебя несколько человек (например, треть команды), будет классно организовать ребят встречаться хотя бы пару раз в неделю. Например, понедельник – день планирования и брейншторма, пятница – день, перетекающий в очную тусовку
Чтобы работало хорошо, надо выбрать проактивного человека «на месте», который поможет пофасилитировать мероприятия.
Быть ближе к дезинтегрированным людям
Этим советом не нужно насиловать лютых интровертов, которые специально уехали далеко, чтобы не видеть людей. Такого человека полноценно не интегрируешь. Если возможно – подбери ему зону ответственности, не требующую регулярных коммуникаций, и дай спокойно жить 🙂
Иногда в команду приходят новички
Иногда – старички дистанцируются
Если кто-то «откалывается», лучшее, что можно сделать – начать лично больше общаться с человеком: говорить о происходящем вокруг, делиться проблемами команды и компании, рассказывать личные истории и интересоваться, как у него идут дела. В идеале – созваниваться, чтобы это обсудить
Некоторые руководители в первый месяц общаются с новичками каждый день. По 15-20 минут, но всё время на связи, причём голосом.
В среднем, если человек чувствует, что люди в команде ценят его мнение по насущным вопросам и доверяют ему достаточно, чтобы говорить о своей жизни за пределами работы, он постепенно открывается команде
Общение лучше начинать руководителю или ментору, а позже – постепенно включать сотрудника в более широкие круги коммуникаций
А какие практики работают у вас?
❤12🔥7👍4🤣1
Вечерний пост для больших руководителей, которые давно не удивлялись
Однажды в канале уже был пост про погружение в детали.
Сегодня – пара кейсов из личного опыта, которая должна замотивировать к этому ещё больше:)
Когда в моей команде было уже более 50 человек (в среднем – 5-7 на тимлида), я поймал себя на мысли, что давненько в код многих команд не заглядывал. Не в формате ежедневного ревью, разумеется, а хоть иногда, чтобы контакт с реальностью не потерять. И заглянул…
1. Стартапная команда
Стейкхолдеры переживают, что мы не очень быстро наращиваем функционал продукта. А в команде – вроде не бездельники.
Открываю репозиторий. И, к своему ужасу, вижу очень хороший и расширяемый код! Модульные тесты. Функциональные тесты. Интерфейсы. Фабрики. Документация.
Проект – в стадии прототипа, мы буквально не знаем при этом, будут ли у него пользователи! Мы, возможно, всё это выбросим через месяц 🙂
Рассказал команде и руководителям про этапы жизни компаний, фокусы внимания и тд. Очевидного не бывает, помнишь?
2. Команда большого продукта
Стейкхолдеры переживают, что мы подолгу тестируем фичи, а в итоге – и медленно, и с кучей багов получается. А в команде – опять же, не дураки.
Открываю парочку пулл-реквестов. Код как код. Тестов меньше, чем я бы ожидал, но..вроде не критично мало.
Прихожу посмотреть, как инженер работает над задачей:
– Пишем код
– Пишем тесты (ну не TDD и не TDD, подумаешь)
– Начинаем сборку в CI и выкатываем в тестовое окружение
– Отдаем на ревью
…
– Стоп! Сразу в CI и тестинг? А локальная сборка? А модульные/функциональные тесты – их же годами писали, сервис старый, нифига ты это не проверишь сам руками сейчас, и твой QA не проверит.
– Ну да. Половина тестов не работает локально, но запускается в CI, а другая половина – вообще не работает у сервиса
– И ты всё время так живешь? Это ж безумно медленно и опасно
– Ну..да
– А чего не жалуешься?
– А у нас давно так и было, я думал, это нормально (контекст: в команде за год по разным причинам сменилось множество людей + она выросла)
Пошли разбираться с тестами и сборкой. Снова вспоминаем, что очевидное тебе – не обязательно очевидно всем
Ну как, появилась мотивация ещё раз заглянуть под капот своей команды?
Однажды в канале уже был пост про погружение в детали.
Сегодня – пара кейсов из личного опыта, которая должна замотивировать к этому ещё больше:)
Когда в моей команде было уже более 50 человек (в среднем – 5-7 на тимлида), я поймал себя на мысли, что давненько в код многих команд не заглядывал. Не в формате ежедневного ревью, разумеется, а хоть иногда, чтобы контакт с реальностью не потерять. И заглянул…
1. Стартапная команда
Стейкхолдеры переживают, что мы не очень быстро наращиваем функционал продукта. А в команде – вроде не бездельники.
Открываю репозиторий. И, к своему ужасу, вижу очень хороший и расширяемый код! Модульные тесты. Функциональные тесты. Интерфейсы. Фабрики. Документация.
Проект – в стадии прототипа, мы буквально не знаем при этом, будут ли у него пользователи! Мы, возможно, всё это выбросим через месяц 🙂
Рассказал команде и руководителям про этапы жизни компаний, фокусы внимания и тд. Очевидного не бывает, помнишь?
2. Команда большого продукта
Стейкхолдеры переживают, что мы подолгу тестируем фичи, а в итоге – и медленно, и с кучей багов получается. А в команде – опять же, не дураки.
Открываю парочку пулл-реквестов. Код как код. Тестов меньше, чем я бы ожидал, но..вроде не критично мало.
Прихожу посмотреть, как инженер работает над задачей:
– Пишем код
– Пишем тесты (ну не TDD и не TDD, подумаешь)
– Начинаем сборку в CI и выкатываем в тестовое окружение
– Отдаем на ревью
…
– Стоп! Сразу в CI и тестинг? А локальная сборка? А модульные/функциональные тесты – их же годами писали, сервис старый, нифига ты это не проверишь сам руками сейчас, и твой QA не проверит.
– Ну да. Половина тестов не работает локально, но запускается в CI, а другая половина – вообще не работает у сервиса
– И ты всё время так живешь? Это ж безумно медленно и опасно
– Ну..да
– А чего не жалуешься?
– А у нас давно так и было, я думал, это нормально (контекст: в команде за год по разным причинам сменилось множество людей + она выросла)
Пошли разбираться с тестами и сборкой. Снова вспоминаем, что очевидное тебе – не обязательно очевидно всем
Ну как, появилась мотивация ещё раз заглянуть под капот своей команды?
Telegram
Lead’s Notes
Ошибки растущих лидов: процессы vs детали
Часто лиды, умеющие круто настраивать процессы, отличающие скрам от канбана и velocity от capacity – это люди, управляющие немаленькими командами (10+ человек). На меньшем масштабе можно справиться и уровнем: «держу…
Часто лиды, умеющие круто настраивать процессы, отличающие скрам от канбана и velocity от capacity – это люди, управляющие немаленькими командами (10+ человек). На меньшем масштабе можно справиться и уровнем: «держу…
👍8❤4🔥2🌚1
#Пятничное
По традиции – развлекательный контент в пятницу вечером.
1. Old but gold, «Теория Жоп»
https://habr.com/ru/articles/593173/
Теория смешная и, одновременно, чудовищно жизненная.
Осторожно: при прочтении можно испытать серию вьетнамских флешбеков!
––
2. Как VK ускоряли работу приложения
https://www.youtube.com/watch?v=KDcOa_QbSQ0
Это – не реклама VK.
Это – история, которая может замотивировать работать над целью до тех пор, пока тебе не покажется, что стало «достаточно хорошо», а не до тех пор, пока у тебя не закончатся очевидные решения
Ребята начинают с пагинации и картинок, но позднее доходят до..алгоритмов сжатия, протоколов передачи данных и изменения сетевого стэка приложения
Если тебе было страшно внедрять новый фреймворк – посмотри это видео и больше не бойся 🙂
––
3. Как снимали «Матрицу»
https://habr.com/ru/companies/first/articles/724300/
Можно воспринимать как историю о знакомых тебе проблемах, с которыми встречаются менеджеры из совсем иной отрасли:
– Подбор команды
– Костыли
– Бюджет
– Неочевидные решения
А можно – просто как развлекательный текст про продакшен крутого кино в 90-е/2000-е годы. В любом случае – по-моему, интересно!
По традиции – развлекательный контент в пятницу вечером.
1. Old but gold, «Теория Жоп»
https://habr.com/ru/articles/593173/
Теория смешная и, одновременно, чудовищно жизненная.
Осторожно: при прочтении можно испытать серию вьетнамских флешбеков!
––
2. Как VK ускоряли работу приложения
https://www.youtube.com/watch?v=KDcOa_QbSQ0
Это – не реклама VK.
Это – история, которая может замотивировать работать над целью до тех пор, пока тебе не покажется, что стало «достаточно хорошо», а не до тех пор, пока у тебя не закончатся очевидные решения
Ребята начинают с пагинации и картинок, но позднее доходят до..алгоритмов сжатия, протоколов передачи данных и изменения сетевого стэка приложения
Если тебе было страшно внедрять новый фреймворк – посмотри это видео и больше не бойся 🙂
––
3. Как снимали «Матрицу»
https://habr.com/ru/companies/first/articles/724300/
Можно воспринимать как историю о знакомых тебе проблемах, с которыми встречаются менеджеры из совсем иной отрасли:
– Подбор команды
– Костыли
– Бюджет
– Неочевидные решения
А можно – просто как развлекательный текст про продакшен крутого кино в 90-е/2000-е годы. В любом случае – по-моему, интересно!
🔥8👍5❤2🐳1
Карта Контента 👇
1. Из синьора в управленцы: нужно ли это вообще и как вырасти
2. Майндсет менеджера: память, очевидное и не очень, getting shit done, избегание консервной банки
3. Что почитать и посмотреть: раз, два, три, четыре, пять
4. Карьерный рост M1 -> M2: раз, два
5. Небольшие советы про людей: увольняй, пингуй, нанимай, задавай вопросы
6. Работа с командой: отношения, матричные роли, менторство, удалёнка, мотивация
7. Работа с задачами: приоритизируй, планируй, ставь дедлайны
8. Эмоциональное состояние руководителя: раз, два
9. Детали – важны: раз, два
10. Про ответственность у подчинённых: раз, два
11. Баланс техника/пипл-менеджмент: раз, два, три
12. Статейки на хабре: о принятии решений, о слишком жестких рамках, вредные советы руководителю
Самое новое в канале – отстаёт от оглавления :(
––
Консультации
Записаться на личную консультацию: тут
1. Из синьора в управленцы: нужно ли это вообще и как вырасти
2. Майндсет менеджера: память, очевидное и не очень, getting shit done, избегание консервной банки
3. Что почитать и посмотреть: раз, два, три, четыре, пять
4. Карьерный рост M1 -> M2: раз, два
5. Небольшие советы про людей: увольняй, пингуй, нанимай, задавай вопросы
6. Работа с командой: отношения, матричные роли, менторство, удалёнка, мотивация
7. Работа с задачами: приоритизируй, планируй, ставь дедлайны
8. Эмоциональное состояние руководителя: раз, два
9. Детали – важны: раз, два
10. Про ответственность у подчинённых: раз, два
11. Баланс техника/пипл-менеджмент: раз, два, три
12. Статейки на хабре: о принятии решений, о слишком жестких рамках, вредные советы руководителю
Самое новое в канале – отстаёт от оглавления :(
––
Консультации
Записаться на личную консультацию: тут
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Lead’s Notes
Обещал пост про мотивацию перехода в управленческий трек и людей, которым стоит (или не стоит) это делать.
Сказано – сделано: https://habr.com/ru/articles/814911/
Лайки на хабре помогают не меньше лайков в канале – менеджерский контент там не всегда жалуют…
Сказано – сделано: https://habr.com/ru/articles/814911/
Лайки на хабре помогают не меньше лайков в канале – менеджерский контент там не всегда жалуют…
👍19🔥9❤3😍1
Lead’s Notes pinned «Карта Контента 👇 1. Из синьора в управленцы: нужно ли это вообще и как вырасти 2. Майндсет менеджера: память, очевидное и не очень, getting shit done, избегание консервной банки 3. Что почитать и посмотреть: раз, два, три, четыре, пять 4. Карьерный рост…»
О важном
Если у тебя за прошедшую неделю прочитаны все чатики, вылизаны все тикеты, сделано 10 коммитов в любимый опенсорс проект, то..возможно, у тебя проблемы с приоритетами.
Один из простых, как палка, но очень ценных инструментов менеджмента – матрица Эйзенхауэра.
Суть – на картинке. Почитать – что угодно из гугла или хабры.
Как приоритизировать:
1. Важное и срочное – сразу делать.
2. Важное и несрочное – делать или, как минимум, сразу планировать.
3. Неважное и срочное – делегировать или, хотя бы, фиксировать время, которое ты этому уделяешь.
4. Неважное и несрочное – честно признаться себе, что такие задачи – не более, чем развлечение. Выполнять только для собственного удовольствия или не выполнять совсем.
Мне – помогает, а тебе?
Если у тебя за прошедшую неделю прочитаны все чатики, вылизаны все тикеты, сделано 10 коммитов в любимый опенсорс проект, то..возможно, у тебя проблемы с приоритетами.
Один из простых, как палка, но очень ценных инструментов менеджмента – матрица Эйзенхауэра.
Суть – на картинке. Почитать – что угодно из гугла или хабры.
Как приоритизировать:
1. Важное и срочное – сразу делать.
2. Важное и несрочное – делать или, как минимум, сразу планировать.
3. Неважное и срочное – делегировать или, хотя бы, фиксировать время, которое ты этому уделяешь.
4. Неважное и несрочное – честно признаться себе, что такие задачи – не более, чем развлечение. Выполнять только для собственного удовольствия или не выполнять совсем.
Мне – помогает, а тебе?
🔥18👍13❤3🗿2🕊1🆒1
Давно нас не было на хабре!
Сегодня – про эффективный менеджмент! Или не очень эффективный..
https://habr.com/ru/articles/817617/
Лайки, репосты и комментарии – помогают 🙂
Сегодня – про эффективный менеджмент! Или не очень эффективный..
https://habr.com/ru/articles/817617/
Лайки, репосты и комментарии – помогают 🙂
Хабр
Команда работает как часы? Возможно, у тебя проблемы
Иногда в мире менеджмента встречается выражение: Команда работает как часы! Некоторые руководители, директора, и даже владельцы бизнеса думают: Процессы настроили? Настроили. Продукт выдают? Выдают....
👍9🔥5❤3👌1
Loaded Question
Loaded question / нагруженный вопрос – вопрос, в который заложено твоё отношение к ситуации.
––
«Как дела у Васи?» – обычный вопрос
«Дела у Васи так себе, да?» – нагруженный вопрос
«Какой статус по проекту?» – обычный вопрос
«Проезжаем по срокам, да?» – нагруженный вопрос
––
1. Один раз на встрече хедов человек высокого уровня спросил:
– А что, Петю мы увольняем? (имя изменено)
Петю мы увольнять не собирались, но репутация человека пострадала немедленно.
2. В другой раз прозвучало
– Запуска без багов нам не ждать, верно?
Думаю, можно не комментировать, как это отразилось на отношении команды к QA и на уверенности QA в своей работе.
Запуск, кстати, всё равно случился с кучей багов – к тестированию особо серьёзно никто не отнёсся :)
––
Задавать нагруженные вопросы стоит осторожно.
Это можно делать, если у тебя есть уверенность в проблеме и вероятная реакция даст желаемый результат.
В противном случае – лучше задать безоценочный вопрос и, если ответ не нравится, или выглядит подозрительным, спускаться в детали, задавая другие вопросы.
Если, копаясь в деталях, ты обнаруживаешь настоящую, стопроцентную проблему, но команда этого не понимает – уже можно задать нагруженный вопрос или прямо сказать: «это – плохо!»
Loaded question / нагруженный вопрос – вопрос, в который заложено твоё отношение к ситуации.
––
«Как дела у Васи?» – обычный вопрос
«Дела у Васи так себе, да?» – нагруженный вопрос
«Какой статус по проекту?» – обычный вопрос
«Проезжаем по срокам, да?» – нагруженный вопрос
––
Когда руководитель задаёт нагруженный вопрос, мнение людей меняется ещё до того, как прозвучит ответ.
Чем выше уровень руководителя, тем сильнее эффект.
1. Один раз на встрече хедов человек высокого уровня спросил:
– А что, Петю мы увольняем? (имя изменено)
Петю мы увольнять не собирались, но репутация человека пострадала немедленно.
2. В другой раз прозвучало
– Запуска без багов нам не ждать, верно?
Думаю, можно не комментировать, как это отразилось на отношении команды к QA и на уверенности QA в своей работе.
Запуск, кстати, всё равно случился с кучей багов – к тестированию особо серьёзно никто не отнёсся :)
––
Задавать нагруженные вопросы стоит осторожно.
Это можно делать, если у тебя есть уверенность в проблеме и вероятная реакция даст желаемый результат.
В противном случае – лучше задать безоценочный вопрос и, если ответ не нравится, или выглядит подозрительным, спускаться в детали, задавая другие вопросы.
Если, копаясь в деталях, ты обнаруживаешь настоящую, стопроцентную проблему, но команда этого не понимает – уже можно задать нагруженный вопрос или прямо сказать: «это – плохо!»
🔥18❤8👍6🙏1