👌 НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ (НОРМИНГ)

• На стадии нормализации происходит каскад изменений.
• Конфликты помогают людям успокоиться и рационализировать мышление.
• Группа перестраивается, изгоняет проблемных участников и пересматривает цели.

Риски и задачи этапа нормализации

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

⭐️ РЕКОМЕНДАЦИИ НОРМИНГ

• Выяснить индивидуальные потребности участников.
• Призывать к сотрудничеству и объяснять, что успех возможен только совместными усилиями.
• Работать сначала со всей группой, затем уточнять договоренности индивидуально.

Мотивация и возвращение участников

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

Роль руководителя

• Руководитель должен быть модератором, направляющим и структурирующим обсуждения.
• Обучать людей навыкам конструктивных взаимодействий и открытой коммуникации.
• Успех зависит от умения руководителя организовывать и модерировать групповые обсуждения.

💪 СТАДИЯ КОМАНДНОЙ РАБОТЫ (ПЕРФОРМИНГ)

• Восстановление производительности и улучшение настроения участников.
• Участники осознают ценность друг друга и становятся настоящей командой.

⭐️ РЕКОМЕНДАЦИИ ПЕРФОРМИНГ

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

🔚 ФИНАЛЬНАЯ СТАДИЯ (РАСПАД)

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

Изменения в команде

• Со временем в команде могут накапливаться изменения в мировоззрении, мотивах и привычках.
• Это может привести к новому кризису, но с меньшим риском развала группы.
• Важно контролировать процесс, чтобы избежать полного развала.

Как пройти систем дизайн?

Все материалы для подготовки к систем дизайнам я запостил в пятничном пыльном чулане. Но что происходит на реальных собесах?

Я провел несколько десятков систем дизайнов, а сейчас прохожу обучение на "илитную архитектуру" (надеюсь, меня возьмут в круг избранных), поэтому у меня есть сформировавшееся мнение.

Мы даём задачку, сформулированную очень размыто. Но там обязательно будет какой-то челлендж от размера: большая нагрузка, много данных, много интерферирующих сценариев и т.п.
Здесь ожидается, что кандидат выяснит, что вообще надо сделать. Поспрашивает, сколько пользователей, продемонстрирует back of the envelope computation skills. Sori za moj ingliš. Это показывает наличие какой-то насмотренности на хай лоад, кроме того, некоторые кандидаты здесь начинают плыть между битами, байтами, мегбитами и мегабайтами, сколько там байтов в инте и флоте... Плохой знак.

Потом моя персональная рекомендация: разработайте API. Его можно потом доделать, но продумывание каких-то основ функционирования системы происходит именно в этот момент. Обычно всем пофиг на rest vs grpc vs graphql, я бы не тратил на это время. Но желательно что-то выбрать, озвучить и оформить API в _едином_ озвученном стиле.
И не забывать про response!

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

Когда кандидат понимает профиль нагрузки, схему API и функциональное устройство системы, он может находить проблемы, с которыми столкнется текущая конфигурация при эксплуатации. Где-то слишком большой рейт на запись, где-то тяжелые запросы на чтение. Нужно указать на эти проблемы и полечить их. Тут же, имхо, стоит подумать об отказоустойчивости. Рассказать, что будет при отказе той или иной части.

Дальше мы ждём, что кандидат подумает о каких-то крайних случаях. На самом деле есть какие-то стандартные кейсы типа супер популярный ивент, человек и т.п. или супер массовый подписчик. Т.е. объект, который все хотят прочитать и объект, который хочет прочитать всех. Чем больше таких штук кандидат найдет и починит, тем лучше впечатление останется.

От расчёта железа решили, все-таки отказаться. Хотя были кандидаты, которые это успевали.

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

P.S.:
есть отдельный трек таких интервью для технических менеджеров и продактов, про него могу отдельно прокомментировать, если вам интересно будет

🧠 РЕТРОСПЕКТИВА

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

• Не оставляйте выявленные проблемы без решения.
• Если проблемы не решаются, люди теряют интерес к процедуре.

⭐️ АЛЬТЕРНАТИВА КОМАНДООБРАЗОВАНИЮ - РЕГЛАМЕНТАЦИЯ

• Регламентация может быть альтернативой командному подходу.
• Регламентация описывает все нюансы работы группы.
• Регламентация может быть необходима в опасных или нестабильных условиях.

⭐️ ПРИМЕРЫ РЕГЛАМЕНТАЦИИ

• Регламентация используется в авиации, поездах, энергетике и хирургии.
• Регламентированные группы могут быть более эффективными, но требуют постоянного контроля.
• Регламентация подавляет инициативу, но может быть необходима для безопасности.

⭐️ ТИМБИЛДИНГ И КОМАНДООБРАЗОВАНИЕ

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

🚨🚨🚨!БУДЕТ СТРИМ!🚨🚨🚨

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

В комментариях к этому посту пишите вопросы!

Как перестать просирать задачи

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

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

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

Потом я прочитал книжку Максима Дорофеева "Джедайские техники". Там очень крутой нарратив, что сложные (компликованные мне самому больно) штуки нам делать тяжело. И подход Максим предлагает очень простой. Но я даже его не смог реализовать. Нужно ЕЩЁ ПРОЩЕ!

Посмотрев на свою рутину и на наивные попытки людей всех рангов и степеней систематизировать и организовать свой телеграм, я обнаружил, что этот мессенджер — главная точка входа. У меня тогда ещё был ноушен с шаренными 1-1 бордами. Начальник мне в телегу написал тему с комментом, что было бы удобно написать "/notion тема на 1-1", а не лезть искать ссылку и заводить задачу. У меня заняло где-то пару часов наклепать бота на make.com, который из текстового сообщения в телеге делал карточку в ноушене и клал на нужную доску. Теперь начальник мог прислать сообщение боту, а не мне — не дергать меня без надобности, но и удобно записать мысль.
А потом ноушен того этого. И скатертью дорожка, если честно.

Поставил я себе todoist, подсмотрев у нескольких коллег. Но в нём все флоу какие-то не для меня. То сложные, то там надо задачам срок проставлять заранее — фу, короче. Нудятина.

Зато ботика переписать на тудуист не составило никакого труда! Поэтому, я начал изучать инструмент и строить что-то более или мене удобное. Кажется, получилось.

Входящие
В тудуисте прям раздел есть такой. Очень удобно. Всё, что приходит в голову, сваливаю туда. Могу написать гениальную мысль в бота в телеге, могу переслать сообщение, на которое надо оптом ответить или прочитать, интересные ссылки, видосики, всё подряд — всё летит во входящие.
Пару раз в день я захожу во входящие и разбираю всё, что там лежит. Переформулирую, дополняю, кладу в базу знаний (ну как базу...) и т.д. Из входящих всё должно либо выполниться, либо превратиться в задачку, которую потом делать буду.

Список задач
Он у меня один. Вообще буквально просто один список задач на сегодня. Но разделен на две колонки: обязательные к завершению сегодня и желательные (которые на ближайшее время на самом деле).
Список у меня сделан фильтром. Он ходит по всем проектам и собирает в две колоночки задачки.
Обязательные я помечаю тегом must.
Все остальные задачи попадают либо по признаку срок=сегодня (это всякие запланированные заранее штуки типа сходить к стоматологу или написать пост в канал), либо они лежат в своих проектах в колонке "ближайшее".

Проекты
Есть два проекта: работа и личные дела. В целом большого смысла в этом разделении нет, но в отпуске приятно при планировании недели не вспоминать про работу. Поэтому так.
В этих проектах по три колонки: ближайшее (поедет в фильтр), когда-нибудь (зачастую никогда, да) и периодически (повторяющиеся задачи, чтоб не мешались, они как раз по срокам в фильтр попадают или по гео локации).
У проекта работа есть подпроекты. Это доски для встреч 1-1. Там есть колонки повестка, действия (тоже в фильтр заезжают), старт/стоп/продолжать, о чем говорили (по идее лог беседы, но мне лень записывать, там пара записей за всю историю). Этих подпроектов дохрена. Ну типа, с кем регулярно встречаемся, для каждого есть такой. Удобно на встрече посмотреть в повестку и вспомнить, че хотел обсудить. А попадают задачи в повестку из входящих, да.

Разное
Есть ещё куча заготовок для тудуиста в интернете. Я себе взял Life Admin, чтобы не забывать покупать кофейные зерна и другие жизненно необходимые вещи, но жена справляется без меня.
Кстати, можно дать доступ жене, чтобы она тоже херачила тебе задачи в бэклог. Тоже удобно.

А как этим всем пользоваться-то?
А всё просто.

- Любая мысль, идея (позвонить маме!, а как там тот парень с родительского собрания? надо попросить чуваков сделать крутой дэшборд! подготовить, наконец, ответ тому коллеге в телегу) — пишешь ботику. Ботик заносит во входящие. Всегда можно на бегу надиктовать в телефон или даже часы. Можно переслать откуда-то, потом вспоминать контекст)))

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

- Идешь в фильтр Go Ahead, берешь там первую же задачу из списка must. Делаешь. Потом следующую.

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

- Раз в неделю прилетает задача "еженедельный обзор". Можно прям по GTD канонам, а можно просто по проектам пройтись и посмотреть, что переложить в когда-нибудь, а что, наоборот, из когда-нибудь в ближайшее или удалить.

- Если есть задача с датой, то просто вбей дату в задачу, положи задачу в периодически. Оно в нужный момент вылезет в фильтре.

Я со своей кучей подпроектов купил себе про подписку. Но в целом схема очень простая и легко повторяется в бесплатной версии. Если хотите помощи с no code ботиком, проще всего попросить ChatGPT, но можно и мне написать, я не кусаюсь.

Система эта у меня постоянно эволюционирует, но в скорее в сторону упрощения (так что может и деградирует). Но смысл уже много лет в том, чтобы ничего не пытаться запомнить, а все записать в одно место, где я это найду. Пока что это лучшая схема из всех, что у меня были. Пользуйтесь! Делитесь своими лафхаками для неэффективного и tupovo трекинга задач в комментах.

Я хотел сделать лайтовый пятничный "Пыльный чулан" про забавную физику, но посмотрел на пост про распределенные системы и решил дать вам ПОБОЛЬШЕ ХАРДКОРА.
Сегодня достаём разговорчики про перфоманс в основном внутри одной машины.

Не так уж и давно я решал SRE Week от Яндекса. Там были задачки на перфоманс.

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

- потом была spsc queue на C++, rate limiter на golang и задача, которую я не решил из-за лени.
Для лучшего понимания memory ordering'ов в очереди стоит почитать пост с картинкой Serializable vs Linearizable и приправить постом про барьеры памяти.
Про отношения между latency и throughput (пригодится с рейт лимитером) есть (имхо) красивая аналогия в соответствующем посте.

- последний блок задач был на исследование проблем с производительностью с помощью bpftrace — там типичная история из жизни performance инженера, когда ты мерил, мерил, но мерил не то 🤡
Постов про bpftrace у меня нет, поэтому я просто порекомендую постом книгу Дениса Бахвалова про перфоманс и микрооптимизации с массированным использованием perf'а. Заодно разберетесь со всякими там фронтендами и бэкендами процессора. А для подготовки к этой книге, стоит прочитать (если еще не) WEPSKAM (хотя лучше pdf найдите).

Вне категорий ещё неймдроппинг:
- Brendon Gregg, System Performance, которую я украл у Серёги
- Peter Sewell, статьи из раздела Relaxed-memory concurrency, кладезь золота, которую мне открыл Шипилёв

Есть ещё, но мне кажется, что уже этого вполне достаточно, чтобы забить себе башку на месяца вперёд))

Event driven management

Как ни странно, это продолжение темы "как всё успевать". Я этого не планировал, но по сути вкусно так получается.

Я уже писал, что не люблю всякие синхронные коммуникации, встречи, звонки (ха-ха) и т.д. Не прям все, а скорее регулярные, потому что их почти (sic!) всегда эффективнее делать письменно и асинхронно.

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

Зачем тут, спрашивается руководитель? Развивать сотрудников и решать конфликты? Ну так это коуч какой-то. Оценивать перфоманс и назначать зарплаты? Можно заменить кем-то из HR. Следить за тем, что процессы соблюдаются? Надзиратель.

Мы знаем, что руководитель здесь нужен для этого всего тоже, но в основном для того, чтобы работа в итоге была сделана. Это вообще как бы основная функция начальства — доводить до результата.

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

Поэтому идеальная система должна работать так. Люди че-то сидят, делают, работу работают, а начальник сидит курит в сторонке. Как только "конвеер встал" (да, у меня опять фордовские аналогии), начальник подрывается и бежит чинить. То есть если сотрудник сам не может исправить ситуацию, он немедленно эскалирует в руководителя. И так по всей иерархии вверх, пока проблема не решится.

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

На деле люди не очень любят "жаловаться", потому что по умолчанию считают, что кому-то от этого плохо станет (и пусть лучше так считают, чем на каждый чих к вам ходить будут, конечно). Поэтому очень круто построить сигнальную систему.

Расскажу, что есть у меня, а что я бы хотел, чтобы было ещё.

1. Я стараюсь коммуницировать, что при затыках, проволочках и потере темпа _нужно_ идти и эскалировать в меня. Это вообще первый и главный сигнал к включению
2. Колонка "запланировано" всегда должна содержать не менее X задач (X, очевидно, разнится). Здесь мы хотим не менее пяти задач, а если их становится меньше трёх, то это повод прямо сейчас разобраться, что ещё нужно докинуть. Иначе следующий освободившийся сотрудник не будет знать, за что взяться и случится бесполезный простой в лучшем случае. В худшем сотрудник будет делать задачу, которая важна _по_его_мнению_. С другой стороны, если в колонке слишком много задач, то это тоже какой-то нездоровый признак — явно что-то сломалось с приоритетами и планированием (если ты планируешься в среднем раз в неделю на команду из пяти человек, а задач в запланированном больше 20-ти штук, то скорее всего вы их не сделаете)
3. Колонка "готово к работе" тоже должна всегда содержать некоторый буфер задач. Если задач в ней становится меньше Y, нужно озаботиться тем, чтобы кто-то уже взялся за запланированное и начал готовить задачу к взятию в работу (у нас это значит выполнить DoR: по чек-листу проверить, что в задаче есть вся нужная инфа, DoD, проведена декомпозиция, учтены и обработаны все внешние зависимости и т.д.). В противном случае мы рискуем оказаться в ситуации, когда код никто не пишет, а все заняты высокими материями типа общения со смежниками или декомпозиции задач. Я уже молчу о том, что не каждый сотрудник одинаково хорошо может с такими задачами справляться, тут нужно всё-таки давать что-то посильное (пусть и с челленджем).
4. Диаграммы DORA. Беглого взгляда на них обычно достаточно, чтобы увидеть какие-то аномалии: слишком быстро или слишком медленно стали делать задачи (на новогодние отлично видно, как релизы откладываются, например). Здесь у нас в трекере есть вьюшка, отображающая цикл тайм по статусам. По ней можно попробовать понять, в какой именно части процесса произошла проблема (релизы, ревью ПРов, декомпозиция или сама разработка и т.п.) — тут либо будет ожидаемо, либо надо копать дальше, но уже ясно направление.
5. Диаграмма потока задач. Здесь просто следим за тем, что решается задач не меньше, чем заводится новых — рост бэклога это не хорошо, это "запасы".
6. Длина очереди обращений в поддержку. Ну тут всё ясно, кажется. Если очередь выросла, надо бы разобраться, что к этому привело и разгрести хвост.
7. Доска с задачами в разбивке по людям. Здесь следим за тем, что у каждого есть задача и в работе только одна в один момент времени.

Этого всего лишь три вкладки в браузере, которые нужно проверять раз в день, некоторые, раз в неделю. И если там всё нормально, то можно заниматься планами развития, глубинными 1-1, написанием постов в каналы в телеге...

Для операционного менеджмента ещё не хватает одной диаграммы:

8. Диаграмма старения задач. Я как-то уже рассказывал о ней в комментариях в канале. Мы следим за тем, что задачка находится в каждом из статусов не дольше, чем это делали 80% задач в прошлом месяце, например. Например, видим, что задача уже три дня в разработке, а 80%% был два дня. На диаграмме старения такая задача будет светиться. Может, её просто забыли передвинуть в правильный статус. А может там есть какая-то проблема, с которой нужна помощь руководителя. Может даже просто задача такая большая или сложная получилась — это всё равно повод следить за ней ежедневно и внимательно (чтобы, например, вовремя бросить её на пол).

Такой диаграммы у меня нет, поэтому мы костылим через дедлайны и гантты пока что. Но в трекере обещали сделать.

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

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

Это первоапрельская шутка была, если что ^^^^^

А ещё напомню, что стряхну пыль с микрофона и проведу стрим, вопросы можно задавать в комментах к посту. Там че-то маловато, поэтому стрим переносится на неделю вперед (на самом деле не поэтому).

Завтра будет плановый пыльный чулан с публицистикой, ничего сложного! Отдыхаем, друзья!

Отправляю без нотификаций ❤️

Пятничная рубрика "Пыльный чулан"

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

А как можно помочь себе и своей башке после всего этого, я рассказал в посте про ДПДГ. Однако полностью избавиться от панических атак у меня получилось лишь несколько месяцев назад. Я _один_ раз сходил к психологу, получил _один_ совет и с тех пор всё спокойно в моей жизни. Ничего такого, просто при приближении панической атаки нужно попробовать понять, что стало триггером. Я так и не понял, но сами попытки успокоили мою психику. Всем здоровья, друзья!

Так что же должен делать руководитель?

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

Я уже пару раз писал, что по моему мнению должен делать руководитель. Но мысли со временем становятся понятнее и четче. Поэтому ещё разок!

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

Например, проблема с процессами. Найми, попроси взаймы, откопай из под земли, привлеки опытного процессного/проектного менеджера. Если не можешь найти — сделай сам.
Если проект не сходится — найди причину и почини. Не хватает людей? Найди! Нет вакансии? Попроси у соседа. Сосед жадничает? Сходи к общему руководителю. И там не получается? Отдай часть обязанностей кому-то. Всё равно не помогло? Ну пора садиться за клавиатуру, дружище. Или освоить какие-то методы повышения продуктивности сотрудников (процессные, инструментальные, мотивационные). Я вот ознакомился с курсором и подобными нейро решениями — это вау!

Или вот у меня ребята программируют на go и c++, а я прям плохо знаю эти языки. Или, например, ты фронтендер, а у тебя QA в команде. И хотят мои/твои ребята развития. Надо бы что-то посоветовать,, ИПР там составить. А как? Найти опытных гошников и спросить их! Например, я сходил в облако, где много пишут на go и попросил их роадмап для развития — они мне всё дали, рассказали.

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

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

Потом можно на конференцию такое сносить рассказать. Если это кому-то будет интересно, конечно 😁 Короче, снова. Надо делать так, чтобы всё работало. Это включает создание условий, устранение препятствий и постоянный мониторинг.

Кстати, к Серёге вернулась книга!

Скоро начинаем! Под этим постом будем переписываться в рамках стрима.

Теперь "Пыльный чулан" не пятничный, к концу недели лучше интересные посты буду постить

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

Начать стоит с картинки из метаанализа, на который все ссылаются. Небольшая пояснительная бригада.
Невероятный плот твист — объективные замеры эффекта не работают!
Вау! Есть всё таки статья, где работает на объективные показатели! Но есть нюанс.
Так а чего они нормально не померяют? Вот чо.

Хочется дополнить из сегодня. Во-первых, я сходил к КПТ психологу и МНЕ ПОМОГЛО! Значит работает! Прям за один раз, прикиньте. Добили мои панические атаки в ноль.

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

И третье, опросники всё таки имеют объективную составляющую, т.к. для них есть исследования корреляций с суицидами (кои объективны, конечно же).

А тут философское послесловие про докмед.