Product Developer

Систематизация vs бюрократия

Талантливые ребята обычно умеют систематизировать, даже если делают это интуитивно.

Здесь под словом «систематизация» я имею в виду создание логической структуры, чтобы любой процесс или информация стали понятными, воспроизводимыми и управляемыми.

И тут ключевое слово — управляемыми.
Потому что если ты не можешь управлять чем-то, ты либо оставляешь это на волю случая, либо начинаешь реагировать на пожар, а не предупреждать его.

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

Но обычно люди в команде очень разные. И все они ошибаются.

И вот менеджер видит, что не все «достаточно талантливые», и начинает вводить процессы, чтобы подстраховать от ошибок.

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

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

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

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

Вы действительно оптимизируете работу?
Или пытаетесь защититься от некомпетентных и неуправляемых сотрудников?

Точно ли нужно строить работу с некомпетентными сотрудниками через внедрение процессов?
А когда вы в последний раз пересматривали или отменяли какой-то процесс?

StarMap — карта компетенций команды

Шаблон
Забрать себе: File -> Make a copy


В двух словах — это экселька, где строки — компетенции, столбцы — ФИО, а значения в ячейках — степень владения компетенцией:
— 0 — нет навыка
— 1 — учится
— 2 — умеет самостоятельно
— 3 — может учить

А еще в этом шаблоне автоматически считается бас-фактор и риски.

Зачем вам стармап?

Для инженера:
— понять, какие навыки прокачивать, чтобы это было полезно команде
— увидеть, где можно выступить ментором
— сориентироваться, к кому идти за советом

Для тимлида:
— составить портрет команды «as is»
— увидеть бас-фактор и ботлнеки
— составить картинку «to be», целевой портрет
— проактивно пойти к разработчикам с запросом на прокачку конкретных навыков
— составить профиль кандидата для найма

———

4 года назад я уже писал пост про стармап — тогда это был способ продать его инженерам в моей команде с точки зрения пользы для них 🙂

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

Вот к чему я пришел:

1. Составлять стармап командой — дорого.
Не подумайте, я не отговариваю вас. Если команда сама хочет — буду только рад!
Но обычно разработчики не покупают это «менеджерское» упражнение. Приятнее фичу напилить 🙂

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

2. Составлять тимлидом — дешевле, и в большинстве случаев эффективнее

Во-первых, это оказался супер полезный инструмент для онбординга тимлида в новую команду.

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

Но есть минусы: без команды можно упустить компетенции. Поэтому так или иначе нужно собирать список с ребятами.

И тоже не всегда это упражнение оправдано:
— Если в команде 3 человека — скорее всего, компетенции можно удержать в голове.
— Если не планируется нового найма — то и профиль кандидата составлять не нужно.
— Если бэклог устаканился и очевидно, что все компетенции в команде есть.

Хотя повторюсь, без выписывания на бумагу есть риск что-то упустить. Даже в команде из 3 человек с устаканившимся бэклогом.
Поэтому если есть возможность и желание что-то систематизировать — со стармапом будет лучше.

———

Забирайте шаблон (File -> Make copy), составляйте стармапы, пишите комменты к посту 🙂

P.S. Шаблон — на самом деле реальный стармап одной из команд, в котором я поменял имена. Список компетенций может вас заинтересовать, но предостерегаю от прямого копирования.

10 привычек растущих сотрудников

К слову о привычках.
Я вписался в 9-месячный курс от Стратоплана за дохрена денег. Проходной балл высокий: не достаточно заплатить, — нужно еще сделать тестовый кейс и пройти собеседование.
Стратоплан — господа уважаемые. Могут себе позволить, так сказать 🙂
В общем, кейс я решил и собес прошел, поэтому иногда буду писать свою рефлексию на тему материалов курса.

А пока — приношу бесплатную полезность: 2х-недельный марафон, который подойдет вообще всем: инженерам и тимлидам, аналитикам, продактам, СТО и фаундерам.
Начнется 13 января.
Спикерами и авторами будут команда тренеров Стратоплана, а также уважаемые товарищи по телеграм-каналам: Евгений Антонов («Тимлид очевидность»), Ольга Елисеева («Teamlead с места в career»), Александра Баптизманская («Нестыдная фасилитация»).

Каждый день будет либо эфир, либо лонгрид.

Вот некоторые привычки:

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

О каждой расскажут не только, почему она полезная, но и как её себе привить.

Участие бесплатное, доступ ко всем материалам останется навсегда.
Нужно только зарегистрироваться: https://stratoplan-school.com/habits/
13-25 января.

P.S. за этот пост мне не платили

Талант vs системность и трудолюбие

Вася — молодец! За что ни возьмется — всё у него хорошо получается.
Быстро разбирается в новом проекте, проектирует идеальную архитектуру и пишет рабочий код с первого раза.
Если нанимает разработчика — тот обязательно окажется топ-перформером.
Запускает проекты в срок и качественно.

Процессы и метрики для Васи — это оверхед. Лишняя нагрузка, мешающая творить:
— Зачем измерять велосити? Срок назвали, попадаем, чего еще надо?
— Зачем составлять профиль кандидата? Не так много хороших людей на рынке, чтобы к ним какую-то линеечку прикладывать.
— Какой такой cycle time? Вам шашечки или ехать?

