Прямо сейчас три команды Авито находятся в поиске опытных тимлидов разработки:
➡️ Тимлид разработки в команду инфраструктуры поиска
➡️ Тимлид разработки в команду внутренних проектов (Legal Tech)
➡️ Тимлид разработки в команду Support Systems
Здесь вы сможете реализовать свои идеи в проекте с многомиллионной аудиторией и талантливой командой.
Зарплата достойная (обсуждается на собеседовании), а ещё:
– мощное железо, дополнительные мониторы и всё, что нужно для продуктивной работы;
– личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
– ДМС со стоматологией с первого дня;
– прозрачная система премий;
– удалёнка и крутой офис в 2-х минутах от метро «Белорусская»;
– терапевт и массажист, которые принимают в офисе.
Откликайтесь на вакансии и присоединяйтесь к одной из команд!
➡️ Тимлид разработки в команду инфраструктуры поиска
➡️ Тимлид разработки в команду внутренних проектов (Legal Tech)
➡️ Тимлид разработки в команду Support Systems
Здесь вы сможете реализовать свои идеи в проекте с многомиллионной аудиторией и талантливой командой.
Зарплата достойная (обсуждается на собеседовании), а ещё:
– мощное железо, дополнительные мониторы и всё, что нужно для продуктивной работы;
– личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
– ДМС со стоматологией с первого дня;
– прозрачная система премий;
– удалёнка и крутой офис в 2-х минутах от метро «Белорусская»;
– терапевт и массажист, которые принимают в офисе.
Откликайтесь на вакансии и присоединяйтесь к одной из команд!
Как строить доверие
Никаких секретных способов быстро заслужить доверие команды нет. Нужно быть хорошим менеджером, на которого можно положиться, и со временем доверие придет. При этом есть некоторые гигиенические вещи, без которых доверия точно не заслужить:
👉Действуйте одинаково в похожих ситуациях. Менеджер, реакцию которого невозможно заранее предсказать, точно не создаст фундамента для доверительного общения.
👉Ясно и открыто рассказывайте про происходящее в компании и любые изменения, которые могут затронуть людей. Если что-то рассказывать нельзя, то не уклоняйтесь от ответов, а ясно объясняйте, почему информацией сейчас делиться нельзя.
👉Будьте надежными, и отвечайте за свои слова.
👉Как можно реже прибегайте к режиму авторитарного управления.
👉Давайте как можно больше фидбэка, причем с уклоном в позитивный.
👉Открыто признавайте заслуги других, а провалы берите на себя.
👉Делегируйте людям в команде не только скучную для вас работу, но и те задачи, которые вам самому кажутся интересными.
Никаких секретных способов быстро заслужить доверие команды нет. Нужно быть хорошим менеджером, на которого можно положиться, и со временем доверие придет. При этом есть некоторые гигиенические вещи, без которых доверия точно не заслужить:
👉Действуйте одинаково в похожих ситуациях. Менеджер, реакцию которого невозможно заранее предсказать, точно не создаст фундамента для доверительного общения.
👉Ясно и открыто рассказывайте про происходящее в компании и любые изменения, которые могут затронуть людей. Если что-то рассказывать нельзя, то не уклоняйтесь от ответов, а ясно объясняйте, почему информацией сейчас делиться нельзя.
👉Будьте надежными, и отвечайте за свои слова.
👉Как можно реже прибегайте к режиму авторитарного управления.
👉Давайте как можно больше фидбэка, причем с уклоном в позитивный.
👉Открыто признавайте заслуги других, а провалы берите на себя.
👉Делегируйте людям в команде не только скучную для вас работу, но и те задачи, которые вам самому кажутся интересными.
jacobian.org
How to Build Trust - Jacob Kaplan-Moss
What are the major management behaviors that can help build trust? Management books often cover the importance of trust, but abstractly. There’s precious little writing about the nuts and bolts, the day-to-day tasks of trust-building. That’s the gap I’d like…
Опрос про Роадмап Тимлида
Я тут недавно посчитал, сколько лет прошло с момента первого запуска Роадмапа Тимлида. Оказывается, целых пять! Изначально я вписался в этот проект с очень корыстной целью – собрать базу знаний, с помощью которой смогу помогать развитию тимлидов, которыми руковожу сам. Так и получилось, за прошедшую пятилетку Роадмап помог мне бесчетное количество раз.
Если вы тоже пользовались Роадмапом для решения каких-то своих задач, то, пожалуйста, пройдите наш небольшой опрос. Нам со Стасом будет очень приятно узнать, каким компаниям мы смогли помочь, а заодно набрать идей по дальнейшему улучшению проекта.
👉Ссылка на опрос
Я тут недавно посчитал, сколько лет прошло с момента первого запуска Роадмапа Тимлида. Оказывается, целых пять! Изначально я вписался в этот проект с очень корыстной целью – собрать базу знаний, с помощью которой смогу помогать развитию тимлидов, которыми руковожу сам. Так и получилось, за прошедшую пятилетку Роадмап помог мне бесчетное количество раз.
Если вы тоже пользовались Роадмапом для решения каких-то своих задач, то, пожалуйста, пройдите наш небольшой опрос. Нам со Стасом будет очень приятно узнать, каким компаниям мы смогли помочь, а заодно набрать идей по дальнейшему улучшению проекта.
👉Ссылка на опрос
Как избегать накопления техдолга
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 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 — медленнее.
Короче, еще одно подтверждение того, что бессмысленно сравнивать перфоманс разработчиков друг с другом, когда они работают над разными задачами, и что вместо фиксации на скорости разработки лучше уменьшать ее неопределенность.
Обязательные знания для тимлида
Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.
Расскажите в комментариях, что, по вашему, входит в комплект обязательных знаний для тимлида!
Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.
Расскажите в комментариях, что, по вашему, входит в комплект обязательных знаний для тимлида!