Привет! Меня зовут Егор Толстой. Я веду подкаст Подлодка, руковожу командой разработки языка программирования Kotlin, а до этого много лет был продакт-менеджером и руководил разными инженерными командами.

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

Если какой-то пост был вам полезен – ставьте 👍, ❤️ и 🔥, мне это важно! А еще лучше – подписывайтесь на мой Твиттер и другие Telegram-каналы: iOS Good Reads, Android Good Reads, QA Channel.

Навигация по постам:
#digest – регулярные подборки лучших материалов
#книги – рекомендации книг
#найм – все, связанное с подбором людей и собеседованиями
#развитие_себя – улучшение своих тимлидовских навыков
#люди – про все навыки, связанные с работой с людьми
#процессы – процессы разработки, управление сроками и скоупом
#техлидство – инженерная культура, архитектура, практики
#управление_компанией – про company-wide процессы, оргструктуру
#инструменты – прикладные материалы, пополняющие ваш toolbox
#качество – управление и улучшение качества системы, за которую вы отвечаете
#карьера – поиск работы тимлидом, прохождение собеседований, рост в компании

Обычно наше знание организационных структур заканчивается на базовом списке: функциональная, матричная, и spotify-like, она же гибкая. Иногда еще холократию вспоминают. Но история видела огромное количество других моделей организации компаний. Справку про то, как они работали и какие компании их попробовали, можно почитать в этой статье.

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

Системный разбор всех возможных подходов к системе финансовой компенсации

🗺Влияние локации сотрудника на зарплату
🪙Почему важно разбираться с локальными налоговыми системами
💰Как работают бюджеты на зарплаты
🧐Грейды и зарплатные перцентили
✨Опционы
📚Как, когда и зачем проводить compensation review

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

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

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

Для того, чтобы помочь тимлидам оценивать грейд своих разработчиков, а вместе с ним и уровень зарплаты, в SkyEng собрали специальный опросник из 14 пунктов. В нем проверяется умение работать самостоятельно, технический кругозор, понимание бизнес проблемы и умение действовать в условиях неопределенности. Говорят, что для них сработало классно. Расскажите в комментариях, что думаете про такой подход.

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

Honeycomb делятся своим подходом к определению грейдов. У них довольно интересный подход – вместо введения кучи критериев они смотрят на два:
🧳Ownership – на каком уровне разработчик вовлекается в проект (execution / process / solution discovery / problem discovery)
📏Scope – какого примерно размера выполняемые проекты (task / feature / project / product / company)

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

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

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

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

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

Сокращения – это очень тяжелый эмоциональный опыт и для тех, кого увольняют, и для менеджеров, которые это решение принимают и выполняют. Во многом травмирует не сам факт увольнения, а неизвестность, которая ему сопутствует. Если вам когда-то придется сокращать команду, то понимание вопросов, которые стоит объяснить людям, может помочь проработать процесс и сделать его менее травмирующим:
❓Почему уволили именно этого человека, а не кого-то еще
❓Какие события привели к решению о сокращении
❓Как решение о сокращении коммуницировалось внутри компании, все ли о нем узнали из первых уст
❓Как попрощаться со всеми, кто будет сокращен, и где найти их контакты
❓Что произойдет с людьми, которыми увольняемый менеджер руководил
❓Что будет с проектами, в которые человек вложил душу и время

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

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

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

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

За последние годы во все большем количестве компаний появляются расширенные инженерные карьерные пути. Часто их обозначают как Staff+. Но одним только введением новых карьерных уровней не обойтись. Staff+ роли требуют соответствующего уровня задач, инженерной и менеджерской культуры. Автор статьи проинтервьюировал кучу staff+ разработчиков из больших и маленьких компаний и сделал подборку самых частовстречающихся дисфункций. Вот некоторые из них:
📌Под красивыми лозунгами про автономность в выборе целей и соедств их достижения staff+ инженеров на самом деле скрывается отсутствие поддержки от менеджеров и понимания с их стороны того, что нужно делать
📌Staff+ инженерам предлагается управлять другими за счет авторитета, в то время как вся корпоративная культура ориентирована на управление за счет административных полномочий
📌Менеджмент требует тратить на написание кода все время, не учитывая другие активности
📌Staff+ инженерам ставятся большие амбициозные цели, но менеджмент не пытается помочь в их достижении за счет работы со стратегией и оргструктурой, в результате ничего не получается

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