Если Вася преуспевает с таким подходом, то скорее всего ему помогает талант.

Проблема в том, что большинство людей — не Вася.
В этом сложно признаться. Я сам сейчас сижу и думаю: «Ну я-то точно талантливый» 😅.
Вернее, раньше мне так казалось. Но за последние годы что-то поменялось.

Может, появление ребенка заняло всё внимание. Может, бюрократия и обустройство жизни в эмиграции.
Но головы стало не хватать.

Если я буду делать всё, как Вася, — то у меня получится хреново.

Поэтому я включаю системность и трудолюбие. Перестаю плеваться от «оверхеда» и ищу в нём пользу:
— При найме составляю целевой портрет команды и профиль кандидата, чтобы самому лучше понять, кого ищу.
— Слежу за метриками, чтобы вовремя заметить: команда берёт в спринт в 2 раза больше работы, чем может сделать.
— Планирую агенду встреч и веду заметки, пишу follow-up чтобы потом не гадать, о чем договорились.
— Выписываю плюсы, минусы и риски перед сложными решениями. По рискам сразу пишу план митигации.

Это отнимает кучу времени. На реальные дела остаётся только 50%.
Но это помогает не обосраться.

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

Решение проблемы плохого WiFi

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

На каждой работе у меня был коллега_с_хреновым_интернетом.

Кажется, это мелочь и его личная проблема. В конце концов, код пишется и дело делается, так что можно и потерпеть.

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

Работать с таким человеком просто неприятно: размытая картинка, пропадающий голос, непонятно, услышал он тебя или нет. А ещё постоянные вылеты со встреч.

Привет, последние полтора года это я 😅

Я борюсь за интернет с соседями.
На прошлой неделе наконец-то победил!

Живу в многоквартирном доме, где ноут видит 20+ WiFi сетей. Ethernet розеток нет, а вход для роутера закладывался в одном месте во всех квартирах. Поэтому все роутеры соседей стоят в одном углу, а стены у нас тонкие.

Из-за этого WiFi нестабильный даже рядом с роутером.

И это люто бесит.
Расскажу, как боролся и как победил.

Помогло решение, к которому шел 1.5 года:
Ethernet over Powerline.

Устройство преобразует цифровой Ethernet в радио сигнал, и пуляет его в розетку, используя провода под напряжением как среду для передачи сигнала.

На другой стороне приёмник проделывает обратное преобразование: ловит радио сигнал из розетки и преобразует его в цифровой Ethernet.

Я слышал об этом еще лет 15 назад, но тогда подумал, что это какая-то хрень и работать нормально не будет.

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

Как же я охренел, когда это завелось.

Просто воткнул девайс в розетку, а Ethernet кабель в роутер и в ноут. И теперь ноут думает, что он напрямую подключен в роутер.

Да, обещанного 1ГБит не дало, но пинг до гугла 9мс и speedtest показал симметричные 170МБит.

Теперь это мой мастхэв для съемного жилья.
Потому что провод всегда стабильнее чем Wi-Fi!

———

Как пришел к этому решению?
Расскажу путь, чтобы вы могли его не повторять 🙂

1. Выбор канала WiFi.

В WiFi 2.4Ghz есть 100MHz и 11 каналов. При этом каждому каналу нужно минимум 20Mhz для модуляции сигнала. Получается, что каналы работают с перекрытием.
Поэтому по факту выбор стоит между 1, 6 и 11.
Если рядом стоят три и более роутера — они друг другу мешают.

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

В MacOS есть встроенная утилита «Беспроводная диагностика» (в меню «Окно» -> «Сканирование»), которая помогает найти менее зашумленный канал.

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

2. Смена роутера на WiFi 5GHz

Решил я попробовать современные технологии — WiFi 5GHz
Каналов больше, проблемы шумных соседей быть не должно.
Прекрасно, подумал я, и заказал новый роутер.

Но оказалось что до дальнего конца квартиры, где я работаю, WiFi 5 не долетает.

3. Провод

По квартире разведены телефонные розетки. Прекрасно, подумал я, и купил обжимку + 4-жильный телефонный кабель + горстку RJ45 и RJ11 коннекторов.

Я осознавал сразу, что это тупиковый путь, но всё равно решил попробовать Вот, пишу, можете не пробовать 🙂

Телефонные провода, даже 4-жильные, не подходят для передачи Ethernet сигнала. То ли изоляции нет и наводки слишком сильные, то ли кабель с большим сопротивлением.

В общем, устройства друг друга не видели.

Дальше думал уже ставить WiFi репитер, но идея использовать провод меня не отпускала.

———

Короче, если мучаетесь с WiFi — попробуйте Poweline Adapter!
Оно того стоит.

P.S. Поделитесь в комментах, какие еще есть варианты решения проблемы, которые я не попробовал?

Стиль менеджмента Linux kernel

«Прежде всего, я бы посоветовал купить “Семь навыков высокоэффективных людей” и не читать. Сожгите, это отличный символический жест.»

Сижу хихикаю со статьи Линуса Торвальдса про менеджерские практики в разработке ядра линукса.

