Карьера разработчика. Стафф – круче, чем senior

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

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

Стафф-разработчик – это пример для подражания. Менеджеры формируют культуру общения в команде, призывая к взаимоуважению и обеспечивая соблюдение социальных норм. А вот технические стандарты задаются самыми авторитетными инженерами. Неважно, что говорят инструкции: если самый опытный разработчик не пишет тесты, все остальные тоже не будут. Это социокультурный феномен, и никакими нравоучениями его не изменить. Когда вышестоящие сотрудники во всеуслышание хвалят чужую работу, относятся друг к другу с уважением, задают уточняющие вопросы, остальные с легкостью делают то же самое. Когда молодые программисты видят в ком-то «разработчика, которым они хотели бы стать», они стремятся работать так же, как этот специалист. (В главе 7 мы рассмотрим, как с помощью личного примера вывести организацию на новый уровень результативности.)

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

Хватит рассуждать. Что делать-то?

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

Вы не менеджер, но вы – лидер

Стафф-разработчик прежде всего – лидер. По уровню старшинства он часто приравнивается к линейному менеджеру, а принципал-разработчик – к директору. Стафф+ разработчик находится на одной ступени с менеджером того же уровня, а значит, он должен быть таким же компетентным. Может быть, вы даже окажетесь авторитетнее и опытнее некоторых менеджеров в вашей организации. Всякий раз, когда возникает ощущение, что «кто-то должен действовать», то скорее всего, этот «кто-то» – вы.

Обязаны ли вы быть лидером? Мидл-разработчики часто спрашивают меня, можно ли продвинуться по карьерной лестнице, не развивая все эти «мягкие навыки» («софт скилы»). Разве технических недостаточно? Если вы не любите общаться с людьми и стали программистом, чтобы делать инженерную работу, может показаться несправедливым, что ваш карьерный рост останавливается из-за отсутствия умения коммуницировать. Но с одними технологиями вы не сможете далеко продвинуться по карьерной лестнице. Если вы хотите выполнять масштабные задачи, то вам придется работать с большими группами людей, а для этого вам потребуется более широкий набор навыков.

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

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

Лидерство может быть разным, и иногда его видно не сразу. Разработать «счастливый путь», который защитит программистов от общих ошибок; сделать ревью кода и проектных решений других участников команды, чтобы они стали увереннее в себе и развили свои навыки; показать, что проектное предложение не соответствует истинным потребностям бизнеса, – все это виды лидерства. Обучение – это лидерство. Планомерное повышение уровня каждого разработчика – тоже лидерство. Выбор технологического направления – лидерство. И наконец, репутация выдающегося технического специалиста, который может вдохновить других людей на реализацию своих планов просто потому, что они ему доверяют, – это тоже особый вид лидерства. Если вы нашли у себя эти черты, то вы – лидер.

Интровертом быть можно, малоприятным типом – нельзя

Многих людей пугает идея лидерства. Но не волнуйтесь: не все стафф– и принципал-разработчики работают по схеме «человек – человек». Среди стафф-разработчиков найдется место для интровертов: даже самые скромные люди могут задать технологическое направление компании благодаря своим знаниям и авторитету. Чтобы стать лидером, не обязательно находиться в центре внимания. Достаточно подавать положительный личный пример и хорошо относиться к людям.

Многие из нас слышали истории про «одного программиста», которого все сторонились, потому что с ним было слишком трудно общаться. Этот типаж, описанный Саймоном Травальей (Simon Travaglia) (https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell), был широко известен в 80-х и 90-х годах. В Usenet[16] и других подобных ресурсах есть множество подтверждений того, что таких людей вполне можно встретить в реальной жизни. Коллеги этого программиста не только терпели его поведение, но и принимали его странные технические решения, только чтобы с ним не связываться. Однако сегодня такой разработчик станет обузой для всех. Какова бы ни была его производительность, сложно представить, что инженер, который не хочет работать в команде, может стоить проваленных проектов, а также результатов и карьеры других программистов. Если такой человек станет еще и примером для подражания в организации, то ее ждут большие проблемы.

