Онбординг и обучение руководителей

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

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

Ну а правда, опытные же!
А вот я считаю, что не опытные. Ну вернее, опытные, но в другом.

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

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

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

А что же делать?
Очередная порция очевидных советов от Тимлида Очевидность. Очевидные вещи, но почему-то не всегда реализуемые 🙁

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

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

Вот повысят, тогда и приходите.

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

Хотя, наверное, это не остановит компании с девизом «слабаки нам не нужны», но это уже совсем другая история.

- Руководитель промоутируемого должен вкладываться в адаптацию. Вы же не запускаете джуна разработчика в проект со словами «вот рутовый пароль от базы, вот так деплоить в прод, давай, дальше сам разберешься». Это и про менторинг, и про явное проговаривание ожиданий, планов, и про погружение в контекст нового подразделения и продукта.

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

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

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

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

Тимлиды и мидл-менеджеры, поделитесь своим опытом о том, как вас онбордили и обучали при повышении.

Context Rot (гниение контекста)

Ребята из Chroma провели масштабное исследование (пост, ролик) и выяснили неприятную правду - все современные LLM страдают от "гниения контекста". И это не баг, а системная проблема текущих архитектур.

Провели контролируемые эксперименты на 18 моделях, за основу взяли тест Needle in a Haystack, но варьировали семантическое сходство между "иглой" и вопросом и добавляли отвлекающие факторы (distractors) + использовали дополнительные тесты типа LongMemEval.

Главный вывод: производительность LLM деградирует нелинейно и непредсказуемо с увеличением длины контекста.
Не то что бы это сюрприз.

Но что еще интересного:
- Когда вопрос и ответ связаны не лексически, а семантически (требуется понимание смысла), производительность падает значительно быстрее с увеличением контекста (кстати, один из способов улучшить это - делать query expansion)
- Thinking modes немного помогают, но не решают проблему
- Парадокс структуры: Модели работают хуже (на 10-15%) на логически структурированном тексте, чем на случайно перемешанных предложениях!

Практические выводы:
1. Context Engineering критически важен - не только наличие информации в контексте, но и то, КАК она представлена, сильно влияет на результат
2. Нельзя полагаться на заявленные длины контекста - даже если модель поддерживает 1M токенов, это не значит, что она будет эффективно работать с такими объемами (кстати, классный был бенч от Nvidia RULER, не нашел ничего подобного для новых моделей).
3. Замечали как память ChatGPT иногда делает его тупее и рассеяннее? Это оно (поэтому я выключаю память по-умолчанию)
4. Популярный Needle in a Haystack - так себе бенчмарк сам по себе, тестируется слишком примитивно
5. Модели лучше помнят то, что в начале и конце контекста. Критически важную инфу размещайте там.


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

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

#ml #courses

Для начинающих (и не только) будет полезно

https://dfedorov.spb.ru/pandas/

Гоняем 100гб csv-файлы на очердной мультиварке 2000-года туда-сюда

Привет, друзья! Врываюсь с полезными материалами! :)

Сделала открытую страничку, посвящённую механистической интерпретируемости.

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

Пока что глобально сильных результатов, вроде тех, что приближали бы к ответу на вопрос "Как спастись от AGI?" нет. Но с помощью MI можно:

— находить интерпретируемые признаки внутри моделей и отслеживать, как они взаимодействуют;
— создавать инструменты для редактирования поведения моделей (feature editing, model steering);
— теоретически понимать архитектуры вроде трансформеров, на которых сегодня держится весь прогресс :)

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

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

Надеюсь больше не пропадать, хотя творческий кризис — это почти полезно, если из него выйти.

Всегда Ваш,
Дата-автор! :)

Как найти пушка-идею для супер-сервиса

Встретил алгоритм поиска идей, которым хочется поделиться:

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

2. Заходим в отзывы и читаем самые отрицательные и самые залайканные (именно этот пункт меня зацепил)

3. Думаем, как можем в своем проекте учесть отрицательные моменты проектов-локомотивов

Ну а дальше самое простое:
4. Быстро-быстро делаем проект - захватываем рынок - зарабатываем свой миллион долларов. Просто и точка!

Практика по сокетам на Python

В видео по компьютерным сетям на этой неделе рассматриваем пример с сокетами на Python:
- Разбираемся, как запустить клиент и сервер в терминале.
- Проверяем, что сервер ожидает соединений (LISTEN) с помощью TCPView и netstat.
- Просматриваем в Wireshark, как данные между сокетами передаются по сети.

Полный код из видео находится в репозитории на GitHub.

Если плохо работает YouTube, то можно смотреть в Дзен или VK.

Поддержать создание курса можно на Boosty или CloudTips.

#dl #competition

#dl #competition

#dl #competition

#dl #competition

#dl #competition