Персонаж эпотажный, запомнился мне словами «Nvidia, fuck you».
Статья, соответственно, написана в таком же стиле.

———

1️⃣ — Решения

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

Если кто-то говорит вам: “выбирайте (а) или (б), нам нужно, чтобы вы приняли решение”, — у вас проблема. Люди, которыми вы руководите, лучше знают детали, чем вы. Поэтому, если они обратятся к вам за техническим решением, вы не должны принимать это решение за них.

…

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

И люди даже будут воспринимать это как истинное лидерство (кхе-кхе, чушь собачья).

2️⃣ — Люди

Большинство людей — идиоты. Быть менеджером означает, что вам придется иметь с ними дело, и, что более важно, — им придется иметь дело с вами.

Оказывается, что посраться с людьми довольно легко, а вот завоевать доверие — сложно. Таким образом, срач немедленно подпадает под категорию “необратимых” решений и становится запретным в соответствии с п. 1. Решения.

Здесь есть всего несколько простых правил:

1. не называйте людей придурками (по крайней мере, публично)
2. научитесь извиняться, если забыли правило (1)
3. уважайте всех в равной степени, чтобы никто не чувствовал себя несправедливо обиженным

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

3️⃣ — Люди — хорошие

Большинство людей - идиоты, и как следствие — вы тоже.
Поэтому всегда найдётся кто-то умнее.

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

Когда вы найдете кого-то умнее себя, ваши управленческие обязанности сводятся к тому, чтобы говорить: «Звучит как хорошая идея — дерзайте» или «Звучит хорошо, но что если xxx?»

Вторая версия, в частности, является отличным способом либо узнать что-то новое об «xxx», либо проявить себя как руководитель, указав на то, о чем более умный человек не подумал. В любом случае вы выигрываете.

4️⃣ — Поиск крайнего

Что-то обязательно пойдет не так, и люди захотят кого-нибудь обвинить. Это будете вы.

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

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

Затем лично сообщите разработчику, который на самом деле облажался, что он облажался. Не только для того, чтобы он мог избежать этого в будущем, но и чтобы он знал, что он у вас в долгу. И, что еще важнее, — он, скорее всего, тот человек, который может это исправить. Потому что, давайте посмотрим правде в глаза, это точно не вы.

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

———

Это не все пункты, советую почитать оригинал.
Я не со всем согласен, местами у самого горит.

Должен ли менеджер принимать решения?
Должен ли разработчик нести ответственность за свои косяки?

Давайте обсудим в комментах 🙂

Микросервисы в Kubernetes — это ответ!
… а какой был ваш вопрос?

Спонсор поста — Selectel.

Давайте порассуждаем, зачем вообще вам микросервисы и Kubernetes.

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

Но на мой взгляд основная причина очень простая — потребность пилить больше фич, а для этого расти в количестве разработчиков и не толкаться локтями.

Именно сложность параллельной разработки на монолите приводит всех к микросервисам.

Казалось бы, можно и в монолите выстроить хорошую архитектуру, которая четко разделит домены и проведет мостики между ними, чтобы обеспечить пресловутые low coupling & high cohesion.

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

Микросервисы и API как мостики для взаимодействия между ними — системное решение для low coupling & high cohesion.

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

Но приходя к микросервисам мы сталкиваемся с накладными расходами:
— Сложнее управлять деплоем и масштабировать
— Сложнее доставлять конфиги и писать логи
— Сложнее делать трассировку запросов и собирать метрики.
А еще нужно обеспечить стабильность не только приложения из микросервисов, но и всей этой машинерии.

Можно всё собирать самому. Начать с Docker-compose на трёх виртуалках, самому поднимать nginx, самому настраивать маршрутизацию. В какой-то момент нагрузка потребует добавления виртуалок и каждый раз — это будет ручная работа и накладные расходы:
— Арендовать еще железа
— Поднять там виртуалки
— Настроить на них все компоненты
— Включить в балансировку
— ….🤯

Можно автоматизировать развертывание своих велосипедов на независимых компонентах, но скорее всего в итоге всё равно придём к Kubernetes.

А это еще больше накладных расходов на сетап и обслуживание компонентов K8s.
Да и в целом правильное управление k8s — это отдельная большая область знаний.
Зачастую в компаниях есть отдельные «DevOps’ы», которые занимаются чисто кубером.

Но Kubernetes — реально отчуждаемая часть, где гораздо проще отдать ответственность хостеру и потом требовать выполнения SLA.

И здесь я верю, что с помощью Managed Kubernetes можно сэкономить и упростить себе жизнь.
Особенно если вы и так хоститесь не в своих датацентрах, а арендуете инфру.

Сервис сам разворачивает кластер Kubernetes с Control Plane, настраивает сетевое окружение, глобальный роутер и поднимает группу нод на выделенных серверах. Со стороны инженеров не нужно париться об администрировании. Вам нужно только выбрать тип кластера и конфигурацию в панели управления. При этом есть доступ к kubectl и всему, что требуется для деплоя ваших микросервисов и маршрутизации трафика снаружи и между ними.

