Взгляд Егора Бугаенко на метрики, которыми можно измерить эффективность разработчиков.
https://www.yegor256.com/2020/06/23/individual-performance-metrics.html

20 июля стартует Podlodka QA Crew – двухнедельная онлайн-конференция, на котороый мы будем глубоко разбирать две темы, которые касаются любого тимлида, в команде которого есть тестировщики или в ожиданиях которого есть ответственность за качество создаваемого продукта:
- 📈 Карьерный рост и развитие QA-инженера
- 🧰 Организация процесса тестирования

Будет так же круто, как и на прошлых сезонах – постоянное общение в Slack, живые форматы с подключением аудитории, инсайты от разных компаний про то, как они строят свои процессы. Приходите сами и скидывайте ссылки своей QA команде!
podlodka.io/qacrew

Неделю назад я уже писал про QA Crew, а теперь – готов поподробнее поделиться самыми интересными моментами из расписания!

Карьерный рост в QA
- Публичные собеседования на позиции QA, с реальными вопросами и объяснением ошибок кандидата в процессе
- Обзор зарплат в QA от ребят из Korn Ferry – это аналитическое агентство, у которых есть инсайдерские данные о зарплатах нескольких тысяч компаний в Москве
- Разбор нескольких веток роста QA – внутри профессии, в разработку, в менеджмент и вообще куда-то за границу.
- Домашнее задание с разработкой своего плана развития

Организация процесса тестирования
- Воркшоп по автоматизации рутинных задач QA специалиста
- Еще один воркшоп, но уже по джедайским техникам работы с Jira
- Круглый стол по тест-дизайну и его практикам
- Разбор разных кейсов построения процессов тестирования – в стартапах, крупных компаниях и аутсорсе

Приходите к нам и делитесь ссылкой со своими QA – будет круто!
podlodka.io/qacrew

Про «обратные собеседования» – когда вместо того, чтобы мучать кандидата вопросами, ты просишь его проинтервьюировать тебя самого.
https://habr.com/ru/post/510574/

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

Я для себя выработал несколько полезных правил, которые, может быть, помогут и вам:
1. Увольнение – это источник очень сильных эмоций для человека. Все, что вы скажете, он будет прокручивать в голове еще долго. Подготовьтесь максимально хорошо и продумайте все возможные сценарии развития разговора.
2. Сейчас нормальный разработчик может найти новую работу за пару недель. Ты не ломаешь жизнь человека, поэтому моральные терзания не должны становиться для тебя блокером для увольнения – делать сложные и неприятные штуки это твоя работа, за которую ты деньги получаешь.
3. Не все люди понимают, что момент их увольнения – окончательный, и могут начать спорить, даже если вы уже много раз это обсуждали. Сразу дайте понять, что торговаться нет смысла.
4. Если вы приняли человека на работу, вы же должны его и уволить. Нельзя перекладывать эту работу на рекрутеров, своего руководителя или кого-то еще.
5. Увольнение не должно быть внезапностью для человека, или вы сделали свою работу очень плохо.
6. Если вы начали думать о том, что пора с кем-то разойтись – не нужно тянуть время. Формализуйте внятные критерии принятия решения и увольняйте, если человек им не соответствует и не исправляется быстро.
7. Как бы гладко вы все не организовали, есть риск начать выглядеть тираном в глазах команды. С этим ничего не поделаешь.
8. Рассказывайте команде о причинах увольнения максимально честно – они все равно все узнают, лучше от вас.

Что самое главное в инженерных процессах, и что тимлид должен делать, чтобы это обеспечить.
http://blog.benjamin-encz.de/post/engineering-process-is-overvalued/

Как в Slack подходят к росту тимлидов внутри команды.
https://slackhq.com/develop-engineering-team-leaders

Стать тимлидом – это только один из вариантов карьеры инженера. Есть и другой, менее популярный – перейти в продакт-менеджеры. Ловите статью с рефлексией инженера, который перешел в продакты, а спустя полтора года вернулся обратно.
http://artsy.github.io/blog/2020/07/23/from-engineering-to-product-management-and-back-again/

