TGViewer
Channel Public Channel
Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

@leadgr

Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами.

РКН: https://gosuslugi.ru/snet/67b4386d2a44e21839a0f87f

Продуктовая папка: https://t.me/addlist/YvmnHCHUp700Nzky

Реклама: @tanyasanovna
Subscribers
28K
Photos
383
Videos
6
Links
1.9K

Showing posts older than #678 · Back to latest

Older Posts 20 shown
Post #677 4.1K
  • 👍 1
Post #676 4.2K
Нашел небольшую заметку, которую не стал бы шарить, если бы она так сильно не попала прямо в меня. В чем суть – автор утверждает, что, вопреки частому мнению, для лида быть мягким / славным / добрым – это не так уж и плохо. Достаточно знать о возможных искажениях и бить себя по рукам, когда замечаешь за собой. Вот они:
🙊Избегание сложных разговоров
😶‍🌫️Чрезмерное смягчение речи из-за боязни обидеть чьи-то чувства
🐶Слишком сильная зависимость от одобрения
📏Низкая планка ожиданий от других людей

За собой я знаю три из четырех искажения, даже написал статью в блог про одно из них.
  • 🔥 24
  • 👍 1
Post #675 4.32K
Интересный взгляд на то, почему очень часто не получается объяснить бизнесу важность выделения времени на решение технического долга. Автор сравнивает тимлида, который пытается выбить время на техдолг, с финансовым директором, который бьет тревогу из-за больших долгов компании, но не может показать конкретный балансовый отчет.

В конце статьи вас ждет разбор терминов, которыми можно оперировать при разговоре с бизнесом.
Cyclic.sh We sound like idiots when we talk about technical debt | cyclic.sh When we use the term technical debt with non-technical business colleagues, they assume, that technical debt is analogous to financial debt. After a few minutes of discussion they are usually relieved to find that there is no actual money problem. How quickly…
  • 👍 3
Post #674 4.92K
Мобильная разработка – более молодая инженерная область, чем бэкенд или веб фронтенд. В то время как сложности написания и масштабирования серверной части проекта известны большинству тимлидов, челленджи мобилки гораздо менее очевидны. Я часто за лидами кроссфункциональных команд тенденцию отмахиваться от проблем мобильной разработки, делегировать их решение самому опытному мобильщику и полностью о них забывать.

Если вы замечали такое и за собой, то советую прочитать вот эту бесплатную книгу. В ней рассматриваются часто встречающиеся задачи. которые надо решать при росте кодовой базы мобильного приложения: оффлайн-режим, навигация, модульность, тестирование, качество, перфоманс. В мобильной разработке действительно очень много специфики, и ее понимание поможет вам лучше погружаться в проблемы команды и продукта.
bitrise.io Business and Tech Reports Read our reports full of mobile development insights and best practices from Bitrise engineers, technology experts, power users, and partners.
  • 👍 14
  • 🔥 1
Post #673 4.13K
Всем привет.

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

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

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

Ребята из 🇺🇦, держитесь ❤️
  • ❤ 230
  • 💩 16
  • 👍 7
  • 👎 6
  • 👏 4
Post #672 5.27K
Я набрал себе несколько менеджерских книг для прочтения в ближайшие месяцы. Давайте такой уговор – я делюсь ими в канале, а вы:
1. Расскажете свой отзыв в комментариях, если читали что-то из них
2. Поделитесь своими планами по чтению

📚Мой список:
The Art of Action
Working Backwards
High Output Management
Шум. Несовершенство человеческих суждений
Азбука системного мышления
Goodreads The Art of Action: How Leaders Close the Gaps between P… Examining the gap between what managers plan, what they…
  • ❤ 16
  • 👍 10
Post #671 4.07K
  • 👍 4
Post #670 4.03K
Давайте сегодня поговорим про платформенную разработку! Напоминаю, что это общий термин для обозначения инженерных команд, которые делают внутренние продукты для других разработчиков. Если 10 лет назад такие команды были только в самых крупных инженерных компаниях вроде Google и Netflix, то сейчас они появляются практически везде.

Я отвечал за платформенную разработку клиентсайда Авито в течение нескольких лет. Мы отвечали за создание инструментов, библиотек и окружения, которые снимали бы головную боль и уменьшали рутину у фронтендеров, бэкендеров и мобильных разработчиков. Основные особенности, которые определяют работу над платформой:
👻Каждый разработчик – сам себе продакт-менеджер, поэтому требуется обучение базовым продуктовым практикам;
🌩Платформенным командам нужно вкладываться в разработку стратегических долгостроев, выхлоп от которых виден не сразу. Поэтому конфликты с продуктовыми командами неизбежны;
🤔Частично из-за второго пункта, частично из-за технологически сложного домена, а частично из-за необходимости частых рисерчей, не каждой команде получается показывать видимые результаты. Из-за этого ее тимлиду регулярно приходится обосновывать ее ценность;