Из плюсов именно Selectel — воркер-ноды работают не на виртуалках, а на выделенном железе. А это убегерает от спецэффектов «шумных соседей» и оверхеда виртуализации. Как итог — обещают экономию на 40% по сравнению с арендой виртуалок.

Подробнее — на лендосе Managed Kubernetes от Selectel.
Реклама, АО «Селектел», ИНН: 7810962785, ERID: 2Vtzqx9pGZm

———

Поделитесь в комментах — поднимали ли вы хоть раз кубер?
Сколько времени это заняло в первый раз и сколько времени тратите на поддержку?

Идемпотентность
… То, о чем многие слышали, но стеснялись спросить 😁

Разбавим менеджерские посты и немножко попроектируем, чтобы разобраться с понятием идемпотентности.
Приведу типичный диалог с Systems Design интервью.

Делаем платёжную систему.
Пользователь хочет отправить другу 1000р.
Но вдруг дрогнула рука, и он дважды нажал кнопку «оплатить».
В итоге отправилось два запроса и с карты списалось дважды.

Что делать?
— «Давайте отключать кнопку после первого нажатия!»

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

Допустим, запрос на сервер пришел, сервер его корректно обработал, но из-за сетевых проблем ответ не вернулся.
Клиент видит сообщение «что-то пошло не так, попробуйте еще раз», нажимает повторно — и списываются ещё 1000р.

— «Давайте дедуплицировать запросы по сумме и назначению!»

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

Идемпотентность — это свойство операции, при котором повторное выполнение будет давать тот же результат, что и первое.

Простыми словами: даже если клиент отправит один и тот же запрос 10 раз, результат будет один и без дополнительных сайд-эффектов.

Казалось бы, можно пост на этом заканчивать.
Но подождите, есть еще не обработанные ситуации:
— Что, если пользователь реально хочет отправить еще тыщу?
— Что делать партнёру, который интегрировался с нашим платёжным шлюзом по API и автоматизировал выплаты своим клиентам?
Ему надо отправить 1000р сейчас и еще 1000р через минуту.

Попытки дедуплицировать по параметрам усложняют логику:
— Сколько времени хранить историю запросов?
— Что делать, если в запросе 100 параметров?
— Что если реально надо отправить подряд три транзакции по 1000р?

Ключ идемпотентности помогает решить эту проблему.

Идея простая:

1. Клиент генерирует уникальный ключ (например, UUID) для каждого запроса.
2. Все повторные попытки отправляются с этим же ключом.
3. Сервер хранит результат выполнения операции по этому ключу и возвращает его при повторных запросах.

Реализовать идемпотентность можно по-разному. Самое простое — кеширование ответов по ключу идемпотентности. Так, например, сделано у Stripe.
На картинке sequence-диаграмма с более сложным, но персистентным вариантом — ключ идемпотентности прикапывается в нашу транзакцию.

В качестве бонус-контента дам ссылку на моё любимое видео — Идемпотентность на коровах.
В двух словах — «Беременную корову нельзя осеменить повторно».

———

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

А вы учитываете идемпотентность при проектировании?

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

Пример целей моего тимлида

———

Этот пост — завершающий в серии про онбординг -> Первый пост с шаблоном чеклиста онбординга.
Сегодня поговорим про цели на ИС.

Когда прохожу собеседования, всегда спрашиваю: как вы через 3 месяца поймете, что я молодец? Зачастую ответы достаточно размытые: процессы работают, таски пилятся, продакт и команда довольны — вот и все критерии.

И это, в целом, нормально. В IT невозможно описать полный список обязанностей в трудовом договоре и критерии прохождения ИС, и я точно не призываю так делать. Этот пост не про KPI и не про формальные критерии прохождения ИС и точно не про инструмент для увольнения после испыталки.

Но есть риск: если ожидания от вас не сформулированы, то вы их можете неправильно понять и не попасть в них. И в итоге оказаться «так себе сотрудником», хотя работали усердно и по вашему мнению всё делали идеально.

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

💡Как составлять цели.

1️⃣ — Описать образ не только хорошего результата, но и превышения ожиданий, а также недостаточного результата.

Так мы поймем, что для руководителя «нормально», а что «прям вау». Ну и где «так себе». Это даст лучшее понимание ожиданий от роли, куда нужно двигаться чтобы получить промо, а где нужно обращать внимание, чтобы не упустить из виду важное.

Пример — составить долгосрочную техническую стратегию команды.

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

2️⃣ По возможности разделить на метричные и проектные.

Метричные дают больше свободы в достижении. В работе с тимлидом важно говорить «что» нужно достичь и оставить достаточно свободы, чтобы он решил сам, «как» это реализовать. Примеры метричных целей: SLI сервисов, % флакующих тестов, Scope Drop спринта, % выполнения квартальных OKR.

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

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

Итог

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

Цели на ИС — это способ переложить ожидания из головы руководителя в голову новичка, чтобы сфокусировать его на самом важном. Дать понять, по каким признакам будет оцениваться его работа.

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

Что такое Кейс-интервью

Disclaimer: это реклама Кейс-клуба от Карьерного цеха

Наём — штука несправедливая, а процесс во многих случаях похож на сдачу экзамена. Это хреново, но такова жизнь.

