О результатах и трате времени

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

––

Несколько примеров:

– Размышления

У полезных размышлений есть результат: начав думать, ты не знал, что делать, а закончив – знаешь

Или: начав думать, ты имел один план на следующую неделю, а закончив, получил другой

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


– Рабочие встречи

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

Если нет – можно было не приходить. Сколько таких встреч ты провел за последний месяц?

– Развитие подчинённых

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

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

Часто ли тебе приходится повторять?

– Занятия спортом [не для профессионалов высокого уровня!]

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

Если нет – вряд ли последние тренировки были эффективны. Сколько месяцев не менялись твои результаты?

– Вечеринки и встречи с друзьями

Если в конце чувствуешь себя лучше, чем до – ты провёл время с пользой

Если нет – можно (а может, и нужно) было не ходить. Сколько таких тусовок у тебя было за год?

––

Продолжи список для себя тем, чем занимаешься регулярно :)

Принятие сложного решения:

Значимые изменения почти никогда не проходят без рисков и боли в моменте.

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

– А что, если мы из этих двух команд соберем одну? Они явно работают над общей целью и цепочки коммуникаций сейчас искусственно разделены
– Интересно, но вот эти двое разработчиков могут расстроиться

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

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

––

Как не попадать в эту ловушку?

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

Представь, что:

1. Решение было принято
2. Риски реализовались
3. Ты потратил 4-6 месяцев упорной работы на то, чтобы справиться с их последствиями
4. Будущее, в котором ты оказался после этого – лучше или хуже настоящего?

Пункт (3) стоит сразу декомпозировать:

– Я распределю обязанности по таким-то членам команды. Открою найм такого-то человека.
– Логику X временно оставим в отдельном сервисе на стэке Y, если сходу не заведётся
– и т.д.

Очень часто в результате этого эксперимента можно увидеть, что:

(а) Негативные последствия несмертельны
(b) Часть негативных последствий можно нивелировать прямо сейчас, взявшись за пункты из декомпозиции шага (3)
(c) Картинка, которую ты видишь через полгода, оправдывает несколько месяцев борьбы с проблемами (которых ещё может и не возникнуть)

И решение, внезапно, принимается :)

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

––

Пользуйся и не застревай.

Дисклеймер: более одного-двух сложных решений впараллель принимать не стоит. Тебе ведь, возможно, и правда предстоит много работы :)

Один способ

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

––

Один способ защитить идею перед руководителем любого уровня:

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

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

––

Один способ дать негативный фидбек взрослому человеку:

«В ситуации X ты сделал Y. Это было не очень хорошо/неэффективно/плохо (выбрать слово в зависимости от последствий), а хорошо было бы сделать Z или W. И вот почему: …»

Никаких shit-сэндвичей, преуменьшений или преувеличений. Никаких личных характеристик.

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

––

Один способ выбрать подходящего для позиции сотрудника:

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

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

––

Один способ изменить курс, если принял плохое решение:

Как можно раньше сообщить всем причастным, что ты принял плохое решение, объяснить, что с ним не так, и предложить выбрать новое.

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

––

Один способ выбрать следующую работу, если ты ориентирован на построение карьеры И ещё не достиг потолка:

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

––

Один способ зарабатывать больше денег:

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

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

––

Один способ спать по ночам:

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

Экспертность и детали реализации.

Популярный способ оценки хардов engineering manager – архитектурное интервью.
Когда-то мне казалось, что сложная часть – это, собственно, архитектура системы end to end: топология сервисов и сети, сторадж, распределение логики по доменам…

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

Оказалось, нет. System Design настолько распространён и заезжен в сети, что крупноблочная архитектура проверяет всего две вещи:

– Умение слушать заказчика
– Минимальную проактивность: погуглить, какие задачи дают на интервью и потратить несколько недель на разбор решений

С этим отлично справляются студенты 🙂

––

Означает ли это, что обсуждать архитектуру overall бессмысленно? Конечно, нет – если человек не обладает даже двумя вышеописанными навыками, как можно доверить ему что-то серьёзное?

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

