Плохой менеджер Артём Арюткин

Команды, платформы и сложные проекты Меня тут некоторое время назад Серёжа Зинкевич - это СЕО К2 Cloud пригласил на подкаст! 🎥Смотреть, если что можно прямо тут. Прислал вопросы и темы для обсуждения. Я глянул - ну топчик. Сумеем заглянуть во все закоулки души и карьеры. О чем поразгоняли: 1. Ошибки, ошибки и еще раз ошибки. Конечно, с моей любимой притчей:

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

2. Где бы я ни был, не могу ни сказать про платформы и про них поговорили. 3. Не забыли и похоливарить и за классический конфликт «быстро» vs «качественно» 4. Ну и вишенка на торте: как понять, что пора команду отпустить.

Все, что нужно знать обо мне как о папе дочки!! 🔥 - если у тебя с твоим ребенком также ❤️ - чисто поддержать нас 🦄 - если у тебя дети ведут себя самым послушным образом

пу-пу-пууу

От хаоса к офферу В поиске оффера чаще всего не хватает не мотивации, а понятных ориентиров: как понять, готов ли я к работе, чего от меня ждут на собеседовании и в каком направлении развиваться дальше. karpovꓸcourses подготовили бесплатный гайд по собеседованиям, где шаг за шагом разобрали весь процесс найма аналитика: этапы собеседований, как выглядит хороший отклик, что проверяют на HR-скрининге, чего ждут на техническом интервью и как презентовать свой опыт. И гайд — «Путь аналитика данных: от Junior к Senior» — это подробное описание грейдов, типичных задач, навыков и зон ответственности, чтобы было понятно, где вы сейчас находитесь и куда двигаться дальше. Переходите по ссылке и забирайте оба гайда в боте бесплатно: https://clc.to/erid_2W5zFGnCDLU Реклама. ООО "КАРПОВ КУРСЫ". ИНН 7811764627. erid: 2W5zFGnCDLU

#пятничное Ну че, было такое? 🔥 - обожаю наблюдать за такими разборками. У меня глаза даже еще больше навыкате бывают 😎 - сам пару раз участвовал ❤️ - хм…никогда не встречал

1️⃣ Монолит first, EDA следом ✅ Вы прошли N секций в процессе найма. Остался маленький нюанс. Нужно решить задачу: "Спроектируйте сервис заказа еды. Масштабируемый на весь мир, естественно." Задачу из System Design😱. Что делать? Давайте разбираться. ⚡️ Конечно, у вас будет кубернетиз и канареечный деплой. ELK, шардированная СУБД. И ещё много чего интересного. Но всё это будет потом. А сначала на сцену должен выйти он - Монолит. Почему? ↗️ Этот базовый компонент позволит: 1) спроектировать минимально работающую систему. 2) описать все нужные флоу - поиск ресторанов, показ меню, выбор блюд, заказ, ... 3) зафиксироваться с интервьюером об очередном пройденном этапе ❗️ Не стоит бояться, что это может быть воспринято как показатель низкого грейда. Скорее, наоборот. В моей практике я видел сениорного кандидата, который сразу пошёл в сложную систему. И поплыл... 🐳 Нарисовал много сервисов. Но где-то стрелочки не доведены до конца. Не все флоу описаны... 🏠 На этом фундаменте уже можно строить масштабируемую систему. В случае сервиса заказа такая архитектура сводится к микросервисной. Где каждый сервис воплощает какой-то из доменов: • обслуживание заказа • проведение оплаты • доставка • ... ❓ Встаёт важный вопрос - как микросервисам взаимодействовать? EDA, твой выход! ‼️ Event-Driven Architecture (EDA) • Мы хотим масштабировать наши сервисы независимо. По максимуму их развязать. Поэтому давайте придумаем такую сущность как событие. order_created, к примеру. • Пускай наш order service при создании пользователем заказа отправляет такое событие. Куда? Не в какой-то определенный сервис. А в какое-то временное хранилище. Вот бы выбрать такое, чтобы можно было с одной стороны легко класть. С другой читать. Настраивать время хранения. • Kafka, твой выход! У нас появляется некое развязывающее ПО. Так называемое middleware. Всё взаимодействие проходит через него. • Поздравляю! 🔥 Мы изобрели архитектуру, основанную на обмене событий между её компонентами! 👍 💯 Почему Кафка? • Логика её использования проста - есть писатели, внутренние топики, потребители • Активно используется в BigTech • Отлично выполняет функцию перекладчика событий. Наш order_created попадает в целевой топик. Откуда эти события вычитывают потребители. В первую очередь payment service. Ещё, возможно, аналитический. Благо функционал consumer groups нам в этом помогает. ✏️ Итого: 1) Мы не пошли в частую ошибку новичка - сразу масштабироваться закидывая интервьюера всеми мыслимыми и немыслимыми терминами 2) Последовали принципу Monolith first 3) Расшили его по сервисам 4) Ввели EDA, события, развязывающий компонент - Kafka 5) Всё это привело нас к более легкому масштабированию "А что с кубернетиз, деплоями, шардированием?", - оказывается до этого может даже не дойти 🐤 💡 Важно начинать с базы. И строить систему эволюционно. 🔥 Удачи в собеседованиях! Автор - Невзоров Владимир. Телеграмм канал - @system_design_world