В общем случае у компаний есть два способа проверить, что менеджер хорошо справится с работой:

1. Искать релевантный прошлый опыт и спрашивать детально, как дейстовал
2. Давать гипотетический кейс и спрашивать, как решал бы

И если в прошлом подобного опыта не было, тогда остается только кейс.

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

Почему? Простой ответ — потому что не умею решать кейсы.

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

Задать не слишком мало и не слишком много вопросов. При этом решать аргументированно и отстаивать свою позицию.

В общем, я поставил себе задачу — научиться решать кейсы.

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

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

Для каждого уровня подбирается свой эксперт:
- Junior решают кейсы с Middle+ и Senior
- Middle & Senior с CPO, хедами и лидами.

Занимает 2 часа в неделю. Все кейсы решаются прямо на занятии, домашек нет.

Кейсы для продактов, но мне показалось релевантным и для тимлидов, поэтому я вписался!

Присоединяйтесь!

Онбординг тимлида (и других менеджеров). Часть 2.

Этот пост — второй из серии про онбординг менеджера и цели на испытательный срок.
Пост про первый месяц тут.

Во второй и третий месяц — продолжаем знакомства, зарабатываем авторитет и показываем результат (и что делать, если нет).

1. Знакомимся с внешними людьми: другие менеджеры, HR BP, стейкхолдеры и заказчики. В разговоре стоит узнать, какие у них есть боли и ожидания от вашей работы.

Можно использовать стандартные вопросы:
— Чем занимаешься? Какие задачи стоят перед тобой или твоей командой?
— Чем мы можем быть друг другу полезны?
— Какие у тебя ожидания от меня? Чем я могу тебе помочь?
— Нужны ли нам регулярные встречи?

2. Зарабатываем авторитет

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

Вы должны ассоциироваться с пользой, которую приносите. Авторитет можно нарабатывать на маленьких полезных делах, которые улучшат жизнь команды, но не требуют больших усилий. Например, решить проблему с доступами или выдачей техники, или настроить ci/cd для автоматического деплоя. Быстро и «дёшево», но это повысит ваш авторитет среди команды.

Можно «позаимствовать» авторитет у неформального лидера. Обсудите с ним свои идеи по улучшению процессов или техники прежде чем презентовать команде. Вы можете не учесть каких-то корнер-кейсов, потому что ещё недостаточно погружены в контекст, а лидер даст обратную связь и поможет доработать предложение — чтобы команда сразу его приняла.

3. Показываем результаты

Руководитель обычно ждёт, что к третьему месяцу вы начнёте показывать какие-то результаты. Поэтому на этом этапе стоит проверить прогресс по целям и собрать обратную связь. Попросить команду дать обратную связь лучше через кого-то нейтрального, например, вашего руководителя или HR. Так ответы будут честнее.

Бывает так, что по некоторым целям показать результаты за 90 дней не получается. На то могут быть объективные причины: например, в команде накопилось много легаси или процессы до вас были настроены плохо и за оставшийся месяц их не исправить. Обязательно обсудите проблемы с руководителем и предупредите, что результатов через месяц не будет.

Скорее всего, он сам понимает, что не всё можно быстро исправить. Но он точно ждёт, что за время онбординга вы разберётесь, какие проблемы есть и что с ними делать. Если вы предупредите о проблемах заранее и предоставите план их решения, у руководителя сложится хорошее впечатление: у вас всё под контролем.

Итог

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

2. Планируйте свой онбординг. Хорошая идея — использовать для этого чек-лист. Можно воспользоваться шаблоном.

3. Зарабатывайте авторитет. Маленькими победами или с помощью авторитета неформальных лидеров.

4. Не страшно, если не получается показать результат за 90 дней. Главное, чтобы у вас был план, и вы ему следовали.

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

Следующий пост в серии — про то, как ставить цели на испытательный срок в виде OKR, и какие результаты реально показать за 3 месяца. Там же приведу пример из последнего онбординга тимлида в моем юните.

Онбординг тимлида (и других менеджеров)
шаблон чеклиста

«Вот команда. тимлидь» — говорят тимлиду и возвращаются только через 3 месяца, чтобы сказать, что он молодец (или не очень).

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

^^ Вы могли подумать, что это сарказм, и это правда, но на половину. Если цели и план онбординга есть от руководителя — хорошо. Но если нет, — важно, чтобы тимлид составил их сам и выровнялся по ожиданиям.

В серии постов поговорим про план онбординга и цели. Это саммари выступления Толи Панова на Podlodka TL Crew, улучшенное и дополненное моими мыслями и материалами.

Первый месяц онбординга

— 1-я неделя: знакомство с командой

На общих встречах и индивидуально обменяться с ребятами ожиданиями, спросить о проблемах, где нужна помощь.

Можно использовать чеклист вопросов для первых 1-1 с инженерами, который составил мой тимлид.

Мой любимый вопрос — «Зачем тебе тимлид?». Если у инженера есть содержательный ответ — это бесценный источник информации для онбординга.

Еще один ценный вопрос — «что работает хорошо и нужно не сломать». Поможет понять, что ценят в текущих процессах — это не стоит поначалу менять.

— 2-я неделя: изучение целей команды

Сначала цели стоит разделить на командные и личные.

