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

За какой личной метрикой важнее всего следить, чтобы принимать хорошие решения?

Поверхностный ответ: за свободным временем в календаре.

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

Эффективно ли это?

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

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

––

Более глубокий ответ: оптимизировать свою интеллектуальную усталость / ресурс принятия решений.

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

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

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

––

Сколько часов интенсивной интеллектуальной нагрузки в день стоит оставлять?

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

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

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

Следи за интеллектуальным ресурсом!

––

// кстати, канал замолчал на пару недель буквально из-за этой практики – они совпали с перформанс-ревью в компании 🙂

О сопротивлении

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

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

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

––

Интуитивный сигнал, который «хочется» воспринять, встретив сопротивление: люди не хотят делать то, что я предлагаю -> наверное, я некомпетентен / идея плохая / etc.

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

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

Напрягаться и менять привычные паттерны – инстинктивно неприятно, причём примерно всем.

––

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

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

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

––

Как понять, в первой ты ситуации или во второй?

Внимательно слушать, что говорит «сопротивление».

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

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

––

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

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

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


––

Дисклеймер: ни в коем случае не стоит полностью игнорировать сопротивление. Ситуации первого типа (с объективными возражениями) всё же встречаются и, пропуская их, ты теряешь доверие команды. А внедряя полезные, но неприятные в моменте решения – не теряешь, если их не 5 в день.

Не бойся сопротивления, но внимательно слушай возражения.

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

Самый деструктивный способ оценивать других и себя – это вопрос: «что человек НЕ сделал?»

– CPO у вас так себе, за два года так и не добавил кнопку «поделиться с другом»

– CTO у нас не очень, за три года так апи сервиса и не отрефакторили

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

––

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

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

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

– Что он СДЕЛАЛ за период Х, какую ценность принёс?

––


– Классный ли у нас CPO?
– А что он сделал за последнее время?
– Придумал, как увеличить количество заказов в два раза
– Да, классный

– Кто из хедов разработки круче, Петя или Вася?
– А что они сделали?
– Петя придумал инструмент, благодаря которому мы сократили ttm в два раза. А Вася пару старых апишек отрефакторил
– Петя круче

– Я развивался или просто тратил время в последние полгода?
– А что нового для себя я СДЕЛАЛ за это время?
– Выучил язык Х, поднялся на должность Y
– Да, я молодец. Теперь подумаю, куда я хочу двигаться дальше


Количество не-сделанного всегда бесконечно. Измерять его для оценки – вредно.

Количество сделанного – конечно и хорошо говорит о реальной ценности.

Если несделанного много – это нормально.
Если сделанного мало – это уже проблема.

––

Но ведь вопрос «чего я НЕ делаю?» может давать полезные идеи для улучшений, разве нет?

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

Оценивай сделанное, планируй не-сделанное :)

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

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

––

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

––

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

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

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

– А что, если мы перепишем сервис 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

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

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

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

––

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

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