Радио «Виктор»: кризисы и кое-что важное
Кризисы бывают очень разные. Есть острые — те, что требуют немедленной реакции здесь и сейчас. По рабочей привычке я называю такие — инцидентами. А бывают те, что резко меняют внешние условия, а потом долго тянутся. Их ключевое свойство — у них нет конца. Они просто в какой-то момент становятся новой реальностью, новой нормой. Ну или сменяются новым кризисом.

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

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

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

После валютного кризиса 2014–2015 я сошёл с инженерной дорожки в сторону менеджерской. Казалось бы, неудачное время: мировые зарплаты разработчиков росли, а курс рубля создавал ещё и дополнительный мультипликатор. Но именно кризис подтолкнул меня к желанию бо́льшей зоны влияния и ответственности. Это было осознанное решение.

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

P.S. Этот пост я начал писать, чтобы пригласить вас послушать наш разговор с Андреем Смирновым и Ульяной Батуевой про кризисы в подкасте «Вдруг тут что-то важное». Но пока писал, ушел в саморефлексию, переписал насколько раз за несколько дней. И получилось то, что вы сейчас прочитали.

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

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

А вот система образования действительно, на мой взгляд, иногда учит не только хорошему, но и плохому. А потом это «плохое» в рабочем контексте выглядит как особенности поколения или просто как инфантилизм. Сегодня поделюсь наблюдениями: с какими установками сталкиваюсь у коллег и как объясняю их себе — школьно-университетским опытом. У самого были похожие паттерны сразу после ВУЗа.

Оценки и рамки
Ключевой индикатор «молодец/не молодец» — это оценка по пятибалльной шкале. В лучшем случае — за выполнение чётко поставленного задания по понятным критериям. Я помню, как сам ждал такой обратной связи: вот таска, вот результат — ну что, я молодец? Ошибок нет? Или всё-таки где-то знак в знаменателе не тот?

А в бизнесе, в корпорациях и в дикой природе всё по-другому. Важно не количество ошибок, а результат. И не в абсолюте, а в сравнении с соседями.
- Гепард догнал антилопу потому, что тренировался, или потому, что она подвернула ногу?
- Сервис выдержал стресс-тест из-за чистого кода или из-за вовремя подставленного бэкоффа?
- Кофейня закрылась из-за плохой работы бариста или из-за поднявшихся налогов?

Результат — это не только ты. И не всегда про правильные действия.

Рамки и подготовка
Школа с детства учит: вот теория, вот задача, вот условия — решай. Пропустил урок — не решил. Вспомнил нужную формулу — молодец.

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

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

А потом ты джун. И что дальше? Ну, понятно, дальше мидлом станешь. Или нет? Рано или поздно наступает такой момент, для которого «импульса» уже не хватает. Я знаю тимлидов, которые прошли эту игру с первого класса и до тимлидства, продвигаясь примерно раз в год. И вот роста нет. Кто плохой: тимлид или его начальник? Или компания не та?

Уровни и скорость
В школе важно было «опережать». Пошёл в школу в шесть — молодец. Начал учить английский в детсаде — круто. Три года плаваешь — уже не ровня «первогодкам».

А потом выясняется: быть джуном в 40 — нормально. Не значит, что ты «отстал». Просто начал новый путь.
У меня есть друг, который запускал ракеты, руководил и владел заводами, а теперь работает тимлидом. Не потому, что не справился где-то. А потому, что захотел.

Скорость и финиш
С детства нас учат бежать к конкретному финишу: к ЕГЭ, к диплому, к «выпускному». Но что за этой чертой? А там все тоже самое. Нет никаких финишных ленточек.

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

Финансовая независимость: стать молодым пенсионером и жить в кайф?

Первый выпуск 8-го сезона начнём с темы, куда же деть все те огромные деньжища, которые мы, айтишники, зарабатываем в наносекунду, как многие считают 😏

Обсудим концепцию FIRE (с англ. Financial Independence, Retire Early) — финансовую независимость и раннюю пенсию. Базово определимся с понятием, попробуем в цифры — сколько нужно зарабатывать, откладывать и как жить. И затронем философский вопрос, как быть фаерщиком в российских реалиях.

Наш гость — Алексей Марков, к.э.н., писатель, музыкант. Вы можете знать его по книге «Хулиномика» и одноименному ютуб-каналу.

