Сеньорность без героизма: Как перестать быть человеком, без которого всё ломается
Коан: «Незаменимость — единственный технический долг, которым принято гордиться».
Коан: «Незаменимость — единственный технический долг, которым принято гордиться».
Вы знаете, где лежит нужный конфиг, почему этот сервис нельзя перезапускать после двух ночи и кто в компании однажды уже чинил похожее. Поэтому, когда что-то ломается, сразу идут к вам. Сначала это приятно: значит доверяют и вы правда разбираетесь. Потом выясняется, что отпуск приходится планировать с оглядкой на прод, а любой сложный вопрос заканчивается сообщением в личке.
Примечание Adviser
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Содержание
Увы, вы не стали самым хорошим инженером. Просто вместе с вашей экспертизой команда получила единственную точку отказа.
Главная ловушка инженерного героизма
Культура героизма работает ровно до первого отпуска, увольнения или выгорания. LeadDev в разборе проблемы go-to engineer описывает, откуда она берётся: знания остаются в голове, ownership не определён, а в компании принято вознаграждать того, кто тушит пожар. Тех, после кого пожары больше не случаются, обычно не замечают.
Дальше запускается цикл. Чем чаще вы отвечаете на вопросы коллег, тем больше вопросов приходит именно вам. Чем больше решаете за других, тем меньше у них шансов научиться решать что-то самим. Вы экономите команде час сегодня и запускаете зависимость, которая завтра обойдётся куда дороже.
Зрелость сеньора можно оценить одним неприятным вопросом: что будет с командой, если вас не будет две недели?
Если ничего страшного, есть документация, второй человек на дежурстве и понятная схема эскалации — система работает. А вот если «лучше бы мне не уезжать» значит, что bus factor вашей команды равен единице. И эта единица — вы.
Ваш результат перестаёт быть только вашим
На каком-то уровне карьеры меняется сама природа результата. Rockstar Developer University, пересказывая подход Camille Fournier из The Manager’s Path, формулирует этот переход просто: от «я сделал» к «моя команда сделала».
Писать код при этом никто не перестаёт, и в человека, который только ходит по встречам, вы не превращаетесь. Меняется другое: собственная выработка перестаёт быть единственным способом приносить пользу.
Скажем, вы нашли сложный production-баг. Как вариант, можно починить его самому за два часа. А можно позвать менее опытного инженера, пройти диагностику вместе, и в следующий раз отдать ему вести такую ситуацию. Первый путь сегодня быстрее. Зато второй оставляет в команде ещё одного человека, который умеет то, что раньше умели только вы.
Поэтому на код-ревью иногда полезнее спросить «что произойдёт под высокой нагрузкой?» или «что будет, если API изменится через месяц?», чем написать «сделай вот так». Такой сократовский подход рекомендуют в разборе «Нero culture Accent Design»: времени он поначалу отнимает больше, зато коллега начинает сам видеть последствия своих технических решений.
С отладкой то же самое. LeadDev предлагает простую схему: сначала менее опытный инженер смотрит, как вы разбираете сложный случай, потом ведёт процесс сам, а вы остаётесь рядом как страховка.
И дальше начинается неприятная часть взросления команды: коллега примет решение, которое вы бы приняли иначе. Если цена ошибки не катастрофическая, это, скорее всего, хорошая инвестиция. Человек, который сам всё сделал и сам столкнулся с последствиями, получает опыт, которого не даст даже очень убедительное объяснение сеньора.
Документация возвращает вам ваше время
«Надо написать документацию» звучит как задача, которую зачем-то добавили сверху. Но если вы постоянно отвечаете на одни и те же вопросы, документация — способ вернуть себе собственное время.
Начинать с огромной Wiki не нужно. Несколько дней подряд смотрите, что у вас чаще всего спрашивают: как выкатывать сервис, где смотреть логи, почему этот endpoint устроен именно так, что делать при конкретном алерте. LeadDev рекомендует превращать повторяющиеся вопросы в простые FAQ, инструкции и guidelines. Всего один ответ, записанный один раз, убирает десятки будущих сообщений.
Для архитектуры хорошо работают ADR — Architecture Decision Records. Описывать каждую строчку кода не нужно. Зафиксируйте решение, альтернативы и причину выбора: почему взяли эту БД, почему отказались от того API, какие ограничения считаются принципиальными. Тогда следующему инженеру достаётся логика решения, а не только его результат.
Для эксплуатации ещё практичнее runbook. Не инструкция на сорок страниц, а короткий сценарий: какой dashboard открыть, какие команды выполнить, что проверить первым, когда и кому эскалировать. В руководстве incident.io советуют начинать с пяти самых частых типов инцидентов и написать пошаговый runbook для каждого.
Хорошая документация перестаёт делать вас обязательным участником каждого процесса. В этом её смысл, а не в бюрократии.
У redundancy есть человеческая версия
В инфраструктуре резервирование — вещь очевидная: упал один сервер, есть второй. К людям тот же принцип применяют заметно реже. Начать стоит с карты критических зон: кто знает конкретную систему, сколько людей способны выполнить эту работу и сколько времени займёт подготовка замены.
Попробуйте нарисовать такую карту для своей команды. Не по грейдам, а по функциям. Кто может самостоятельно провести релиз? Кто знает платёжный контур? Кто способен принять решение во время инцидента? Кто восстановит сервис, если вас нет? Самые опасные места находятся быстро.
С on-call такая же логика. Вместо «если что-то случилось — звоните Николаю» нужны primary и secondary. Второй не обязан вмешиваться в каждый инцидент, но должен понимать, что происходит, и быть готовым принять эстафету. Для менее опытных инженеров полезна shadow rotation: отдельный слой дежурства, где новичок наблюдает за primary, получает тот же контекст и постепенно готовится взять pager сам.
А цепочка эскалации должна быть предельно конкретной. Не «напишите в командный чат», а primary → secondary → engineering manager. Если первый не ответил за отведённое время, система должна знать, кого будить дальше. Так спасение из импровизации превращается в процесс.
Что почитать и какие курсы пройти, если хочется уйти от роли главного спасателя
Курс Leadership Development for Engineers
Пожалуй, самое точное попадание в тему статьи: программа сделана для инженеров, которые переходят к лидерству и управлению. Внутри — работа с командой, coaching и mentoring, разрешение конфликтов, постановка целей и планирование. Три курса, примерно два месяца при нагрузке около 10 часов в неделю.
Become an Engineering Manager: The Complete Course
Здесь фокус шире: people management, развитие команды, 1:1, конфликты, технические решения, процессы, риски и работа со стейкхолдерами. Брать его стоит не тому, кто хочет научиться быть лидером, а инженеру или техлиду, которому нужно понять, как устроена управленческая часть роли изнутри. Сейчас это 68 лекций общей продолжительностью около 4 часов 40 минут.
Если лекции — не ваш формат и хочется разобраться со своей системой управления, книги работают не хуже. Для темы «как перестать быть узким местом» полезны сразу несколько ракурсов.
- Andy Grove — High Output Management. Про то, как менеджер увеличивает результат команды, а не собственный объём работы. Одна из классических рекомендаций по управлению, и заслуженно.
- Michael Bungay Stanier — The Coaching Habit. Полезна в контексте менторинга: вместо автоматического ответа на каждый вопрос вы учитесь задавать вопросы, после которых человек находит решение сам. Хорошо ложится на переход от «я знаю ответ» к «я умею сделать так, чтобы ответ нашёлся в команде».
- Will Larson — An Elegant Puzzle. Уже прямо про engineering management: структура команд, технический долг, управление ростом, преемственность. Особенно полезна, если хочется смотреть на инженерную организацию как на систему, а не как на набор сильных специалистов по отдельности.
- Peter Drucker — The Effective Executive. Уровень более общий, но попадает точно, когда проблема уже не в технических навыках, а в том, куда уходят ваше внимание, решения и ответственность. Книгу называл одной из важных для своего управленческого подхода сооснователь Dropbox Дрю Хьюстон.
Смысл перечисленного не в том, чтобы добавить ещё пять пунктов в ваш список «что надо изучить». Если после курса или книги вам по-прежнему звонят ночью с каждым инцидентом, а днём озадачивают каждой архитектурной проблемой, обучение ничего не изменило.
Хороший результат выглядит иначе: вы постепенно становитесь менее необходимы для отдельных операций, а команда — самостоятельнее. Это один из самых практичных признаков сеньорности.
Срочность тоже надо спроектировать
Одна из причин, по которым «герой» всё время занят, — команда считает срочным слишком многое.
Тут удобно взглянуть на проблему глазами Google SRE. В их определении toil — ручная, повторяющаяся, автоматизируемая работа, которая не требует существенного человеческого суждения и не создаёт долговременной ценности. Работа, которая помогает системе продолжать существовать, но не делает её лучше.
Неприятность toil в том, что он растёт вместе с системой. Больше пользователей — больше ручных операций. Больше сервисов — больше алертов. Больше клиентов — больше исключений.
В Google это однажды пришлось решать радикально. Команда Bigtable SRE утонула в ручных пользовательских запросах — от выделения квот до создания датацентров. Вместо того чтобы нанимать людей под этот поток, команда заручилась поддержкой менеджмента и начала отказывать в кастомных запросах там, где их можно было автоматизировать. По данным Google SRE, за два года количество ручных запросов упало с более чем 2200 за квартал до 400.
Вот это и есть инженерная сеньорность: не стать самым быстрым исполнителем ручной операции, а сделать так, чтобы её больше не приходилось выполнять руками.
С алертами стоит проделать то же самое. Для каждого спросите: что конкретно человек должен сделать прямо сейчас? Если ответа нет, возможно, это вовсе и не pager.
Как понять, что вы действительно перестали быть «героем»
Есть простой тест: уйдите в отпуск. Не как эксперимент с увольнением, а как обычные две недели без постоянного контроля Slack. Перед этим составьте список зон, где вы сейчас единственная точка знания или решения. Для каждой найдите второго человека, добавьте документацию и договоритесь о границах эскалации.
А вернувшись, смотрите не на количество сообщений, а на то, что произошло без вас.
Сколько раз команда эскалировала вам то, что могла решить сама? Сколько инцидентов потребовало вашего участия? Сколько вопросов уже было описано в документации? Равномерно ли распределяется on-call нагрузка?
Если один инженер стабильно получает в несколько раз больше внерабочей нагрузки, проблема остаётся системной. В руководстве incident.io по on-call равномерность нагрузки как раз считается одним из признаков здоровой ротации.
Есть показатель ещё неприятнее: сколько вашего времени по-прежнему уходит на работу, которую после нормальной передачи контекста мог бы делать другой человек.
Сеньорность в этом смысле выглядит почти парадоксально. Чем больше вы растёте, тем меньше у команды поводов обращаться лично к вам.
Спасение — плохая единица измерения
Героический фикс отлично смотрится в Slack: «Прод лежал, но Николай всё починил». Хуже смотрится продолжение: «Прод падал три раза, но Николай каждый раз всё починил».
Смысл не в том, чтобы в системе появился человек, способный выдержать ещё один пожар. Она становится сильнее, когда следующий пожар не требует именно этого человека.
Так что ваша следующая задача как сеньора, возможно, вовсе не закрыть ещё один сложный тикет. Посмотрите, где команда до сих пор ждёт лично вас. Передайте один участок, запишите один runbook, проведите одну shadow-сессию, уберите один лишний pager.
И однажды лучший результат вашей работы будет выглядеть совсем не героически: просто ночью ничего не случилось, коллеги разобрались сами, а вы спокойно спали.
Объяснение на страницу: почему не читают документацию и что исправить в первую очередь
Объяснение на страницу: почему не читают документацию и что исправить в первую очередь
Переход из аутстаффа в продуктовую компанию в ЕС: почему собеседования часто валятся не на стеке
Переход из аутстаффа в продуктовую компанию в ЕС: почему собеседования часто валятся не на стеке
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.