Сегодня необычный эксперимент. Я хочу дать написать пост в мой канал - Володе Невзорову, который супер эксперт в System Design и даже ведет отдельный канал об этом. Если вы помните, то я топлю за то, что менеджер должен шарить в технике. И вот Володя написал для вас пост о том, как решить одну из задач проектирования.

🚀 Scrum кажется простым на схемах, но в реальной жизни всё сложнее: роли путаются, ответственность размывается, команда перестаёт быть самоуправляемой. Как избежать этого? Приглашаем на открытый вебинар, где разберём, как устроена ролевая модель Scrum на практике. Узнаете: ✔️ Отличия проектного и продуктового подходов ✔️ Что действительно меняется при переходе на Scrum ✔️ Почему классические управленческие привычки здесь не работают Вы чётко поймёте: 🔹 За что отвечает Scrum-мастер 🔹 Роль владельца продукта 🔹 Как формируется ответственность команды 🔹 Что объединяет все роли в единую систему Эти знания помогут выстроить рабочие процессы без микроменеджмента и конфликтов.. 📅 Открытый урок пройдёт 3 февраля в 20:00 МСК в преддверие старта курса «Agile Project Manager». Зарегистрируйтесь, чтобы не пропустить: 👉https://otus.pw/qKOL/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Спираль социализации решения Не уверен, что это официальный термин. Но явление максимально реальное. Социализация решения - это когда ты публично «проносишь» идею через организацию: объясняешь, собираешь вопросы, закрываешь риски, добираешь поддержку. И вот что я постоянно вижу: менеджеры проваливают социализацию не потому что идея слабая, а потому что они выбирают неправильный порядок. Как обычно происходит: 1. придумал идею 2. сделал презентацию 3. вышел сразу на широкий круг 4. получил шквал вопросов / возражений / «а почему не так?» сдулся, демотивировался, пошел «допиливать» в одиночку Проблема тут простая: ты приходишь “на всех” без прогрева и без опоры. И аудитория делает свою работу, то есть начинает проверять решение на прочность. Только проверка происходит публично, шумно и не в твою пользу. Как надо: Социализация - это спираль. Начинай с ближнего круга: тех, кто лоялен к тебе, реально шарит в контексте, сможет добить решение вопросами «по делу», а не политикой. Прошел первый виток → поправил → получил поддержку. Дальше расширяй круг: следующий виток стейкхолдеров, потом следующий. И важный эффект: на каждом витке у тебя появляется “опора”. Ты уже не «один с презентацией», а «мы обсудили с X и Y, договорились вот так, спорные моменты закрыли». Это резко меняет позицию в обсуждении и снижает уровень хаоса. Вывод простой: не спешите “показать всем”. Выделите эти лишние 4–8 часов на прогрев и прогоны. Это выглядит профессионально, экономит нервы и, как правило, ускоряет согласование в итоге. Че скажите, есть ли термин «спираль социализации»: 💯 - еще мой дед так говорил и термин точно есть ❤️ - поддержать бедолагу: сам придумал проблему, сам ее решил

А кому сегодня 34 года? Тот я😁 Некоторые вехи достигаются ваще без особых усилий 😁

