Как избегать накопления техдолга
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?"
👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать.
👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay.
👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?"
👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать.
👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay.
👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.
Benji's Blog
Supporting Sustainability - Benji's Blog
what about from the management side? I often hear from engineering and product managers that they're unaware, or learn too late, that folks were accumulating debt. It becomes visible when teams are no longer able to achieve goals.
Как построить найм студентов
Один из способов расширить воронку найма – посмотреть в сторону найма студентов, которые пока нигде поработать не успели. С одной стороны, нужно построить непростой процесс обучения и отфильтровывания тех из студентов, кто не готов вкладываться, а с другой вы можете получить отлично обучаемых людей, которые готовы будут быстро вникнуть именно в ваш технический стек.
Ребята из МойОфис рассказывают, как запускали два потока студенческих стажировок и с какими сложностями столкнулись. По цифрам результат такой:
👉50 собеседований на входе воронки, 5 наймов спустя 3 месяца.
👉4 из 5 нанятых остались в компании после испытательного срока.
Один из способов расширить воронку найма – посмотреть в сторону найма студентов, которые пока нигде поработать не успели. С одной стороны, нужно построить непростой процесс обучения и отфильтровывания тех из студентов, кто не готов вкладываться, а с другой вы можете получить отлично обучаемых людей, которые готовы будут быстро вникнуть именно в ваш технический стек.
Ребята из МойОфис рассказывают, как запускали два потока студенческих стажировок и с какими сложностями столкнулись. По цифрам результат такой:
👉50 собеседований на входе воронки, 5 наймов спустя 3 месяца.
👉4 из 5 нанятых остались в компании после испытательного срока.
Хабр
Как начать нанимать в штат студентов: опыт создания инженерной школы в МойОфис
Развитие любого крупного ИТ-проекта рано или поздно приводит к потребности в новых сотрудниках. Не всегда её просто покрыть: даже при наличии в компании зрелых HR-процессов и нужных бюджетов, поиск...
Пост для всех, кто любит новогодние подарки с пользой
Грейд клуб от Яндекс Практикума запустил адвент-календарь для руководителей цифровых команд.
Грейд Клуб — сообщество для нетворкинга цифровых лидеров и площадка для поиска решений о том, как драйвить рост IT-команд.
На протяжении трех недель пользователи будут получать классные подарки от клуба и его партнеров. А их собралось внушительное количество: Эйч, МИФ, Ясно, Кинжал и топовые эксперты индустрии.
Внутри вас ждут:
🎁Полезные фичи для мессенджеров
🎁Билеты на отраслевые конференции
🎁Гайды по эффективному лидерству и другие полезные подарки.
Переходите в бот адвент-календаря, чтобы не пропустить подарки!
ООО Яндекс. ИНН 7736207543
Грейд клуб от Яндекс Практикума запустил адвент-календарь для руководителей цифровых команд.
Грейд Клуб — сообщество для нетворкинга цифровых лидеров и площадка для поиска решений о том, как драйвить рост IT-команд.
На протяжении трех недель пользователи будут получать классные подарки от клуба и его партнеров. А их собралось внушительное количество: Эйч, МИФ, Ясно, Кинжал и топовые эксперты индустрии.
Внутри вас ждут:
🎁Полезные фичи для мессенджеров
🎁Билеты на отраслевые конференции
🎁Гайды по эффективному лидерству и другие полезные подарки.
Переходите в бот адвент-календаря, чтобы не пропустить подарки!
ООО Яндекс. ИНН 7736207543
Бреслав и Ложечкин про обратную связь
Вышел новый эпизод дочернего проекта Подлодки – подкаста для менеджеров "Бреслав и Ложечкин". В этот раз разговор идет про обратную связь: когда и кому она нужна, сколько времени на нее тратить и с какими подводными камнями можно столкнуться.
Вышел новый эпизод дочернего проекта Подлодки – подкаста для менеджеров "Бреслав и Ложечкин". В этот раз разговор идет про обратную связь: когда и кому она нужна, сколько времени на нее тратить и с какими подводными камнями можно столкнуться.
Как запрашивать фидбэк на свою работу
Типичная история – вы работаете над какой-то идеей, запрашиваете у коллег фидбэк, и вместо чего-то полезного получаете поток обратной связи про несущественные аспекты и косметику. Чтобы этого избежать, надо заранее проговаривать, фидбэк какого типа вы ожидаете. Вот одна из моделей:
👉Работа завершена на 5%: "Согласны ли вы с проблемой, которую я решаю?"
👉Работа завершена на 30%: "На правильном ли пути я нахожусь с моим решением проблемы?"
👉Работа завершена на 60%: "Является ли решение разумным, достигнем ли мы с ним наших целей?"
👉Работа завершена на 90%: "Пропустил ли я что-нибудь?"
👉Работа завершена на 100%: "Что в следующий раз надо сделать по-другому?"
Типичная история – вы работаете над какой-то идеей, запрашиваете у коллег фидбэк, и вместо чего-то полезного получаете поток обратной связи про несущественные аспекты и косметику. Чтобы этого избежать, надо заранее проговаривать, фидбэк какого типа вы ожидаете. Вот одна из моделей:
👉Работа завершена на 5%: "Согласны ли вы с проблемой, которую я решаю?"
👉Работа завершена на 30%: "На правильном ли пути я нахожусь с моим решением проблемы?"
👉Работа завершена на 60%: "Является ли решение разумным, достигнем ли мы с ним наших целей?"
👉Работа завершена на 90%: "Пропустил ли я что-нибудь?"
👉Работа завершена на 100%: "Что в следующий раз надо сделать по-другому?"
hellojames.co.uk
Getting better feedback on your work | hellojames
I'm a designer who helps growing organisations build great in-house teams.
Производительность определяется не личностью разработчика, а случайными факторами
Интересное исследование за 1995 год. 500 разработчиков выполняли на протяжении времени набор одинаковых задач, оценивая свои трудозатраты на разные этапы работы над ними. На выходе получились интересные данные:
👉В рамках отдельных заданий есть огромная разница между некоторыми программистами – лучший может быть производительнее худшего аж в 55 раз.
👉Если отбросить эти выбросы, то разница между 25 и 75 перцентилем очень небольшая.
👉Все интереснее, когда анализируется производительность каждого разработчика в рамках всех задач. У 90% разработчиков очень большой разброс времени выполнения разных заданий. Фактически 482 из 494 программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее.
Короче, еще одно подтверждение того, что бессмысленно сравнивать перфоманс разработчиков друг с другом, когда они работают над разными задачами, и что вместо фиксации на скорости разработки лучше уменьшать ее неопределенность.
Интересное исследование за 1995 год. 500 разработчиков выполняли на протяжении времени набор одинаковых задач, оценивая свои трудозатраты на разные этапы работы над ними. На выходе получились интересные данные:
👉В рамках отдельных заданий есть огромная разница между некоторыми программистами – лучший может быть производительнее худшего аж в 55 раз.
👉Если отбросить эти выбросы, то разница между 25 и 75 перцентилем очень небольшая.
👉Все интереснее, когда анализируется производительность каждого разработчика в рамках всех задач. У 90% разработчиков очень большой разброс времени выполнения разных заданий. Фактически 482 из 494 программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее.
Короче, еще одно подтверждение того, что бессмысленно сравнивать перфоманс разработчиков друг с другом, когда они работают над разными задачами, и что вместо фиксации на скорости разработки лучше уменьшать ее неопределенность.
Обязательные знания для тимлида
Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.
Расскажите в комментариях, что, по вашему, входит в комплект обязательных знаний для тимлида!
Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.
Расскажите в комментариях, что, по вашему, входит в комплект обязательных знаний для тимлида!
Skyeng — EdTech-компания с целой экосистемой сервисов для изучения иностранных языков. В 2022 году они решили усилить аналитическое направление, построив новое корпоративное хранилище данных и сменив инструменты для аналитики.
Новое хранилище построено на сервисах платформы данных Yandex Cloud, покрывающей полный цикл работы с данными в облаке. Ядром DWH стал Yandex Managed Service for Greenplum® , для оперативного доступа к данным используется Yandex Managed Service for ClickHouse®, а для визуализации — Yandex DataLens.
Переход на сервисы Yandex Cloud позволил Skyeng сократить расходы на аналитику данных на 10% и ускорить тестирование маркетинговых гипотез. Это помогло компании за год увеличить продажи на 26%, а число клиентов — на 12%.
Как сервисы Yandex Cloud помогают Skyeng развиваться, читайте по ссылке.
Please open Telegram to view this post
VIEW IN TELEGRAM
Как убедить всех замедлить разработку
Представьте(а, может, вам и представлять не надо) , что с каждым месяцем вы все медленнее и медленнее деливерите фичи из-за накопившегося технического долга и других проблем, а бизнес при этом пушит, чтобы вы ускорялись. Любое ускорение в такой ситуации приводит только к тому, что вы создаете еще больше технического долга, башня которого в ближайшем будущем обрушится на вашу голову.
Единственное разумное решение в такой ситуации – замедлить разработку еще сильнее, исправить накопившиеся проблемы, и потом вступить в игру с новой силой. Проблема в том, что такой подход так просто не продать, особенно в период утраты доверия к команде. Держите советы из статьи, как все-таки достичь желаемого:
👉Оцените все, что от вас требуют сделать, в финансовых метриках, хотя бы очень приблизительно.
👉Выберите самые импактящие вещи, которые заблокированы существующими проблемами. Используйте их для обоснования.
👉Продумайте стратегию отдачи техдолга, которая уменьшает возможные риски и позволяет заинтересованным прозрачно видеть прогресс.
👉Быстро проверьте свои основные предположения до того, как продавать план. Например, точно ли вы сможете переписать какой-то компонент системы в обозначенное время.
👉Заранее продумайте, какие трейдоффы возможны, и используйте их как аргумент в переговорах.
👉Включите свою работу в продуктовый роадмап, сделайте ее видимой, чтобы всем было очевидно, что она связана с болями пользователя.
👉Выбирайте стратегию, которая сможет показать хоть какие-то ранние результаты.
Представьте
Единственное разумное решение в такой ситуации – замедлить разработку еще сильнее, исправить накопившиеся проблемы, и потом вступить в игру с новой силой. Проблема в том, что такой подход так просто не продать, особенно в период утраты доверия к команде. Держите советы из статьи, как все-таки достичь желаемого:
👉Оцените все, что от вас требуют сделать, в финансовых метриках, хотя бы очень приблизительно.
👉Выберите самые импактящие вещи, которые заблокированы существующими проблемами. Используйте их для обоснования.
👉Продумайте стратегию отдачи техдолга, которая уменьшает возможные риски и позволяет заинтересованным прозрачно видеть прогресс.
👉Быстро проверьте свои основные предположения до того, как продавать план. Например, точно ли вы сможете переписать какой-то компонент системы в обозначенное время.
👉Заранее продумайте, какие трейдоффы возможны, и используйте их как аргумент в переговорах.
👉Включите свою работу в продуктовый роадмап, сделайте ее видимой, чтобы всем было очевидно, что она связана с болями пользователя.
👉Выбирайте стратегию, которая сможет показать хоть какие-то ранние результаты.
The Beautiful Mess
TBM 257: How to Make the Case for Slowing Down to Speed Up
How can we make the case for slowing down to speed up when we are already going slow, and when shutting things down and starting over is not an option?
Универсальное правило для продуктивной работы
Держи голову свободной! Тебе никогда не придёт в голову гениальная идея, если она всегда забита операционными мелкими задачами. Помнишь, как ты придумывал что-то перед сном или в отпуске? А сколько из этих идей моментально забывались?
🍅Помодоро или регулярных медитаций не хватает, это лишь кратковременная фокусировка на чём-то. Надо создать систему, в которой абсолютно все твои мысли и задачи будут учтены. Так ты избавишь голову от каждодневного хлама и начнёшь кратно увеличишь скорость роста как себя, так и всей компании.
О том, как система тайм-менеджмента может помочь достичь такого состояния расскажут на вебинаре 16 декабря в 20:30 по мск. Участие бесплатное, надо лишь зарегистрироваться в боте
Держи голову свободной! Тебе никогда не придёт в голову гениальная идея, если она всегда забита операционными мелкими задачами. Помнишь, как ты придумывал что-то перед сном или в отпуске? А сколько из этих идей моментально забывались?
🍅Помодоро или регулярных медитаций не хватает, это лишь кратковременная фокусировка на чём-то. Надо создать систему, в которой абсолютно все твои мысли и задачи будут учтены. Так ты избавишь голову от каждодневного хлама и начнёшь кратно увеличишь скорость роста как себя, так и всей компании.
О том, как система тайм-менеджмента может помочь достичь такого состояния расскажут на вебинаре 16 декабря в 20:30 по мск. Участие бесплатное, надо лишь зарегистрироваться в боте
Навигаторы как замена архитектурным комитетам и командам
Про проблемы, вызываемые в компании наличием централизованной функции архитекторов, в канале мы обсуждали уже много раз (как минимум вот). При этом польза от них тоже есть, как минимум в том, чтобы любые технические вопросы не эскалировались до СТО. Один из вариантов замены – навигаторы.
👉На каждую большую бизнесовую область выделяется один человек навигатор. Им может быть только тот, кто активно контрибьютит в связанную кодовую базу.
👉Зоны ответственности навигаторов не пересекаются.
👉Навигатор целиком отвечает за принятие крупных технических решений в его области.
👉Если решение сталкивается с бизнесовыми или пипл-менеджерскими ограничениями, навигатор должен сам договориться с ответственными людьми.
👉Навигаторы отчитываются перед СТО за все принятые решения.
👉Если пара навигаторов не может договориться, вопрос эскалируется до СТО.
Про проблемы, вызываемые в компании наличием централизованной функции архитекторов, в канале мы обсуждали уже много раз (как минимум вот). При этом польза от них тоже есть, как минимум в том, чтобы любые технические вопросы не эскалировались до СТО. Один из вариантов замены – навигаторы.
👉На каждую большую бизнесовую область выделяется один человек навигатор. Им может быть только тот, кто активно контрибьютит в связанную кодовую базу.
👉Зоны ответственности навигаторов не пересекаются.
👉Навигатор целиком отвечает за принятие крупных технических решений в его области.
👉Если решение сталкивается с бизнесовыми или пипл-менеджерскими ограничениями, навигатор должен сам договориться с ответственными людьми.
👉Навигаторы отчитываются перед СТО за все принятые решения.
👉Если пара навигаторов не может договориться, вопрос эскалируется до СТО.
Lethain
Navigators
In Staff Engineer’s chapter on Managing Technical Quality, one of the very last suggestions is creating a centralized process to curate technical changes:
Curate technology change using architecture reviews, investment strategies, and a structured process…
Curate technology change using architecture reviews, investment strategies, and a structured process…
Как деливерить быстрее
Набор принципов, некоторые из которых показались мне интересными:
👉Protect momentum. Чем чаще вы что-то релизите, тем выше получается держать уровень мотивации и энергии в команде. Длинные циклы разработки приводят к выгоранию и потере контакта с пользователем.
👉Beware of prioritization. Бессмысленно тратить много времени на приоритизацию, когда все, что действительно важно – это какую задачу делать прямо сейчас, а какую – следующей.
👉Only doers can plan what you work on. Как только за планирование начинают отвечать оторванные от разработки люди, появляется искуственное раздувание сроков разработчиками, которые не хотят промахиваться в оценках. А работа занимает все выделенное на нее время.
👉There is no quality vs speed tradeoff. Плохое качество кода замедлит вам работу в будущем. Любой компромисс такого рода – в долгую вреден. При достаточном уровне культуры разработки и скиллов инженеров можно достичь обеих целей.
Набор принципов, некоторые из которых показались мне интересными:
👉Protect momentum. Чем чаще вы что-то релизите, тем выше получается держать уровень мотивации и энергии в команде. Длинные циклы разработки приводят к выгоранию и потере контакта с пользователем.
👉Beware of prioritization. Бессмысленно тратить много времени на приоритизацию, когда все, что действительно важно – это какую задачу делать прямо сейчас, а какую – следующей.
👉Only doers can plan what you work on. Как только за планирование начинают отвечать оторванные от разработки люди, появляется искуственное раздувание сроков разработчиками, которые не хотят промахиваться в оценках. А работа занимает все выделенное на нее время.
👉There is no quality vs speed tradeoff. Плохое качество кода замедлит вам работу в будущем. Любой компромисс такого рода – в долгую вреден. При достаточном уровне культуры разработки и скиллов инженеров можно достичь обеих целей.
Equals
How to ship fast
A lot has been written on how important it is for startups to ship fast. Less has been written on how to ship fast.
Почему вы увольнялись с менеджерской работы
Я увольнялся с менеджерских позиций два раза. Первый раз был в 2016 году в Rambler&Co. У нас одним днем сменился весь менеджмент технического подразделения на каких-то очень эффективных ребят из Инновы. Первое, что они сделали – собрали всю нашу команду и начали рассказывать про Scrum и другие великие изменения, которые планируют внедрить. На любые разумные вопросы про эти изменения отвечали чем-то типа "Да я уже пять успешных бизнесов построил, когда сделаешь столько же, вопросы и задавай". После этой встречи мы завели встречи для всего iOS отдела, на которых совместно стали готовиться к интервью. Спустя пару месяцев уволился и я, и процентов 70 всей команды. Мораль, которую я для себя вынес – даже если вас нанимают ради внедрения изменений, не стоит врываться с ними с порога без внятной стратегии их исполнения.
Второй раз был уже из Авито. В какой-то момент количество скучных менеджерских задач на монй позиции стало перевешивать интересные. В частности, смешно получилось с перфоманс ревью. Еще в 2017 году я начал его внедрять в компании. Со временем он эволюционировал, превращаясь во все более сложную машину. Два года спустя, сидя поздно вечером на калибровке, на которой мы несколько часов до хрипоты спорили о том, кто из двух незнакомых мне инженеров заслуживает +0.05 к оценке, я понял, что это совсем не то, на что я хочу тратить свою жизнь.
А теперь ваша очередь! Расскажите в комментариях, почему вы увольнялись с менеджерской работы.
Я увольнялся с менеджерских позиций два раза. Первый раз был в 2016 году в Rambler&Co. У нас одним днем сменился весь менеджмент технического подразделения на каких-то очень эффективных ребят из Инновы. Первое, что они сделали – собрали всю нашу команду и начали рассказывать про Scrum и другие великие изменения, которые планируют внедрить. На любые разумные вопросы про эти изменения отвечали чем-то типа "Да я уже пять успешных бизнесов построил, когда сделаешь столько же, вопросы и задавай". После этой встречи мы завели встречи для всего iOS отдела, на которых совместно стали готовиться к интервью. Спустя пару месяцев уволился и я, и процентов 70 всей команды. Мораль, которую я для себя вынес – даже если вас нанимают ради внедрения изменений, не стоит врываться с ними с порога без внятной стратегии их исполнения.
Второй раз был уже из Авито. В какой-то момент количество скучных менеджерских задач на монй позиции стало перевешивать интересные. В частности, смешно получилось с перфоманс ревью. Еще в 2017 году я начал его внедрять в компании. Со временем он эволюционировал, превращаясь во все более сложную машину. Два года спустя, сидя поздно вечером на калибровке, на которой мы несколько часов до хрипоты спорили о том, кто из двух незнакомых мне инженеров заслуживает +0.05 к оценке, я понял, что это совсем не то, на что я хочу тратить свою жизнь.
А теперь ваша очередь! Расскажите в комментариях, почему вы увольнялись с менеджерской работы.
Как в Google работает code review
Интересный разбор особенностей code review в Google – от гайдлайнов и до разбора Critique, внутреннего инструмента для ревью. Среди заметных фич:
👉Использование AI для того, чтобы в одну кнопку применить предложения из комментария.
👉Автоматическая генерация комментов-саджестов для ревьюеров кода на основе работы статических анализаторов.
👉Есть специальные дэшборды, которые показывают, какие ревью на ком зависли.
👉Если PR содержит и стилистический рефакторинг, и изменения бизнес-логики, Critique отфильтровывает только значимый код.
Интересный разбор особенностей code review в Google – от гайдлайнов и до разбора Critique, внутреннего инструмента для ревью. Среди заметных фич:
👉Использование AI для того, чтобы в одну кнопку применить предложения из комментария.
👉Автоматическая генерация комментов-саджестов для ревьюеров кода на основе работы статических анализаторов.
👉Есть специальные дэшборды, которые показывают, какие ревью на ком зависли.
👉Если PR содержит и стилистический рефакторинг, и изменения бизнес-логики, Critique отфильтровывает только значимый код.
Гайд по переходу к асинхронным коммуникациям
Все знают, что даже 3 встречи способны сделать полностью бесполезным рабочий день у разработчика. Но не все пытаются с этим что-то сделать. Держите довольно подробный гайд по тому, как подготовить команду к переходу на асинхронный режим взаимодействия, какие конкретные изменения надо сделать, и как постепенно менять культуру.
Все знают, что даже 3 встречи способны сделать полностью бесполезным рабочий день у разработчика. Но не все пытаются с этим что-то сделать. Держите довольно подробный гайд по тому, как подготовить команду к переходу на асинхронный режим взаимодействия, какие конкретные изменения надо сделать, и как постепенно менять культуру.
Тест для сборки инструкции к менеджеру
В конце года принято ретроспективно смотреть на все проекты, процессы и коммуникации. Ребята из SETTERS Media запустили тест-конструктор инструкции к себе как к менеджеру.
Как работает:
👉 Отвечаете на десять вопросов про свой стиль постановки целей, делегирования и коммуникаций
👉 Рассказываете о своих увлечениях и грузите фотку, чтобы вас ни с кем не спутали
На выходе получаете красиво сверстанную пдф, в которой подсвечены ваши основные менеджерские черты. Можно (и даже нужно) пошэрить файл с командой, потому что подтянуть коммуникации = подтянуть вообще все процессы. Пробуйте и рефлексируйте перед Новым годом!
Реклама. ООО "СЕТТЕРС МЕДИА"
В конце года принято ретроспективно смотреть на все проекты, процессы и коммуникации. Ребята из SETTERS Media запустили тест-конструктор инструкции к себе как к менеджеру.
Как работает:
👉 Отвечаете на десять вопросов про свой стиль постановки целей, делегирования и коммуникаций
👉 Рассказываете о своих увлечениях и грузите фотку, чтобы вас ни с кем не спутали
На выходе получаете красиво сверстанную пдф, в которой подсвечены ваши основные менеджерские черты. Можно (и даже нужно) пошэрить файл с командой, потому что подтянуть коммуникации = подтянуть вообще все процессы. Пробуйте и рефлексируйте перед Новым годом!
Реклама. ООО "СЕТТЕРС МЕДИА"
Выпуск Подлодки про то, кто такой engineering director
Руководить другими менеджерами – совсем не то же самое, чем линейными сотрудниками. Записали выпуск Подлодки с Евгением Котом про то, в чем заключаются основные особенности работы инжиниринг директором от обычной менеджерской роли, и поговорили, какие знания и навыки будут обязательными.
Руководить другими менеджерами – совсем не то же самое, чем линейными сотрудниками. Записали выпуск Подлодки с Евгением Котом про то, в чем заключаются основные особенности работы инжиниринг директором от обычной менеджерской роли, и поговорили, какие знания и навыки будут обязательными.
podlodka.io
Podlodka #349 – Engineering director
Часто карьерную лестницу технических менеджеров представляют исключительно через количественный рост в зоне ответственности, горизонте планирования и числе людей. Почему это не так и в чем есть качественные отличия поговорили с Евгением Котом.
Кому и зачем надо становиться менеджером
Очень классный мотивационный пост про то, почему стоит выбирать менеджерский карьерный трек помимо чуть большей в среднем по больнице зарплаты. Мне запали следующие мысли:
👉Задача менеджера – не принимать все решения, а делать так, чтобы они принимались.
👉Иерархия в компаниях существует для координации изменений в отдельных подсистемах и их постепенных улучшений. Менеджеры обеспечивают наличие в системе цикла обратной связи, благодаря которому эти улучшения и происходят, а систему получается выровнять вокруг общей цели.
👉Для некоторых людей потребность менторить других и передавать им свои знания – биологический императив. Это не обязательное требование, чтобы быть менеджером, но хорошая причина.
👉Другая хорошая причина – насмотреться на плохих менеджеров, понимать, как делать не надо, и хотеть помочь другим не страдать от тех же проблем.
👉Для хорошего инженера работа менеджером в течение пары лет – отличный опыт, чтобы вырасти в стаффа.
👉Опыт работы менеджером сильно помогает вам улучшить навыки взаимодействия с людьми, которые требуются и в личной жизни: вы учитесь управлять собой, понимать свои чувства и чувства других людей, устанавливать границы, говорить о неудобных вещах.
Очень классный мотивационный пост про то, почему стоит выбирать менеджерский карьерный трек помимо чуть большей в среднем по больнице зарплаты. Мне запали следующие мысли:
👉Задача менеджера – не принимать все решения, а делать так, чтобы они принимались.
👉Иерархия в компаниях существует для координации изменений в отдельных подсистемах и их постепенных улучшений. Менеджеры обеспечивают наличие в системе цикла обратной связи, благодаря которому эти улучшения и происходят, а систему получается выровнять вокруг общей цели.
👉Для некоторых людей потребность менторить других и передавать им свои знания – биологический императив. Это не обязательное требование, чтобы быть менеджером, но хорошая причина.
👉Другая хорошая причина – насмотреться на плохих менеджеров, понимать, как делать не надо, и хотеть помочь другим не страдать от тех же проблем.
👉Для хорошего инженера работа менеджером в течение пары лет – отличный опыт, чтобы вырасти в стаффа.
👉Опыт работы менеджером сильно помогает вам улучшить навыки взаимодействия с людьми, которые требуются и в личной жизни: вы учитесь управлять собой, понимать свои чувства и чувства других людей, устанавливать границы, говорить о неудобных вещах.