В понедельник стартанет новый сезон конференции Podlodka Techlead Crew про Continuous Delivery. Сессии – топовые, я планирую заскочить на вот эти:
📌 Доклад «NFR на поставку». Даже те команды, которые занимаются обеспечением качества, постоянно забывают про различные нефункциональные требования, а особенно – про перфоманс. NFR – классная практика, которая позволяет все такие требования стандартизировать и постепенно автоматизировать. А спикера из AWS вдвойне интересно послушать.
📌 Доклад «Тестирование NFR». Должен хорошо расширить первый доклад, и досыпать теорию конкретными инструментами и подходами.
📌 Публичное собеседование с проектированием системы CD. Публичные собесы – это всегда бодро, а от Владимира Иванова – тем более.

Залетайте на борт, пока не поздно! Для подписчиков канала сделали промокод – techlead_gr_crew.

Практически каждая компания в определенный момент своего развития начинает использовать feature flags – либо только для управления выкаткой отдельных фичей, либо для создания «виртуальных веток» для работы без бранчевания в Git. Чтобы протокол описания фичефлага не переизобретался каждый раз заново, началась разработка OpenFeature, открытого стандарта, аналогичного OpenTelemetry для метрик. Посмотрите, может быть, подойдет и вашему проекту!

#техлидство

Новый твиттер-тред с 15 ментальными моделями, которые могут помочь вам при принятии решений. Вот несколько кайфовых:
📌Ladder of Inference – последовательный алгоритм перехода от доступных данных по какому-то вопросу к конкретным действиям по его решению
📌Pre-Mortem – вы представляете, что ваше решение оказалось неудачным, и раскручиваете его в обратную сторону к причинам, которые могли бы к этому привести
📌Decision Tree – модель реальности, описываемая в виде mutually exclusive collectively exhaustive дерева, позволяющая визуализировать разные сценарии развития событий, их вероятность и экономический эффект

#развитие_себя

Ребята, которые делают сервис анонимных технических интервью, поделились интересными данными про то, насколько навыки коммуникации влияют на успешность собеседования.

Для начала немного объясню, как работает сервис. Анонимный прелставитель крупной технологической компании проводит собеседование анонимного кандидата. После этого интервьюер дает оценку по следующим критериям:
- Прошел ли кандидат на следующий этап
- Навыки программирования (1-4 балла)
- Навыки проблемсолвинга (1-4 балла)
- Навыки общения (1-4 балла)

Анализ данных по 10.000 прошедших интервью показал, что наименьшая корреляция с успешностью прохождения у коммуникаций. С повышением оценки на 1 балл в шкалах программирования и проблемсолвинга вероятность провала секции уменьшается в 1.5-2.5 раза, а с повышением в коммуникациях – всего в 1.1 раз.

Понятно, что собеседования на этом сервисе не отражают положения дел по всей индустрии, но картина получается интересная.

#найм

Один из пунктов, который может появиться в личном плане развития любого тимлида – это прокачка английского языка. Это важно сразу по многим причинам:
💬В любой момент вашей карьеры может появиться необходимость общаться с зарубежными клиентами или подрядчиками
🚜Вы можете решить релоцироваться и пойти по собеседованиям в FAANG как инжиниринг менеджер
📚Большая часть действительно интересной менеджерской литературы – не русскоязычная

Но только добавить изучение английского в план развития – мало. Одна из причин, по которой люди все время начинают и бросают учить английский — незнание своего уровня языка. В итоге берутся за контент, который им не по силам. Например, сериал «Друзья» часто советуют смотреть тем, кто начинает учить язык, но в нём полно юмора, который начинающие пока понять не могут. В итоге разрыв знаний удручает и мотивация снова падает.

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

Есть две крайности в механизмах принятия решений, в которые часто скатываются команды:
👑Авторитарная модель, когда решение за группу принимает один человек
🤝Консенсус, когда для принятия решения требуется согласие всех участниклв

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

Для тех, кто страдает от этих моделей, а в особенности от консенсуса, есть еще один подход. Вместо того, чтобы добиваться активного согласия от каждого участника обсуждения, можно довольствоваться отсутствием активно несогласных. Этот принцип часто встречается под именем disagree and commit. В статье – чуть больше деталей и много дополнительных ссылок для заинтересовавшихся.

#процессы

Большая часть материалов, которые я публикую – это статьи и твиттер-треды. Не забывайте о том, что огромное количество полезных знаний находится в подкастах! Недавно вышел новый подкаст «Для tech и этих» – о том, какими идеями IT-компании меняют мир. В каждом выпуске четыре tech-менеджера СберМаркета — Никита Елагин, Семён Мацепура, Олег Федоткин и Вячеслав Артемьев — обсуждают управленческие решения IT-гигантов и делятся собственным опытом.
🔸Как управлять производительностью огромной команды на примере Uber?
🔸Почему культура достигаторства в Netflix приводит к выгоранию и токсичности внутри команды?
🔸Как Amazon внедряет инновации даже при быстром росте штата?
Подкаст выходит каждые две недели по средам. Первый и второй выпуски уже доступны на всех платформах: https://bit.ly/3asIIK1

Статья с советами для инженеров и менеджеров, которые работают в early stage стартапах:
⚖️При выборе технического решения всегда явно показывайте альтернативы и принятые трейдоффы, это помогает всем выравниваться вокруг единых приоритетов
⏳В первую очередь разрабатывайте те части системы, которые скорее всего не будут меняться. За это время команда получит возможность разобраться с задачами с большей неопределенностью.
📆Не спешите вкладываться в какие-то долгоиграющие инфраструктурные решения – в стартапе все может поменяться в любой день, и это сразу превратится в техдолг.
⌚️Для крупных задач проводите мысленный эксперимент – как бы вы подошли к ее решению, если бы сроки были на порядок меньше – месяц вместо года, неделя вместо месяца. Это может помочь найти какие-то неожиданные решения.
🥱Выбирайте скучные технологии. Слишком экзотический стек не даст вам быстро растить команду при необходимости.