– Какую базу тут выбираешь? Редис? Он быстрый и ты с ним много работал? Круто. Кстати, а как он работает и почему он быстрый? Я слышал, инстанс делает записи однопоточно – это разве не медленно? А что будет, если…

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

– Вот здесь будет множество апдейтов впараллель. Какая там СУБД у тебя, постгрес? Ага, а какой уровень изоляции ты бы настроил? А как буквально бы апдейт написал? А индексы? А сколько памяти на такой понадобилось бы, поместится на тачку?

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

Разговор о деталях и «небольших» трудностях – очень сильный фильтр на реальную экспертизу. Без него проводить систем-дизайн просто не имеет смысла в 2025-м году.

––

Мой канал на сегодня (кстати, а вы хотели бы?)) почти не содержит глубоко-инженерного контента и тех самых деталей, однако..не так давно я увидел очень хороший контент от Саши (автор примечателен, с одной стороны, тем, что умеет доступно и интересно рассказывать о тех самых деталях реализации. А с другой – ещё, например, тем, что стал лидом бэкенда в Яндексе в 21 год :))

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

Доброе утро!

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

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

– Как перестать бояться переговоров

– О переработках

– Первые шаги

– Как сдвинуть с мёртвой точки работы над сложной задачей

– Зона ответственности

– Секреты эффективности: сохранение энергии

– Самый деструктивный вопрос при оценке других и себя

– О результатах и трате времени

–––

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

А сюда можно нажать, если появится желание поговорить.

Новые форматы и новые знакомства

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

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

Задавайте вопросы, ответы на которые хотели бы услышать, в комментариях к этому посту – в конце эфира мы разберём те, что сможем :)

Время – суббота, 24-го мая, 19:00 по Москве. Ссылка будет позже в каждом из каналов. Будем всех ждать!

Самый важный софт-скилл:

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

«Как поставить цели человеку в команде?»

Обратно-симметричный от сотрудника: «Что мне делать, чтобы расти?»

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

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

––

Размышления об этом заставили меня задуматься:

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

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

– Я крутой специалист на стэке X. Рядом лежит сервис, в котором никто не разбирается, на стэке Y. Руководитель говорит, что бизнесу очень критично допилить в нём фичу. А что, если я попробую потратить несколько дней и разобраться?

– Я давно и успешно руковожу командой бэкенда. Говорят, мы запускаем новый сервис, в котором 80% логики написано фронтами, а бэкенд – на nodejs. И руководить им сейчас некому. А что, если я попробую разобраться в происходящем и предложить свою помощь?

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

––

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

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

Адаптируйся и будешь расти 🙂

Как поднять эффективность команды

В 20-30-х годах прошлого века в США исследовали методы повышения производительности на заводе «Вестерн Электрик». Одна из гипотез состояла в том, что повышение освещённости рабочего места положительно скажется на производительности труда работников.

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

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

И если уменьшить – тоже вырастет!

И если, продолжая эксперимент, перестать менять освещение..тоже вырастет!

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

––

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

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

Наблюдаемые метрики действительно растут. И не только при первом наблюдении :)

Вечер субботы

Напоминаем, что сегодня в 19:00 (мск, UTC+3) нас ждёт совместный стрим Lead’s Notes и Борис опять про менеджмент от представителей миров разработки и ml. Задавайте вопросы до или во время стрима и приходите :)

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

Начинаем стрим про менеджмент с автором крутейшего канала про ML !

Можно подключаться:
- Youtube: https://www.youtube.com/watch?v=8Vz8HgvjDK8
- Riverside: https://riverside.fm/studio/boris-4

Можно оставлять вопросы в комментариях к этому посту, но ещё лучше слать их в чат на Youtube 🙂

О проблемах с самооценкой

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

Но существует и обратная проблема, очень опасная для highly-performant менеджеров: пробивающая космос самооценка. Выражается в ощущении, что ты – самый эффективный руководитель, которого можно представить, «фактически готовый ceo чего угодно».

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

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

Начиная с некоторого уровня ты почти наверняка попадешь в сетап:

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

– Руководитель менее экспертен, чем ты, в твоем домене (это дефолт для c/c-1 позиции, а иногда и раньше) и может испытывать сложности с тем, чтобы давать тебе обратную связь

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