Командные — проекты, которые бизнес или заказчики ждут от вашей команды.

Личные — задачи, для выполнения которых обязательно ваше участие. Например, команда пятый спринт подряд факапит цели и продакт просит вас с этим разобраться.

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

Продакт погрузит в цели и проекты команды. Стоит попросить его рассказать не только о том, чем команда занята сейчас, но и о планах на 3-6 месяцев.

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

— 3-я неделя: формирование целей, определение приоритетов

Здесь всё зависит от предыдущего пункта.
Совет — фокусироваться на том, что не решится без вашего участия.
Личные цели — за вас никто не сделает.
Наём команды — самому все проекты не затащить.

В разговорах с ребятами из пункта 1 может помочь вопрос: «Если бы ты был мной — на чем сфокусировался бы?»
В итоге стоит эти приоритеты зафиксировать и выровняться с руководителем.

— 3-я неделя: изучение команды
Когда вы знаете цели, какие проекты горят и какие есть проблемы, — пора предметно посмотреть на команду.
Есть ли все нужные компетенции?

Здесь может помочь StarMap команды. Это таблица, где в строках навыки, которые нужны команде для работы: языки, фреймворки, модули, компоненты, сервисы и тд. Каждый столбец — это член команды, который обладает навыком, готов учиться, или готов учить других.

— 4-я неделя: погружение в проекты

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

Важная ремарка: если руководитель сразу говорит, что проект Х — суперважный, то не стоит откладывать на 4ю неделю.

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

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

———

Итогом первого месяца должно стать понимание вводных, постановка реалистичных целей, и начало движения по этим целям.

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

Сколько зарабатывают бэкендеры?
А продакты? А тимлиды?

Есть сервисы, где анонимно публикуют зарплату и отзывы о работодателях.
Из зарубежных известных — Glassdoor и levels.fуi
А вот у нас такого нет. Вернее, не было до недавнего времени.

Знакомые ребята запустили в телеге Glassdoor на минималках — Getmatch. Инсайдеры из российских IT-компаний анонимно расказывают о процессе собеседования в бигтехи, сколько на самом деле платят, приходится ли перерабатывать, есть ли токсики в команде, какие шансы вырасти по зарплате в компании и что для этого делать.

Там же ребята делятся опытом прохождения собесов, рассказывают, что спрашивают на секциях, какие этапы и какие офферы.

Мой любимый пост — про бэкендера с зп 950к.

А еще публикуют исследования, например «Как выросла зарплата продактов за 3 месяца?» или «Кто зарабатывает больше продакты или проджекты?».

Канал хорош, а комменты под постами — прямо огонь 😄 Видно, что тема цепляет. Чуваки набрали 15к подписчиков за 2 месяца. Я подписался.

@g_jobchannel

Инцидент-менеджмент

«Инцидент» — что для вас в этом слове?

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

Вы когда-нибудь задумывались, что 99.99% доступность — это не больше 4 минут даунтайма в месяц?

Успеть отреагировать и починить инцидент за короткое время — целая отдельная область знаний со специальными профессиями: Дежурные мониторинга, SRE, Инцидент-менеджеры. Но и без разработчиков сервиса не обойтись.
Из каждого инцидента должны быть выводы, а система должна становиться чуточку надежнее.

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

Ведущие — Виктор Корейша, руководитель направления Managed Services в Ozon, и Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure и автор канала «Тимлид Очевидность».

Гости подскаста — Андрей Борзов, заместитель технического директора по эксплуатации в Туту и Андрей Чупейкин, CTO блока платформы в Ozon.

Слушайте на удобной платформе

Рост инженера в тимлида

1 октября один из наших инженеров стал менеджером.
Поздравим Никиту! 🚀
И немного посочувствуем ему 😅

Часто тимлидом становится самый сильный инженер после ухода или повышения руководителя.
Обычно это выглядит так: «Вася уходит, теперь ты тимлид. Поздравляем, готовься страдать»

Так компания может потерять хорошего инженера, а взамен получить плохого менеджера.

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

Есть системный подход, который повышает шансы на успех мероприятия.
На примере Никиты, который за 1.5 года после трудоустройства вырос до тимлида, посмотрим, как в Авито устроен процесс.


1️⃣ — Сначала стать отличным инженером
Из плохого инженера хороший менеджер не получится.

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


2️⃣ — Проявлять задатки менеджера
… а не быть самым технически прокачанным и авторитетным

Переход инженера в менеджера возможен начиная с грейда Е5. Для понимания, есть еще Е6-7-8.
Никита пришел как раз на Е5, и у него уже был опыт тимлидства на прошлом месте.

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

3️⃣ — Определить точку А
какие компетенции менеджера уже есть, а каким нужно учиться.

Для этого в Авито есть секция «Оценка менеджерского опыта», если кандидат был тимлидом в прошлом.
Либо «Кейс», если опыта заведомо нет.

На этапе «оценки опыта» мы определили, какие компетенции у Никиты не было возможности прокачать на прошлом месте, но Авито ожидает их от готовых тимлидов. Эти компетенции позже мы будем осознанно прокачивать.