Если вы думаете, что этот абзац про вас, зайдите на сайт Kind Engineering (https://kind.engineering/), где Эван Смит (Evan Smith), SRE-менеджер в Squarespace, дает конкретные рекомендации, как стать по-настоящему доброжелательным коллегой. Вы удивительно быстро сможете избавиться от репутации человека, с которым трудно работать.

Вы – технический специалист

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

Это не означает, что вы будете писать много кода. На уровне стафф+ ваша цель – эффективно решать проблемы, и скорее всего, вам не придется программировать. Возможно, вам стоит заняться архитектурным проектированием или взять на себя обязанности руководителя, то есть делать то, с чем справитесь только вы, а программирование оставить другим. Стафф-разработчики часто решают трудные, неоднозначные и запутанные задачи, проделывая ровно столько работы, сколько необходимо, чтобы эти задачи стали понятны другим и их мог довести до конца кто-то еще. Как только проблема становится разрешимой, она превращается в возможность для развития менее опытных разработчиков (иногда с поддержкой стафф-разработчика).

Для некоторых стафф-разработчиков самым эффективным инструментом решения проблем является глубокое погружение в код. Другие получают хорошие результаты, если пишут документацию, или становятся мастерами в области анализа данных, или проводят невероятно много индивидуальных встреч. Неважно, как вы решаете проблемы, главное, что вы их решаете.[17]

Вы стремитесь к самостоятельности

Когда вы только начали работать программистом, скорее всего, вами руководил менеджер: он выдавал вам задачи и способы их решения. Когда вы стали сеньором, возможно, менеджер подсказывал вам, какие проблемы важно решить в первую очередь, а поиск решения оставлял за вами. На уровнях стафф+ менеджер только делится с вами информацией, но именно вы говорите ему, что важно, а что нет. Сабрина Леандро (Sabrina Leandro), принципал-разработчик в компании Intercom, задается вопросом (https://oreil.ly/FOI1L): «Теперь вы знаете, что должны работать над важными и актуальными проблемами. Но где вы возьмете этот волшебный список отложенных трудоемких задач, которые вы должны выполнить?» И сама отвечает: «Вы же его и напишете!»

Когда вы станете руководителем, вам придется разрываться между различными направлениями деятельности компании. Но вы сами отвечаете за распределение своего времени. Количество часов в неделе ограниченно (см. главу 4). Вы сами выбираете, на что их потратить. Если вас просят выполнить какую-то работу, проявите свою компетентность: оцените, насколько высок приоритет у этой задачи, сколько времени потребуется на выполнение и какую пользу можно извлечь из достигнутого результата (включая возможность наладить дружеские отношения с людьми, попросившими вас о помощи), и решите сами, делать или нет. Если вас о чем-то просит генеральный директор (CEO, Chief Executive Officer) или другой начальник, то вы придаете его просьбе соответствующий вес. Но где самостоятельность, там и ответственность. Если выполнение поручения приведет к росту издержек для бизнеса, вы обязаны предупредить об этом. Не стоит молча наблюдать, как проблема разрастается до все больших масштабов. (Конечно, чтобы вас услышали, нужно заслужить доверие и научиться делать верные прогнозы.)

Вы задаете направление технологического развития компании

Стафф-разработчик – это технический лидер, и именно он должен убедиться, что компания выбрала верное технологическое направление развития. Основной продукт или сервис, который предлагает предприятие, – это набор технических решений: архитектура, системы хранения данных, фреймворки и инструменты, которые используются, и т. д. Неважно, на каком уровне приняты решения: команды, нескольких команд или всей организации. Ваша обязанность проконтролировать, что все сделано качественно и задокументировано. Смысл не в том, чтобы самостоятельно продумывать все (или даже некоторые необходимые!) аспекты, а в том, чтобы убедиться, что действенное решение найдено и согласовано со всеми заинтересованными сторонами.

Вы часто и продуктивно общаетесь с людьми

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

Разбираемся в специфике роли стафф-разработчика

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

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

Давайте начнем с позиции стафф-разработчика в должностной структуре компаний.

Место в структуре организации

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

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

Рис. 1.3. Стафф+ разработчики на разных уровнях иерархии. Разработчику А намного проще получить исчерпывающую информацию о бизнес-процессах организации и говорить на уровне директоров, чем разработчику D, даже если разработчики А и D имеют одинаковый уровень профессионализма

Ваш руководитель находится высоко в служебной иерархии

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

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

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

Ваш руководитель находится низко в служебной иерархии

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

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

Если ваш начальник линейный менеджер, он может оказаться менее опытным, чем вы. Это не проблема, но это ограничивает ваши возможности учиться у своего руководителя, и это точно не будет способствовать вашему карьерному росту: ваш начальник просто не сможет вам помочь. Но все это не важно, если ваши потребности в опытном наставнике закрываются другими способами.[18] Например, если должность вашего руководителя недостаточно высокая, постарайтесь найти возможность принимать участие во встречах «через уровень» (skip-level meetings), то есть в совещаниях с начальником вашего начальника.[19] Найдите способ оставаться в курсе всех ключевых событий в вашей организации.

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

Сфера ответственности

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

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

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

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

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

Сфера ответственности слишком велика

Если ваша сфера ответственности слишком велика (или не определена), то у вас могут появиться следующие проблемы.

Отсутствие ощутимых результатов

Если на вас можно свалить что угодно, то скорее всего, на вас свалят вообще все, особенно если в организации слишком мало старших сотрудников. С другой стороны, может случиться так, что вы будете выполнять только побочные квесты, не имея какой-либо основной цели.[20] Постарайтесь не распыляться на мелочи. Иначе у вас (или у того, кто вас нанял) появится ощущение, что вы ничего не достигли.

Снижение скорости принятия решений

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

Усталость от принятия решений

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

Сложности в налаживании дружеских связей

Если вы работаете с большим количеством команд, то вам будет сложнее установить регулярные контакты и построить дружеские отношения, которые облегчают выполнение задач (и делают работу приятной!). Остальные разработчики тоже в проигрыше: они не получают наставничества и поддержки, которую может дать «свой» стафф-разработчик, вовлеченный в их задачи.

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

Сфера ответственности слишком мала

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

Отсутствие ощутимых результатов

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

Упущенные возможности

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

Другие разработчики уходят на второй план

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

Чрезмерное усложнение

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