А давайте устроим немножко интерактива в канале. Нас уже за сотку перевалило – глядишь, кто-нибудь да напишет:

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

Ответы выйдут в отдельных постах

#ОтветыНаВопросы

Как вырасти от M1 до M2? Часть 1

M1 Engineering Manager – обычный тимлид
M2 Engineering Manager – руководитель лидов M1

В общем случае, ступеньки уровня выше M1 – это нетривиальные переходы (в отличие, например, от middle -> senior, который почти автоматически происходит с опытом и развитием хардов), поэтому дисклеймер: советы из поста помогут тебе набрать нужные компетенции и выжать на максимум вероятность продвижения. Но эта вероятность никогда не равна 100% – например, если, пока ты будешь качаться, дела у твоего отдела пойдут плохо, начнутся сокращения, остановится найм и из лидов оставят только очень сильных людей – ап может не случиться и тебе нужно будет рассматривать возможности в других командах и компаниях

1. Твоя команда – классно работает

Звучит тривиально, но:

a. Попадаешь ли ты на 80% в свои коммиты стейкхолдерам? Касается и продуктового бэклога, и техдолга. Всё ли хорошо с визибилити и пониманием стейкхолдерами состояния твоих дел?
b. Перестают ли твои андерперформеры быть таковыми за несколько месяцев? // прокачать перформанс – нормально; расстаться – нормально; сохранять статус кво – плохо
c. Всё ли хорошо со стабильностью сервисов?
d. Растут ли по скиллам твои подчинённые? А если растут – считают ли тебя при этом компетентным?

Список можно продолжать, но ты, вероятно, и так знаешь, где дела идут не очень хорошо (а если не знаешь – подумай + спроси у своего руководителя). Так вот – начать стоит с того, чтобы по максимуму вычистить проблемы в текущей зоне ответственности. Без этого твоё повышение – странное дело 🙂

2. Твоя команда может работать без тебя

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

Если кандидатов несколько – начни с того, чтобы распределить управленческую нагрузку между ними (например, Вася ревьюит и помогает вести проекты по скоупу разработки А; Петя – ревьюит и помогает вести проекты по скоупу разработки Б) и понаблюдать, как и насколько быстро будет расти каждый из них. Важно: нужно очень прозрачно коммуницировать всем в команде зоны ответственности и следить, чтобы люди не толкались локтями по задачам, чтобы избежать политической борьбы в команде

Когда это получится – у тебя, во-первых, фактически появится опыт управления людьми, выполняющими менеджерские обязанности, а во-вторых – банально появится свободное время, чтобы делать что-то ещё

#ОтветыНаВопросы

Как вырасти от M1 до M2? Часть 2

3. Ты успешно ведёшь проекты на стыках нескольких команд

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

Это, как и пункт (2) – полноценная часть опыта работы M2-руководителя

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

Почему этот пункт стоит в конце?
Чтобы ты не пришел к руководителю с запросом: «апни меня, пожалуйста, на следующий уровень». Если ты просишь об этом, и при этом ничего из вышеперечисленного не умеешь – это выглядит, как минимум, странно (если руководитель тебя любит, он сформулирует это мягче, но подумает примерно так)

Нормально выглядит разговор следующего вида:

«
Я хочу дорасти до руководителя более высокого уровня.

– Я знаю, что в моей текущей зоне ответственности есть такие-то проблемы. Вот так, я думаю, можно их решить, и я собираюсь это сделать. Есть ли другие, значимые по твоему мнению?
– Прямо сейчас команда не может самостоятельно жить без меня. Я собираюсь распределить вещи X, Y, Z; из Васи я попробую вырастить заместителя (или, как минимум, частичного заместителя), и вот почему я думаю, что это может сработать
– Мне видится важным получить опыт и показать, что я могу вести проекты с другими лидами моего текущего уровня. Можешь ли ты помочь мне подобрать проекты в компании (например, через несколько месяцев, когда я продвинусь по пунктам 1 и 2 и освобожу времени), чтобы я попробовал? Если увидишь, что я тебя подвожу, открутим всё обратно
– Какие ещё вещи, по твоему мнению, важны в нашей компании и нашем контексте, чтобы я смог вырасти?»

Первые три пункта – must have почти независимо от того, с какими задачами ты работаешь. Твой руководитель, вероятно, добавит других вещей, специфичных для компании, её текущих болей и потребностей, особенностей людей в вашем отделе и тд

5. Что делать, если руководитель мне откажет?

Спросить, почему)

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