4️⃣ — Должно быть обоюдное желание
Спустя полгода Никита сказал, что посмотрел на работу тимлида в Авито и передумал 😂. Поэтому мне пришлось открывать вакансию тимлида, когда тимлид Авторизации ушел в саббатикал.

Спустя еще 3 месяца, Никита решился, но тимлида я уже нанял. На первый взгляд это проблема, но на самом деле — совсем нет.
В Авито есть TechLead Hub — это пул обученных кандидатов в техлиды, которые прошли интервью и готовы стать техлидами в других командах.

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

5️⃣ — Получить теоретическую базу
Мы предложили Никите пройти внутренний курс Engineering TeamLead School. На курсе он узнал что-то новое и систематизировал то, что уже знал: про управление людьми, командами, процессами, целеполагание и бизнес.

6️⃣ — Попрактиковаться будучи инженером
Чтобы выполнять задачи тимлида, не обязательно официально им быть. Никита начал применять знания на практике: процессы потюнил, квартальный роадмап построил, в найме поучаствовал, в онбординге помог.

7️⃣ — Пройти интервью
Это обязательный этап. Его проводит независимый руководитель из другого кластера, чтобы оценить готовность кандидата. Не все проходят это интервью с первого раза. Например, я прошел на TUL только со второго раза, прокачав западающие навыки после первого интервью.

8️⃣ — Поздравляю, у вас тимлид.
Дальше — долгий путь перехода, «онбординг» и цели на «испытательный срок».
Бросать на этом этапе свежеиспеченного тимлида — очень рискованно.
Но об этом будет следующий пост.

———

А вы видели воочию, как инженер становился тимлидом? Поделитесь!
Особенно интересно, как это ощущается среди разработчиков, когда твой вчерашний братишка — теперь твой руководитель.

Предположения и жопа

When you assume, you make an ass of you and me.

Недавно наткнулся на эту фразу, решил поделиться 😅
Мой вольный перевод: «Когда ты предполагаешь, ты выставляешь дураком и себя и меня».
Смысл в том, что предположения могут приводить к ошибкам, из-за которых в итоге пострадают обе стороны.

Представим ситуацию:

1. Петя ждёт задачу Васи, чтобы приступить к своей. От этого зависит цель спринта.
2. Петя уходит на полспринта в отпуск, рассчитывая, что задача Васи будет готова к середине спринта.
3. Вася, между тем, решает начать с более интересных для себя задач. Ведь никто не уточнял приоритеты.
4. Петя выходит из отпуска и видит, что задача только взята в работу.
5. В итоге Вася успел все свои задачи, Петя не успел ничего, а цель спринта — провалена.

Что происходит дальше?

Петя злится на Васю, обвиняя его в непрофессионализме.
Вася чувствует себя несправедливо обвинённым, ведь он сделал все свои задачи.
Но при этом цель спринта провалена и Вася чувствует свою ответственность за это.

Оба оказывается в жопе неудобной ситуации.

Почему? Из-за того, что оба сделали предположения, но не потрудились обсудить реальные ожидания.

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

Podlodka Techlead Crew с 14 по 18 октября

До Авито у меня не было опыта работы с канареечными релизами и graceful degradation, про circuit breaker я только слышал, а feature-toggles готовил неправильно.

Мне бы помог следующий сезон Techlead Crew — «Проектируем надёжность»!

Смотрите, какие крутые сессии и спикеры:

1️⃣ — Архитектурная ката «Проектируем надежность»
Будем в командах решать реальные архитектурные задачи, изучать новые методы и подходы.

Проведут:
— Павел Лакосников, руководитель Arch Governance в Авито;
— Игорь Антонов, Тимлид в Т-Банке;
— Григорий Скобелев, Techlead в Plata и директор ПК Techlead Crew;

2️⃣ — Доклад «Канареечный деплой: от стратегии к надежности»
— Илья Садыков, Senior Backend Engineer в Авито,
поделится опытом развития канареек в Авито. Считаю, тут это очень круто сделано, и доклад будет полезен мне самому, чтобы понять особенности механизма.

3️⃣ — Круглый стол «Архитектура на старте: подготовка к успеху»
— Александр Поломодов (Т-Банк) и Олег Бондарь (Яндекс) обсудят ключевые принципы надежной архитектуры и механизмы самоисцеления и повторных попыток.

4️⃣ — Публичное собеседование Техлида
Проведет Григорий Кошелев. В ходе интервью проверим, насколько техлиды понимают важность надёжности систем.

И еще 6 крутых сессий! Я делал HR Crew и Teamlead Crew в составе программного комитета и могу сказать, что ПК подлодки старается сделать каждый сезон лучше предыдущего.

От всей души рекомендую https://podlodka.io/techcrew
Для моих подписчиков — промокод techlead_crew_7_2HRicB

OAuth 2.0 в картинках: sequence-диаграмма.

Эту инфографику я перевел специально для поста.
Оригинал см в статье ув. тов. Phil Boutros.

OAuth 2.0 в картинках

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

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

Участники:

👤 Пользователь — владеет ресурсами и авторизует ваше приложение на доступ к ним. Например, ему нужно разместить объявление, но вместо регистрации с логином и паролем он хочет «войти через Google».