#процессы

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

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

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

Что предлагает проверять автор:
💭Умение думать. Его проверяют обсуждением прошлого опыта и задаванием вопросов «Почему ты сделал Х» вместо «Как ты сделал Х».
🔬Любознательность и насмотренность. Проверяется обсуждением взглядов разработчика на тренды в разработке и его собственное развитие.
🎨Продуктовое мышление. Проверяется, опять же, разговором о прошлом опыте – упоминает ли кандидат о чем-то, кроме технологий, и понимает ли, зачем вообще продукт делается.
🤪Адекватность.

Из интересных правил проведения собеседования:
- Полное отсутствие кода
- 4-5 собеседующих
- Отсутствие стандартного списка вопросов

#найм

Я периодически рассказываю про то, что тимлиду важна техническая насмотренность. Сегодняшний материал как раз из тех, что хорошо ее развивает – разбор того, как выглядит архитектура крупных сервисов, среди которых Uber, Netflix, Amazon.

#техлидство

Одна из веток развития тимлида – project management. Она становится особенно необходима, когда тимлид начинает работать за пределами своей собственной сыгранной команды. Например, отвечать за проект, результат которого зависит от одновременной работы нескольких других команд. И в таких случаях от умения грамотно определять зависимости, управлять договоренностями и ожиданиями зависит то, а получится ли выполнить проект в сроки.

Наши партнеры из Яндекс Практикума проводят бесплатный вебинар про карьеру менеджера проектов. Если вы подумываете прокачаться в этой области – обязательно загляните. О профессии расскажет Станислав Беляев, наставник на курсе «Менеджер проектов» и Engineering Manager в компании Microsoft.

Вы узнаете,
— что ждет младшего менеджера в небольшом стартапе и в корпорации,
— чем джуниор-специалист отличается от мидл-специалиста,
— какие карьерные траектории возможны для проджекта,
— какие знания и навыки нужны для старта в профессии

📆 10 июня в 19:00
👉Зарегистрироваться на вебинар

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

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

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

Уже на этой неделе, 9 июня(четверг), стартует Школа Soft Skills от проекта PSYvIT.

Месяц занятий будет посвящен прокачке 4-х гибких навыков:
⁃ умению учиться
⁃ коммуникабельности
⁃ управлению конфликтами
⁃ формированию work-life баланса

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

Вы сможете проходить курс в комфортном для вас темпе: все вебинары будут в записи в течение 6 недель курса.

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

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

Регистрация закрывается 9 июня 2022. Успевайте!

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

Владимир Горовой, опытный менеджер из Яндекса, проинтервьюировал кучу коллег из разных компаний и собрал список того, что отличает успешных в их глазах техлидов, и как они могут развиваться. Картинка сложилась довольно реалистичная. Главные атрибуты хорошего техлида по версии автора:
🛠Техническая экспертиза и доверие менеджеров к ней
💰Вовлечённость в продукт и понимание того, как он влияет на бизнес
🏞Способность менять свою модель мира и видеть мир на разных уровнях детализации;
💭Умение учиться у других, развиваться самому и развивать других;
❤️Cтрасть и увлеченность своей работой

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

#развитие_себя #техлидство

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

Вот несколько инсайтов:
⏱Разные часовые пояса могут стать плюсом, если правильно распределить нагрузку. Например, наличие географически-распределенных QA часто позволяет быстрее проходить через этап тестирования.
📆Распределенная работа заставляет внимательнее подходить к тайм-менеджменту и подготовке общих встреч.
📖Отсутствие возможности в любой момент дернуть любого коллегу и уточнить договоренности приводит к тому, что они четче описываются заранее.

#процессы

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

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

Яндекс Практикум приглашает вас на курс «Как управлять командой. Курс для руководителей».

За 4 месяца вы научитесь:
* расставлять приоритеты;
*  оптимизировать процессы подразделения;
* системно развивать команду.

Курс подойдёт вам, если: 
* вы — действующий руководитель; 
* ваш управленческий стаж меньше трёх лет; 
* у вас в подчинении есть команда с постоянным составом. 

Начать учиться →

Тимлидам сложно увидеть результат своей работы. Обратная связь между предпринимаемыми действиями и их результатами гораздо более слабая и отложенная, чем в инженерной работе. Это часто становится причиной тревожности – «А хорошо ли я справляюсь со своей работой?», «А точно ли я не работаю слишком мало?», «А вдруг меня скоро уволят?».

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

Побольше про феномен тимлидской тревожности можно почитать в этой статье. А для более глубокого погружения в тему тревожности, попробуйте книгу «Свобода от тревоги» Роберта Лихи, мне ее очень рекомендовали.

#книги #развитие_себя #антипаттерны

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

Интересный подход к разделению всей инженерной работы на два типа:
😌Positive engineering – ежедневные задачи, направленные на создание видимой ценности для продукта
😞Negative engineering – задачи, направленные на «страховку от поломок» для критичной продуктовой функциональности

К negative engineering можно отнести, например, корректную обработку исключений. Или инфраструктуру для регулярной проверки целостности данных.

То, сколько времени затрачивается на negative engineering, напрямую зависит от того, в какой момент жизненного цикла фичи приходится этим заниматься. Если «страховочная» инфраструктура закладывается заранее, то часто можно на системном уровне закрыться от целого класса проблем. Если об этом не подумать, то платить придется позже, постоянно добавляя все новые и новые патчи.

#техлидство