Таня Рейли – Карьера разработчика. Стафф – круче, чем senior (страница 4)
Часть I. Панорамное мышление
Глава 1. Как вы думаете, что вы здесь делаете?
Идея карьеры стафф-разработчика (или «инженерный путь») является новой для множества компаний. Организации расходятся во мнениях о том, какими качествами должны обладать самые старшие программисты и какую работу те должны выполнять. Сильвия Ботрос (Silvia Botros) пишет (https://oreil.ly/xwgRn), что тем не менее большинство единодушны в следующем: вершина инженерной карьеры – это не просто «еще более сеньорный сеньор», хотя ясного понимания, что это такое, нет. Поэтому первая глава моей книги начинается с экзистенциального вопроса: зачем компаниям нужны «самые старшие» разработчики? Потом, вооружившись ответом, мы раскроем суть роли стафф-разработчика: разберем требования к техническим навыкам и лидерские качества, которые необходимы на этой должности, а также выясним, что означает «работать самостоятельно».
Обязанности стафф-разработчика могут быть самыми разными, и существует множество способов выполнять их качественно. Однако каждая из них нацелена на решение конкретной задачи, и не любой компании нужен специалист со всем спектром возможных функций. В этой книге я расскажу, что подразумевает роль стафф-разработчика: сфера ответственности, степень влияния на рабочие процессы, место в служебной иерархии, основная цель и другие составляющие. Вы сможете использовать мой опыт, чтобы понять, как вам работать, в каком направлении профессионально развиваться или кого нанять. Наконец, поскольку разные компании по-разному понимают функционал стафф-разработчика, мы постараемся согласовать эти представления с мнением ключевых фигур компании.
Давайте начнем с того, в чем заключается работа стафф-разработчика.
Кто вообще такой стафф-разработчик
Если бы существовало только одно направление карьерного роста (как показано на рис. 1.1 слева), то многие программисты столкнулись бы с трудным и даже жестоким выбором: остаться на должности разработчика и продолжать совершенствовать свое мастерство в написании кода или перейти в менеджмент и развиваться как управленец.
Поэтому многие компании теперь предлагают «инженерную» карьеру, или путь индивидуального контрибьютора (individual contributor), позволяя программистам расти параллельно тому, как растут выбравшие «менеджерскую» карьеру. Пример такого карьерного пути показан на рис. 1.1 справа.
Рис. 1.1. Две карьерные возможности: с одним путем развития и с двумя
Карьерные возможности в разных компаниях сильно отличаются друг от друга, и для их сравнения даже создали специальный веб-сайт levels.fyi.[11] Количество этапов карьерного пути и их названия также могут быть различными. Вам даже могут встретиться одни и те же названия в разном порядке.[12] Но слово сеньор используется очень часто. Марко Роджерс (Marco Rogers), директор инженерного направления, который разработал должностные иерархии для двух компаний, назвал уровень сеньора «переходным» (https://oreil.ly/MpwsJ). Роджерс говорит: «На позициях ниже сеньора люди развивают способность работать самостоятельно, на должностях выше сеньора возрастает влияние на процессы в компании и ответственность за результат».
Иногда уровень сеньора рассматривается как «вершина»: вам больше не нужно расти в должности.[13] Но если вы все же продолжаете свой служебный рост, то становитесь «техническим лидером». Следующая ступень после сеньора обычно называется «стафф-разработчик», это название я и буду использовать далее.
На рис. 1.1 показаны два варианта карьерного роста, и программист уровня сеньор может выбирать, развиваться ли как менеджер или как стафф-разработчик. После перехода на следующую ступень изменение должности со стафф-разработчика на менеджера или наоборот нужно рассматривать как горизонтальное перемещение, а не карьерный рост. Сеньор-стафф-разработчик находится на том же уровне, что и старший менеджер, принципал-разработчик находится на уровне директора и т. д.; в служебной иерархии отдельных компаний могут быть и более высокие уровни. (Я обозначу должности, расположенные выше сеньора, словом «стафф+», которое придумал и описал Уилл Ларсон (Will Larson) в своей книге «Staff Engineer».)
Иногда я слышу, как люди настаивают на том, что должности не имеют (или не должны иметь) значения. Они приводят разумные доводы в пользу того, что их компания является эгалитарной меритократией, которая сторонится опасностей иерархии, и говорят: «Мы живем в демократическом обществе и с уважением принимаем все идеи». Конечно, их позиция достойна восхищения: мнение любого человека важно, даже если он находится в самом начале своего карьерного пути.
Но все же должности имеют значение. Команда разработчиков среднего звена написала статью, в которой обозначила три причины необходимости должностей: «Они помогают осознать, что вы растете как профессионал, помогают преодолеть укоренившиеся в отрасли предрассудки и информируют окружающих об уровне вашей компетентности» (https://oreil.ly/oUkHe).
Первая причина является субъективной и, наверное, мотивирует не всех, но две другие описывают эффект, который должности оказывают на людей вокруг вас. Неважно, является компания эгалитарной или нет, в ней всегда будут те, кто по-разному относится к людям, находящимся на разных должностных уровнях, и большинство из нас хотя бы немного волнует собственный статус. Доктор Кипп Круковски (Dr. Kipp Krukowski), профессор практики по предпринимательской деятельности Государственного университета Колорадо, в своей работе 2017 года «The Effects of Employee Job Titles on Respect Granted by Customers» пишет: «Должности работают как символы, с их помощью компании информируют людей внутри и вне фирмы о компетентности своих сотрудников» (https://oreil.ly/zD3kp).
Мы постоянно оцениваем людей и неосознанно строим предположения. Если мы не приложим усилия, чтобы разобраться со своими подсознательными оценками, то скорее всего, попадем под влияние стереотипов. Например, исследование 2015 года (https://oreil.ly/snmmY) показало, что примерно половину из 557 темнокожих и латиноамериканских женщин – специалистов в области науки, технологий, инжиниринга и математики, участвовавших в исследовании, ошибочно принимали за обслуживающий или административный персонал.
Аналогичные предрассудки существуют и в отношении программистов. Бытует мнение, что белые и азиатские мужчины-разработчики более опытны и технически подкованны, а также лучше разбираются в коде, независимо от того, работают ли они уже несколько десятилетий или только вчера выпустились из университета. Женщины, особенно небелые, иногда воспринимаются как менее опытные и менее квалифицированные. Всем им приходится прилагать дополнительные усилия, чтобы доказать свою компетентность.
В вышеупомянутой статье разработчиков среднего звена сказано, что должности помогают разрушить стереотипы и дают представление об уровне компетентности программиста. Формирование правильных ожиданий сберегает специалистам время и силы, которые в противном случае пришлось бы потратить, снова и снова подтверждая свой статус. Это экономит им несколько часов в неделю.
Должность также может повлиять на работу, которую вы получите в будущем. Как и многие представители технологической отрасли, я каждый день получаю электронные письма с предложениями работы от LinkedIn. Лишь три раза я получила от рекрутеров, не читавших мою анкету, приглашение на более высокую должность, чем была у меня на тот момент. В остальных случаях мне предлагали либо позицию, которая в точности соответствовала моей, либо более низкую.
Вот что представляет собой должность стафф-разработчика в иерархии компаний. Но давайте посмотрим, зачем нужны уровни технических лидеров. Во вступлении я назвала три основополагающих навыка инженерной карьеры: панорамного мышления, реализации проектов и повышения квалификации. Почему именно инженеры должны обладать такими умениями? Зачем вообще нужны стафф-разработчики?
Работа в любой инженерной компании требует постоянного принятия решений: какие технологии внедрить, что разрабатывать, продолжать инвестировать в систему или отказаться от нее. Часто круг лиц, обязанных сделать важный выбор, четко определен и последствия предсказуемы. Но некоторые решения имеют фундаментальный характер и затрагивают всю программную архитектуру, и никто не может знать, как это повлияет на другие компоненты системы.
Для принятия правильных решений нужен контекст. Опытные разработчики знают, что ответ на большинство технологических вопросов зависит от обстоятельств. Недостаточно понимать плюсы и минусы выбранной технологии: вы должны разбираться в деталях конкретной ситуации. Что вы пытаетесь сделать? Сколько у вас времени, денег, упорства? Каков приемлемый уровень риска? Что нужно бизнесу? Ответы на эти вопросы и есть контекст принятия решения.
Определение контекста требует времени и сил. Каждая команда склонна принимать решения исходя из своих интересов, а каждый программист, скорее всего, будет сфокусирован на достижении целей своей команды. Но часто решения, принятые одной командой, имеют последствия для всей компании. Локальный максимум – это лучшее решение для отдельной команды, которое может оказаться неудачным для организации в целом.