Как инженер учится договариваться — Сергей Киселёв

Сергей Киселёв начинает историю со студенческой компании в Иркутске: разработка систем для бизнеса постепенно привела его к руководству. Конференции помогли увидеть новые возможности, а переезд в Петербург — снова выбрать инженерную роль. В Яндексе Сергей занимался оценкой качества поиска, затем внутренней инфраструктурой и сервисами Yandex Cloud. Опыт организации работы продолжал проявляться и без формальной должности руководителя.

В MWS Cloud Platform Сергей пришёл создавать Development Platform. Первые полгода он собирал ядро команды, затем помогал другим направлениям выстраивать найм. Он начинал с задач и первых собеседований, обучал интервьюеров и создавал внутреннее сообщество. Платформа тоже росла через совместную работу: инженеры приходили в продуктовые команды, помогали писать сервисы и одновременно развивали общие инструменты. Так появились направления Go, Kotlin, развёртывания и единого API.

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

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