Agaltsov Anton | TeamLead-блог

👔 Engineering Manager — руководитель, который отвечает за людей, а не за код Engineering Manager (EM) — это управленческая роль, фокус которой полностью смещён с техники на people-менеджмент. В отличие от TechLead, отвечающего за архитектуру и качество кода, EM занимается наймом, развитием сотрудников, performance review и процессами, обеспечивающими предсказуемую работу команды. Роль EM появляется, когда инженерная организация вырастает до 30–50 человек. На этом этапе объём работы с людьми становится слишком большим, чтобы TechLead мог совмещать техническое лидерство и полноценное управление людьми. Решение — разделение зон ответственности: TechLead фокусируется на технологиях, EM берёт на себя людей, и они работают в паре. Переход с позиции TechLead в EM — это смена системы координат. EM не оценивается по написанному коду или техническим решениям. Критерии эффективности другие: насколько команда стабильна, предсказуема и развивается. Для технического специалиста это часто становится психологически сложным шагом — нужно научиться измерять свой успех через успех команды. 🔗 Engineering Manager: https://agaltsovav.ru/docs/overview/engineering-manager/

📊 Бенчмарки LLM: почему 90% на MMLU — это ещё не повод выбирать модель Каждый раз, когда выходит новая языковая модель, мы видим цифры: «90% на MMLU», «Elo 1350 в Chatbot Arena». Это бенчмарки — стандартизированные экзамены для LLM. Но за красивыми числами скрывается много нюансов. 🔸 Бенчмарк ≠ метрика. Метрика отвечает «как измерять», бенчмарк — «через что прогнать модель». 🔸 Ни один бенчмарк не скажет, подойдёт ли модель вашей задаче. Он даёт первичную ориентацию, но финальный выбор — только на собственных данных. Что искажает результаты: ❌ Загрязнение данных. Вопросы бенчмарка попадают в обучающую выборку — модель не решает, а вспоминает. Из-за этого OpenAI отказался от SWE-bench Verified. ❌ Переобученность. Модели натаскивают под MMLU: 90% на нём, но на свежих аналогах — проседание. ❌ Чувствительность к промпту. Та же модель может показать 40% в zero-shot и 80% в few-shot. ❌ Self-reported scores. Цифры от вендора — наименее надёжный источник. Вендор контролирует все переменные и выбирает выгодные настройки. Как читать лидерборды: ✅ Сравнивайте модели одного размера ✅ Игнорируйте разницу в 1-2% — это статистический шум ✅ Не доверяйте насыщенным бенчмаркам (топ-модели на плато 85-90%) ✅ Предпочитайте слепые площадки — Chatbot Arena Elo надёжнее формальных тестов ✅ Валидируйте на своих данных — это главное правило Подробно об этом читайте тут: https://agaltsovav.ru/docs/ai/llm-benchmarks/

📌 Head of Development — кто это и зачем нужен? Когда инженерная организация вырастает за 50–100 человек, CTO физически перестаёт справляться с операционным управлением каждой командой. Появляется Head of Development — руководитель, отвечающий за весь отдел разработки. Ключевое отличие от других ролей: 🔸 Head of Development управляет не разработчиками, а Engineering Manager'ами и TechLead'ами 🔸 Отвечает за структуру, процессы и стратегию на уровне нескольких команд 🔸 Практически не пишет код — если начинает, это сигнал о микроменеджменте Разделение с CTO: Head of Development отвечает за то, КАК работает отдел (процессы, люди, эффективность), а CTO — за то, КУДА движется компания технологически. Когда роль появляется: • До 50 инженеров — обычно не выделяется, обязанности берёт на себя CTO • 50–100+ — становится необходимостью • В стартапах до 20 человек CTO может напрямую вести разработчиков Главная сложность: бывший EM, ставший Head of Development, часто лезет в работу команд напрямую. Успешный руководитель учится измерять свой успех через метрики отдела и развивает менеджеров, а не делает работу за них. Подробно об этом читайте тут 👉 [agaltsovav.ru](https://agaltsovav.ru/docs/overview/head-of-development/)