От идеалиста к прагматику: чему учит путь Staff Engineer
До прочтения этой книги я считал понятие Staff Engineer синонимом терминов вроде Team Lead или Engineering Manager. Однако оказалось, что за ним скрывается не просто другое название для технического менеджера, а метароль, обладающая рядом особенностей – позиция высококвалифицированного специалиста с отдельной веткой карьерного развития.
Я добавляю приставку «мета», потому что в разных компаниях такой специалист может называться по-разному и иметь разный уклон. Если к его воплощению в виде архитектора или техлида мы уже привыкли, то описанные автором альтернативные инкарнации – Solver и Right Hand – для меня стали открытием, и я даже не берусь их перевести. Но если отвлечься от названий, то главные организационные отличия staff-инженера вот в чем:
1. Отсутствие непосредственных подчинённых. 2. Прямое подчинение своему руководителю, минуя промежуточный управленческий уровень де-юре или де-факто.
О втором пункте Уилл Ларсон прямо не говорит, но отличную иллюстрацию к нему приводит Таня Рейли в книге The Staff Engineer’s Path (в русском переводе – Карьера разработчика ). Учитывая, что Ларсон ссылается на неё со словами «I eagerly waiting for Tanya to publish the canonical book on Staff engineering», думаю, это видение он полностью разделяет.
Если посмотреть на российский контекст, то сотрудников уровня staff+ вполне можно встретить на верхних этажах корпоративной иерархии (скажем, в роли замдиректора), а вот на нижних – практически нет. В нашем бигтехе примеров комплексного развития этой идеи я, честно, не припоминаю. Да, в редких местах встречаются дополнительные ступени для линейных исполнителей за пределами классической линейки junior-middle-senior – вроде грейда Principal в Авито или 18+ грейдов в Яндексе – но их присваивают, скорее, в исключительных случаях. Например, когда ценный сотрудник принципиально не хочет идти в менеджеры, или когда подходящей управленческой позиции нет, а человек хочет роста зарплаты, но в вилку своего текущего грейда уже не вписывается. А вот Ларсон как раз убедительно говорит о пользе институционализации – создания отдельной карьерной лестницы для индивидуальных исполнителей. Это дает:
• Ясность: окружающим понятен особый статус такого сотрудника. • Стимул: можно глубже развивать профессиональные навыки, не упираясь в потолок зарплаты и не будучи вынужденным идти в менеджеры. • Четкость: ожидания формализованы в матрицах компетенций и зарплатных вилках.
Определив, где находится staff-инженер, Ларсон подробно разбирает, чем он занимается:
• Управляет техническим развитием проекта, продукта или целой платформы. • Исследует новые области и создает прототипы решений. • Занимается онбордингом, менторством и спонсорством коллег. • Координирует работу внутри команды и между командами.
Можно сказать, что эти темы довольно очевидны и многократно описаны в литературе по управлению, но лично для меня в изложении Ларсона выделились три ценных блока.
Во-первых, систематизация полезных терминов. В книге удобно собраны такие концепции, как:
• Спонсорство (в управленческом смысле). • Snacking и preening – виды неэффективной, «сиюминутной» деятельности. • Being glue – работа «социального клея», скрепляющего процессы и людей.
Во-вторых, чёткая дорожная карта повышения технической зрелости компании. До этого я встречал нечто подобное лишь в Паттернах дизайн-менеджмента Юрия Ветрова, но применительно к дизайну. Ларсон же определяет их для инженерии: fixing hotspots → adopting best practices → prioriting leverage points → aligning technical vectors → measuring technical quality → spinning up a technical quality team → running a quality program. Без пояснений звучит, конечно, абстрактно, но углубляться в них и тем самым отнимать хлеб у автора здесь не буду.
В-третьих, и, пожалуй, самое ценное – сборник управленческих паттернов, каждому из которых посвящена отдельная глава:
• Stay aligned with authority – о важности общего видения с руководством. • Learn to never be wrong – о вреде растраты социального капитала в спорах и конфликтах по непринципиальным для вас вопросам. • To lead, you have to follow – про увязывание своих инициатив в существующие формальные и неформальные видения, стратегии, регламенты и проекты компании. • Create space for others – про следование стратегии «голубого океана» в выборе ниш для своей деятельности и спонсорстве. • Build a network of peers – о необходимости проектировать не только технические, но и социальные структуры. • Present to executives – о непростом, но важном искусстве повышении своей видимости внутри компании.
Хочу отметить, что ценность этих советов сложно оценить умозрительно. Мое осознание их фундаментальности пришло только через личный опыт и негативные последствия их игнорирования. Постепенное принятие этих поведенческих паттернов – болезненный процесс профессионального и даже, не побоюсь этого слова, духовного роста. Он хорошо согласуется с поговоркой: «кто в молодости не был революционером, у того нет сердца, а кто в зрелости не стал консерватором, у того нет ума».
В начале карьеры нас часто наполняют идеализм, перфекционизм и вера в простые решения сложных проблем. Более того, эти качества катализируют стартовый инженерный рост, и подсознание закрепляет за ними ярлык «хорошо». Вдобавок, первые успехи кружат голову и раздувают эго. С таким багажом мы дорастаем до задач высокого уровня, на котором неизбежно возникает взаимодействие с другими людьми. И вот тут-то закреплённые внутренние установки вступают в противоречие с реальностью, и у академических принципов часто не остается шансов:
• Stay aligned with authority – зачем? Я же, будучи узким специалистом, компетентнее своего руководителя в своей сфере! Вспоминается корпоративный мем из Яндекса: «К счастью для компании, я обладаю собственным правильным взглядом на пути развития сервиса и обладаю возможностью его реализовывать лишь с небольшой помощью менеджеров». • Learn to never be wrong – зачем? Нельзя же жить вразрез со своими принципами. Надо либо настаивать на своем, либо огораживаться и создавать вокруг себя value oasis. • Create space for others – зачем? Я – глубокий специалист в строго определенных темах. Думать о других сферах, где мои знания поверхностны, – неэффективно. • Build a network of peers – зачем? Я всю жизнь справлялся со всем сам, а нетворкинг код за тебя не напишет. • Present to executives – пусть этим занимаются менеджеры. Мое время и знания слишком ценны, чтобы тратить их на презентации вместо «настоящего дела».
В общем, к этому пониманию действительно нужно прийти, и путь этот труден. Когда я завожу об этом разговор с некоторыми (особенно успешными) коллегами, я часто чувствую неприятие. Уважаемый мной Sean Goedecke, ведущий популярный блог о жизни в бигтехе и пропагандирующий те же принципы, даже наговаривает на себя, называя такой подход циничным. Но я не согласен. Путь вниз из идеалиста в циники в русской классике хорошо описал Иван Гончаров на примере главного героя романа Обыкновенная история Александра Федорыча Адуева. Анализируя его, я сходства с собой не наблюдаю. Для меня это путь смирения эго, и считаю его скорее добродетельным, чем циничным. Да, грань между ними тонка, но в том и интерес жизни – постоянно нащупывать этот срединный путь.
Напоследок – ложка дёгтя. Примерно половину книги занимают интервью с действующими staff-инженерами. Лично для меня этот раздел оказался избыточным: несколько прочитанных историй не добавили новых инсайтов. Впрочем, возможно, это потому, что я уже прошел часть этого пути и не являюсь целевой аудиторией раздела, а для тех, кто только присматривается к роли, эти живые примеры могут быть очень полезны.
3 понравилось
