Как соревноваться за кандидатов на вакансии, если какие-то компании могут предложить программисту 800.000р, а вам на похожей вакансии поднятие вилки до 180.000р согласовать не могут? Держите хороший материал про то, из каких параметров складывается конкурентоспособный оффер. Плохая новость – в первую и в главную очередь из зарплаты. Хорошая новость – есть много дополнительных факторов, на которые вы, как тимлид, можете повлиять:
📌Качество организации процесса найма и опыт кандидата в нем. Это соприкосновение с компанией даст ему оценить вашу культуру и понять, хочет ди он в ней работать.
📌Если вы не можете дать кандидату зарплату выше оговоренной вилки, вы можете попробовать согласовать какие-то дополнительные плюшки – четырехдневную рабочую неделю или дополнительный отпуск. Разные плюшки для разных людей имеют разный вес, и этим надо пользоваться.
📌Для того, чтобы реализовать многие из таких плюшек, вам не нужно явное согласие своего менеджера или HR. Что напрямую не запрещено, то может быть разрешено. Будьте смелее. Если у вас в компании нет четырехдневки, а человеку она очень важна – пусть просто не работает по пятницам, за ним же никто не следит.

СЕО GitLab, которые всегда были remote-first компанией, написал неплохую колонку про то, почему попытки возвращать сотрудников в офисы после пандемии – тупиковый путь. Возможно, какие-то из его аргументов помогут и вам в спорах за добро.

В больших компаниях менеджеры любят спорить про хедкаунт и выбивать больше людей на свои проекты. Твиттер-тред с развенчиванием трех мифов про хедкаунт:
❌Хедкаунт влияет на достижение short-term целей
✅На самом деле хедкаунт влияет на достижение целей в лучшем случае через 6-9 месяцев

❌Хедкаунт выделяется на команду
✅В масштабе компании отдельные команды мало что значат, хедкаунт выделяется на приоритетные направления развития

❌Хедкаунт – ограничивающий фактор скорости разработки
✅Основной ограничивающий фактор – способность менеджмента тащить проект

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

Оффер в Яндекс за 2 дня 🚀

9-10 июля Яндекс проводит Weekend Offer для мобильных разработчиков, участники которого смогут присоединиться к командам Маркета, Еды, Такси и многих других сервисов.
Если у вас есть опыт коммерческой разработки на iOS, Android, Flutter от 3 лет — регистрируйтесь на сайте и решайте задачи предварительного этапа.
9 июля две онлайн-секции с кодом и уже на следующий день лучшие участники получат офферы от Яндекса.

Держите две полезные подборки:
1️⃣Шаблоны дизайн-документов/RFC используемых в Google, Uber, SoundCloud и других компаниях
2️⃣Шаблоны Product Requirement Document от Intercom, Figma, Asana

#инструменты

Один из необходимых скиллов для тимлида – умение учиться. Надеюсь, вы проходили тот самый курс “Learn how to learn” на Coursera, или читали книгу его автора, Барбары Оакли, “Думай как математик”. Если нет – обязательно положите себе это в бэклог, получите кучу пользы и удовольствия.

Еще один крутой способ прокачать этот навык – прийти на конференцию Podlodka Soft Skills Crew. В новом сезоне мы расскажем, как выстроить эффективный подход к самообучению – понять свои цели, построить план по их достижению, выбрать подходящие инструменты и встроить это в свою жизнь на уровне привычки. Все это присыпано воркшопами и разбором ваших собственных проблем, так что после конференции вы выйдете с планом, подходящим именно вам!

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

👉Конференция начинается 11 июля, залетайте с промокодом leadgr_learn2learn!

STAR-метод – очень популярный подход к рассказыванию примеров из своего опыта. Он очень полезен, например, на интервью, когда вас просят рассказать про проект, которым вы больше всего гордитесь. Суть подхода в том, что вы раскладываете весь рассказ на четыре части.

1️⃣S – Situation
Контекст истории. Почему решаемая задача была важной, почему за ее решение взялись именно вы, какие дополнительные внешние факторы играли роль.

2️⃣T – Task
В чем именно состояла ваша задача. Максимально конкретное описание.

3️⃣A – Actions
Что конкретно вы сделали для того, чтобы задача решилась. Здесь важно отделять свой вклад от остальной команды, и показать связь предпринятых действий с задачей.

4️⃣R – Results
Какие результаты получились после выполнения задачи. Как вы поняли, что все стало хорошо.

Дополнительно рассказ можно усилить, ответив еще на пару вопросов:
*️⃣Что можно было сделать лучше?
*️⃣Как можно было бы достигнуть таких же результатов с вдвое меньшим бюджетом?

🔗Дополнительные ссылки
Пример ответа по STAR от Uber SRE
Пример ответа по STAR от Stripe Engineer
Твиттер-тред по теме

Только что начался офигенный открытый собес. Андрей Бреслав проводит софтскилловую секцию собеседования на техлида. Подключайтесь!