На какие вопросы подискутируем с Алексеем:
❓Как действовать согласно стратегии FIRE и от чего это зависит?
❓Какой возраст считается тем самым ранним пенсионным?
❓Какой золотой стандарт процента от капитала, на который вы можете жить и почти его не тратить?
❓Что нужно знать о горизонтах планирования?
❓Какие есть ошибки на пути к FIRE?
❓Почему важно не вкладывать всё в один инструмент?
❓Что ещё важно делать, кроме как мало тратить и много зарабатывать?
❓Что нужно делать вместо того, чтобы учиться сберегать от зарплаты в 50к?
❓Почему важно учитывать отношение к доходам и тому, если что-то пошло не так?
❓Какой навык ключевой в финансовом благополучии (и в целом по жизни)?

И супер-бонусом от Алексея — хулигид по финансам с перечнем рекомендуемых материалов о финансах. Это вау! 🔥

Этот эпизод, как и весь сезон, выпускается при поддержке драйвовой команды инженеров — @AvitoTech. Ребята создают сервисы, которыми пользуется треть жителей России каждый месяц.
Команда активно делится подробностями про устройство разработки внутри Авито через различные форматы. Рекомендуем посмотреть Avitalk — шоу толковых людей, где в формате интервью гости рассказывают о своем погружении в профессию, делятся советами и лайфхаками, как найти собственный путь. Эпизод «От разработчика до директора нескольких кластеров» будет интересен тимлидам разработки и другим управленцам в IT.

🎙Открывают новый сезон все те же старые ведущие. Это Виктор Корейша, руководитель направления Managed Services в Ozon, и Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure, автор канала «‎Тимлид Очевидность»‎. В этом сезоне вас ждут традиционные 11 выпусков, по средам раз в две недели.

🎧 Слушайте подкаст «Кода кода» в Яндекс Музыке, Apple Podcasts, Spotify, VK и много ещё где по ссылке: https://kodakoda.mave.digital/ep-80

🐝 Пишите отзывы, предлагайте темы, спорьте или соглашайтесь с гостями и ведущими. Нам важна ваша обратная связь!

Реклама. ООО «‎Авито Тех»‎, ИНН 9710089440, erid: 2SDnjcVkdos

Новый выпуск подкаста готов к публикации 🎙

Дорогие слушатели, рады сообщить: 8-й сезон подкаста «Кода кода» уже на старте. Мы готовы снова делиться с вами крутыми историями из жизни в IT.

Цитируя классиков, пчела с новым выпуском на площадки к вам летит 🐝 Первый выпуск в эту среду!

Вас ждут крутые гости, обсуждения актуальных тем, увлекательные истории и лайфхаки.

Выходить будем традиционно по средам, раз в 2 недели. Запланировали 10 обычных выпусков и один специальный — интрига!

Где слушать? На всех популярных платформах: Яндекс Музыка, Apple Podcasts, VK и другие, ищите через mave: https://kodakoda.mave.digital

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

До встречи в среду 🚀

Радио «Виктор»: преемник
В комментариях к предыдущему посту был вопрос, на который отвечаю здесь. Немного контекста: в Озоне отдел — это несколько команд, а руководитель отдела — это тимлид тимлидов. Вопрос:
Можешь рассказать, как ты искал преемника на своё место руководителя двух отделов?
Не все управленческие задачи решаются «в лоб». Как только вы становитесь руководителем, один из первых (и самых незаметных) вопросов — а кто после меня? Преемник — это не всегда конкретный человек. В моем случае было два отдела, и у них почти не было общих проектов. Гораздо логичнее было найти и вырастить по одному кандидату в каждом.

Вот как я действовал:
1️⃣ Выбрал потенциальных тимлидов, у кого видел задатки.
2️⃣Поговорил про карьеру. Оставил в «пуле» только тех, кому реально интересно развитие. Таких, кстати, не так много.
3️⃣ Показывал, что я делаю и как принимаю решения. На 1:1 обсуждали не только поступки, но и мотивацию.
4️⃣Давал обратную связь, особенно там, где чего-то не хватало. Часто и честно.
5️⃣Расширял контекст: про соседние команды, общие проекты. А где сам не мог — создавал условия, чтобы человек мог узнать больше.
6️⃣ Делегировал ответственность. Иногда — временно, иногда — насовсем.

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

К моменту моего назначения руководителем направления, один из преемников уже был готов. Мне оставалось усилить фокус на пунктах 4–6 и постепенно передать бразды.

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

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

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

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

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

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

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

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

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

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

Мой мир перевернулся, когда я узнал про Центральную предельную теорему. Оказалось, что даже для множества случайных величин можно сказать кое-что определённое: их сумма распределяется по Гауссу. Позже, изучая статистическую физику, я наткнулся на другие интересные факты. Например, каждая молекула воды движется хаотично, но чайник всё равно кипит ровно при 100°C.