Вы могли пропустить, но Дядюшка Боб выпустил новую книгу – “Чистый Agile”. Перед тем, как бросаться читать, можете просмотреть рецензию от Жени Никитина, там все хорошо разложено по полочкам.
https://docs.google.com/document/d/1oGP9CpCslqzKcg_ShLEVYcXKoM9R6UN_mnpMOdogY2U/edit

Пять универсальных принципов организации системы по управлению знаниями в команде.
http://www.nickmilton.com/2020/06/5-universal-principles-for-knowledge.html

Сегодня стартует вторая неделя нашего Podlodka QA Crew, и это идеальный момент, чтобы заскочить к нам на борт – ведь всю неделю мы будем говорить про близкую тимлидам тему организации процесса тестирования! Вы узнаете:
- Как организовать тестирование на продакшне и перейти к fail fast модели
- Как устроено QA в стартапах, крупных компаниях, аутсорсе
- Техники уровня БОГ в работе с Jira
- Разберетесь с тест-дизайном и автоматизацией собственной рутины

Билет на вторую неделю можно купить за 2.400 рублей. Что в него входит:
• Доступ в Slack и к прямым эфирам всех активностей второй недели
• Доступ к видеозаписям про карьеру в QA первой недели
podlodka.io/qacrew

Найм нового человека в команду должен быть в первую очередь важен для тимлида. Рекрутеру плевать, появится ли у вас в команде новый человек сейчас или только через полгода. Рассказываю, как найти кандидатов на свою вакансию мечты.
https://etolstoy.com/hiring/

Транскрипт отличного доклада Виталия Шароватова про увольнения с прошлого сезона Podlodka Teamlead Crew. Учимся увольнять одним днем, разбираться с размером компенсации и решать другие сложные вопросы.
https://sharovatov.github.io/entries/2020-06-firing.html

Размышления про то, станет ли все-таки удаленка новой нормой для технологических компаний.
http://allenc.com/2020/06/getting-to-distributed-teams-as-the-norm/

Еще одна обзорная статья про OKR в вашу копилочку. В тексте там еще есть дополнительные полезные ссылки.
http://pragmati.st/2020/06/16/okrs-delivery-results-adoption-results-impact-results/

Кстати, у меня появился еще один канал, в этот раз про QA – так что подписывайтесь, техлидам бесконечно актуально!
https://t.me/qa_channel

У тимлида есть две мета-задачи – не быть мудаком и помогать своей команде со временем работать лучше. Большинство тимлидов не справляются даже с первой (я и сам такой, чего уж там).

Как определить в себе тимлида-мудака:
1. Вы работаете в режиме черного ящика и оторваны от своей команды. Никто не может точно сказать, чем и почему вы заняты, но щеки вы все равно надуваете и бегаете между сотней митингов.
2. Вы боитесь замарать руки и никогда сами не делаете задач, которыми занимается ваша команда. Типичный сценарий – тимлид, который стал слишком хорош или слишком занят, чтобы попрогать вместе со всеми.
3. Фокусируетесь на решении своих собственных проблем, а не проблем своей команды. Например, настойчиво внедряете условный Scrum, потому что вам ваш босс велел, а не потому, что он команде правда нужен.
4. Внедряете в команду всратые практики, которые не распространяются на вас самих. Хотите, чтобы все вам присылали недельные отчеты? Начните с себя, поживите так пару месяцев, и только потом катите на других людей.
5. Не воспринимаете людей прямо и строите из себя диванного психотерапевта, искренне веря в то, что вы можете понимать их скрытые мотивы.
6. Вы не последовательны в своих решениях и работаете в режиме менеджера-генератора случайных чисел.
7. Подмазываетесь к успехам своей команды, даже если сами руку к ним вообще не приложили, а просто существовали.

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

Про модели принятия решений в командах, их хорошие и плохие отличительные черты.
https://medium.com/@cgroom/on-making-decisions-579354de3166

Что такое личные границы и как их правильно отстаивать, в том числе во взаимоотношениях с командой.
https://habr.com/ru/post/513282

Интересная практика написания менеджерских Readme, в которых ты рассказываешь про свои рабочие принципы и процессы.
https://mattnewkirk.com/2017/09/20/share-your-manager-readme/