Илон Маск репостнул его исследование, а я позвал его на подкаст Будущее и настоящее с исследователем из Стенфорда. Ну что, я вам тут не просто так все писал и писал про: 1. Как ребята из стенфорда оценили с помощью ML продуктивность разработки. 2. А потом с помощью этой же модели выяснили, что 10% инженеров или 1.8 млн. в мире не работают (100 тыс.инеженеров в 600 компаниях были изучены). 3. А потом про то, как и где лучше всего применить AI. А писал и изучал я все это, потому что в воскресенье, то есть вчера - мы писали в офисе подкаст с тем самым Егором Денисовым-Бланшем. Егор стал супер знаменит после того, как Илон Маск репостнул его твит и, в общем, дальше понеслась. Что говорит Егор: 1. Если вы еще не используете AI - бегите! Егор говорит, что если 6 месяцев назад он был не то, чтобы скептичен, а предлагал искать правильные места для использования, то теперь вам пора бежать. 2. Все, кто считает, что продуктивность разработчика нельзя померить чаще всего оказываются самыми слабыми компаниями в части реальных результатов. При этом, и те, кто обвешали каждый чих метриками- не топ перформеры. Ключевая задача менеджмента найти правильный баланс. 3. Каждые 6 месяцев AI будет забирать некий кусок вашей работы. И всем нам придется научиться с этим жить. В целом, получилось очень круто! Прямо 2 часа невероятно плотного разговора. Ребята забрали все это на монтаж! Так что ждем! Stay tune, как говорится!

Оооо Тут вирусится история с «мой 2016», ловите! Мне 24, я еще не седой, выгляжу как тощая шпала и огромный прыщ на лбу - вишенка на торте! Это, кстати, меня сделали Тимлидом и начальник с воем кабинете фоткает для корпоративного портала! А ты в 2016? 😎 - еще сдавал или готовился к ЕГЭ 🧑‍💻 - уже синьор помидор с 10+ лет опыта ❤️ - ток работать как раз начинаю, джун-мидл

#пятничное Вы там держитесь! И аккуратнее при планировании 💯 - жиза! ❤️ - помогите! 🦄 - я так не делаю

За свою карьеру я видел принципиально два подхода к подбору человека на роль CTO. 🔧 CTO – самый сильный эксперт, он должен знать до мельчайших подробностей как работает его продукт, участвовать во всех встречах и согласовывать все решения. Я сам вырос из такого CTO, столкнувшись со временем с целым рядом проблем: ⚠️ Сложные решения замыкаются на одном человеке, который с ростом компании становится бутылочным горлышком, а эффективное масштабирование становится невозможным ⚠️ Быть везде и всегда – верный путь к выгоранию и вероятному уходу, а болезнь или увольнение такого человека – сродни катастрофе (bus-фактор) ⚠️ Люди в такой команде растут в основном только технически – CTO принимает основные управленческие решения и единолично несет за них ответственность ⚠️ CTO зачастую не видит критичной необходимости нанимать людей сильнее себя и средний уровень экспертизы команды не растет ✅ У этого подхода, на мой взгляд, лишь одно преимущество – имея в одной голове все детали и нюансы небольшого продукта можно принимать отдельные технические решения заметно быстрее и точнее. Поэтому при всех описанных недостатках он вполне работает до определенного размера компании, и особенно – если CTO вырос вместе с ней. 🧩 CTO – архитектор окружения, инженер человеческих систем из сильных экспертов и процессов. Такой человек следует принципу: "Don't aim to be the smartest person in the room. Aim to be the one who builds the best room". При грамотном выстраивании: ✅ Решения принимаются распределенно – людьми, которые фокусно и экспертно ищут наилучшие варианты, а вся система может масштабироваться ✅ Люди в такой среде активно растут, получая личный управленческий опыт и обмениваясь им ✅ При найме в команду экспертов сильнее CTO растет общая сила симбиоза знаний и опыта отдельных участников ✅ Команда автономна и может достаточное время успешно функционировать в его отсутствие ⚠️ Недостаток у этого подхода, на мой взгляд, лишь один – при распределенном принятии решений нелинейно растут издержки на коммуникации, что, впрочем, будто бы неизбежно происходит при значительном росте любой компании

Леша Суринов (мой хороший знакомы и СТО SberID) выдал базу про то, какие виды СТО бывают. И вот лучше не скажешь и я согласен на все 100%