А иногда..тебе скажут что люди следующего уровня в компании просто не нужны и не будут нужны ещё много лет. Лучшее, что ты можешь сделать для своей карьеры (и, как ни странно, для компании) в этом случае – всё же выполнить первые три пункта и поискать место, где люди более высоких уровней востребованы. Выполняя задачи (1) – (3) ты, во-первых, получишь опыт, о котором у тебя спросят при устройстве на новую работу, если будешь претендовать на более высокую управленческую позицию; а во-вторых – твоя текущая команда, став крепкой и самостоятельной, не сильно пострадает, когда ты её покинешь

#ОтветыНаВопросы

Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 1

Начнём с M1-руководителя:

1. Сколько времени тратить на людей

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

Я не думаю, что возможно эффективно выполнять работу руководителя, инвестируя меньше 10% времени в одного подчинённого.

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

Получается, если в команде 3 человека – на работу с ними нужно 30% ресурса. Если людей у тебя 7 – 70%. Поэтому больше 6-7 подчинённых иметь не рекомендуется

2. Процессы и работа со стейкхолдерами

Помимо работы с подчинёнными у тебя есть процессы – планирования/дейлики/груминги и тд. Ну и, собственно, взаимодействие с менеджерами и другими заказчиками. Если команда не огромная и ты с ней не первый день – в 15-20% времени будешь укладываться

Процессы идут хорошо, если перформанс команды растёт, сходимость проектов растёт (или достигла уровня 70%+ и держится там) и люди в команде и за её пределами хорошо понимают, что происходит. Если это не верно – ты либо воюешь своими процессами не в ту сторону, либо недостаточно в них инвестируешь. По личному опыту – процессы идут хорошо не более, чем у 50% команд в компании просто потому, что это – сложно. А ещё – я ни разу не видел, чтобы процессы шли хорошо, если лид команды самоустранялся от них и всё отдавал продакту/проджекту/скрам-мастеру. Не потому, что люди – плохие, а потому, что надо уметь не только строить пайплайн работы и набор встреч, а ещё и сутево хорошо понимать, что делают ребята, вовлечённые в процесс.

#ОтветыНаВопросы

Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 2

3. Технические вопросы

Грубыми подсчетами получаем, что около 30% времени должно оставаться на технические задачи у лида первого уровня с командой в ~5 человек. И, до тех пор, пока ты находишься на таком уровне, это время стоит правда инвестировать в технику. Просто потому, что в противном случае ты по квалификации быстро отстанешь от своих прямых подчинённых и превратишься из руководителя команды в руководителя проектов

To Sum Up

50-20-30 люди-процессы-техника у лида средней команды первого уровня

––

Завтра выйдет продолжение про M2+ руководителей

#ОтветыНаВопросы

Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 3

M2+ руководитель:

1. Сколько времени нужно тратить на людей

Для начала – 10% на прямого подчинённого, как у M1.
А ещё – у твоих прямых подчинённых теперь есть команды. И туда надо заглядывать, измерять температуру, помогать своим подчиненным-лидам находить проблемы, отмечать быстрорастущих непрямых подчинённых и т.д.

Добавим 3-5% налога на работу с командой. Итого – 15% на директ-репорта

2. Процессы и работа со стейкхолдерами

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

А ещё – ты больше не можешь менять процесс за один день со словами: «ребята, с завтрашнего дня вот этот митинг проводим по-другому, а здесь меняем вот эту штуку; всем, у кого не выйдет – я помогу». Теперь у каждого твоего подчиненного есть свой процесс и своё сильное мнение о том, как правильно жить команде. Начиная с уровня M2 и выше тюнинг процессов – это переговоры и с подчиненными, не только со стейкхолдерами

Накидываем 5-10% на процессы к цифрам M1. По крайней мере, до тех пор, пока вы с командой очень плотно не сработались и не начали понимать друг друга с полуслова (а это – займёт время).

Итого – 25-30% на процессы

3. Техника

Всё оставшееся время, если оно есть.
Важно: нельзя оставлять 0. Тебе нужно хотя бы примерно понимать работу прямых подчинённых. Они уже – не разработчики, т. что ревьюить код не нужно. Но нужно успевать отсматривать архитектурные решения и успевать вместе с ними поговорить про большие стройки. Если ты этого не успеваешь – ты, опять же, из руководителя постепенно превращаешься в проджекта

To Sum Up:

У M2 руководителя, который не выстроил команду до идеального состояния, с четырьмя direct-reports:

60-30-10 люди-процессы-техника

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

Важно: 5 прямых подчиненных дадут тебе загрузку больше 100%. Я не встречал хороших M2, которые работают с текущей командой меньше года, имеют 5 прямых подчиненных и укладываются в 40-часовую рабочую неделю. Это примерно невозможно

