Я вам веселых менеджерских историй из икса принес. Хороших выходных!
https://x.com/12_18/status/1904946807970357384
https://x.com/12_18/status/1904946807970357384
👍29
42. Команда из джунов и культурные различия. Евгений Jesovile
👉 https://youtu.be/n-od0zxm8kA
Менеджеры строят систему из людей, которые строят целевую систему. Системы нельзя копировать по чертежам, под каждый случай нужно выстраивать свою команду. Для этого у менеджера должен быть чемоданчик наработанных инструментов.
В этом выпуске мы поговорили с Евгением про его путь в профессию, аналитический подход, культурные различия и как использовать все это, чтобы построить эффективную команду из джуниоров.
Канал Евгения - https://xn--r1a.website/jesovile_It_madness
Твиттер - https://x.com/EugeneJesovile
Трэк The Algorithm - userspace - https://youtu.be/UOn156pgC50?si=IcJ8Crox3UNM6XV9
Книга Нила Форда "Fundamentals of software architecture" - https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451
👉 https://youtu.be/n-od0zxm8kA
Менеджеры строят систему из людей, которые строят целевую систему. Системы нельзя копировать по чертежам, под каждый случай нужно выстраивать свою команду. Для этого у менеджера должен быть чемоданчик наработанных инструментов.
В этом выпуске мы поговорили с Евгением про его путь в профессию, аналитический подход, культурные различия и как использовать все это, чтобы построить эффективную команду из джуниоров.
Канал Евгения - https://xn--r1a.website/jesovile_It_madness
Твиттер - https://x.com/EugeneJesovile
Трэк The Algorithm - userspace - https://youtu.be/UOn156pgC50?si=IcJ8Crox3UNM6XV9
Книга Нила Форда "Fundamentals of software architecture" - https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451
👍13
В одном из прошлых выпусков, Егор и я сравнивали результаты теста личности. У меня ожидаемо там был высокий балл по негативности.
Т.е. я всегда вижу самый плохой сценарий развития. И постоянно получал обратную связь, что я очень негативный.
Исправить свою личность довольно сложно, но я нашел другой подход. Во первых, я теперь более осознан о этой черте своего характера. Поэтому у меня есть пара секунд, которых достаточно чтобы фронтальная кора перехватила управление. Это позволяет не выдавать негативную оценку ситуации или рефреймить ее.
Я считаю, что ситуацию всегда полезно рассмотреть в полном спектре. Поэтому мое видение негативного сценария тоже ценно. Но теперь я предвосхищаю свою оценку словами: мы все знаем, что я склонен видеть пессимистичные сценарии, но считаю, что ситуацию следует рассмотреть со всех сторон. Вот как я вижу возможный исход...
Такая рефлексия снимает напряжение принимающей стороны. Они не видят меня как негативщика без причины, скорее как человека, который осознанно рассказывает о возможных альтернативных сценариях.
Побочным эффектом получилось: to do the other thing.
Не помню где этот прием вычитал, кажется из фильма. Штука в том, что если ты всегда совершаешь одну и ту же ошибку - попробуй делать противоположную вещь. Так и здесь. Я могу теперь поймать свой сценарий и попробовать посмотреть как если бы он позитивно сбылся наоборот.
https://youtu.be/btd5On3EgQE?si=D7le_bls2ZI4XgAZ
Т.е. я всегда вижу самый плохой сценарий развития. И постоянно получал обратную связь, что я очень негативный.
Исправить свою личность довольно сложно, но я нашел другой подход. Во первых, я теперь более осознан о этой черте своего характера. Поэтому у меня есть пара секунд, которых достаточно чтобы фронтальная кора перехватила управление. Это позволяет не выдавать негативную оценку ситуации или рефреймить ее.
Я считаю, что ситуацию всегда полезно рассмотреть в полном спектре. Поэтому мое видение негативного сценария тоже ценно. Но теперь я предвосхищаю свою оценку словами: мы все знаем, что я склонен видеть пессимистичные сценарии, но считаю, что ситуацию следует рассмотреть со всех сторон. Вот как я вижу возможный исход...
Такая рефлексия снимает напряжение принимающей стороны. Они не видят меня как негативщика без причины, скорее как человека, который осознанно рассказывает о возможных альтернативных сценариях.
Побочным эффектом получилось: to do the other thing.
Не помню где этот прием вычитал, кажется из фильма. Штука в том, что если ты всегда совершаешь одну и ту же ошибку - попробуй делать противоположную вещь. Так и здесь. Я могу теперь поймать свой сценарий и попробовать посмотреть как если бы он позитивно сбылся наоборот.
https://youtu.be/btd5On3EgQE?si=D7le_bls2ZI4XgAZ
YouTube
Не люблю людей, но менеджер | Team Lead Talks Ep. 10
Самая большая ошибка менеджера — не знать себя. У всех есть слепые пятна. Егор и Дима прошли популярный тест на критерии личности, чтобы разобраться в себе. В 10 выпуске мы делимся результатами теста understandmyself.com от Джордана Питерсона. Насколько результаты…
👍25
У меня есть пет проект на работе: наш бекофис. Написан на реакте, апи клиенты и типы все генерятся из openapi. Большинство апих уже есть, надо просто выносить их в UI. Такие вещи невозомжно приоритизировать, поэтому я делаю это в свободное время по 10-15 минут в день.
Из-за корпоративной среды в прошлой компании нужно было сделать много приседаний, чтобы оно запустилось локально. Туннели поднять. После продажи нашего отдела в другую компанию локальная разработка совсем сломалась в нашем коде, но вместе с тем улучшилось вокруг. Доп контейнеров и туннелей теперь не надо. Поэтому первым делом я починил локальный запуск, чтобы можно было работать с кодом. До этого программисты просто в дев выкатывали и смотрели (не спрашивайте).
Теперь постоянно допиливаю нужные фичи и чиню мелкие занозные баги. В прошлую неделю написал письмо команде спорта со списком всего, что команда починила. Люди счастливые писали в личку. Благодарили.
Это предыстория.
Сегодня пишу команде бекенда: норм если мы разрешим этот заголовок на API GW, а то у меня CORS? Инженер отвечает, что вообще норм. И чуть позже: но чище если мы перенесем этот параметр в get params из header, пара строчек буквально.
Бекенд у нас на джаве и скале. Плюс апи сервисы смотрят наружу, поэтому я туда только смотреть хожу. Вот и в этот раз решил, что раз можно header, то туда и пойду. Добавил на стейдж, проверил, что работает, и пишу в чат: спасибо, все работает.
Инженер пишет в личку:
— Дим, а чего ты так мое предложение поправить апи отмел?
— К сожалению, не могу потратить на это 3 инженеро-дня, так что желательно АПИ не трогать.
— Так я явно сказал, что там 3 строчки всего!
— Вот именно поэтому я говорю, что _всего_ 3 дня: поправить, поревьювить, протестировать, выкатить.
И тут инженер просветлел.
Мы очень медленно катим фичи. Просто умереть можно. Я все понимаю, с одной стороны: такие изменения не должны занимать больше полу часа. С другой стороны: ответственность, дежурство, секурити. Вокруг этого мы накрутили процессы, да и наш джава стек не особо заточен под скорость разработки. То есть все обоснованно, сами виноваты, но я не могу перестать этот статус кво шатать.
Какие тут могут быть варианты? Чтобы сократить время до релиза нужно провести подготовку, прямо как я чинил локальную версию.
1. Сократить время на ревью можно через парное программирование. Т.е. само время программистов тратится столько же, но время на ожидание упраздняется. Сели вместе, дописали пару строчек, выкатили на стейдж, проверили, покатили в прод. Но тогда мне синхронно нужно отвлечь двоих.
2. Катить в прод через канари релизы. Когда новая версия кода получает чуть-чуть трафика, доля которого постепенно нарастает. Тут обратная сторона с откатом. Возможные баги прилетают назад спустя пару дней, когда вы уже возможно подзабыли контекст. Еще одна проблема, которую нужно решить - конкурентное тестирование нескольких изменений. Сколько версий кода может одновременно тестироваться? Какой для этого должен быть формат деплоя? Возможно функции? Сколько мы разрешаем тратить на это денег, ведь на каждую версию тратится какое-то количество ресурсов.
3. Менять стек. Если нужно поменять пару строк — это не проблема, но когда мы говорим про фичи побольше, то тут вылезает вся прелесть джавы: https://xn--r1a.website/git_rebase/1088 Плюс желательно чтобы фреймворк для тестирования тоже был очень гибким.
4. Иметь отдельный флот апи для админки. Это снижает риск, но может дать ложную уверенность, что все быстро работает или работает вообще. Да и доп расходы опять же плюс отслеживание версий. Т.е. это почти как канари, но без публичного трафика.
Какие у вас есть идеи?
Из-за корпоративной среды в прошлой компании нужно было сделать много приседаний, чтобы оно запустилось локально. Туннели поднять. После продажи нашего отдела в другую компанию локальная разработка совсем сломалась в нашем коде, но вместе с тем улучшилось вокруг. Доп контейнеров и туннелей теперь не надо. Поэтому первым делом я починил локальный запуск, чтобы можно было работать с кодом. До этого программисты просто в дев выкатывали и смотрели (не спрашивайте).
Теперь постоянно допиливаю нужные фичи и чиню мелкие занозные баги. В прошлую неделю написал письмо команде спорта со списком всего, что команда починила. Люди счастливые писали в личку. Благодарили.
Это предыстория.
Сегодня пишу команде бекенда: норм если мы разрешим этот заголовок на API GW, а то у меня CORS? Инженер отвечает, что вообще норм. И чуть позже: но чище если мы перенесем этот параметр в get params из header, пара строчек буквально.
Бекенд у нас на джаве и скале. Плюс апи сервисы смотрят наружу, поэтому я туда только смотреть хожу. Вот и в этот раз решил, что раз можно header, то туда и пойду. Добавил на стейдж, проверил, что работает, и пишу в чат: спасибо, все работает.
Инженер пишет в личку:
— Дим, а чего ты так мое предложение поправить апи отмел?
— К сожалению, не могу потратить на это 3 инженеро-дня, так что желательно АПИ не трогать.
— Так я явно сказал, что там 3 строчки всего!
— Вот именно поэтому я говорю, что _всего_ 3 дня: поправить, поревьювить, протестировать, выкатить.
И тут инженер просветлел.
Мы очень медленно катим фичи. Просто умереть можно. Я все понимаю, с одной стороны: такие изменения не должны занимать больше полу часа. С другой стороны: ответственность, дежурство, секурити. Вокруг этого мы накрутили процессы, да и наш джава стек не особо заточен под скорость разработки. То есть все обоснованно, сами виноваты, но я не могу перестать этот статус кво шатать.
Какие тут могут быть варианты? Чтобы сократить время до релиза нужно провести подготовку, прямо как я чинил локальную версию.
1. Сократить время на ревью можно через парное программирование. Т.е. само время программистов тратится столько же, но время на ожидание упраздняется. Сели вместе, дописали пару строчек, выкатили на стейдж, проверили, покатили в прод. Но тогда мне синхронно нужно отвлечь двоих.
2. Катить в прод через канари релизы. Когда новая версия кода получает чуть-чуть трафика, доля которого постепенно нарастает. Тут обратная сторона с откатом. Возможные баги прилетают назад спустя пару дней, когда вы уже возможно подзабыли контекст. Еще одна проблема, которую нужно решить - конкурентное тестирование нескольких изменений. Сколько версий кода может одновременно тестироваться? Какой для этого должен быть формат деплоя? Возможно функции? Сколько мы разрешаем тратить на это денег, ведь на каждую версию тратится какое-то количество ресурсов.
3. Менять стек. Если нужно поменять пару строк — это не проблема, но когда мы говорим про фичи побольше, то тут вылезает вся прелесть джавы: https://xn--r1a.website/git_rebase/1088 Плюс желательно чтобы фреймворк для тестирования тоже был очень гибким.
4. Иметь отдельный флот апи для админки. Это снижает риск, но может дать ложную уверенность, что все быстро работает или работает вообще. Да и доп расходы опять же плюс отслеживание версий. Т.е. это почти как канари, но без публичного трафика.
Какие у вас есть идеи?
Telegram
$ git rebase it memes
Это я читаю ваш код наджави и думаю, что вы отлетели там нахкй
@git_rebase / send memes
@git_rebase / send memes
👍10
Довольно заметного инженера уволили из Икса, он описывает, чем он занимался на позиции Staff. Коротко: чинил хайзенбаги и разбирался в заброшенных сервисах, когда те начинали чудить. По ссылке он детально описывает, что он починил.
На самом деле, как мне кажется, человека надо было выделить в отдельный юнит починки всей фигни и найти еще одного такого же, чтобы они как Леголас и Гимли друг перед другом по-приятельски конкурировали.
Такой сетап надо еще уметь продать наверх.
Максим @faang_career говорит, что парень сам виноват и на должности Стаффа нужно больше осведомленности и проактивности.
Что думаете?
https://x.com/yacineMTB/status/1936278079225127184
На самом деле, как мне кажется, человека надо было выделить в отдельный юнит починки всей фигни и найти еще одного такого же, чтобы они как Леголас и Гимли друг перед другом по-приятельски конкурировали.
Такой сетап надо еще уметь продать наверх.
Максим @faang_career говорит, что парень сам виноват и на должности Стаффа нужно больше осведомленности и проактивности.
Что думаете?
https://x.com/yacineMTB/status/1936278079225127184
👍13
Вы знаете, что такое pip в менеджменте?
Anonymous Poll
19%
Менеджер, знаю, а то и сажал.
15%
Менеджер и не в курсе.
18%
Программист, знаю, а то и сидел.
32%
Программист и не в курсе.
15%
Я и есть pip.
43. Команда менеджеров — EM First Team. Евгений Сергеев, Eng Director, Flo
В этом выпуске мы поговорили с Евгением Сергеевым — директором инжиниринга в компании Flo. Евгений прошел путь от инженера до руководителя технических команд, и сегодня он поделился с нами своим опытом этой трансформации, рассказав о ключевых моментах и подводных камнях, с которыми сталкивается каждый, кто решает сменить код на менеджмент.
Мы обсудили множество важных тем: как происходил карьерный переход Евгения и формирование его команды, что такое EM First team, какие стратегии он использует для управления производительностью и мотивацией разработчиков, как создавать новые роли в компании и решать конфликты. Также затронули вопросы найма, важность разнообразия в менеджменте, инструменты для построения эффективных команд и создание инженерной стратегии.
https://youtu.be/DG2vxMAwbOU
Ссылки:
- Выступление Евгения на LeadDev https://leaddev.com/management/organizational-evolution-from-products-to-user-needs
- https://en.wikipedia.org/wiki/Wardley_map
- Книга Team Topologies https://teamtopologies.com/
- Блог компании Flo https://medium.com/flo-health
- Статья про он-бординг пользователей https://learnings.aleixmorgadas.dev/p/mobile-onboarding-evolution-at-flo
- Статья про менеджерство во Flo https://newsletter.manager.dev/p/being-an-engineering-manager-at-flo
В этом выпуске мы поговорили с Евгением Сергеевым — директором инжиниринга в компании Flo. Евгений прошел путь от инженера до руководителя технических команд, и сегодня он поделился с нами своим опытом этой трансформации, рассказав о ключевых моментах и подводных камнях, с которыми сталкивается каждый, кто решает сменить код на менеджмент.
Мы обсудили множество важных тем: как происходил карьерный переход Евгения и формирование его команды, что такое EM First team, какие стратегии он использует для управления производительностью и мотивацией разработчиков, как создавать новые роли в компании и решать конфликты. Также затронули вопросы найма, важность разнообразия в менеджменте, инструменты для построения эффективных команд и создание инженерной стратегии.
https://youtu.be/DG2vxMAwbOU
Ссылки:
- Выступление Евгения на LeadDev https://leaddev.com/management/organizational-evolution-from-products-to-user-needs
- https://en.wikipedia.org/wiki/Wardley_map
- Книга Team Topologies https://teamtopologies.com/
- Блог компании Flo https://medium.com/flo-health
- Статья про он-бординг пользователей https://learnings.aleixmorgadas.dev/p/mobile-onboarding-evolution-at-flo
- Статья про менеджерство во Flo https://newsletter.manager.dev/p/being-an-engineering-manager-at-flo
👍18
Вывести человека из сеньорной команды, чтобы разблокировать рост
У меня есть один инженер, который довольно долго топтался на уровне мидла. В команде есть два довольно сеньорных человека, которые подхватывали все инициативы гораздо быстрее чем другие люди были способны осознать необходимость вмешательства.
Помог коучинг и тех и других, чтобы довести человека до промо, но чудо случилось когда соседней команде потребовался гостевой лид. Они подхватывали один наш проект и надо было помочь разобраться.
Я отправил туда парня и он там расцвел! Никто не сдерживает, никто не присматривает, никто не подхватывает. Расчитывать можно только на себя и он отлично справляется! Только позитивные отзывы и приглашение лидить более крупный проект в той же области.
Отправлял не с целью избавиться, а как раз чтобы у него наконец появилась возможность раскрыться.
Было?
У меня есть один инженер, который довольно долго топтался на уровне мидла. В команде есть два довольно сеньорных человека, которые подхватывали все инициативы гораздо быстрее чем другие люди были способны осознать необходимость вмешательства.
Помог коучинг и тех и других, чтобы довести человека до промо, но чудо случилось когда соседней команде потребовался гостевой лид. Они подхватывали один наш проект и надо было помочь разобраться.
Я отправил туда парня и он там расцвел! Никто не сдерживает, никто не присматривает, никто не подхватывает. Расчитывать можно только на себя и он отлично справляется! Только позитивные отзывы и приглашение лидить более крупный проект в той же области.
Отправлял не с целью избавиться, а как раз чтобы у него наконец появилась возможность раскрыться.
Было?
👍63
Влиять, а не властвовать. CERN, стартапы, Bardeen AI. Артем Арутюнян | Team Lead Talks Ep.44
С Артемом Дима познакомился в компании Mesosphere. Где они оба работали над разными проектами. Артем запомнился как чуткий лидер, который тем не менее был готов принимать сложные решения.
В этом выпуске мы поговорили с Артемом Арутюняном о его пути в программировании, опыте работы в CERN и текущем проекте BARDIN AI. Артем поделился своими воспоминаниями о первых шагах в программировании, сложностях, с которыми он сталкивался на пути менеджера, и значимости нюансов культуры и языка для выстраивания эффективного сотрудничества, особенно когда у тебя нет классической власти менеджера над командой.
https://youtu.be/SnaeufL0e90
С Артемом Дима познакомился в компании Mesosphere. Где они оба работали над разными проектами. Артем запомнился как чуткий лидер, который тем не менее был готов принимать сложные решения.
В этом выпуске мы поговорили с Артемом Арутюняном о его пути в программировании, опыте работы в CERN и текущем проекте BARDIN AI. Артем поделился своими воспоминаниями о первых шагах в программировании, сложностях, с которыми он сталкивался на пути менеджера, и значимости нюансов культуры и языка для выстраивания эффективного сотрудничества, особенно когда у тебя нет классической власти менеджера над командой.
https://youtu.be/SnaeufL0e90
👍12
Forwarded from Senior Software Vlogger
Как принципы влияют на культуру компании
Грамотно подобранные инженерные принципы могут стать важной частью вашей культуры, помочь держать фокус и принимать решения в спорных ситуациях. В этом выпуске обсуждаем примеры принципов, как их выбирать и балансировать.
Тему инженерных принципов мы с Евгением уже затрагивали в одном из выпусков подкаста Team Lead Talks. Мы решили ее раскрыть на примере компаний AWS и Flo в отдельном выпуске.
https://youtu.be/iuuWsFqoZJg
Грамотно подобранные инженерные принципы могут стать важной частью вашей культуры, помочь держать фокус и принимать решения в спорных ситуациях. В этом выпуске обсуждаем примеры принципов, как их выбирать и балансировать.
Тему инженерных принципов мы с Евгением уже затрагивали в одном из выпусков подкаста Team Lead Talks. Мы решили ее раскрыть на примере компаний AWS и Flo в отдельном выпуске.
https://youtu.be/iuuWsFqoZJg
👍12
Картик пишет про США, но я вижу похожую ситуацию и в Европе.
«Я поговорил со многими людьми в сфере технологий, которые пытаются получить работу опытного инженерного менеджера Senior Manaer. Год назад я сам был в такой ситуации и столкнулся с рынком труда напрямую.
Примерно с середины 2022 года начался процесс упрощения организационных структур в техкомпаниях и ликвидации множества позиций среднего менеджмента. Изначально это делали в компаниях вроде Meta, чтобы ускорить процесс принятия решений, когда несколько уровней вице-президентов фактически подчинялись друг другу.
Однако процесс пошёл дальше и затронул множество позиций старших менеджеров. В итоге директора по инженерии получили в прямое подчинение большое количество линейных инженерных менеджеров. Такая организационная структура сейчас чрезвычайно распространена в техкомпаниях.
Любому инженерному менеджеру с большим опытом, включая управление другими менеджерами, сейчас очень трудно найти работу. Их считают переквалифицированными для линейных ролей менеджеров и недостаточно квалифицированными для немногих доступных позиций директоров. И конкуренция за эти редкие вакансии слишком высока.
На сегодняшний день прямые рекомендации от действующих директоров (и выше) фактически остаются единственным надёжным способом получить такую должность. Нужно, чтобы кто-то, кто вас знает и кому вы доверяете, мог оправдать ваш найм и протолкнуть вас в начало очереди»
https://x.com/hkarthik/status/1963045229755539714
«Я поговорил со многими людьми в сфере технологий, которые пытаются получить работу опытного инженерного менеджера Senior Manaer. Год назад я сам был в такой ситуации и столкнулся с рынком труда напрямую.
Примерно с середины 2022 года начался процесс упрощения организационных структур в техкомпаниях и ликвидации множества позиций среднего менеджмента. Изначально это делали в компаниях вроде Meta, чтобы ускорить процесс принятия решений, когда несколько уровней вице-президентов фактически подчинялись друг другу.
Однако процесс пошёл дальше и затронул множество позиций старших менеджеров. В итоге директора по инженерии получили в прямое подчинение большое количество линейных инженерных менеджеров. Такая организационная структура сейчас чрезвычайно распространена в техкомпаниях.
Любому инженерному менеджеру с большим опытом, включая управление другими менеджерами, сейчас очень трудно найти работу. Их считают переквалифицированными для линейных ролей менеджеров и недостаточно квалифицированными для немногих доступных позиций директоров. И конкуренция за эти редкие вакансии слишком высока.
На сегодняшний день прямые рекомендации от действующих директоров (и выше) фактически остаются единственным надёжным способом получить такую должность. Нужно, чтобы кто-то, кто вас знает и кому вы доверяете, мог оправдать ваш найм и протолкнуть вас в начало очереди»
https://x.com/hkarthik/status/1963045229755539714
X (formerly Twitter)
Karthik Hariharan (@hkarthik) on X
I've spoken to a lot of folks in tech who are trying to land an experienced eng manager job. I was there myself about a year ago and dealt with the job market first hand.
Starting in about mid 2022, there was a push to flatten tech orgs and eliminate a lot…
Starting in about mid 2022, there was a push to flatten tech orgs and eliminate a lot…
👍16
Грузить дубли видео выпуски прямо в телеграм?
Anonymous Poll
55%
Давай попробуем
45%
Мне и Ютуб/спотифай/бусти/ямузыка норм
Корпо стресс культуры
Один знакомый менеджер недоумевает: зачем некоторые фанги устраивают своим инженерам ненужные стресс? Зачем нанимать топ 1% и потом устраивать потогонку? Ведь есть другие фанги где этого не делают.
Я думаю, что у этого есть как естественные причины, ну просто так исторически сложилась культура. Такой был изначальный костяк.
Но так же как это может являться и отстройкой от рынка.
Вы не задумывались почему некоторые люди постоянно влезают в совершенно отбитые отношения? А в спокойных отношениях им скучно.
Так же и здесь. Да, нормального человека опыт такой работы выжгет до тла, но человеку с другой психикой будет по кайфу. Они будут плавать в этой культуре как рыба в воде. Причем они точно так же могут страдать на показ как все плохо, но работать в компании без стресса они не смогут. Там им будет очень скучно. Мало динамики. Много планов. Все планы реалистичные. Менеджер даже сука не орёт.
В итоге получается, что такие люди будут задерживаться в потогонках. Им больше некуда пойти. Уходить будут "неподходящие". Либо "бумеранги" которые уходят в другую потогонку, а потом возвращаются за фиксой.
Поэтому я всегда говорю: вы должны на 100% отдавать себе отчёт куда вы идете. Притвориться не получится. Чревато выгоранием до костей.
Один знакомый менеджер недоумевает: зачем некоторые фанги устраивают своим инженерам ненужные стресс? Зачем нанимать топ 1% и потом устраивать потогонку? Ведь есть другие фанги где этого не делают.
Я думаю, что у этого есть как естественные причины, ну просто так исторически сложилась культура. Такой был изначальный костяк.
Но так же как это может являться и отстройкой от рынка.
Вы не задумывались почему некоторые люди постоянно влезают в совершенно отбитые отношения? А в спокойных отношениях им скучно.
Так же и здесь. Да, нормального человека опыт такой работы выжгет до тла, но человеку с другой психикой будет по кайфу. Они будут плавать в этой культуре как рыба в воде. Причем они точно так же могут страдать на показ как все плохо, но работать в компании без стресса они не смогут. Там им будет очень скучно. Мало динамики. Много планов. Все планы реалистичные. Менеджер даже сука не орёт.
В итоге получается, что такие люди будут задерживаться в потогонках. Им больше некуда пойти. Уходить будут "неподходящие". Либо "бумеранги" которые уходят в другую потогонку, а потом возвращаются за фиксой.
Поэтому я всегда говорю: вы должны на 100% отдавать себе отчёт куда вы идете. Притвориться не получится. Чревато выгоранием до костей.
👍17
Team Lead Talks Подкаст
Андрей Васнецов — сооснователь и CTO компании Qdrant, написал первую версию векторной базы данных во время ковида. Основал компанию совместно с учредителями с предыдущей работы, которая привлекла инвестиции и целится стать стандартом для векторных баз данных.…
Новое интервью с Андреем! https://www.youtube.com/watch?v=_GwPpxtMcNs
YouTube
«Мы хотим перепридумать поиск». Как один программист сделал стартап на $200 млн
НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН И РАСПРОСТРАНЕН ИНОСТРАННЫМ АГЕНТОМ ЕЛИЗАВЕТОЙ НИКОЛАЕВНОЙ ОСЕТИНСКОЙ ЛИБО КАСАЕТСЯ ДЕЯТЕЛЬНОСТИ ИНОСТРАННОГО АГЕНТА ЕЛИЗАВЕТЫ НИКОЛАЕВНЫ ОСЕТИНСКОЙ 18+
Приобрести апартаменты в премиум-комплексе Tbilisi Downtown:…
Приобрести апартаменты в премиум-комплексе Tbilisi Downtown:…
👍7
Работа с AI-агентами учит быть лучшим менеджером для людей
Я тут навайбкодил уже 2 штуки и вот что я вам скажу: работать с ИИ-агентами оказалось удивительно похоже на управление людьми — пока не понимаешь одно ключевое различие, которое всё меняет.
Сначала я работал с ИИ-агентами так же, как ставлю задачи инженерам: объясняя что нужно, давал контекст, ждал результат. Но за несколько месяцев стало ясно: ИИ не просто помогает с работой — он прокачивает навыки менеджмента.
Вот что работает как с ИИ, так и с людьми:
1. Контекст надо проговаривать
ИИ заставляет четко формулировать требования и ограничения и требует весь контекст. Забудь про «они и так поймут». Только конкретика. Удивительно, но с людьми точно та же история.
2. Закладывай погрешность
У людей случаются неудачные дни, ИИ галюцинирует и вообще не дает детерминированный ответ. Результат никто не гарантирует. Процессы проверки — тесты, ревью кода — спасают команду от провалов.
3. Режь зацикливание на корню
Наблюдение: чем дольше ИИ крутит задачу тем хуже будет результат. Инженеры тоже любят прыгать в кроличью нору. Чем дольше ты тянешь и не вмешиваешься, тем хуже. Хороший менеджер вмешивается быстро. Переформулируй задачу, раздроби ее еще больше, поменяй исполнителя. Делай все чтобы работа двигалась
4. Дроби задачи
Сложные размытые задачи ломают как ИИ, так и людей. Мелкие проверяемые кусочки — беспроигрышная стратегия.
5. Доверяй, но проверяй
ИИ божится, что баг починен. Разработчики иногда тоже. Проверка обязательна. Плюс ИИ: он не устает. Пусть пишет тесты для кода. Пусть вычитывает документы пока не получится. Можно даже одну модель (сотрудника) проверять другой.
6. Напоминай о целях
У ИИ ограниченная память, у людей — перегруженная голова. Без регулярных напоминаний все сбиваются с курса. Командам нужны ритуалы синхронизации, ИИ — перезагрузка контекста.
Главное отличие: люди умеют "разбираться", ИИ — нет. Так что здесь сходство заканчивается.
Людям можно доверить задачу и знать, что они:
* Соберут нужную информацию сами
* Применят прошлый опыт
* Попросят помощь, когда нужно
* Поймут бизнес-контекст без объяснений
А еще и сами придут и скажут сколько они всего проактивно сделали, даже просить не надо было!
ИИ-агенты так не умеют. Агенты не обладают агентностью! Хехе. Пока. Никакого "разберись сам" — только то, что ты явно объяснил. Иначе провал.
Вот такой урок. С одной стороны такая строгость делает тебя лучшим менеджером: ты яснее ставишь задачи, четче передаешь контекст, выстраиваешь надежную обратную связь. Полезные навыки.
Но если перегнуть палку, начнешь относиться к людям как к роботам — лишишь их самостоятельности, права на суждение и ответственности. А именно это и делает команды эффективными.
Лучшие менеджеры найдут баланс:
* Точность как с ИИ — для ясности задач и контроля
* Человечность в лидерстве — для роста, суждений и автономии
ИИ-агенты (возможно) не заменят разработчиков. Но могут сделать тебя лучшим лидером для них.
Я тут навайбкодил уже 2 штуки и вот что я вам скажу: работать с ИИ-агентами оказалось удивительно похоже на управление людьми — пока не понимаешь одно ключевое различие, которое всё меняет.
Сначала я работал с ИИ-агентами так же, как ставлю задачи инженерам: объясняя что нужно, давал контекст, ждал результат. Но за несколько месяцев стало ясно: ИИ не просто помогает с работой — он прокачивает навыки менеджмента.
Вот что работает как с ИИ, так и с людьми:
1. Контекст надо проговаривать
ИИ заставляет четко формулировать требования и ограничения и требует весь контекст. Забудь про «они и так поймут». Только конкретика. Удивительно, но с людьми точно та же история.
2. Закладывай погрешность
У людей случаются неудачные дни, ИИ галюцинирует и вообще не дает детерминированный ответ. Результат никто не гарантирует. Процессы проверки — тесты, ревью кода — спасают команду от провалов.
3. Режь зацикливание на корню
Наблюдение: чем дольше ИИ крутит задачу тем хуже будет результат. Инженеры тоже любят прыгать в кроличью нору. Чем дольше ты тянешь и не вмешиваешься, тем хуже. Хороший менеджер вмешивается быстро. Переформулируй задачу, раздроби ее еще больше, поменяй исполнителя. Делай все чтобы работа двигалась
4. Дроби задачи
Сложные размытые задачи ломают как ИИ, так и людей. Мелкие проверяемые кусочки — беспроигрышная стратегия.
5. Доверяй, но проверяй
ИИ божится, что баг починен. Разработчики иногда тоже. Проверка обязательна. Плюс ИИ: он не устает. Пусть пишет тесты для кода. Пусть вычитывает документы пока не получится. Можно даже одну модель (сотрудника) проверять другой.
6. Напоминай о целях
У ИИ ограниченная память, у людей — перегруженная голова. Без регулярных напоминаний все сбиваются с курса. Командам нужны ритуалы синхронизации, ИИ — перезагрузка контекста.
Главное отличие: люди умеют "разбираться", ИИ — нет. Так что здесь сходство заканчивается.
Людям можно доверить задачу и знать, что они:
* Соберут нужную информацию сами
* Применят прошлый опыт
* Попросят помощь, когда нужно
* Поймут бизнес-контекст без объяснений
А еще и сами придут и скажут сколько они всего проактивно сделали, даже просить не надо было!
ИИ-агенты так не умеют. Агенты не обладают агентностью! Хехе. Пока. Никакого "разберись сам" — только то, что ты явно объяснил. Иначе провал.
Вот такой урок. С одной стороны такая строгость делает тебя лучшим менеджером: ты яснее ставишь задачи, четче передаешь контекст, выстраиваешь надежную обратную связь. Полезные навыки.
Но если перегнуть палку, начнешь относиться к людям как к роботам — лишишь их самостоятельности, права на суждение и ответственности. А именно это и делает команды эффективными.
Лучшие менеджеры найдут баланс:
* Точность как с ИИ — для ясности задач и контроля
* Человечность в лидерстве — для роста, суждений и автономии
ИИ-агенты (возможно) не заменят разработчиков. Но могут сделать тебя лучшим лидером для них.
👍48