Аналитика давно перестала быть территорией «дата-саентистов». Сегодня с данными живут: - продакты, - менеджеры, - маркетинг, - тимлиды, да и вообще все, кто принимает решения, а не просто пересылает письма. Поэтому аналитические навыки — это не про смену профессии. Это про взросление роли. На программе «Аналитика данных» от МФТИ и Нетология как раз идут не «по верхам», а по нормальному пути: Откуда вообще берутся данные и почему им нельзя верить «по умолчанию»? Как анализировать, чтобы находить сигналы, а не рисовать красивые графики? Внутри — Python, базы данных и базовые подходы к ИИ. Без магии, но с пониманием, что, зачем и для кого ты делаешь. Формат — онлайн. Подойдёт: - тем, кто хочет зайти в аналитику осознанно, - и тем, кто уже работает с данными, но чувствует, что всё «лоскутами». На выходе: 1. дипломы МФТИ и Нетологии, 2. портфолио проектов, 3. и, что важнее, — системная картинка в голове. Начать учиться → Реклама. ООО “Нетология” ОГРН 1207700135884 Erid:2VSb5wjTvr5

Ваша разработка замедляется и это… Нормально! С каждым годом оценка задач/трудоемкость должны расти, селя-ви. Почему так? 1. закон Лемана, о котором я уже писал: энтропия всегда растет! 2. Товарищ Кент Бек (чел, который придумал экстремальное программирование и в свое время участвовал в формулировке Agile Manifesto) расписал эту же теорию, но на современный лад. Опциональность (это из экономической теории) - количество вариантов действий/шагов, которые у вас есть для следующего шага. Как пример, шахматы. У вас на старте 20 возможных ходов. После первого хода соперника, количество ваших опций может уменьшиться (если вы ходите вторым). Фичи - количество фичей постоянно растет (ну это нормально, если ваш бизнес развивается). И вот получается, что каждая следующая фича делает ваш продукт лучше, но замедляет с каждым новым релизом. То есть уменьшает вашу опциональность (для простоты, условно, вы выбираете некий стек и теперь завязаны на него и каждая следующая фича только усиливает эту зависимость. ORACLE в свое время подсадил на себя 80% корпораций). Возможно вы не чувствуете это сегодня, но точно ощутите на себе завтра Что делать? Кент предлагает использовать Tidy First- подход. 1. Tidying first - означает, привести код в более чистое, структурированное состояние перед новой функциональностью, 2. Ответить на вопросы: Что мешает следующей фиче сейчас? Что можно упорядочить, чтобы её сделать легче? 3. Такая работа может временно снизить скорость видимого прогресса, но в долгой перспективе убыстряет весь процесс, потому что увеличивает опциональность. То есть, отщипнуть немного сегодня, чтобы сохранить темп. Звучит как хорошая инвестиция! Ну если короче, надо перед каждой фичей делать небольшой рефакторинг. Картиночку я вам тоже приложил. А как у вас дела с управлением техдолгом? 🦄 - четко выстроенный процесс, каждый спринт инвестируем ресурсы 🔥 - нууу скорее вот прямо по жесткой необходимости раз в 3-12 месяцев 💊 - памагитеее! Живем с долгом еще от 2018 года, чисто как не тех долг, а ипотека

Давно не было про ощущения вне моно-найма, а опросы говорят, что вам это интересно! Победа конца прошлого года — перестал оценивать свое решение о выходе из моно-найма только деньгами. Почти год я старался зарабатывать сильно больше, чем в корпорации, вот прямо почти любой ценой, и это было единственной метрикой успеха. Сейчас же покататься на лыжах в понедельник — не менее важная штука, чем объём выручки. Сегодня, например, мы начали утро на катке всей семьёй. Короче, я заадоптил окончательно, что дело не только в деньгах. И не столько. Отсутствие избытка больше не повод для тревоги: • На ипотеку, аренду квартиры и базовые потребности семьи заработал — класс. • Долгосрочные проекты двигаются — вообще отлично, значит не стою на месте. • Есть время жить — супер, я за этим и шёл. • Кратно меньше стресса — это офигеть какое достижение, дороже денег, потому что в гробу нет карманов. Это не означает, что пропали амбиции и живу по течению. Как будто даже наоборот! Перестал истерить и начал смотреть дальше вперёд. Если первый год я воспринимал как майлстоун и задачей было продержаться и быть в своих глазах красавчиком, то теперь пришло осознание, что впереди охренеть какой марафон, и я в самом начале пути. У подножия холма своей истории. А если повезёт — у подножия горы. И вот тут появилась внутренняя целостность и радость от жизни. Почувствовал счастье от достаточности и устойчивости. Прошлый год был истеричной погоней за финансовыми результатами. Этот год будет про выстраивание длительных историй. Может даже планировать научусь, кто знает. Жить в состоянии "продержаться" очень ресурсоёмкая история. Раньше думал, что иначе и не бывает, а сейчас как понял. И вам желаю это на своём опыте прожить и понять. А если уже — вы красачик или может быть красавица!

