Егор опубликовал пост про рычаги управления, а я решил чуточку разобрать.
числа. многие считают что через числа круто можно менять все параметры систем, процессов и прочее. но нет, числа можно измерять, достаточно понятно, их удобно обсуждать. но системно влиять цифры и числа на что-то — не будут.
запасы и буферы. если запасов мало — мы будем на острие, но постоянно бояться мелких колебаний. а если запасы большие — то просто будем очень инертными и начнем стагнировать.
материальные потоки. например, нахождение бутылочных горлышек или недостаточно утилизированных мест. управление потоками позволит существенно, но долго и дорого, менять что-то в системе.
задержки. мы что-то сделали и ждем. мы что-то получили и забыли уже почему. например — обратная связь. или строительство системы. физические процессы изменять мы не можем, но влиять на адаптацию системы — должны.
сила отрицательной обратной связи. то есть то, что возвращает систему в стабильное состояние. чем их больше, тем устойчивее система.
сила положительной обратной связи. те связи, что усиливаются сами по себе. они могут расшатать систему или вызвать её рост.
информационные потоки. ведь информация — то, откуда система черпает свое состояние. чем прозрачнее — тем быстрее и лучше исправляются проблемы.
правила системы. законы, стандарты, разрешения. понятный рычаг, к тому же действует на долгую перспективу.
способность к самоорганизации. возможность создавать новые правила и связи без внешних вмешательств.
цели систем. куда стремится система. надо очевидно обозначить что цели могут разниться. рост против стабильности. фичи против качества. если мы меняем цель системы — мы меняем всё поведение системы.
парадигма системы. набор предположений и ценностей (из них надо выращивать цели, правила и структуры системы). парадигмы очень сильно меняют систему, но они и очень устойчивые.
сила выхода за рамки парадигм. если участники системы могут выйти за рамки текущей парадигмы и сменить способ мышления — изменения не заставят себя долго ждать. нужно уметь видеть системы в целом, без текущих концепций.
поэтому, если вы видите, что что-то пора менять или придя на новое место свежим взглядом видите пробелмы — надо выбрать через какие рычаги вы будете менять поведение системы. чтобы не потратить силы на легкие рычаги, а система вернется в прошлое состояние.
числа. многие считают что через числа круто можно менять все параметры систем, процессов и прочее. но нет, числа можно измерять, достаточно понятно, их удобно обсуждать. но системно влиять цифры и числа на что-то — не будут.
запасы и буферы. если запасов мало — мы будем на острие, но постоянно бояться мелких колебаний. а если запасы большие — то просто будем очень инертными и начнем стагнировать.
материальные потоки. например, нахождение бутылочных горлышек или недостаточно утилизированных мест. управление потоками позволит существенно, но долго и дорого, менять что-то в системе.
задержки. мы что-то сделали и ждем. мы что-то получили и забыли уже почему. например — обратная связь. или строительство системы. физические процессы изменять мы не можем, но влиять на адаптацию системы — должны.
сила отрицательной обратной связи. то есть то, что возвращает систему в стабильное состояние. чем их больше, тем устойчивее система.
сила положительной обратной связи. те связи, что усиливаются сами по себе. они могут расшатать систему или вызвать её рост.
информационные потоки. ведь информация — то, откуда система черпает свое состояние. чем прозрачнее — тем быстрее и лучше исправляются проблемы.
правила системы. законы, стандарты, разрешения. понятный рычаг, к тому же действует на долгую перспективу.
способность к самоорганизации. возможность создавать новые правила и связи без внешних вмешательств.
цели систем. куда стремится система. надо очевидно обозначить что цели могут разниться. рост против стабильности. фичи против качества. если мы меняем цель системы — мы меняем всё поведение системы.
парадигма системы. набор предположений и ценностей (из них надо выращивать цели, правила и структуры системы). парадигмы очень сильно меняют систему, но они и очень устойчивые.
сила выхода за рамки парадигм. если участники системы могут выйти за рамки текущей парадигмы и сменить способ мышления — изменения не заставят себя долго ждать. нужно уметь видеть системы в целом, без текущих концепций.
поэтому, если вы видите, что что-то пора менять или придя на новое место свежим взглядом видите пробелмы — надо выбрать через какие рычаги вы будете менять поведение системы. чтобы не потратить силы на легкие рычаги, а система вернется в прошлое состояние.
Telegram
Teamlead Good Reads – ежедневные советы про менеджмент людей и команд
Как менять поведение систем
Донелла Медоуз – автор очень известной книги про системное мышление "Thinking in Systems". Есди вы ее не читали, то вот это ставшее уже классическим эссе про то, какие рычаги для изменения поведения систем существуют, даст довольно…
Донелла Медоуз – автор очень известной книги про системное мышление "Thinking in Systems". Есди вы ее не читали, то вот это ставшее уже классическим эссе про то, какие рычаги для изменения поведения систем существуют, даст довольно…
а вот у нас на прошлом месте
в одной там компании, которую я не буду называть, делали вот так!
а еще знаете, во всех бигтехах принято делать вот такие вещи.
знаете, по моему опыту — лучше делать следующим образом.
но если что — в ИМЯРЕК обычно ПРОЦЕСС иначе проходит.
так вот: если у вас есть опыт, которым вы хотите поделиться — хорошенько покрутите текущую ситуацию и примерьте пример до конца. не нужно вслепую доводить до "скопируем", но берите лучшее из своего (и чужого) опыта, давая простор для эволюционных изменений и роста.
либо вовсе, забудьте всё, что учили в школе, оно вам не понадобится, начинайте заново, с чистого листа и делайте хорошо.
и нет, я вроде не про то, что я на новом месте)))
в одной там компании, которую я не буду называть, делали вот так!
а еще знаете, во всех бигтехах принято делать вот такие вещи.
знаете, по моему опыту — лучше делать следующим образом.
но если что — в ИМЯРЕК обычно ПРОЦЕСС иначе проходит.
так вот: если у вас есть опыт, которым вы хотите поделиться — хорошенько покрутите текущую ситуацию и примерьте пример до конца. не нужно вслепую доводить до "скопируем", но берите лучшее из своего (и чужого) опыта, давая простор для эволюционных изменений и роста.
либо вовсе, забудьте всё, что учили в школе, оно вам не понадобится, начинайте заново, с чистого листа и делайте хорошо.
и нет, я вроде не про то, что я на новом месте)))
😁12
наконец-то запустили лендинг)
https://observability-conf.ru я там в ПК, но еще и выступлю со стендапом(даешь антикризисную коммуникацию)
последние несколько лет плотно дружу с ребятами из команды наблюдаемости (не важно где они, в какой компании), поэтому решил что мое участие в этой конфе обязательное.
да, на техно-трек еще нужны спикеры, но мест там не много, уже затащили кучу спикеров. поехали!
https://observability-conf.ru я там в ПК, но еще и выступлю со стендапом
последние несколько лет плотно дружу с ребятами из команды наблюдаемости (не важно где они, в какой компании), поэтому решил что мое участие в этой конфе обязательное.
да, на техно-трек еще нужны спикеры, но мест там не много, уже затащили кучу спикеров. поехали!
❤11🔥5
двуличие и лицемерие
я долгое время был уверен что лицемерие и двуличие это одно и то же. ну как: одному говоришь одно, другому — другое и всё крутишь в свою выгоду. это ты двуличный или лицемерный?
а если ты в одних обстоятельствах действуешь одним образом, а в других — переобуваешься?
если ты свои (или чужие) плохие действия прикрываешь благими намерениями — ты лицемер.
а если ты говоришь "всё сделаем хорошо!", а делаешь дерьмово (осознанно) — ты двуличный.
однако, избежать оба этих искривления (недостатка) можно через прозрачность и открытость. декларируй публично, держись курса. а если курс надо изменить — делай это публично и снова держись курса.
последовательность лучше непредсказуемости. со стороны зла и слабости очень удобно действовать непредсказуемо, но это никогда не создаст вам хорошей репутации и не даст искренних союзников на долгий срок.
я долгое время был уверен что лицемерие и двуличие это одно и то же. ну как: одному говоришь одно, другому — другое и всё крутишь в свою выгоду. это ты двуличный или лицемерный?
а если ты в одних обстоятельствах действуешь одним образом, а в других — переобуваешься?
если ты свои (или чужие) плохие действия прикрываешь благими намерениями — ты лицемер.
а если ты говоришь "всё сделаем хорошо!", а делаешь дерьмово (осознанно) — ты двуличный.
однако, избежать оба этих искривления (недостатка) можно через прозрачность и открытость. декларируй публично, держись курса. а если курс надо изменить — делай это публично и снова держись курса.
последовательность лучше непредсказуемости. со стороны зла и слабости очень удобно действовать непредсказуемо, но это никогда не создаст вам хорошей репутации и не даст искренних союзников на долгий срок.
❤8
Forwarded from nubes [всему облака]
Media is too big
VIEW IN TELEGRAM
Резервирование — это важно. Мы, как облачный провайдер с собственными дата-центрами, это знаем.
Но даже если у ЦОДа 33 канала связи, какой-нибудь экскаватор может наворотить дел и слегка нарушить стабильность работы облака.
В ООО «Магат» так и случилось. Скажем больше: их еще и от электричества грозились отключить.
Как ребята справились с такой патовой ситуацией, смотрите на любой удобной платформе.
🛡 VK
🛡 RuTube
🛡 YouTube
Но даже если у ЦОДа 33 канала связи, какой-нибудь экскаватор может наворотить дел и слегка нарушить стабильность работы облака.
В ООО «Магат» так и случилось. Скажем больше: их еще и от электричества грозились отключить.
Хорошая новость в том, что все это выдумка и происходило исключительно в рамках нового выпуска шоу «Второй фактор».
Как ребята справились с такой патовой ситуацией, смотрите на любой удобной платформе.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁3
червонцы
знаете такую фразу "я не червонец, чтобы нравиться всем"? вроде, Бунин сказал, или Кинчев. не суть важно.
важно вот что: если уж кому и нравиться — то своей команде, для них ты должен быть хорошим, честным, открытым и справедливым.
если мыслить шире — своей командой можно назвать много кого, не только тех, у кого ты в штатке, но и в масштабах компании, а может и дальше.
и уж точно не стоит переживать, если для "чужих" ты сделал что-то, что их не устроило. да потому что всегда найдутся те, кто не доволен или кого не устроило что угодно.
это не призыв делать плохо, лишь бы свои прихвостни (оу май) сказали "батя, жги дальше", но повод призадуматься "если все, кому важно и нужно — довольны, то вот не пофиг, что там говорят в стороне?".
haters gonna hate, а мы едем дальше!
знаете такую фразу "я не червонец, чтобы нравиться всем"? вроде, Бунин сказал, или Кинчев. не суть важно.
важно вот что: если уж кому и нравиться — то своей команде, для них ты должен быть хорошим, честным, открытым и справедливым.
если мыслить шире — своей командой можно назвать много кого, не только тех, у кого ты в штатке, но и в масштабах компании, а может и дальше.
и уж точно не стоит переживать, если для "чужих" ты сделал что-то, что их не устроило. да потому что всегда найдутся те, кто не доволен или кого не устроило что угодно.
это не призыв делать плохо, лишь бы свои прихвостни (оу май) сказали "батя, жги дальше", но повод призадуматься "если все, кому важно и нужно — довольны, то вот не пофиг, что там говорят в стороне?".
haters gonna hate, а мы едем дальше!
🔥10👍3
радость сделанного и тяжесть зависшего
есть люди, которые получают удовольствие от процесса. им как будто не важен результат, важно само действие, то что происходит, шаг за шагом. гусары, нет.
а я вот — результата всегда жду. и если что-то долго делаю, переделываю и не получается — это очень демотивирует. ну то есть нет, не когда надо микро-победы. даже проигрыши — хорошо. плохо когда нет результата или не ясны перспективы.
висит над тобой этот Дамоклов меч, а ты тревожишься. зато когда доделал — закрываешь эти 20 вкладокчатжпт и выдыхаешь!
поэтому я не веду тудушки — я в них утопаю, а домашние дела, которые надо сделать — либо делаю сразу, либо очень стараюсь сделать как только смогу.
есть люди, которые получают удовольствие от процесса. им как будто не важен результат, важно само действие, то что происходит, шаг за шагом. гусары, нет.
а я вот — результата всегда жду. и если что-то долго делаю, переделываю и не получается — это очень демотивирует. ну то есть нет, не когда надо микро-победы. даже проигрыши — хорошо. плохо когда нет результата или не ясны перспективы.
висит над тобой этот Дамоклов меч, а ты тревожишься. зато когда доделал — закрываешь эти 20 вкладок
поэтому я не веду тудушки — я в них утопаю, а домашние дела, которые надо сделать — либо делаю сразу, либо очень стараюсь сделать как только смогу.
❤10🔥1
Forwarded from МТС True Tech
У нас вышел новый подкаст «На острие DevOPS: AI, IAC, что дальше?» 🔥
В этом выпуске мы разбираем, как меняется мир DevOps — от философии и базовых принципов до самых свежих трендов.
Ведущие выпуска:
Алексей Костюков — DevOPS Lead в MWS;
Арина Зайцева — Senior DevOPS в MWS.
В гостях:
Антон Егорушков — приглашенный DevOPS-эксперт.
Переходите по ссылке!
#TrueTechExpert@truetechcommunity
В этом выпуске мы разбираем, как меняется мир DevOps — от философии и базовых принципов до самых свежих трендов.
Ведущие выпуска:
Алексей Костюков — DevOPS Lead в MWS;
Арина Зайцева — Senior DevOPS в MWS.
В гостях:
Антон Егорушков — приглашенный DevOPS-эксперт.
Переходите по ссылке!
#TrueTechExpert@truetechcommunity
Please open Telegram to view this post
VIEW IN TELEGRAM
умный в комнате
вчера во внутренней встрече прозвучала отчасти инсайт-фраза. многие ей вдохновились (не знаю, надолго ли?):
да, мысль не нова, цитата понятно чья (Джеймса Уотсона, но не того, а этого)
но я вдруг понял для себя — это же очень важный критерий в работе: когда ты работаешь в команде, у которой ничему не учишься — ты для начала теряешь ориентиры, потом стагнируешь, а после — демотивируешься.
если в твоей команде, отделе, компании есть люди, слушая которых, смотря на их работу — ты вдохновляешься — это и есть стимул, это движущая мотивация.
и да, без выпендрежа, но я попадал в компании, где я был в позиции "я деградирую, меня тут ничему не научат". и, что страшнее, я видел в таких компаниях людей умных и классных, которые просто садились ниже травы и не шумели. просто им так комфортно.
а мне так не комфортно. я буду шуметь)
вчера во внутренней встрече прозвучала отчасти инсайт-фраза. многие ей вдохновились (не знаю, надолго ли?):
Если вы будете самым умным в комнате, то вы ничему не научитесь, значит, вы просто ошиблись дверью
да, мысль не нова, цитата понятно чья (Джеймса Уотсона, но не того, а этого)
но я вдруг понял для себя — это же очень важный критерий в работе: когда ты работаешь в команде, у которой ничему не учишься — ты для начала теряешь ориентиры, потом стагнируешь, а после — демотивируешься.
если в твоей команде, отделе, компании есть люди, слушая которых, смотря на их работу — ты вдохновляешься — это и есть стимул, это движущая мотивация.
и да, без выпендрежа, но я попадал в компании, где я был в позиции "я деградирую, меня тут ничему не научат". и, что страшнее, я видел в таких компаниях людей умных и классных, которые просто садились ниже травы и не шумели. просто им так комфортно.
а мне так не комфортно. я буду шуметь)
❤7👍5
наблюдаемость
я еще до прихода в Yandex Cloud, знал что в этом году будет запуск observability platform (можно и MaaS — monitoring as service) и ждал выхода, общался на стендах с ребятами.
потом я собеседовался к ним же в команду и у меня горели глаза от того, о чем мне рассказывали (я даже вкинул пару фича-реквестов на словах).
ну а когда я попал-таки в Yandex Cloud, в свою команду (о чем не жалею), а вокруг только и разговоров об observability platform — тогда я узнал как её назовут.
а теперь вот, сегодня, выкатили monium и всех зовут смотреть.
хорошо бы, конечно, чтобы помимо платформы, методологиями люди обрастали, то есть не только мы, внутри, но и все мы, снаружи.
я немало времени провел рядом или внутри o11y и мне все эти штуки понятны и знакомы, o11y это далеко не только мониторинг (и не только мой грядущий стендап 19 марта)
я еще до прихода в Yandex Cloud, знал что в этом году будет запуск observability platform (можно и MaaS — monitoring as service) и ждал выхода, общался на стендах с ребятами.
потом я собеседовался к ним же в команду и у меня горели глаза от того, о чем мне рассказывали (я даже вкинул пару фича-реквестов на словах).
ну а когда я попал-таки в Yandex Cloud, в свою команду (о чем не жалею), а вокруг только и разговоров об observability platform — тогда я узнал как её назовут.
а теперь вот, сегодня, выкатили monium и всех зовут смотреть.
хорошо бы, конечно, чтобы помимо платформы, методологиями люди обрастали, то есть не только мы, внутри, но и все мы, снаружи.
я немало времени провел рядом или внутри o11y и мне все эти штуки понятны и знакомы, o11y это далеко не только мониторинг (и не только мой грядущий стендап 19 марта)
❤6
ответственность
это слово, в котором я часто опечатываюсь из-за идущих подряд тстстстстствт, ну понятно)
а еще это свойство, которое нужно в себе взращивать, если ты хочешь расти и быть востребованным, нужным (но не будь незаменимым!)
и вроде: чем выше грейд — тем больше ответственность, потому что с большой силой и далее по тексту.
а что вообще вкладывается в ответственность? сказать "да, это я накосячил"? нет. взять на себя проект? тоже не совсем. скорее, понять что от тебя надо и быть в этом полностью. то есть не увиливать, не отказываться и доводить результат.
но, разумеется, можно поменять по пути цель или сойти с дистанции досрочно — это не снимает ответственность, а просто дает возможность её переместить или перераспределить. главное не скидывать всё вникуда (хотя, если результат уже никому не нужен и не важен — можно).
обязанность же — это что-то более жесткое, потому что если ты обязан — это зафиксировано, это от тебя будут требовать, а не просто ждать.
кстати, обязан ли менеджер быть ответственным?
ответственнен ли менеджер за то, что делают его подчиненные в рамках их ответственности?
а что если зону ответственности поменять на зону контроля? о, да, шериф в городе! тогда даже становится интересно: что я контролирую, над чем имею власть (бе) и право решения (вот это уже хорошо).
не набирайте себе ответственности и контроля, за которыми не сможете следить и отвечать. потому что в какой-то момент с вас будут это требовать.
это слово, в котором я часто опечатываюсь из-за идущих подряд тстстстстствт, ну понятно)
а еще это свойство, которое нужно в себе взращивать, если ты хочешь расти и быть востребованным, нужным (но не будь незаменимым!)
и вроде: чем выше грейд — тем больше ответственность, потому что с большой силой и далее по тексту.
а что вообще вкладывается в ответственность? сказать "да, это я накосячил"? нет. взять на себя проект? тоже не совсем. скорее, понять что от тебя надо и быть в этом полностью. то есть не увиливать, не отказываться и доводить результат.
но, разумеется, можно поменять по пути цель или сойти с дистанции досрочно — это не снимает ответственность, а просто дает возможность её переместить или перераспределить. главное не скидывать всё вникуда (хотя, если результат уже никому не нужен и не важен — можно).
обязанность же — это что-то более жесткое, потому что если ты обязан — это зафиксировано, это от тебя будут требовать, а не просто ждать.
кстати, обязан ли менеджер быть ответственным?
ответственнен ли менеджер за то, что делают его подчиненные в рамках их ответственности?
а что если зону ответственности поменять на зону контроля? о, да, шериф в городе! тогда даже становится интересно: что я контролирую, над чем имею власть (бе) и право решения (вот это уже хорошо).
не набирайте себе ответственности и контроля, за которыми не сможете следить и отвечать. потому что в какой-то момент с вас будут это требовать.
🔥6
reliability
я всегда стараюсь быть человеком, на которого можно положиться. то есть, меня можно о чем-то попросить и знать что я сделаю. ну или даже я может сам найду что сделать и сделаю. reliable person
простое слово надежность — не очень полно раскрывает понятие reliability.
оно так же включает доступность, например, отказоустойчивость и прочие антихрупкие свойства.
применительно к системам — это вообще комплексный принцип , включающий подходы, практики и инструменты.
в системной инженерии, есть целый фреймворк r9y, который я надеюсь перевести на русский и рассказать о нем на какой-либо конференции.
а еще, в своей работе, я занимаюсь именно reliability, customer reliability engineering.
это значит, что моя команда помогает клиентам получать стабильные системы, получать лучший опыт от использования услуг Yandex Cloud, но не ограничиваясь этим. мы строим не только клиентский опыт, но и практики, подходы работы со сложными системами.
если сублимировать мой опыт в профессиональной деятельности, то прямо многое меня вело именно к тому, чем я занимаюсь теперь. сочетание devops практик, понимания продуктовых систем, высоконагруженных сервисов, а так же душноты работы с технической поддержкой — и вот мы находимся здесь.
CRE — это интересно, это сложно и каждый раз неожиданно. можно сильно упростить и сказать что это SRE for customers. но по правде — SRE в наших краях уже давно неверно толкуется))
я всегда стараюсь быть человеком, на которого можно положиться. то есть, меня можно о чем-то попросить и знать что я сделаю. ну или даже я может сам найду что сделать и сделаю. reliable person
простое слово надежность — не очень полно раскрывает понятие reliability.
оно так же включает доступность, например, отказоустойчивость и прочие антихрупкие свойства.
применительно к системам — это вообще комплексный принцип , включающий подходы, практики и инструменты.
в системной инженерии, есть целый фреймворк r9y, который я надеюсь перевести на русский и рассказать о нем на какой-либо конференции.
а еще, в своей работе, я занимаюсь именно reliability, customer reliability engineering.
это значит, что моя команда помогает клиентам получать стабильные системы, получать лучший опыт от использования услуг Yandex Cloud, но не ограничиваясь этим. мы строим не только клиентский опыт, но и практики, подходы работы со сложными системами.
если сублимировать мой опыт в профессиональной деятельности, то прямо многое меня вело именно к тому, чем я занимаюсь теперь. сочетание devops практик, понимания продуктовых систем, высоконагруженных сервисов, а так же душноты работы с технической поддержкой — и вот мы находимся здесь.
CRE — это интересно, это сложно и каждый раз неожиданно. можно сильно упростить и сказать что это SRE for customers. но по правде — SRE в наших краях уже давно неверно толкуется))
Forwarded from Инженер и Менеджер
Потратил 30 минут на новую статью McKinsey, чтобы вам не пришлось.
Свежая статья McKinsey — «Courageous Conversations: How to Lead with Heart». Рассказывают про четыре типа «смелых разговоров», которые должен вести CEO. Приводят цитаты Черчилля и Кира Великого! Слово courage встречается 47 раз, если вам интересно.
Но я отжал воду и вот что получилось.
🔹Obligation to dissent — несогласие как обязанность
Современное лидерство — это не про «у нас можно спорить с начальством» (это типа декларация). Современный руководитель создает атмосферу «ты обязан сказать, если видишь проблему».
Разница: лидер не ДЕКЛАРИРУЕТ принципы, а СОЗДАЕТ окружение, в котором эти принципы прорастут.
McKinsey предлагает назначать «chief challenger» в совещаниях — человека, чья работа тестировать допущения группы. Идея не новая (premortem, red team), но формулировка «обязанность, а не право» меняет фрейм. Когда ты молчишь — ты не «осторожный», ты не выполняешь свою работу.
У меня в команде такой человек есть на постоянной основе. Он выступает в роли адвоката дьявола, и я постоянно его за это публично благодарю. Это важно: как лидер вы должны поощрять смелость выступать в такой роли. Кстати, привет тебе, сотрудник Х, если ты себя узнал!
🔹Hardware vs Software в обратной связи
Типичная проблема: менеджер даёт обратную связь и мешает в одну кучу факты, эмоции, оценки и пожелания. Получается либо сухой удар цифрами («SLA просел на 15%, разберись»), либо мягкое облако без конкретики («хотелось бы больше ownership»).
McKinsey предлагает простое разделение. Сначала — hardware: что произошло, какие были договорённости, какой результат. Потом — software: почему ты это поднимаешь, с каким намерением, чего хочешь для человека.
«Релиз опоздал на две недели, потому что мы поздно подключили инфру» — это hardware.
«Я говорю это не чтобы наказать, а потому что хочу, чтобы в следующий раз ты сам эскалировал раньше» — это software.
Когда оба слоя идут вперемешку, человек не понимает, его ругают или учат. Когда раздельно — слышит и то, и другое.
🔹Withholds — невысказанные обиды
McKinsey удивляет нас фактом: команды с накопленным напряжением работают хуже, чем счастливые команды. Спасибо, McKinsey! Ждем статью «Быть здоровым лучше, чем быть больным: доказываем на цифрах» в вашей следующей рассылке.
А если серьезно, как раз 5-го Марта я писал пост на тему конфликтов. Моя позиция: лучше столкнуть два мнения, чем позволить невысказанным словам копиться где-то внутри человека.
tl; dr
Но главная мысль статьи — не декларировать, а создавать. И я подписываюсь под ней: я слишком много видел деклараций и гораздо реже — действия.
Свежая статья McKinsey — «Courageous Conversations: How to Lead with Heart». Рассказывают про четыре типа «смелых разговоров», которые должен вести CEO. Приводят цитаты Черчилля и Кира Великого! Слово courage встречается 47 раз, если вам интересно.
Но я отжал воду и вот что получилось.
🔹Obligation to dissent — несогласие как обязанность
Современное лидерство — это не про «у нас можно спорить с начальством» (это типа декларация). Современный руководитель создает атмосферу «ты обязан сказать, если видишь проблему».
Разница: лидер не ДЕКЛАРИРУЕТ принципы, а СОЗДАЕТ окружение, в котором эти принципы прорастут.
McKinsey предлагает назначать «chief challenger» в совещаниях — человека, чья работа тестировать допущения группы. Идея не новая (premortem, red team), но формулировка «обязанность, а не право» меняет фрейм. Когда ты молчишь — ты не «осторожный», ты не выполняешь свою работу.
У меня в команде такой человек есть на постоянной основе. Он выступает в роли адвоката дьявола, и я постоянно его за это публично благодарю. Это важно: как лидер вы должны поощрять смелость выступать в такой роли. Кстати, привет тебе, сотрудник Х, если ты себя узнал!
🔹Hardware vs Software в обратной связи
Типичная проблема: менеджер даёт обратную связь и мешает в одну кучу факты, эмоции, оценки и пожелания. Получается либо сухой удар цифрами («SLA просел на 15%, разберись»), либо мягкое облако без конкретики («хотелось бы больше ownership»).
McKinsey предлагает простое разделение. Сначала — hardware: что произошло, какие были договорённости, какой результат. Потом — software: почему ты это поднимаешь, с каким намерением, чего хочешь для человека.
«Релиз опоздал на две недели, потому что мы поздно подключили инфру» — это hardware.
«Я говорю это не чтобы наказать, а потому что хочу, чтобы в следующий раз ты сам эскалировал раньше» — это software.
Когда оба слоя идут вперемешку, человек не понимает, его ругают или учат. Когда раздельно — слышит и то, и другое.
🔹Withholds — невысказанные обиды
McKinsey удивляет нас фактом: команды с накопленным напряжением работают хуже, чем счастливые команды. Спасибо, McKinsey! Ждем статью «Быть здоровым лучше, чем быть больным: доказываем на цифрах» в вашей следующей рассылке.
А если серьезно, как раз 5-го Марта я писал пост на тему конфликтов. Моя позиция: лучше столкнуть два мнения, чем позволить невысказанным словам копиться где-то внутри человека.
tl; dr
Но главная мысль статьи — не декларировать, а создавать. И я подписываюсь под ней: я слишком много видел деклараций и гораздо реже — действия.
👍3❤2
ИИ и он-прем
вовсю идет 2026 год и если ты не юзаешь ИИ — ты отстал от жизни.
но если ты живешь в реалиях современности — ты не хочешь все размещать в облаках, ты хочешь и он-прем уметь крутить. в том числе и ИИ, и даже (ого!) managed сервисы.
и что же я вам хочу сказать? крутые ребята (в их числе мой хороший знакомый Юра, мы вместе работали и теперь снова вместе работаем), выкатили сегодня долгожданный Stackland!
это, очень грубо говоря Yandex Cloud у нас дома. то есть на своем железе можно разместить часть сервисов (в том числе ai studio) и работать в похожем на привычную консольку интерфейсе.
почему мне интересно это? да потому что я давно уже адепт не просто cloud-native, а cloud-agnostic, который в себя включает мультиклауд и даже гибрид (он-прем + облака).
летс гоу и хорошего развития продукту!
вовсю идет 2026 год и если ты не юзаешь ИИ — ты отстал от жизни.
но если ты живешь в реалиях современности — ты не хочешь все размещать в облаках, ты хочешь и он-прем уметь крутить. в том числе и ИИ, и даже (ого!) managed сервисы.
и что же я вам хочу сказать? крутые ребята (в их числе мой хороший знакомый Юра, мы вместе работали и теперь снова вместе работаем), выкатили сегодня долгожданный Stackland!
это, очень грубо говоря Yandex Cloud у нас дома. то есть на своем железе можно разместить часть сервисов (в том числе ai studio) и работать в похожем на привычную консольку интерфейсе.
почему мне интересно это? да потому что я давно уже адепт не просто cloud-native, а cloud-agnostic, который в себя включает мультиклауд и даже гибрид (он-прем + облака).
летс гоу и хорошего развития продукту!
❤6
кубир
https://k8sday.ru/kubeer-talks-3 буду там
судя по составу и по тенденции — будет как минимум хехе, а как максимум хаха
https://k8sday.ru/kubeer-talks-3 буду там
судя по составу и по тенденции — будет как минимум хехе, а как максимум хаха
ух ща как сделаем!!!
сидишь ты с командой и понимаешь — как же классно можно что-то завернуть! и "ух ща как сделаем!"
а потом случается реальность:
ух — не особо энтузиазм проявляется. то есть да, мы хотим, но не прямо бежим сверкая пятками и роняя руду по пути.
ща — не прямо ща, где-то в течение квартала. а квартал — это всего лишь 12 спринтов, а значит вообще может и не в квартале, ну в этом году, или ку5 29
как — давайте разбираться, коллеги! подкидывайте идеи. что значит "у нас так не принято делать?" и что, надо выбирать другой стек? то есть, наши процессы не подходят? получается, идейно никто не против, но все разобьется о реальность и ту реализацию, что придется выполнять?
сделаем — результат будет точно отличаться от исходной идеи. возможно, разительно. а возможно и вообще не будет достигнут. ведь для многих процесс — важнее результата.
но подождите, не так всё туманно и пессимистично)
ух ща как сделаем — это заряд, стимул, направление. запомните свое стремление и состояние и обращайтесь к нему в процессе. а если результат другой — ну что ж, DoD это хорошо, но agile это тоже важно.
не упарывайтесь, а то "мы" в этой фразе никто и не сказал))
сидишь ты с командой и понимаешь — как же классно можно что-то завернуть! и "ух ща как сделаем!"
а потом случается реальность:
ух — не особо энтузиазм проявляется. то есть да, мы хотим, но не прямо бежим сверкая пятками и роняя руду по пути.
ща — не прямо ща, где-то в течение квартала. а квартал — это всего лишь 12 спринтов, а значит вообще может и не в квартале, ну в этом году, или ку5 29
как — давайте разбираться, коллеги! подкидывайте идеи. что значит "у нас так не принято делать?" и что, надо выбирать другой стек? то есть, наши процессы не подходят? получается, идейно никто не против, но все разобьется о реальность и ту реализацию, что придется выполнять?
сделаем — результат будет точно отличаться от исходной идеи. возможно, разительно. а возможно и вообще не будет достигнут. ведь для многих процесс — важнее результата.
но подождите, не так всё туманно и пессимистично)
ух ща как сделаем — это заряд, стимул, направление. запомните свое стремление и состояние и обращайтесь к нему в процессе. а если результат другой — ну что ж, DoD это хорошо, но agile это тоже важно.
не упарывайтесь, а то "мы" в этой фразе никто и не сказал))
Forwarded from канал сыча (anton egorushkov)
моя традиция: в этот день постить эту песню.
https://youtu.be/LRWDHqSq_yo?si=1D5fsjNxIjoEmrbC
https://youtu.be/LRWDHqSq_yo?si=1D5fsjNxIjoEmrbC
YouTube
Боги - Гагарин
Боги - Гагарин (с альбома "Убить время")
Краснодар, инди-рок
Краснодар, инди-рок
❤4👌2
снежинки и стахановцы
в эпоху снежинок и чудиков, уже стало привычным дуть всем в парус и бояться спугнуть рабочий вайбик, лишь бы работали, лишь бы тасочки двигали по досочкам.
если что-то вдруг не так (смузи недостаточно банановый) — они встанут и уйдут.
но это крайность. а есть и другая крайность — сотрудник с горящими глазами, бежит делать всё, что может. делает хорошо и не отказывается.
когда такого сотрудника нагрузили всем чем можно, требуют еще больше, он даже может не замечать, что что-то стало хуже.
не, это не про "медленно варили", это просто про разные приоритеты.
но если вдруг этот сотрудник встанет и уйдет — будет сильно хуже (потому что он может и делает сильно больше снежинки)
поэтому — берегите всех одинаково и не забывайте что печеньки и лимиты по обедам начинают волновать, когда задач хороших нет (или атмосфера хреновая).
в эпоху снежинок и чудиков, уже стало привычным дуть всем в парус и бояться спугнуть рабочий вайбик, лишь бы работали, лишь бы тасочки двигали по досочкам.
если что-то вдруг не так (смузи недостаточно банановый) — они встанут и уйдут.
но это крайность. а есть и другая крайность — сотрудник с горящими глазами, бежит делать всё, что может. делает хорошо и не отказывается.
когда такого сотрудника нагрузили всем чем можно, требуют еще больше, он даже может не замечать, что что-то стало хуже.
не, это не про "медленно варили", это просто про разные приоритеты.
но если вдруг этот сотрудник встанет и уйдет — будет сильно хуже (потому что он может и делает сильно больше снежинки)
поэтому — берегите всех одинаково и не забывайте что печеньки и лимиты по обедам начинают волновать, когда задач хороших нет (или атмосфера хреновая).
питерский хайлоад++
мне уже пару-тройку раз принесли что видели рекламу со мной про saint highload++ 2026. и действительно: мы с Таней и Антохой будем там вести воркшоп по отказоустойчивому приложению (а точнее — подходам построения и траблшутингу) в Yandex Cloud.
приходите к нам, будет весело, практично и даже интересно (мы проверяли). 22-23 июня, в Санкт-Петербурге.
мне уже пару-тройку раз принесли что видели рекламу со мной про saint highload++ 2026. и действительно: мы с Таней и Антохой будем там вести воркшоп по отказоустойчивому приложению (а точнее — подходам построения и траблшутингу) в Yandex Cloud.
приходите к нам, будет весело, практично и даже интересно (мы проверяли). 22-23 июня, в Санкт-Петербурге.
❤9🔥6