Лайфхак на все случаи жизни, когда что-то пошло не так

Почему нет смысла волноваться и гневаться на людей

Подчинённый до повышения и после повышения оклада.

Money ball_вы не просили, но вот советы по увольнению

Про фильм MoneyBall чаще всего говорят в контексте подхода к набору людей в команду и смены парадигмы, которая устоялась в некой индустрии.

Но там же прямо от п.1 до п.7 описан и показан этап увольнения людей.

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

1. Вы должны сесть и проговорить в слух все свои аргументы. И сделать это нужно несколько раз, пока вы не начнете в них верить. Первое, да и не только, увольнение - адский стресс. Вы не сможете «на лету» придумывать аргументы. А еще сложнее будет, если человек перед вами, классный, но с конкретной работой не справляется. Вот тогда становится совсем тяжело подобрать нужные слова. А вы и не должны - подготовьтесь заранее.
2. Увольнение - стресс и для того, кого увольняют. В зависимости от человека, он может промолчать, задать вопрос, ответить утвердительно и предложить обсудить условия или начать говорить о своих личных проблемах, которые вы дополнительно создаете ему увольнением. Это жестко. Вы должны быть к такому готовы. Ниже будет опциональный пункт (7): тут решать толко вам.
3. Начинать нужно с ключевого посыла. В фильме, главный герой сразу говорит о том, что «игрок продан/обменян». Не нужно говорить о том, какой он хороший, какие у него были успехи. Это лишнее. Это мучает вас обоих.
4. Оперируйте фактами, где результат был низкий. Лоу-перформеры, если вы хороший руководитель дающий откровенную обратную связь, скорее всего уже знают о своих проблемах. Перед вами взрослый и умный человек, но он лоу-перформер при выполнении конкретных задач. Не нужно думать, что он «идиот», не унижайте ни себя, ни его.
5. Виноваты ли вы как руководитель? Да. Только если вы затянули с увольнением, если не давали правильной обратной связи. Помните, что не нужно «съедать» себя, просто так! Нужно учиться на своих ошибках.
6. Если не знаете, не умеете увольнять - поговорите с руководителем своим. Слушайте, это нормально, блин, не знать и не уметь. Если ко мне приедет мой менеджер и скажет, что он не знает как «правильно увольнять» я буду готов сидеть с ним и репетировать «увольнение». Это же моя работа, а от его перфоманса, зависит мой перфоманс.
7. Опциональный. Если вы будете «прикипать» к команде: дружить семьями, ходить на вечеринки, где вы «перестанете быть менеджером» (не делайте так), то увольнения будут даваться вам хуже…

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

@badtechproject

Как оценивается производительность сотрудников в FAANG

Расскажу на примере Facebook.

Периодичность. Оценки производительности происходит периодически. Раньше это было раз в 6 месяцев. Потом сделали раз в год. Сейчас промежуточный вариант. Раз в 6 месяцев более лайтовая оценка и финальная раз в год. Есть также раз в квартал (раз в 3 месяца) чекапы с менеджером, что все идет как надо.

Что оценивается. Инженерные специальности оцениваются по 4 осям: project impact, operational excellence/better engineering, direction и people. Для каждой из осей и для каждого левела есть список ожиданий. Это то, что по каждой из осей ожидается от работы инженера. Этот список пересекается с тем, как оценивают соответствие левела сотрудника на поведенческом собеседовании.

Как оценивается.

Self evaluation. Инженер пишет большой документ с перечислением своих достижений за указанный промежуток времени по каждой из оси (self evaluation). Достижения должны содержать числовые характеристики, должны быть подтверждены ссылками на метрики, code change, дашборды, посты, документы и т.д. Очень желательно, чтобы эти достижения ссылались на те цели, которые были поставлены в начале полугодия. Раз в полгода, в компании происходит планирование, на котором формируются цели для команды, отдела и т.д. А также конкретный список проектов под эти цели. Инженер может быть ответственным за один или несколько проектов и целей. Или за подпроект или подзадачу, если проект большой, а его уровня не хватает быть лидом всего проекта. Большинство достижений будут так или иначе связанными с теми проектами и целями, которые были поставлены в начале полугодия. Но ваши достижения могут этим не ограничиваться. Может появится новая работа, новые идеи, вы сделали что-то еще.

Feedbacks. Инженер запрашивает фидбеки от коллег, с кем он работал в течении этого промежутка времени. Что было хорошо, что надо улучшить.