А если углубиться в квантовую механику, то сама вероятность перестаёт быть субъективной оценкой — но об этом как-нибудь отдельно.

Как работать со случайностью?
Я люблю настольные игры, особенно долго увлекался коллекционной карточной игрой MTG (Magic: The Gathering). Где каждый игрок сам собирает колоду. Комбинаций — бесчисленное множество, но на турнирах побеждают не случайные сборки, а самые сильные взаимодействия в рамках формата.

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

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

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

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

Про что из этого мне стоит написать подробнее?

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

Много лет назад, будучи джуном, я работал над сайтом интернет-магазина и занимался там ценообразованием. Логика формирования цены была сложной — алгоритм зависел от десятка вводных. Заказчик регулярно спрашивал: «Почему цена получилась такой, ведь очевидно, что должно было быть иначе?» или «Как наценка могла стать настолько низкой?». Формально моя работа заключалась в том, чтобы разбираться в каждом случае. Чуть выходя за пределы — добавить логов, вывести алгоритм формирования для каждого товара в каждый момент времени в админке.

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

Почему не знания/навыки?
Конечно, джун, едва понимающий, как работают инженерные системы, не сможет сразу стать главным архитектором. Но если ему не всё равно, он будет искать решения для задач, которые видит. И ответы на вопросы, которые ставит. Рано или поздно эти решения будут находиться — через упорство, новые навыки, готовые инструменты или делегирование.

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

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

Руководствуясь принципом «сначала наденьте маску на себя, а потом на ребенка», важно накапливать этот запас энергии. Иногда для этого нужно где-то повести себя реактивно, где-то отдохнуть, на что-то «забить». Главное — не позволить липкому болоту праздности полностью затянуть вас.

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

Например, сейчас я отвечаю за довольно объемную часть инфраструктуры и периодически подрываюсь по звонку робота, которого мы лаского называем «Железной женщиной», в любое время дня и ночи. Она звонит, когда что-то сломалось и поднят инцидент. И на звонке мне нужно быть максимально проактивным: сначала убрать влияние сбоя, потом докопаться до причин. Но по-настоящему «не все равно», не тогда, когда ты чинишь что-то в зоне своей ответственности или даже по соседству. А когда, в рамках проблем-менеджмента, находишь более широкий класс проблем и организуешь процесс его решения.

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

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

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

А что в работе?
Ровно так же и в рабочих переговорах. Если вы обсуждаете крупный проект в широком составе, то плохо говорить о нём общими словами. Но так же плохо пытаться проговорить все детали. Правильный подход: выбрать заранее несколько важных ключевых деталей и их подсветить, оконтурить, выделить. А другие места обозначить и скрыть за общим фасадом. Таким образом, вы, с одной стороны, обозначите глубину проекта, подсветите какой-то ключевой риск или момент, который требует координации с рядом команд. С другой — не перегрузите собеседника подробностями. Выбор конкретных деталей сильно зависит от ситуации.

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

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

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

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

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

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

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

Ещё хуже — пытаться сделать «приятный сюрприз для заказчика» или «придержать нашу главную фишку на потом». Это почти никогда не работает. Лучше с самого начала договариваться максимально подробно, а потом обсуждать необходимые изменения и дополнения так часто, как это возможно. Я представляю это как принцип часов: скорость стрелки всегда направлена по касательной, но движется она по дуге, потому что на неё действует ускорение. Оно действует постоянно и понемногу. Так, что стрелка, уверен, этого даже не замечает.

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

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

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

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

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

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

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

Когда правила можно (и нужно) нарушать?
Это не значит, что любые правила — это догма. Представьте, что вы можете ездить на красный свет, потому что у вас есть спецпропуск. Делать это в обычных условиях — социально безответственно. Но если за вами погоня или вы везете пострадавшего в больницу, то это оправдано. В других ситуациях вам стоит остановиться на красный. И даже заплатить штраф, если вы этого не сделали.

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

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

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

Давайте станем ближе?

Поделитесь, какую позицию вы занимаете и какой у вас уровень IT-шности.
От вас — участие в опросе, от нас — полезный и захватывающий контент 🤝

Заглянем в бар?

Вы помните, как мы, ваши бесценные ведущие Витя Корейша и Женя Антонов, пригласили Настю Абрашитову в бар? 🍸

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

Пока мы готовим новый сезон в «Кода кода», предлагаем послушать самый мёд из подкаста «Три тимлида заходят в бар».