Stack Overflow подбили итоги своего ежегодного большого исследования разработчиков. Для тимлида такие отчеты полезны по следующим причинам:
📖Можно увидеть изменение трендов по тому, как люди входят в IT и учат новые технологии, и адаптировать под них свою воронку найма
🧐Технологии постоянно устаревают. Это не должно быть немедленным поводом для смены технического стека, но одним из факторов, влияющих на тот же найм, вполне может быть.
⏰Понимание того, из каких активностей состоит рабочий день разработчика может вырвать вас из радужных представлений о том, что код пишется 4-8 часов в день, и приземлить на суровую реальность.

Чаще всего тимлидом становятся по следующей схеме:
1️⃣Сидишь, пишешь код, никого не трогаешь
2️⃣Тебя хлопает по плечу руководитель, и говорит, что ты теперь тимлид
3️⃣Тимлидишь

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

Яндекс Практикум запускает большой курс «Как управлять командой. Курс для руководителей» на целых четыре месяца. Ребята обещают научить расставлять прилритеты, оптимизировать процессы и системно развивать команду. Курс расчитан на тех, кто уже стал руководителем и работает с командой с постоянным составом.

Старт обучения: 21 июля. Если вы узнали себя, посмотрите – такой курс может вам помочь!

Тимлидам часто приходится руководить кроссфункциональными командами. Как следствие, нужно решать задачу оценки и развития людей, работающих по тем специальностям, знания о которых у вас будут в лучшем случае поверхностными. Если вы оказались в такой ситуации, вам может помочь алгоритм, описанный в статье. Автор с его помощью работала с развитием QA, но он применим и для других направлений.

#люди #инструменты

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

Поняв, что такая схема не работает, Интерком создали отдельную виртуальную команду дежурств, состоящую целиком из добровольцев. Эта команда стала отвечать за слежение за всеми алертами и постепенное улучшение системы. Количество единовременно дежурящих сократилось с 30 до 6 человек, и количество инцидентов тоже постепенно снизилось.

#процессы #техлидство

Большой гайд от GitLab про то, как управлять командой в условиях удаленной работы. Как и все остальные материалы из их плейбука – хорошо проработан и основывается на куче примеров из их же опыта. Несколько мыслей, которые мне понравились:
📌Многие руководители неосознанно начинают микроменеджерить, когда не могут видеть свою команду глазами. То, что вам может казаться здоровой синхронизацией, для вашего сотрудника может быть жестким микроменеджментом.
📌Нужно стараться как можно большее число процессов переводить в асинхронный режим. Это помогает получить максимум пользы от ремоута, когда каждый может работать в своем удобном режиме и часовом поясе.
📌Сохраненная в письменном виде информация становится еще более ценной. Документируйте больше своих решений, ожиданий от сотрудника и фидбэка. Это даст людям возможность потреблять информацию в своем темпе.

#процессы

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

На интенсиве по аргументации специалисты из Яндекс Практикума научат достигать целей с помощью диалога, а не давления. Дадут алгоритм для быстрой подготовки к рабочим встречам и пять инструментов, чтобы отстаивать интересы.

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

7,5 часов вебинаров, где можно отработать навыки, и бессрочный доступ к интерактивному учебнику с теорией. Интенсив длится девять дней и стоит 15 000 ₽.
Новый поток стартует 18 августа. Записаться →

Когда инженерная команда Uber выросла до 100 человек, было принято решение разбить ее на две большие части:
🪄Program – команды, которые делают продукт для конечных пользователей
🪠Platform – команды, которые разрабатывают инфраструктуру и продукты для внутренних потребителей

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

#управление_компанией

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

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

#процессы

Руководители команд, 26 июля в 18:30 встречаемся в московском офисе Авито на первом TeamLead meetup!

Спикеры и темы 🔥

👉🏻 Чего ждут коллеги разных уровней от тимлида?
Работа тимлида не ограничивается собственной командой. Надо контактировать с другими командами, начальством, продактом, и у каждого есть свои ожидания. Евгений Рейх, руководитель кластера Goods Classified, подробно разберёт их.

👉🏻 Как осознать себя в роли руководителя тимлидов?
Если вы хорошо научились управлять разработчиками, это ещё не значит, что будет просто координировать тимлидов. Сергей Баранов, который недавно возглавил юнит Тарифы и не понаслышке знает об этом, поделится своим опытом смены образа мышления, ошибками и источниками силы.

А ещё после каждого выступления ребята проведут открытые дискуссии с коллегами из СберЗдоровья, Тинькофф, Skyeng и Ozon.
Регистрируйтесь: clc.to/Te3ETg.

Кстати, если вы не в Москве или не сможете прийти на встречу, то присоединяйтесь к прямой трансляции митапа на ютуб-канале AvitoTech.

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

Где бы я ни работал, мне приходилось решать конфликты между дизайнерами и разработчиками. Дизайнеры, которые не хотят думать о граничных состояних приложения. Разработчики, которые задают отступы или межстрочные расстояния на глаз, и отказываются проводить попиксельную сверку с макетом. Больше всего запомнился случай, когда разработчик и дизайнер из одной команды не разговаривали друг с другом около полугода, а все сообщения передавали через кого-то третьего.

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

#люди #процессы