Как следствие: норма прямых подчиненных у M2 всегда меньше – чем у M1. Выше по лестнице – правило сохраняется

––

Схемы M1 и M2 намеренно упрощены, тк на самом деле есть ещё найм, публичные активности, пятничное пиво с командой и тд. Они ситуативно отъедают проценты. Но с ними пост превратился бы в очень-много-буков-и-сложные-формулы или..в часовой подкаст, которых я пока не выпускаю)

Я устал от ограничений на размер поста и накатал статью на хабр: https://habr.com/ru/articles/813731/

Будем делить контент на два вида: покороче – в телеге, подлиннее – в журнале)

Кстати, говорят, лайки и комменты на хабре тоже помогают)

Очевидное и не очень

Случалось ли тебе разозлиться на человека (или даже решить, что он, возможно, зря находится на своей позиции) из-за того, что он не понимает или не делает что-то, «очевидно» необходимое?

Например:

– Руководитель не проводит регулярные 1x1 с подчинёнными
– Разработчик отдаёт на ревью код без тестов
– Продакт приносит в команду задачи в последний момент, а в описании – только ссылка на фигму
– Проджект делает круглые глаза, когда ты спрашиваешь у него, где посмотреть гант по важному проекту

––

Мне и многим моим знакомым – случалось! Я даже слышал, что это влияло и влияет на оценки людей на ревью :)

Есть подход, который, во-первых, помогает больше любить людей, а во-вторых – повышает эффективность команды, улучшает отношения в коллективе и даёт пачку других плюсов:

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

––

Люди не рождаются с необходимым набором знаний. Бывают разработчики, которым ни один руководитель не сказал, что код без тестов – это опасно. Бывают тимлиды, которых не учили проводить 1х1-ы (правда, бывают!). Бывают продакты, которые всю предыдущую карьеру провели в стартапах, где все знали и понимали друг друга с полуслова и тикеты правда можно было оформлять картинками

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

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

#ОтветыНаВопросы

Как лиду растить людей? Как не быть боттлнеком в развитии своей команды?

Классные руководители всегда думают, как развивать команду. Один из базовых инструментов – обратная связь. Чем чаще – тем лучше. Для джуна или миддла – её можно эффективно давать каждую неделю и человек будет меняться.

Если успеваешь отсмотреть, что сделал сотрудник за последнее время, с ОС всё просто: насыпаешь комментов в код или дизайн-ревью + записываешь важные темы, о которых лучше детально поговорить голосом, и относишь их на 1х1.

Но бывают ситуации сложнее:

– Команда почти полностью состоит из джунов, детально отревьюить всех – ты не можешь (как я понимаю, кейс автора вопроса)
– В команде есть люди, разбирающиеся в своём стэке лучше руководителя. Так бывает, например, в кросс-функциональных командах.

––

Что делать?

Внедрять практику менторства

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

Запустить его можно быстро. Пройдись по другим лидам и поспрашивай, есть ли у них хорошие инженеры, которым интересно пообучать людей в обмен на твою (и твоей команды) положительную рекомендацию к перформанс-ревью. Часто такие люди находятся:

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

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

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

А человек примет обратную связь не от руководителя?

1. В большинстве случаев – примет, если правильно и честно объяснить мотивацию: «Я хочу помочь тебе вырасти, но моего ресурса на это сейчас не хватает. А вот у Васи – есть возможность и он успешно работает в компании на позиции X. Переняв его экспертизу, ты сможешь вырасти. Более того – Вася может тебе помогать, а уволить тебя за косяки – не может, он же не руководитель) Как тебе идея?»

2. Если по какой-то причине сотрудник всё же идет в полный отказ – можно запроксировать обратную связь через себя.

––

На дистанции – конечно, стоит растить менторов и из людей в своей команде, если сейчас их нет 🙂

Делитесь в комментариях своими практиками!

#ОтветыНаВопросы

Как синьору стать лидом? В какие навыки инвестировать?

Моё мнение про харды M1:

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

Если ты уже синьор – хардов тебе хватает.

Синьора от лида отличают управленческие скиллы. В них входят навыки:

– Переговоров
– Проектного управления
– Организации процессов
– Выдачи обратной связи людям

Как приобрести эти навыки и стать лидом

Прийти к своему лиду с запросом:

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

Вам с лидом нужно сделать две вещи:

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

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

Шаг 2 бывает сложным. Если размер команды твоего лида позволяет, он может отрезать тебе кусочек – пару инженеров в подчинение и зону ответственности. Я начинал с такой команды

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

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