1️⃣ Неприятные разговоры с сотрудниками — как проводить, чтобы не навредить?
Про кондиционерные войны, гигиену, зависимости, громкие звуки, ссоры Ивана Ивановича и Ивана Никифоровича, противогаз, Чебурашку и многое другое.
2️⃣ Бесконечные встречи в календаре. Как не сойти с ума и успеть пообедать?
База выживания в диких условиях — подготовка к встречам, модерация, фокус внимания, 2-3 встречи в один слот и то, как кукушечку держать при себе.
3️⃣ Тайм-менеджмент — как успевать срочное и не терять важное
О борьбе с прокрастинацией, лайфхаках успеть всё (и не успеть тоже), навыке вести заметки во время встречи, дедлайнах своих и чужих.
4️⃣ Перфоманс ревью — объективная оценка или способ выжимания соков и формализм ради формализма?
Субъективные оценки vs Объективные показатели, Польза vs Вред, Манипуляции vs Помощь своей команде.
5️⃣ Как тимлиду поменять работу и не сойти с ума
Экзистенциальные вопросы — нужен ли ты кому-то, нужно ли делать карьерный шаг назад, что будет и как быть, если …

Это не наш субъективный выбор, а аналитика и фидбэк слушателей.
Наслаждайтесь и следите за новыми выпусками в телеграм-канале подкаста 👀

Радио «Виктор»: Собеседование — не допрос
Договорённости о работе всегда предшествуют переговоры, и часть этих переговоров называется собеседованием. Наверняка вы видели мок-собеседования на YouTube, скорее всего, участвовали в найме со стороны собеседующей стороны и, конечно, проходили собеседования сами. И, вероятно, наблюдали или даже участвовали в таких собеседованиях, где одна сторона задаёт вопрос, получает на него ответ и... просто переходит к следующему вопросу. А потом мы читаем тысячи жалоб на то, что «спрашивали алгоритмы, а кому они нужны» или «меня полтора часа мучали кейсами, и я не знаю, хорошо ли я справился».

При этом ничто не мешает собеседующему объяснить, почему он задаёт именно этот вопрос. Как ответ на него повлияет на работу в команде? Как кандидат относится к такому формату работы? Часто это может дать гораздо больше информации. А ведь в этом и цель — узнать максимум. К тому же, вы попутно выполните и вторую цель диалога — на конкретных примерах покажете, чем вы тут вообще занимаетесь.

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

Допустим, вы решаете спросить: «В чём отличие горутины от потока?» Обсудив ответ и углубившись в детали, вернитесь к вашей позиции. Почему для вас это важно?
- Может быть, у вас был баг, который приводил к резкому росту числа горутин, и вы упирались в планировщик.
- Может, у вас CPU-интенсивные приложения, и вам важно следить за утилизацией ядер.
- Может, вы переносите бизнес-логику с Java на Go и стремитесь сохранить параллелизм.
- Может, сочетание лимитов в кубере и установленных GOMAXPROCS ваших приложений уже приводило к троттлингу и падению бизнес-метрик, и вам важно, чтобы каждый член команды хорошо понимал, как и что стоит настраивать.

А если вы сами не понимаете, зачем задаёте этот вопрос, то, может, он и не нужен?

Soft skills интервью или менеджерская секция
Вы просите человека рассказать про свой провальный проект. Обсуждаете это с ним, делаете выводы. Но почему бы не объяснить, что именно вам тут было важно? И почему бы не поделиться в ответ своим провальным проектом?

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

И так во всём
В первом сезоне подкаста «Кода кода» меня почти не слышно. Я не только не озвучивал своего мнения, но даже вырезал свои вопросы там, где контекст склеивался. Позже мы с Женей стали активно делиться и своим мнением. А в последних сезонах — дополнять гостей и даже спорить с ними.

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

Пока в нашем подкасте перерыв, решил предложить вам послушать и посмотреть интервью, которое я брал у коллег. Это была разовая акция, в рамках нашей (Озоновской) конференции E-code. В организации и проведении которой я активно участвовал в начале осени.

Говорили о том, как написанный код превращается во что-то реальное и осезаемое. Гостями были два CTO:
🧑 Леонид Налчаджи, технический директор по продукту и технологиям логистики;
🧑 Иван Лазарев, технический директор по продукту и технологиям товарных операций.

В этой беседе:
🔉 обсудили, зачем инженеры Ozon Tech ездят работать на склады и в курьерскую службу;
🔉 вспомнили ошибки разработки и их последствия;
🔉 рассказали про преимущества — почему мы так любим работу в IT, которая влияет на миллионы пользователей.

➡ Смотреть и комментировать.

Радио «Виктор»: инструменты управления иллюзорны, но такова жизнь

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