Если вы хотите побольше узнать про платформенную разработку, полистайте вот этот твиттер-тред. Он крут тем, что там очень-очень много ссылок на другие статьи и доклады, многие из которых – золото.
Twitter Daniel Bryant "Platform Engineering" is rapidly becoming the new DevOps or SRE. Almost every day we hear about another org building an internal developer platform or control plane. Want to know what platform engineering is, where the trends are going, and why you should…
  • 🔥 7
  • 👍 4
Post #669 3.56K
Вокруг Scrum всегда велось бесконечное количество холиваров. Покажите мне любую команду, которую затащили на обучение скраму, и я смогу предсказать вопросы, про которые буду вестись споры:
🤔Как считать сторипойнты и зачем они вообще нужны?
😡Зачем проводить ретроспективу каждую неделю, если ее ценность со временем падает?
🤬Зачем вслепую следовать всем указаниям скрама, если на команду хорошо ложатся другие процессы?

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

А вообще, аккуратнее с чистым скрамом, как и с любым другим карго-культом.
  • 🔥 3
  • 👍 1
Post #668 4.92K
Post #667 3.71K
Интересный взгляд на то, почему в большинстве организаций performance review скорее дисфункция, чем полезный инструмент. По мнению автора дело в том, что с его помощью пытаются достичь двух совсем разных целей – опредение уровня компенсации сотрудника и помощь его развитию. Если у вас тоже есть ощущение, что проблемы процесса кроются на пересечении этих двух направлений, почитайте статью.
  • 👍 15
Post #666 3.77K
В команде Kotlin, где я сейчас работаю, я довольно сильно заморочился с настройкой процесса онбординга новых сотрудников. Для меня этот процесс критически важен – я нанимаю непрограммистов в команду разработки языка программирования. Если их плавно не погрузить в детали рабочих процессов, не объяснить базовое устройство всех компонентов системы простыми словами и не поставить четкие и ясные цели, то вкатывание в команду очень усложнится.

Сейчас онбординг у меня состоит из следующих больших кусков:
📹 Видеокурс, где простым языком объясняется устройство различных компонентов: компилятора, IDE, билд тудтнга и других штук
🎛 Trello-доска с задачами на погружение в компанию, разными материалами для изучения и ключевыми людьми, с которыми нужно познакомиться
🎯 Цели на период онбординга, которые составляются вместе с новичком спустя пару недель работы
🤝 Наличие ментора, который сопровождает новичка в процессе онбординга

Когда-нибудь я обязательно напишу про это свою статью. А пока я прокрастинирую, можете почитать другой материал про онбординг, где довольно четко разложили все необходимые этапы и накидали лайфхаков.
Medium Conducting a Successful Onboarding Plan and Onboarding Process Successful onboarding plan & process are composed of various aspects — technical and personal. These are my tips for a smooth onboarding
  • ❤ 10
  • 👍 6
  • 🔥 2
Post #665 3.85K
В продолжение вчерашней темы держите классную методичку от Pluralsight. В ней разбирается 20 паттернов поведения команд и отдельных людей в них. Эти паттерны можно заметить как наблюдая за поведением людей, так и при детальном анализе метрик из системы контроля версий и трекера задач. В отличие от других статей про использование инженерных метрик в этой мне нравится, что авторы не пытаются делать каких-то выводов про успешность работы команды, а смотрят на них просто как на желтые флажки.
  • ❤ 17
  • 👍 4
  • 👎 1
  • 👏 1
  • 💩 1
Post #664 3.94K
Перфекционисты – это разработчики, которые ставят сами себе очень высокую планку стандартов качества и делают все, чтобы ей соответствовать. Тут две проблемы. Во-первых, в большинстве случаев этот перфекционизм излишний и негативно влияет на сроки. Во-вторых, в погоне за недостижимым идеалом разработчик-перфекционист довольно быстро может начать выгорать.

Шесть признаков перфекциониста:
- Страх провала
- Подход «все или ничего»
- Не умеет делегировать
- Часто прокрастинирует
- Слишком сильно сфокусирован на результате
- Тяжело принимает конструктивную критику

Подробный рассказ про эти шесть признаков и подходы к управлению такими людьми
Fellow 8 Tactics to Help Manage Perfectionists at Work What does a perfectionist look like at work, and how can you support them? Here are 8 strategies to help you manage them!
  • 👍 14
Post #663 4.07K
Встречи – черная дыра, поглощающая время большинства тимлидов. Их много, они очень часто бесполезны или плохо организованы, и, что еще хуже, сильно вырывают из рабочего контекста.

Когда я впервые стал тимлидом, я попросил руководителя посоветовать мне каких-нибудь книг по теме. Одной из них было «Руководство фасилитатора» Сэма Кейнера. Это очень крутая книга для всех, кто хочет построить себе системную картинку про принципы работы групповой дискуссии и набрать десятки инструментов по управлению ей. Максимально рекомендую!