Packets. Далее ваш менеджер смотрит на ваш self-evaluation и составляет пакет документов на каждого из его инженеров. В нем, кроме всего прочего, есть краткая выжимка ваших ключевых достижений, которые повлияли на оценку от менеджера.

Предварительная оценка. После изучения ваших достижений и сравнения их с ожиданиями по каждой из осей, а также с целями, которые были поставлены в начале полугодия, ваш менеджер выставляет вам оценку. Эта оценка имеет множество градаций: does not meet expectation, meets some, meets most, meets all, exceed, greatly exceed, redefine.

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

Performance Review Conversation. Это митинг с вашим менеджером, на котором он сообщит вам вашу оценку, причины того, что повлияло на эту оценку. Обсудит фидбеки и даст свой фидбек на вашу работу. Далее на основе этой оценки вам будет сообщено, какой бонус вы получите, какое повышение зп у вас будет и дадут ли вам и сколько новых акций (refreshers). Если у вас оценка ниже meets all, то у вас могут быть проблемы. Обычно, после двух полугодий подряд с оценкой ниже meets all - человека отправляют на pip или сразу увольняют по соглашению сторон (silent layoff).

Conflict Resolution

На поведенческом собеседовании в FAANG компании очень часто можно встретить вопросы вроде:

1) Tell me about a time you had a conflict with your manager.
2) Tell me about a time you had a conflict at work.
3) Tell me about a time you had a disagreement with someone.

Такие вопросы часто спрашивают в Facebook (Meta) для оценки Conflict Resolution, а также в Amazon при оценке Amazon Leadership Principle - Have Backbone; Disagree and Commit.

Junior-Senior кандидаты из СНГ, да и Staff тоже, очень частно заваливаются на этом вопросе. Это, очень часто, служит причиной получения офера на более низкий уровень или реджекта.

Казалось бы, какой-то бессмысленный HR-вопрос. Но поработав в FAANG более 7 лет я понял, что этот навык супер важный. Не только на собеседовании, а в ежедневной работе. Особенно, с ростом вашего левела.

Кандидаты из СНГ очень часто получают Red Flags и получают reject или down level.
Типичные Red Flags:
1) У меня никогда не было конфликтов. Это просто вранье. Конфликты на работе программиста встречаются почти каждый день. Это не конфликты по типу гопстопа или ты меня уважаешь, а конфликты по вопросам связанным с вашей работой. Это несогласия по время code review, design review, разные мнения и подходы у разных людей к той или иной проблеме. Разные мнения по поводу приоритета той или иной задачи, проекта и т.д. Конфликты возникают как между коллегами в рамках одной команды, так и разногласия между командами, отделами или даже внешними компаниями-партнерами или клиентами. Если у вас не было конфликтов - вы никогда не работали программистом. Или же вы всегда решали их двумя плохими способами: избеганием или продавливанием своего мнения.
2) У меня был конфликт X, и в итоге он решился тем, что я доказал, что я прав, а все другие не правы. Даже если такие случаи были, то это плохой пример. Вы должны обосновывать свою позицию, но должны слышать и другую сторону, а не силой пытаться ее продавить. Если у вас только такие примеры, то скорее всего большинство таких примеров, когда вторая сторона просто забила и прогнулась, для нее это не было приоритетом или у вас было больше власти, сил и желания это продавить. И скорее всего, в итоге часть таких решений были неоптимальными.
3) У меня был конфликт X, в итоге я, просто, проигнорировал и избежал конфронтации и все как-то само решилось. Конфликт на работе это не обязательно что-то плохое. Игнорирование конфликта на работе приводит к накоплению противоречий между сторонами, ухудшению collaboration, а как следствие к ухудшению эффективности организации. При правильном подходе можно найти лучшее решение, чем форсила каждая из сторон конфликта. В таком случае выигрывают все - win-win Conflict Resolution.
4) Вы не использовали данные, в конфликтах. Иногда причина конфликта - это нехватка данных и неверные предположения сторон. В таких случаях можно отложить resolution конфликта, сделать сбор данных и собраться снова и найти win-win resolution.