Плюшки
Тимлид может раздавать «интересные» задачи как награду или закрывать глаза на отступления от корпоративных правил для поощрения. И наоборот — забирать это в качестве наказания. Вот только границы таких методов очень узкие. Потому что если использовать их «на всю катушку», быстро столкнешься с последствиями. Например, увеличишь bus factor, потому что только один человек в команде «трогал» эту новую крутую технологию.

Деньги
Трудоустройство — это понятная договоренность: работодатель платит деньги, а сотрудник выполняет работу. Вот только для инженерных профессий это работает плохо (подозреваю, что и для многих других тоже). Проблемы начинаются уже на старте, в момент договоренности. Вы когда-нибудь видели служебную инструкцию, которая объясняла бы, что от вас ожидается? Ради интереса попробуйте составить такую сами про себя, а потом проверьте, насколько реальность совпадает с написанным.

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

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

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

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

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

Что же остается?
Все вышеперечисленное. И еще множество других методов. Цель этого поста — показать, что никакого волшебного «пульта управления» нет. Ни у тимлида, ни у мидл-менеджмента, ни у топов, ни у собственников. Его просто не существует. Люди слишком сложные.

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

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

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

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

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

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

P.S. Обычно в постах я пытаюсь привести примеры из своей практики. Но тут они могут быть слишком чувствительными для участников тех или иных событий.

Радио «Виктор»: Как искать бездельников?
Инженерная профессия включает большую долю творчества. Разработка так и называется, потому что это про изобретение решений. В других IT-профессиях, например, в дизайне, эксплуатации, QA, тоже много изобретательства. А это значит, что:
- На производительность влияют не только навыки, инструменты и контроль, но и такие эфемерные вещи, как удобство, понимание цели и даже хорошее настроение.
- Нет полностью объективных критериев оценки навыков.
- Не существует эффективного способа контроля продуктивности.
- Один человек за час может сделать больше, чем десять за десять дней.

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

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

История Васи
Однажды я пришел руководить удаленной командой, которая делала проект по оптовой продаже цветов. Был разработчик, назовем его Вася, который несколько месяцев работал над проектом. Цветы закупались на голландских биржах. Где-то данные получали через API, а где-то приходилось парсить HTML/XML прайс-листы. Вася участвовал в обсуждениях, задавал вопросы, но его задачи постоянно сдвигались. Однажды он показал нам белую страницу, где «ну уже почти все готово, только багу поправить». В другой раз, показал по видео кусок кода, который вот уже почти работает, но к ревью еще не готов. В третий — показал, что в базе, которую он наполняет, вот уже что-то есть (правда оказалось, что данные только первого запроса в первый API метод).

Я пошел общаться с командой и разбираться почему так. Может, действительно, эта задача такая трудная, а я снаружи не вижу. И оказалось, что несколько предыдущих задач, которые «сдавал» Вася, на самом деле за него делали другие члены команды. К кому-то он приходил с просьбой помочь. С кем-то делали проект вдвоем, только вот «Вася приболел». А кто-то вообще половину работы сделал в рамках кодревью. И так ловко это было сделано, что никто в команде не считал Васю нахлебником. А проджект менеджер был Васей доволен. Результат моего исследования показал, что Вася не сделал ни одной задачи(!) за несколько месяцев — все делал кто-то другой. При этом, технически он был даже лучше подкован, чем коллеги.

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

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

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

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

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

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

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

Умения
Возможно, вы формально все делаете правильно, но «дьявол кроется в деталях». Например, одно дело — проводить регулярные 1-to-1, другое — получать от них результат.

Недавно я разговаривал с другом, который жаловался, что вынужден микроменеджерить через уровень: решать некоторые задачи вместе с тимлидом и его сотрудником буквально втроем. Он и подчеркивал важность результата, и планы составлял, и показывал на примерах, как их добиваться. Использовал разные подходы, проводил ретро по аналогичным задачам. Но каждый раз все заканчивалось чем-то вроде «ну, будем внимательнее». Проблема была в том, что не хватало работы в режиме постмортем. Хочется сказать, что сразу все стало хорошо, но врать не буду — выводы делать еще рано.

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

Однажды мы не могли отладить плавающий баг с etcd. При определенном паттерне использования, спустя несколько суток единичные стримы из сотен тысяч «залипали»: соединение не обрывалось, но данные переставали поступать через watch. Проблема вроде была понятна, удавалось ее повторить, код всех компонентов был открытым — бери и решай. Но мы бились несколько недель. В итоге я решил привлечь опытного разработчика из соседней команды. Ему хватило трех дней, чтобы найти проблему. Причем именно там, где ее искали несколько человек, но упорно не видели.

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

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

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