А пока присматриваетесь к книге, можете начать с прочтения статьи с набором советов разного уровня по тому, как сделать ваши встречи чуть более ценными. Фреймворк 5Р, про который тут идет речь, сам использую на постоянной основе.
Medium Stop scheduling meetings without the 3Hs and 5Ps Poorly planned and facilitated meetings are one of the biggest annoyances I’ve had to deal with in my career (second only to…
  • 👍 18
  • 🔥 2
Post #662 3.08K
На прошлой неделе у нас разгорелся хороший такой холивар в комментариях к материалу про систему определения зарплат в Facebook. Вдогонку к этому, ребята из стартапа ConvertKit поделились своим подходом к определению финансовой компенсации для своих сотрудников.

Тезисно:
- Все получают одинаковые зарплаты в зависимости от грейда, основанные на данных от Radford;
- Зарплаты одинаковы вне зависимости от локации;
- Компенсируется 5% от зарплаты, если сотрудник откладывает их на пенсионный счет;
- 52% от профита компании выплачивается всей команде в виде performance бонуса. Топы получают 8%, владельцы – 40%;
- Грейд не влияет на бонус. 75% разделяется поровну между всеми, 25% зависит от времени работы в компании;
- Сотрудники получают доли в компании;
- Все финансовые данные абсолютно открыты для команды.
Twitter Nathan Barry In the last 5 years, we’ve paid $3.9 million in profit sharing to the ConvertKit team. While most companies hope to return money to shareholders in a moonshot acquisition, we’ve created a unique model to help our team think like owners. Here’s how our compensation…
  • 👍 9
Post #661 3.57K
RACI-матрица – супер простой и дико полезный инструмент для того, чтобы достичь прозрачных договоренностей о ролях и ответственности в проекте. Работает он следующим образом – вы выделяете конечный набор обязанностей в проекте, а затем каждому вовлеченному в него человеку назначаете одну из ролей:
- Responsible – тот, кто физически выполняет работу
- Accountable – тот, кто отвечает за результат и аппрувит его
- Consulted – тот, с кем надо обсудить решение и принять мнение во внимание
- Informed – тот, кому надо сообщить по факту принятия решения

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

В общем, советую, это один из инструментов, которыми должен уметь пользоваться любой тимлид.
https://habr.com/ru/company/timeweb/blog/597281/
  • 👍 24
Post #660 3.17K
Многие разработчики и тимлиды становились жертвой ошибки «я все сделаю сам». Уверен, что у вас тоже были похожие кейсы – вы брали на себя большой проект, исчезали с ним на продолжительное время, отделываясь статус-апдейтами вроде «я рисерчу», а потом оказывалось, что вы изначально решали не ту проблему. Или изобрели велосипед. Или получившееся решение можно было сделать в разы проще. Короче говоря, если бы вы работали над проектом не в одиночку, этих проблем бы не случилось.

В статье хорошо разложены причины такого поведения и конкретные способы борьбы с ним.
https://www.thezbook.com/the-biggest-mistake-i-see-engineers-make/
The ZBook The Biggest Mistake I See Engineers Make Throughout my career, the biggest mistake I see engineers make is doing too much work on their own before looping in others. I’ve experienced this mistake as both an IC and a manager. As an IC, it’s a mistake I made many, many times early in my ow...
  • 🔥 7
  • 👍 6
Post #659 3.26K
1-1 встречи все уже давно взяли себе на вооружение. Но есть несколько интересных кейсов, которые хорошо решаются встречами другого вида: 1-1-1. У «тройничков» есть своя групповая динамика, которой стоит уметь пользоваться.

В статье рассматривается несколько конкретных кейсов «тройничков»:
1. Смена руководителя у сотрудника
2. Временный перевод человека из проекта в проект
3. Ввод в кроссфункциональную команду новой роли, ожидания от которой не понятны
4. Пропушивание решений с помощью третьего человека
https://davidxiang.com/2021/12/30/use-more-1-1-1s/
David Xiang Use More 1-1-1s – David Xiang 1-1s are core to management. Ad-hoc feedback delivery, bi-weekly check-ins with your directs, monthly meetings with your skip-levels, annual performance reviews. Their use cases are well-defined and well-understood. 1-1-1s, on the other hand, can be much…
  • 👍 5
Post #658 3.26K
В крупных инженерных компаниях менеджерский карьерный трек – это только одна из веток развития. Вторая, равная по количеству уровней и компенсации – техническая. В статье Principal Engineer из Амазона делится тем, как устроен процесс повышения до принципала и какие ответственность и влияние на компанию появляется с этой лычкой.

Чтобы зацепить ваше внимание, краткое описание условий для повышения:
- Наличие подробного документа от твоего менеджера, описывающего твои достижения
- 5-7 людей выше по уровню, подписавшихся под этим документом и оставивших свой фидбэк
- Два ассессора, которые детально изучили все, что ты делал на работе: дизайн документы, код, комментарии на кодревью и доклады
- Аппрув от специального комитета
- Аппрув от еще более специального комитета самых мощных инженеров
https://medium.com/geekculture/belonging-to-amazons-principal-engineering-community-aa8059152fbf
Medium Belonging to Amazon’s Principal Engineering Community “The State of the Union is Strong”
  • 🤯 11
  • 👎 4
  • 👍 2
  • 🤮 1
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →