Майндсет тимлида и его руководителя

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

А вот тимлид тимлидов смотрит на картину несколько иначе. Со стороны выглядит, что он делает то же самое: отбивает какие-то задачи и проекты в смежников или небытие, отдувается перед топами на всевозможных разносах, защищая команды. Но на самом деле, есть очень существенное отличие. Если о нем не задумываться, то поведение М2 менеджера может казаться тимлидам нелогичным.

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

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

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

В целом, я, например, даже пытаюсь объяснять свои решения тимлидам. Но, во-первых, не всегда об этом думаю, во-вторых, не всегда нахожу силы, в-третьих, всё равно иногда вижу реакцию типа "ага, ну я понял, как _на_самом_деле_, но буду транслировать твою версию, я тебя раскусил".

М2 это работать почти никак не мешает. Просто иногда тимлидов заносит и надо их поправлять. А вот тимлиду изменение майндсета на М2 может помочь вырасти на следующую ступеньку.

P.S.:
Kind reminder, что вы можете связаться со мной через бота в описании, он звездочек не просит.

Ну и это, гораздо чаще и ГОРАЗДО менее дистилированный контент выходит на моём втором канале, про книжки там тоже бывает, но скорее комментарии, чем обзоры.

Отвечаю на вопрос от подписчицы

А как у тебя получилось стать менеджером менеджеров?

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

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

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

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

Ещё я уверен на 90%, что нужна какая-то системность в работе. Должны быть процессы, иначе невозможно уследить за всеми командами одновременно, должен быть какой-то персональный тайм и таск менеджмент, иначе задачи будут забываться, просыпаться, а на этом уровне такое бывает критично. Должен быть какой-то процесс постоянного самосовершенствования: обучение, эксперименты. Это косвенный признак того, что даже если еще не до конца готов — быстро подтянется.

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

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

При этом мне кажется, что, например, лидерство, умение говорить, эмпатия и прочие супер полезные для руководителя вещи вообще-то не обязаны быть сильно проявленными. Что-то из этого необходимо на С-уровне, но не на уровне среднего менеджмента. Хотя лишним точно не будет.

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

Забурился в разработку RAG

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

Я напишу небольшой пост про RAG, как и обещал после поста про LLM. А пока кратенько введу вас в курс дела.
Если у нас есть какая-то LLM моделька, но нет возможности дообучить её на каких-то наших данных, либо мы хотим заставить её отвечать со ссылками на источники, то можно прикрутить к ней источники данных. Например, пацаны из Perplexity мне сказали, что они подняли у себя внутри полностью инфраструктуру классического поиска, но с альтернативными алгоритмами ранжирования. Собственно, для ответов кормят LLM'ке найденные документы. Прям текстом.

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

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

У меня есть невероятная способность портить выхлопы любых ML алгоритмов. Так и в этой лабе, модель, на которой проверяли авторы, устарела и больше недоступна. Я заменил её на аналогичную, но с гораздо большим числом параметров и на одно поколение новее. И все оптимизации стали делать результаты только хуже 🤡
Модели очень быстро умнеют. Кстати, BM25 (или TF-IDF) один из немногих хаков, которые таки дали прирост качества. А это именно что классический поиск (типа как lucene/elastic).

Пока я смотрел на линейные поиски в этих лабах, меня не оставляло острое желание переделать на locality-sensitive hashing, но Грок мне говорит, что на таких размерностях (у эмбеддингов в лабе около 4к координат) работать будет хреново и надо брать KD-tree (а я не хочу, я в аспирантуре на него насмотрелся уже). Поэтому от меня контрибьюта пока не будет.

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

Дальше у меня на очереди агенты и, возможно, сделаю любопытный MCP-сервер (но это не точно).

Что думаете про RAG? Не нужен? Круто? Сыро?

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

Очень интересный выпуск подкаста "Бреслав и Ложечкин"

Просто урывками прокомментирую.

Проронил скупую мужскую слезу на истории об оверачиверах, которые выйдут из проекта уже не с тем здоровьем, с которым в него заходили. Чёт так обидно стало. Правда глаза колет. Очень больно такое осознавать постфактум. Берегите себя, оверачиверы.

Зацепила фраза про "мы не можем себе позволить платить людям ниже рынка, потому что иначе мы тогда никого не наймём". Имеется в виду платить текущим сотрудникам меньше, чтобы при урезании ФОТ никого не увольнять. Мало кто понимает, что не бывает абстрактного маленького или большого оклада. Мало кто понимает, что значит зарплата "в рынке". Обычно судят по шапочным знакомым и усредняют. На деле же куча компаний нуждается в совершенно разного уровня специалистах, поэтому они нанимают совершенно разный персентиль сотрудников. И как раз из зарплат ты можешь заимплаить свой персентиль — на что ты согласился и куда тебя взяли. А то что Петям и Васям в соседнем ООО Ромашка платят больше твоего, не аргумент в пользу повышения твоей зарплаты.
Отсюда же вытекает и правило, что ты не можешь платить меньше нужного тебе персентиля, люди нужной квалификации просто не придут к тебе. Это может быть обидно, но надо это осознать и работать над этим.

Про одиночество руководителя это вообще в сердечко. Я пытался искать кого-то внутри компании, каких-то peer'ов, с кем обсуждать это всё. Иногда даже получалось, но вот кто-то уволился, кто-то в декрете, кто-то занялся чем-то совсем другим... Поэтому у меня а ля "мастермайнды" каждую неделю с моим другом по универу. Он примерно на той же позиции, что и я, у него примерно те же проблемы, и мы офигенно продуктивно через это пробираемся вместе. Рекомендую найти себе человека того же уровня заряженности, что и вы и устраивать такие встречи.

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

В комменты давно не захоживал наш глубокоуважаемый 10x engineer, а я знаю, вы любите всякое про HFT почему-то
Вот, во-первых, очень оригинальный тг-канал, который мне искренне нравится. Во-вторых, целый обзор релевантных HFT блогов. Там даже можно прочитать уже в конце концов, чем отличается quant researcher от quant developer, и че вообще там делать надо, в этих ваших конторах.

P.S.
Если вы все ещё не в чате моего канала, то теряете примерно половину контента от читателей. Далеко не все из чата прорастает в комменты к постам.

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

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

Три уровня управления командами

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

В определенный момент такая схема может перестать масштабироваться. Часто это происходит при переходе на уровень управления тимлидами. В этот момент появляются регламенты и процессы. Руководители уже больше доверяются какому-нибудь управленческому фреймворку (Kanban, RUP etc.), разрабатывают схему "объективной" приоритезации (CD3, RICE etc.), обращают внимание уже только на некоторые задачи (особо важные, выпадающие по срокам etc.), вводят какие-то правила, как сотрудникам брать новые задачи, критерии приемки готовых, всякие DOR/DOD etc.

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

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

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

Не сговариваясь https://t.me/channel_23derevo/1058

Дочитал «Хорошая стратегия, плохая стратегия» Ричарда Румельта

Книга крайне занятная. Думаю, что её действительно стоит почитать, чтобы усвоить, что является стратегией, какими характеристиками она обладает. Но гораздо важнее, что она объясняет, что стратегией не является!

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

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

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

Самая главная идея, идущая красной нитью через всю книгу: стратегия должна быть сфокусирована на одном направлении. Идея в том, чтобы не распылять свои силы, а сосредоточить всё в одной точке, таким образом получив преимущество перед конкурентами. Это не значит, что должна быть только одна цель, но это означает, что все цели должны быть согласованы между собой. Нужна синергия. Чтобы одна цель усиливала другую.

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

Третья, супер неочевидная мысль. Для реализации стратегии важно поймать правильный момент. Вполне вероятно, что в данный момент на рынке появилась какая-то новая возможность, пошла новая волна. Если её распознать и оседлать, то можно крупно преуспеть. С другой стороны, таких возможностей в конкретный момент времени может и не быть вовсе.

У хорошей стратегии должно быть трёхчастное ядро. Каждая часть важна, нужны все эти части.
1. Постановка диагноза. Это, собственно, тот самый угол зрения или выбор ментальной модели, в которой четко видны проблемы, которые мы будем решать. Здесь нужно четко определить причины этих проблем.
2. Направляющая политика. Это рамки, общий подход для решения задачи. На какие рычаги будем давить?
3. Согласованные меры. Это уже план. Не просто цели, но и шаги для их достижения. Как именно мы будем давить на рычаги?

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

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

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

В третьей части книги прямо излагается, как же стратегию составить.
Стратегия — это гипотеза. Нужно выявить некую аномалию, что-то, что не вписывается в общепринятые рамки и копать это. Так родится гипотеза. Эту гипотезу, конечно же, нужно проверить. А дальше собирать данные, адаптировать решение согласно им и т.д.

Из интересного отмечу:
1. Румельт рекомендую вести списки дел
2. Выгружать все идеи на бумагу, записывать
3. Всегда ставить под сомнение собственные устанвоки и знания
4. Использовать для генерации идей деструктивный метод: почему предложенная идея не сработает, покритиковать её, поменять, придумать новую. Он даже представляет у себя в голове целую комиссию, которой отдает на оценку свои идеи
5. Помнить, что миллионы мух всё-таки могут ошибаться