Как с этим бороться?

Если ты дорос до такого уровня, частью твоей личной ответственности становится поиск подходящего окружения и зон для улучшения:

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

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

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

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

Если есть другие полезные подходы – делись в комментариях 🙂

Команды специального назначения

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

– Вы, получается, не только нагрузку наливаете в систему, но и сами ищете способы устранения узких мест?
– Да
– Это же сложная задача, требует большого погружения в контекст и экспериментов с сервисами. Вы оказываетесь эффективнее внутренних команд разработки?
– Да! Это одна из причин, почему к нам обращаются
– А как вы это делаете? То есть, почему вы эффективнее?
– Ну смотри:

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

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

––

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

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

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

Вторых команд всегда меньше, но они всегда есть.

А как живёте вы?)

Менеджмент второго уровня

Что происходит с тимлидом, который слишком хорошо справляется со своей работой?

Он начинает выглядеть бесполезным и отправляется на мороз

Команда вырастает и он становится руководителем второго уровня, лидом для других лидов.

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

Делюсь презентацией с советами и ошибками начинающих руководителей M2, из своего закрытого выступления прошлого года!

Мы обещали, что запись будет – и запись есть!

https://youtu.be/HjfqcHjHwdg

На стриме обсуждали:

– Как и почему каждый нас оказался на управленческой позиции?
– Почему мы решили или не-решили продолжать менеджерский трек?
– Что вообще такое хороший или плохой менеджмент? Какова роль менеджера, создает ли он что-то сам?
– А что такое хорошие или плохие процессы?
– Также разобрали несколько вопросов подписчиков в конце эфира про карьеру, удержание сотрудников, стартапы и бигтехи

И другие интересные штуки

––

Если формат зайдёт – будем пробовать ещё 🙂

В комментариях можно оставить фидбек / вопросы, ответы на которые не прозвучали / предложить интересные вам темы для будущих постов или подкастов!

Самое интересное, что я читал за прошедшую неделю

Четверо крутых венчурных инвесторов и аналитиков (среди которых, например, Мэри Микер, выпускающая аналитику трендов в tech аж с 95-го года) выпустили отчёт про состояние и тренды AI с момента появления до текущего момента.

Контента и графиков – очень много, но оно действительно стоит чтения.

Если это исследование не убедит тебя попробовать AI конкретно в твоём бизнесе, оно, как минимум, однозначно убедит, что не погружаться просто нельзя. Очередная технологическая революция уже произошла и LLM теперь – то же самое, что калькулятор или смартфон

Знаешь ли ты, например, что adoption пользователями ai в целом и llm-ок в частности растёт быстрее, чем..росло и растёт проникновение в мир интернета, пк и смартфонов? Это и многие другие удивительные вещи можно узнать из слайдов, которые я положу прямо сюда :)

Что не нужно эффективному руководителю?

– Полный консенсус в команде

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

Для выбора решения, в пределе, достаточно двух оков: заказчика (==того, кто за это «платит») и исполнителя (==того, кто будет чинить, когда оно сломается в проде).

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

– Стратегия больше, чем на год

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

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


– Менеджеры, у которых нет метрик и личных целей

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

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

– Сотрудники, которые давно «немного не дотягивают»

Во-первых, если человек «немного не дотягивает» месяцами – это видят все. Буквально

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

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

––

Отдельный небольшой хак для личной эффективности руководителя: тык

Прийти поговорить о своей эффективности: тык

Интересные люди и контент

С ростом big tech в нём появляется всё больше неожиданных и интересных ролей.

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

Один из таких удивительных людей, по совместительству мой хороший знакомый и коллега – Артём. Он совмещает роли head of PMO и руководителя продуктов для разработчиков и старается сделать жизнь наших инженеров лучше, смотря на них как на пользователей.

Артём ведёт крутой канал, в котором публикует материалы, например, про:

– Влияние AI и платформенных технологий на эффективность разработки

– Выгорание

– Классные книги и внедрение инноваций

И многое другое.

Рекомендую как источник классного менеджерского контента от очень крутого и нестандартного специалиста 🙂