💻 Ваше клиент-серверное приложение — например, доска объявлений, где вы хотите разрешить вход через Google.

🔐 OAuth провайдер — предоставляет сервер для авторизации и сервер для доступа к ресурсу. Например, Google предоставляет доступ к имени, email и ID пользователя.


🛠️ 5 шагов, чтобы реализовать «вход через Google»:

1️⃣ — Получить конфигурацию OAuth
Провайдеры предоставляют discovery-endpoint, который вернет актуальные url для OAuth протокола.
Рекомендуется запрашивать конфигурацию вместо хардкода или сохранения в конфиге.
Проверьте сами: https://accounts.google.com/.well-known/openid-configuration

2️⃣ — Отправить запрос на авторизацию
После нажатия на кнопку «Войти через Google» ваше клиентское приложение выполняет запрос в ваш бэкенд.
Ваш бэкенд перенаправляет клиента на URL, составленный с помощью authorization_endpoint из 1️⃣ и стандартных oauth-параметров:

1. response_type=(code|token) — Определяет flow: Auth Code или Implicit. Используйте code, т.к. иначе токен передается на клиент в query string, оставаясь в логах веб-серверов, и может быть украден с клиента

2. client_id — Публичный идентификатор вашего приложения, который вы получили через веб-интерфейс OAuth провайдера для разработчиков.

3. state Уникальный случайный код, который генерирует ваш бэкенд. Нужен, чтобы предотвратить CSRF атаки. В конце флоу помогает убедиться, что изначальный запрос был инициирован вашим приложением.

4. scope — Список типов ресурсов, к которым приложение запрашивает доступ. openid — для доступа к userinfo_endpoint из 1️⃣. calendar_read — чтение календаря.

3️⃣ — Пользователь взаимодействует с OAuth провайдером.
Обычно здесь пользователь вводит логин-пароль, проходит 2fa через sms, и т.д. Если пользователь уже залогинен на этом устройстве, то увидит просто кнопку "Предоставить доступ YourApp к информации о вас".

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

4️⃣ — Получение токена
OAuth провайдер перенаправляет браузер обратно к вашему сервису, используя redirect_uri, который передал ваш бэкенд на шаге 2️⃣.

Параметры redirect_uri:
1. state — Должен соответствовать тому, который передал ваш бэкенд на шаге 2️⃣. Если не совпадает, — значит пользователь подвергся CSRF атаке.
2. code — Одноразовый код, сгенерированный oauth провайдером.

Ваш бэкенд делает запрос в OAuth Auth server для получения access_token и других.
После получения access_token ваш бэкенд использует его для запросов к ресурсам.

Auth Code flow безопаснее, чем implicit flow, потому что добавляется шаг взаимодействия вашего сервиса и OAuth провайдера для получения токена. Таким образом на клиенте не светятся никакие секреты, и вероятность их компрометации снижается.

5️⃣ — Получение ресурсов
Когда ваш сервис получает access_token, он может быть использован для вызова API сервера ресурсов сразу или в будущем.

access_token имеет ограниченный срок действия и его нужно регулярно обновлять с помощью refresh_token.

Доказательством аутентификации служит id_token. ID пользователя можно достать из поля sub (subject), раскодировав base64 JWT id_token.
Или обратиться к userinfo_uri, используя access_token.


Вот собственно и всё.
OAuth — это просто.
Распространите.

——

Специально для поста я перевел инфографику из статьи ув. тов. Phil Boutros.
На картинке к посту — превью. Сам pdf файл — чуть ниже.

Для закрепления материала можно поиграться в официальной OAuth 2.0 Playground

Servant leadership vs Управляемость команды

Disclaimer: это реклама бесплатного вебинара от Soft Skills Lab. Ребят уважаю, тема откликается, сам пойду.

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

Google был одной из первых компаний, кто популяризировал эту концепцию. В книге Work Rules автор утверждает, что свобода сотрудников — ключ к продуктивности. И что единственный способ обеспечить свободу — это отнять власть у менеджеров. Например, менеджер не может самостоятельно решить вопрос о найме, увольнении или оценке на перформанс ревью.

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

Этот подход может сплотить команду, поднять мотивацию и привести к росту перформанса и скорости достижения результатов.

Но…

Есть некая грань, после которой команда садится на шею и становится неуправляемой:

▫️ исключения из правил становятся нормой — опоздать, забыть, не прийти
▫️ требования к тимлиду/продакту/… растут, а эффективность команды падает
▫️ отговорок больше, чем сделанных задач

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

3 октября в 20:00 по мск Саша Клименко, основательница Soft Skills Lab, проведет открытый воркшоп «Как не потерять управляемость команды? 5 ошибок в коммуникации и как их исправлять».

Это будет бесплатное занятие в Zoom с практикой на реальных кейсах и общением голосом (приносите свои ситуации и вопросы!)

За 1,5 часа вы узнаете:

▫️ Какие ошибки в коммуникации не дают наладить контакт с командой?

▫️ Как отследить потерю управляемости и не допустить ее?

▫️ Что делать, если вы уже чувствуете, что сотрудники сели на шею?

Ссылку на встречу отправят в бота. Зарегистрироваться.

Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqx6CbxM