Не критические, но отрицательные сигналы:
1) У нас был конфликт X, и мы нашли компромисс. Это скорее всего означает, что каждая из сторон немного прогнулась, и осталась немного недовольной. Каждая из сторон просто пошла на уступки, не пытаясь найти какое-то новое, более лучшее решение, которое бы удовлетворила все валидные требования и приоритеты каждой из сторон. Обычно, это от лени и безразличия или свойства психики по избежанию конфликтов. Часто это приводит к неоптимальными решениям.
2) У нас был конфликт X, я полностью признал, что я не прав и сделал так, как сказали, не протестуя. Такое бывает, но это не оптимальный пример для собеседования. Если вы попытались возразить и уже в обсуждение поняли, что были не правы - то это хорошее поведение. Но не лучший пример для собеседования. Лучше подойдут примеры win-win. А если вы не пытались возразить, то скорее всего в итоге было получено неоптимальное решение.

Почему Amazon имеет такие низкие оценки от сотрудников

Я публиковал ранее рейтинг Big Tech компаний, по отзывам от сотрудников, без учета отзыва по компенсации и дайверсити: рейтинг
Amazon там на последнем месте.
Я проработал в Amazon 3.5 года, и я бы не сказал, что мой опыт был ужастным.

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

1) Amazon Leadership Principles. Во всех фангах есть ключевые ценности компании, слоганы и своя культура. Но нигде она так не форсится, как в Amazon. Эти Leadership Principles не просто слоганы, они реально используются в ежедневной работе. Они используются во время технических обсуждений, design review, code review, sev/coe review как реальные аргументы. По ним вас будут оценивать во время перфоманс ревью в конце года. По ним вам будут давать фидбек коллеги. Все это начинает напоминать какую-то секту или религию. И многие называют это промывкой мозгов. Что касается меня, то вначале все это было непривычно, было отторжение, но потом привык и даже начал считать все это, как имеющее вмысл. Если в них вдуматься, то они достаточно осмысленны и полезны.
2) Oncall. Все разрабы по очереди делают саппорт системы, которую они разрабатывают. В некоторых командах такой саппорт - это ночной кошмар. Вам приходится просыпаться посреди ночи и тушить пожары. Особенно, это характерно, для некоторых AWS команд. Многие не выдерживают такого режима и уходят. У меня такого не было в команде. Я за 3.5 года просыпался может быть раз 5 среди ночи и быстро делал рестарт или ролбек, если он автоматически не срабатывал, иногда быстрые конфиг изменения. А уже детальный поиск рут коза и починка была в обычное время. Поэтому, когда собеседуетесь в команду, спросите про oncall, если не спать всю неделю это не ваше.
3) Менеджеры. От менеджера зависит ваша оценка на перфоманс ревью очень сильно. Если вы испортите отношения с менеджером в Amazon, то это сделает вашу жизнь в компании очень короткой и неприятной. Это бывает редко, но все же случается. Я такое несколько раз видел за свою работу, опишу отдельными постами.
4) PIP. PIP - это performance improvement plan. Если вы получили плохую оценку перфоманса, или менеджер хочет от вас избавиться, то вам дадут сложный проект на ограниченный промежуток времени. Все будет документироваться. Если вы его не сделаете, то вас уволят. В Amazon, почти никто не выживает на pip. Люди просто используют эти пару месяцев для поиска работы. Поэтому его в шутку называют paid interview preparation. В других компаниях он тоже есть, но в Amazon и Facebook это чаще, чем в других компаниях. Раньше это было для ~5% в год, или что-то около этого. Сейчас не знаю, может больше. В Facebook раньше это было для 1-3% и половина его переживала. Сейчас в Facebook говорят про 10% в год и даже без pip. Многие называют это silent layoff. Опишу постами, истории, которые я знаю. Но на практике это мало заметно.

P.S. в Amazon есть и другие минусы, но часть из них связана с компенсацией, что в других компаниях можно больше получать, херовый vesting schedule, вам первые два года будут давать мало акций, меньше рефрешеров. Но я не оцениваю компенсацию. Также есть проблемы с промоушенами выше L5, но это в той или иной степени везде не так просто.

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

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

Что со стороны моря, что со стороны города, здание выглядит как огромный пенис.

Если отбросить вполне реальный вариант о том, что собственник и архитектор решили: "Давайте построим на берегу Батуми гигантских размеров хер", то перед нами архитектурное решение, про которое ни один человек — ни в процессе планирования, ни в процессе реализации — не смог (или не решился) поднять вопрос о том, что получается какая-то хрень.

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

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

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

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

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

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

P.S Ну или собственник здания все-таки хотел построить огромный хрен, и тогда это, как минимум, весело.

В компании X Development (это научно-исследовательская «дочка» Alphabet) есть забавный фреймворк под названием «Обезьяна и пьедестал». Его суть в том, что при разработке новой прорывной технологии команда должна сосредоточиться сначала на самых сложных частях проблемы и только потом уже заниматься всем остальным.