Если с шагом (1) всё ок, а в шаге (2) железно отказывают без конкретных претензий к навыкам, у меня плохие новости: пора искать другую работу. Кто-то же должен был тебе честно это сказать)

Обещал пост про мотивацию перехода в управленческий трек и людей, которым стоит (или не стоит) это делать.

Сказано – сделано: https://habr.com/ru/articles/814911/

Лайки на хабре помогают не меньше лайков в канале – менеджерский контент там не всегда жалуют 🙂

#ЧтоПосмотреть

Наступил вечер пятницы, так что..развлекательный контент!
За не-развлекательным – просто полистай канал вверх 🙂

Пост про книги уже был, теперь – про кино.

Айтишного, думаю, тебе хватило и за неделю, так что вечером будет не-айтишное.

––

Одержимость – анти-инструкция про работу с топ-перформерами и выгоранием. И в целом очень крутой фильм. А тебе доводилось сталкиваться с такими руководителями?)

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

Тёмные времена – фильм представляет собой долгое и тяжелое описание эпизода из жизни Черчилля. В нём, по сути, описан путь к принятию одного (одного, Карл!) решения. Если думаешь, что с тобой что-то не так и тебе очень тяжело договариваться с людьми – возможно, ты узнаешь, что не одинок в этой проблеме 🙂

Как провести 1х1 с человеком, перекладывающим ответственность

Часть 1.

Продолжаем отвечать на вопросы.

Бывает, что сотрудник затягивает сроки, проваливает проекты, а потом говорит:

Тут смежники задачу вовремя не сдали. А здесь – в библиотеке баг нашёлся, я его две недели дебажил. А потом у меня похмелье было. Затем – ноутбук в озеро уронил. А после – дизайнера автобус сбил. Так что мне не лещ, а орден мужества полагается. Скажи спасибо, что я живым выбрался!

Cоветую прозрачно сказать сотруднику, что его работа – не просто написать свою часть кода. Его работа – это:

a. Писать свою часть кода
b. Поддерживать у заказчиков актуальную информацию о времени сходимости
c. Сделать всё возможное, чтобы код оказался в продакшене
d. Если внешние обстоятельства мешают пункту (c), настойчиво потыкать в них палочкой. Если не действует – звать на помощь руководителя, чтобы он помог пробить стену

Пункт (а) – cамый простой.

(b) – сложнее. Надо ежедневно проверять, уверен ли ты, что задача доедет в срок. Если нет, стоит сразу поговорить со стейкхолдерами.

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

Пункты (c) и (d) обязательно объяснять на примерах. Для этого нужно вместе с инженером рассмотреть несколько свежих кейсов и показать, как можно было поступить:

1. Здесь – стоило прийти и попинать Петю, напомнить ему про дедлайн и вашу договорённость. Не сработало – эскалируешь в меня

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

3. Здесь – можно было написать дизайнеру. Не помогло – эскалируешь

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

Иногда – человек окажет сопротивление и договариваться об этом не захочет.
Значит, надо разбираться в причинах.

Как провести 1х1 с человеком, перекладывающим ответственность

Часть 2.

Если при разговоре, описанном в предыдущем посте, возникло сопротивление, разберись в мотивации сотрудника:

Боюсь, что смежники пошлют меня куда подальше

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

А почему менеджеры/руководители сами не могут отследить все проблемы всех сотрудников. Можно я только код буду писать, и всё?

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

Нет, все равно не буду. Я согласен только писать код и ничего кроме этого

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

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

Если нет – придется, рано или поздно, искать другую работу. Иначе профита не будет ни для кого: ты не сможешь положиться на сотрудника и ожидать, что он будет приносить результат (закончится или безумным микроменеджментом, или провалами всех порученных проектов), а сотрудник – не сможет получить положительную оценку на перформанс ревью, нормальную зарплату/премию и тд. Если договориться никак не выходит – надо готовить план расставания.

Отличие сильного руководителя от слабого

Доброе утро!

Не любишь понедельники? Вот тебе инсайт вместо кофе:

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

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

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

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

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

Ты больше, чем твои эмоции. Команда их забудет или простит. Команда запомнит твои действия.

А теперь – делай то, что правильно. Удачной недели!

Экспериментируем с форматами

Сегодня – играем в сарказм!
Инвертируем содержимое и идём к успеху :)

https://habr.com/ru/articles/815923/

Ваши лайки на хабре – согревают и помогают)

#ОтветыНаВопросы

Как поддерживать отношения в распределённой команде?

Удалёнка – вызов для менеджера и отношений в команде.
Заменить коммуникации и отношения, возникающие между людьми, по 8 часов в день проводящих рядом, тяжело, но побороться за них – можно 🙂