Отлично утренний пост дополняет Антон. Который утверждает, что вырвался из пут корпорации и теперь кайфует! Верим Антону?))

Лидер с влиянием или GPT на ножках? Жила была Лена, школу она закончила с отличием, в инстутите тоже все все было норм, знания Лена умело поглощать с невероятной скоростью и точностью. Друзья, однокурсники и знакомые называли ее ходячей энциклопедией и Лену, в глубине душе это радовало. Ведь все логично складывается - больше знаешь - круче становишься. Вот тебе пятерки, вот тебе диплом правильного цвета, и вот тебе стажировка в большой нефтяной компании. Попав на стажировку Лена быстро стала показывать сверхрезультаты, то, что другие делали за 6 часов она умудрялась сделать за 40 минут, да и объемом работы обходила всех остальных стажеров, Лене было совершенно не сложно и конечно скоро ее перевели на должность специалиста. Следующие несколько лет Лена росла по экспертным грейдам, и все было опять логично. Более сложные задачи требовали больших компетенций и знаний, а у Лены с этим всегда было прекрасно, она перемещалась по уровням словно в тетрисе и все было предсказуемо. Потом случился потолок экспертных грейдов и директор предложил Лене возглавить отдел. Посмотрев по сторонам и поняв для себя, что это просто еще один уровень в этой игре - Лена вписалась. И в начале все было неплохо, управление оказалось такой же наукой, в которой нужно было просто разобраться и постпенно стало понятно что делать с подчиненными. Лене стало нравится, она захотела расти дальше, пока не споткнулась о стену, которую раньше не замечала. С какого-то момента стало понятно, что руководители над Леной и ее коллеги, руководители смежных подразделений, вообще не обязательно про глубокую экспертизу. Часто Лене казалось (хоть природная вежливость не позволяла об этом даже думать), что половина ее коллег конченные дегенераты, которые в своем домене вообще ничего не понимают, но почему-то сидят. И, о ужас, к ним даже руководство временами прислушивается. При этом Лена воспринималась как “очень умная и высокопотенциальная”, вот только к важным решениям ее не привлекали. С ней работали в режиме “запрос-ответ”, очень радовались, когда ответы нравились и… ничего. А меж тем у Лены внутри, все чаще, горели эмоции: опять кретинское решение, опять неправильное назначение, опять идиотский план. И она пыталась найти еще больше экспертных аргументов и донести до руководителей что же здесь не так. Но как она не старалась, со стороны все выглядело, как будто GPT апгрейднули с 4й на 5ю версию, стал умнее, толковее, точнее, но вот решаем мы все равно без него. Отгадка Лениной проблемы в том, что часто влияние вообще никак не связано с экспертизой и вот почему: 1. Экспертиза делает тебя ценным, но не делает тебя субъектом решений, система легко платит за умного помощника, но крайне неохотно отдаёт власть тому, кто привык быть всегда прав. 2. Людей вроде Лены отодвигают не потому, что они слабые, а потому что они слишком хорошо видят риски - и редко проговаривают готовность взять ответственность за последствия. 3. Пока ты доказываешь, что прав, кто-то рядом просто принимает решение - даже если оно хуже. Лена слишком долго росла в модели «я знаю лучше - значит меня должны слушать». Но корпоративный мир устроен иначе: здесь слушают тех, кто не только объясняет, почему нельзя, но и говорит как будет - и готов потом отвечать за последствия. Поэтому система нашла для Лены удобную роль, полезную, уважаемую и вообще суперценную - GPT на ножках. И если в какой-то момент ты ловишь себя на том, что тебя ценят за ум, но обходят стороной, когда нужно выбрать направление, возможно, ты всё ещё растёшь в экспертизе, но давно не растёшь во влиянии. А это две разные траектории ) #сережинымысли