Вот как этот фреймворк описал CEO X Development Астро Теллер:

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

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

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

Как этот фреймворк можно применять в бизнесе?

▪️ Разбираем новый проект на составные части

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

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

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

#максима

Сначала создайте коммерческий продукт, и только потом мигрируйте на него.

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

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

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

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

Эта формула (максима) применима, однако, только если есть ресурсы — время и деньги.

Как-то тут собраны все причины увеличения рабочего времени, потраченного на болтовню, кроме основных - https://t.me/sexydesign/7583 А основные такие:

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

- Совещания из-за размера компаний.
Размер компаний налагает сильный штраф на взаимодействие. Многие процессы, кажущиеся совершенно бессмысленными, - результат размера компаний. Например, процесс performance review (абсолютно бесполезный в том виде, в котором он обычно предлагается) рождается из-за невозможности непосредственного руководителя знать, как работает его подчиненный. Поэтому он получает данные из косвенных признаков, в результате чего реальная эффективность подменяется visibility работника (тем, как он выглядит в глазах окружающих). То же самое касается, например, регулярных созвонов со статусами проектов, где куча высокооплачиваемых спецов час сидит, чтобы потом за пять минут рассказать, как обстоят дела в проекте. Подобного рода встреч довольно много, и они отнимают время, чудом оставшеется после 1) скрама, 2) разговоров с заказчиком, 3) собственно рабочих встреч

Завершить могу опытом одного из проектов. В нем моя команда работала совместно с американской командой заказчика. Их производительность составляла где-то 25% от производительности моей команды. Мне не было понятно, почему результаты настолько жалкие, ведь люди были неплохие. При этом бесконечная иерархия скрам-мастеров то устраивала нам миты, где мы обсуждали общие цели, рисовали картинки в Миро и рассказывали про любимую музыку, то делала еще что-то столь же дикое и бессмысленное. Пообщавшись с их лидом, я поняла, в чем дело. 80% из его рабочего времени занимали митинги. За оставшиеся 20% он попросту не успевал работать, ведь эти крохи времени еще и рассредоточены по дню. Когда я сказала, что у меня пропорция для членов команды выглядит наоборот, он только вздохнул. Чем все кончилось? Скрам-мастера заказчика решили, что у нас слишком мало митингов и мало прозрачности - и в итоге производительность упала тоже.

Вышел трейлер второго сезона «Разделения».

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

У первого сезона сериала очень высокие рейтинги и 14 номинаций на премию «Эмми». Так что можете посмотреть, если пропустили

r/#television

Даже собаки умеют делегировать

Меня сегодня впечатлила история о собаках, которую Дробышевский рассказал на лекции «Анатомия власти»:

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

Я думаю, что вожак был настолько уверен в своём авторитете, что не считал, что временное делегирование власти другой собаке (которая разбирается в конкретном процессе лучше него) пошатнёт его власть. Даже более того, он позволял управлять процессом тому участнику стаи, который был полезен всем участникам группы. Тем самым только подкрепляя свой авторитет.

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

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

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

Однако не всегда люди так делают. Я спросила Дробышевского:
—Почему иногда люди, а, может и другие виды, стремятся к абсолютной власти, а не поступают как в вашем примере с собаками?

Дробышевский ответил из роли просто человека, а не учёного:
—Потому что иногда люди просто глупы.

Вот как тут не вспомнить «Собачье сердце» Булгакова, где Шариков в обличье собаки Шарика был умнее и благороднее, чем в обличье человека.

На территории пост-правды этого уже не будет никогда

Не звони мне, не звони!

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

«Чем более ответственная (и, соответственно, высокооплачиваемая) должность, тем чаще она предполагает звонки и решение различных корпоративных вопросов в нерабочее время. В частности, это норма для любых руководящих позиций, в том числе, для руководителей среднего звена», — комментирует Ольга Сапожникова, руководитель отдела по подбору персонала кадровой компании UTEAM.

Интересно, что в ряде стран, среди которых Австралия, Франция, Бельгия, Испания, существуют законы, которые разрешают игнорировать звонки и сообщения в нерабочие часы, без риска каких-либо санкций от начальства.

В России, как отмечает Федеральная служба по труду и занятости, сотрудники также не обязаны отвечать на рабочие звонки во внеурочные часы.

Теперь вы знаете, что делать. Если ничего не боитесь, конечно.

💥Телеграм-канал новых возможностей