Вот, что помогало мне:

Пятничное пиво

Я раньше думал, что выпить и пообщаться можно только лично в баре или в офисе. По зуму – странно.

А потом наступил ковид и..знаете – не так и плохо. Я потестировал на себе и друзьях, потом на команде – и сработало. Начало пережить непросто, но, если не дать разговорам провиснуть и взять с собой любимые напитки, всё будет в порядке. Через 30-60 минут расстояние ощущается не так остро и барьеры частично растворяются. А ещё – в конце не нужно ехать домой на такси 🙂

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


Онлайн-игры

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

Некоторые ребята могут бодро и весело порубиться в CS или доту после работы.
Кому-то заходят аналоги классических настолок вроде codenames, шпиона или мафии.
Можно выбрать игру исходя из знаний об участниках команды или банально – устроить голосование.


Пространство для неформального общения

Если в команде ещё нет чатика, в который по средам кидают жаб, по вторникам – обмениваются лучшими событиями за прошедшую неделю (я не шучу, практика называется «happy tuesday»), а каждый второй понедельник – постят своих домашних животных – стоит попробовать

В нём же можно делиться впечатлениями про кино/книги/whatever

Если чатик стабильно живёт – можно прицепить к нему зум/дискорд/whatever-комнату, в которую можно зайти, например, каждый день во время обеда/ужина и поболтать с теми, кто на связи


Локальные хабы

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

Чтобы работало хорошо, надо выбрать проактивного человека «на месте», который поможет пофасилитировать мероприятия.


Быть ближе к дезинтегрированным людям

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

Иногда в команду приходят новички
Иногда – старички дистанцируются

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

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

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

Общение лучше начинать руководителю или ментору, а позже – постепенно включать сотрудника в более широкие круги коммуникаций

А какие практики работают у вас?

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

Однажды в канале уже был пост про погружение в детали.
Сегодня – пара кейсов из личного опыта, которая должна замотивировать к этому ещё больше:)

Когда в моей команде было уже более 50 человек (в среднем – 5-7 на тимлида), я поймал себя на мысли, что давненько в код многих команд не заглядывал. Не в формате ежедневного ревью, разумеется, а хоть иногда, чтобы контакт с реальностью не потерять. И заглянул…

1. Стартапная команда

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

Проект – в стадии прототипа, мы буквально не знаем при этом, будут ли у него пользователи! Мы, возможно, всё это выбросим через месяц 🙂

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

2. Команда большого продукта

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

Открываю парочку пулл-реквестов. Код как код. Тестов меньше, чем я бы ожидал, но..вроде не критично мало.
Прихожу посмотреть, как инженер работает над задачей:

– Пишем код
– Пишем тесты (ну не TDD и не TDD, подумаешь)
– Начинаем сборку в CI и выкатываем в тестовое окружение
– Отдаем на ревью
…

– Стоп! Сразу в CI и тестинг? А локальная сборка? А модульные/функциональные тесты – их же годами писали, сервис старый, нифига ты это не проверишь сам руками сейчас, и твой QA не проверит.
– Ну да. Половина тестов не работает локально, но запускается в CI, а другая половина – вообще не работает у сервиса
– И ты всё время так живешь? Это ж безумно медленно и опасно
– Ну..да
– А чего не жалуешься?
– А у нас давно так и было, я думал, это нормально (контекст: в команде за год по разным причинам сменилось множество людей + она выросла)

Пошли разбираться с тестами и сборкой. Снова вспоминаем, что очевидное тебе – не обязательно очевидно всем

Ну как, появилась мотивация ещё раз заглянуть под капот своей команды?

#Пятничное

По традиции – развлекательный контент в пятницу вечером.

1. Old but gold, «Теория Жоп»

https://habr.com/ru/articles/593173/

Теория смешная и, одновременно, чудовищно жизненная.
Осторожно: при прочтении можно испытать серию вьетнамских флешбеков!

––

2. Как VK ускоряли работу приложения

https://www.youtube.com/watch?v=KDcOa_QbSQ0

Это – не реклама VK.
Это – история, которая может замотивировать работать над целью до тех пор, пока тебе не покажется, что стало «достаточно хорошо», а не до тех пор, пока у тебя не закончатся очевидные решения

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

Если тебе было страшно внедрять новый фреймворк – посмотри это видео и больше не бойся 🙂

––

3. Как снимали «Матрицу»

https://habr.com/ru/companies/first/articles/724300/

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

– Подбор команды
– Костыли
– Бюджет
– Неочевидные решения

А можно – просто как развлекательный текст про продакшен крутого кино в 90-е/2000-е годы. В любом случае – по-моему, интересно!