Kitabı oxu: «Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов»

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

© ООО Издательство "Питер", 2025

⁂

Будьте в курсе изменений в IT

Работа над этой книгой велась четыре года, и на ее страницах я постарался собрать те наблюдения и советы, которые не потеряют своей актуальности со временем. Поэтому все изменчивые составляющие IT-индустрии: рынок труда, объемы инвестиций в стартапы и передовые технологии – здесь не рассматриваются. Все актуальные вопросы я регулярно освещаю в своем еженедельном издании «The Pragmatic Engineer Newsletter».

«The Pragmatic Engineer Newsletter» – одно из самых читаемых онлайн-изданий о технологиях и № 1 среди технологического контента на платформе Substack. Это еженедельная рассылка, предлагающая взгляд изнутри на работу Big Tech компаний и стартапов, с актуальной информацией о состоянии рынка технологий. Издание будет особенно полезно разработчикам ПО, техническим менеджерам и всем, кто работает в IT.

Bloomberg описывает мою рассылку так¹:

В своих статьях [Гергели Орош] искренне и с глубоким знанием дела рассказывает о сфере IT. «The Pragmatic Engineer» охватывает широкий круг тем – от обзоров состояния Big Tech компаний и сокращений в отрасли до рекомендаций, как сотрудникам подготовиться к перформанс ревью.

Подписаться можно здесь:

pragmaticurl.com/newsletter

Надеюсь, эта книга поможет вам разобраться во всех изменениях в сфере IT, особенно в сочетании с моими статьями.

Гергели

От издательства

Мы выражаем огромную благодарность клубу рецензентов ИТ-литературы ReadIT Club за помощь в работе над русскоязычным изданием книги и вклад в повышение качества переводной литературы.

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

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

О научном редакторе русского издания

Дмитрий Бардин – ведущий разработчик, архитектор решений, один из авторов курса «Архитектор ПО» от Яндекс Практикума. Опыт в ИТ более 15 лет. Работал руководителем службы продуктовой разработки и ресурс-менеджером, в настоящее время занимается разработкой бэкенда сервиса «Кинопоиск» с применением языков Go и Java.

Предисловие

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

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

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

По мере роста моей команды и появления подчиненных уровнем на две ступени ниже (skip-level) у меня оставалось все меньше времени на детальное менторство. Но я начал замечать некоторые типичные паттерны в обратной связи, которую давал своим сотрудникам, и поэтому решил публиковать посты в блоге с советами, как хорошо писать и проводить качественные код-ревью. Мои посты получили теплый отклик, их читали и делились ими гораздо больше людей, чем я ожидал. Тогда я и начал писать эту книгу.

Спустя два года работы у меня появился черновик, готовый к публикации. В это же время я запустил рассылку «The Pragmatic Engineer Newsletter». Основное внимание в ней уделяется актуальным событиям в IT-индустрии, подробным разборам работы известных компаний, трендам в разработке ПО, а также периодическим интервью с интересными людьми из сферы IT. Работа над статьями помогла мне осознать, как же много «пробелов» было в черновике книги. Следующие два года я посвятил переработке ее содержания, по одной главе за раз.

После четырех лет работы я могу с уверенностью сказать, что «Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов» и «The Pragmatic Engineer Newsletter» дополняют друг друга. Хотя их содержание пересекается лишь в незначительной степени.

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

Невозможно переоценить важность английского языка для моей карьеры – и для карьеры в области разработки ПО в целом. Я родился и вырос в Венгрии, и моя первая работа была в венгерской IT-компании, где все говорили на венгерском. Однако даже тогда, чтобы разобраться с проблемой в коде, мне приходилось читать статьи на английском. При написании кода я использовал языки программирования, в которых используется английская лексика. Английский – это язык для разработки ПО и всего сообщества программистов. Все крупные международные технологические компании используют английский язык для общения. Именно благодаря своим знаниям английского я смог переехать в Нидерланды и работать в Uber, говоря на работе только на этом языке и сотрудничая с разработчиками из десятков других стран.

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

Надеюсь, вы найдете в этой книге полезные идеи, которые не утратят своей ценности в течение многих лет.

Введение

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

Книга следует структуре «типичного» карьерного пути разработчика ПО – от начинающего сотрудника до сеньора/лида, а затем и до инженера уровней стафф+. Она обобщает мой собственный опыт работы и те подходы, что я использовал, будучи ментором для разработчиков разных уровней.

Мы рассмотрим как «гибкие» навыки (soft skills), важность которых растет по мере увеличения ответственности, так и «жесткие», например концепции разработки ПО и подходы, которые помогут вашему профессиональному росту.

Названия позиций и ожидания от них могут варьироваться в зависимости от компании. Чем выше «ранг» компании, тем больше требований предъявляется к разработчикам. Например, уровень «сеньор-разработчик» предполагает значительно более высокие ожидания в таких компаниях, как Google (уровень L5) и Meta (уровень E5), по сравнению с компаниями более низкого ранга. Если вы работаете в крупной компании, вам будет полезно изучить главы и о более высоких уровнях, а не только о текущем или о том, который вас интересует.

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

Как читать эту книгу

Книга состоит из шести независимых частей, каждая из которых включает несколько глав:

• Часть I. Основы карьеры разработчика

• Часть II. О компетентном разработчике ПО

• Часть III. Разносторонний сеньор

• Часть IV. Прагматичный техлид

• Часть V. Образцовый стафф и принципал

• Часть VI. Заключение

Части I и VI применимы ко всем уровням инженеров – от начинающего разработчика до принципала и выше. Части II, III, IV и V охватывают все более старшие уровни и объединяют все актуальные темы в разделы, такие как «Программная инженерия», «Сотрудничество», «Выполнение задач» и др.

Эта книга – справочник, к которому вы можете обращаться по мере вашего карьерного роста. Но сначала предлагаю сосредоточиться на темах, которые вызывают у вас трудности, либо на уровне карьеры, к которому вы стремитесь. Учтите, что ожидания могут сильно различаться в зависимости от компании.

В книге все темы и описания уровней согласованы с ожиданиями в Big Tech компаниях и скейлапах. Однако некоторые темы, полезные и на более низких уровнях, также детально рассматриваются в последующих частях. Например, в части V, в главе 24 «Надежные программные системы» подробно освещены логирование, мониторинг и дежурства, хотя знать о них полезно, а зачастую даже необходимо на уровнях и ниже стафф-разработчика. Поэтому я рекомендую использовать оглавление – перемещаясь не только по темам, но и по уровням.

А теперь давайте начнем…

Часть I. Основы карьеры разработчика

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

Только когда я перешел в более крупные компании, такие как JP Morgan и Microsoft, я заметил, что не всегда те, кто работает усерднее всех либо достигает лучших результатов, получают самые большие бонусы или быстрее всех продвигаются по карьерной лестнице. Когда я стал техническим менеджером в Uber, у меня была команда инженеров, которым требовалась регулярная обратная связь по результатам работы и поддержка в их профессиональном росте, например в продвижении на следующий уровень.

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

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

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

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

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

Глава 1. Карьерный путь

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

Карьерные пути разнообразны, и не существует единого мнения, какой из них можно считать «плохим», а какой «хорошим». У каждого человека он свой, поэтому лучшее, что вы можете сделать, – это понять, что интересно и подходит именно вам.

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

В этой главе мы рассмотрим следующие вопросы:

1. Типы технологических компаний

2. Типовые карьерные пути в сфере разработки ПО

3. Оплата труда и «уровни» компаний

4. Центры затрат и центры прибыли

5. Альтернативные подходы к оценке карьерного роста

1.1. Типы компаний

Не существует единой классификации компаний, но тем не менее можно определить ряд характеристик, важных именно для программиста. Так, выделяют следующие типы компаний.

Технологические гиганты (Big Tech)

Это крупные публичные технологические компании, такие как Apple, Google, Microsoft и Amazon. Они нанимают десятки тысяч программистов, а рыночная капитализация составляет миллиарды долларов.

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

Средние и крупные технологические компании

Сюда относятся компании, для которых разработка ПО является ключевой составляющей их бизнеса. Они меньше технологических гигантов и нанимают сотни или тысячи программистов. В качестве примера можно привести Atlassian, Dropbox, Shopify, Snap и Uber.

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

Скейлапы

Скейлапы представляют собой стабильно развивающиеся компании с венчурным финансированием. Они уже имеют устоявшийся на рынке продукт, и поэтому стремятся к расширению доступа к рынкам. Они даже могут намеренно работать в убыток, чтобы увеличить свою долю на рынке товаров и услуг. К подобным компаниям относятся, например, Airtable, Klarna и Notion.

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

Одной из разновидностей скейлап-компаний являются так называемые единороги – компании с частной оценкой в $1 млрд и более. В 2010-х годах таких компаний было относительно немного, и их статус «единорога» означал, что компания впоследствии может стать крупным игроком на рынке. На сегодняшний день компаний-единорогов стало больше, и данный статус утратил свою значимость.

Стартапы

Стартапы – это компании с венчурным финансированием, которые еще не привлекли достаточный объем инвестиций и стремятся к тому, чтобы их продукт соответствовал ожиданиям рынка. Подобные компании основаны на какой-либо инновационной идее, привлекающей клиентов.

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

Примером успешного стартапа, который вырос до скейлап-компании, является Airbnb в 2011 году. Основанная в 2008 году, компания привлекла начальные инвестиции от фонда Y Combinator. К 2010 году услуги Airbnb начали набирать популярность, и компании удалось привлечь $7,2 млн в раунде серии A. В 2011 году компания привлекла уже $112 млн в раунде серии B, продемонстрировав инвесторам свой потенциал.

Примером неудачного стартапа может послужить компания – разработчик Secret, приложения для анонимного обмена сообщениями. Приложение было разработано в 2013 году и позволяло пользователям анонимно делиться своими секретами с другими людьми. Компания добилась хороших результатов и за два года привлекла $35 млн инвестиций. Однако в 2015 году она прекратила свою деятельность и возвратила инвесторам часть средств.

Стартапы предоставляют своим программистам наибольшую свободу, но в то же время не могут гарантировать им стабильность. Кроме того, работая в подобных компаниях, сложнее всего поддерживать баланс между работой и личной жизнью, ведь успех в данном случае зависит от способности команды выпустить продукт до того, как закончатся деньги. Рабочую атмосферу в коллективе стартапа зачастую определяют его основатели. В некоторых компаниях царит принцип «Work hard, play hard» («Хорошо поработаем – хорошо отдохнем»), в то время как другие предпочитают обеспечить устойчивую рабочую культуру. Деятельность в рамках одного стартапа разнообразна, состав специалистов зачастую разномастный, а возможности для карьерного роста обширны.

Некоторые стартапы предлагают своим сотрудникам долю акций компании – риск таких инвестиций высок, как и их потенциальная доходность. Если бизнес оказывается успешен и в итоге выходит на биржу или выгодно продается, первые сотрудники компании, владеющие значительной долей акций, получают огромную финансовую выгоду. Так и произошло с Airbnb, когда в 2020 году компания вышла на IPO (первичное публичное размещение акций) с рыночной капитализацией в $86 млрд. Другим примером может послужить и компания – разработчик сервиса для совместной работы в области дизайна Figma, которая в 2022 году была приобретена Adobe за $20 млрд.

Традиционные компании, не относящиеся к технологическому сектору, но занимающиеся разработкой собственного ПО

Основная деятельность таких компаний мало связана с технологиями. Некоторые из них существуют уже более 50 лет и были основаны до начала бума разработки программного обеспечения. Другие работают в отраслях, где компьютерные технологии не являются главным источников дохода.

Примеры таких компаний включают IKEA (производитель мебели для дома), JPMorgan Chase & Co (финансовые услуги), Pfizer (фармацевтика), Toyota (автомобили) и Walmart (розничная торговля).

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

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

Традиционные, но технологически подкованные компании

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

К таким компаниям относятся, например, Broadcom, Cisco, Intel, Nokia, Ericsson, Mercedes-Benz и Saab. Большинство производителей различного оборудования, а также автомобилей попадают в эту категорию.

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

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

Малые компании без венчурного финансирования

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

1. Отсутствие давления со стороны инвесторов.

2. Нужна прибыль, иначе бизнес ждет крах.

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

Государственный сектор

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

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

Примером правительственной организации с хорошей репутацией является британское подразделение Digital Service, которое разрабатывает и поддерживает многие государственные веб-сайты. Компания публикует свои проекты на GitHub (https://github.com/alphagov), что делает ее деятельность прозрачной и общедоступной. Еще одним примером компании государственного сектора с хорошей инженерной культурой является Британская вещательная корпорация (BBC).

Некоммерческие организации

Подобные компании ставят своей целью служение каким-либо общественным интересам, как, например, Code.org, Khan Academy и Wikimedia Foundation.

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

Консалтинговые, аутсорсинговые компании и студии разработки

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

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

К примерам консалтинговых и аутсорсинговых компаний можно отнести Accenture, Capgemini, EPAM, Infosys, Thoughtworks и Wipro.

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

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

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

Однако работа в консалтинговых компаниях имеет и ряд недостатков. Ниже представлены наиболее распространенные.

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

• Объем работы устанавливается клиентом. К услугам консалтинговых компаний обычно прибегают для выполнения тех проектов, которые компания-клиент считает находящимися вне своей основной компетенции.

• Недостаточное внимание уделяется лучшим практикам разработки программного обеспечения. Клиенты платят за получение краткосрочного результата, а не за работу над долгосрочными задачами, такими как, например, сокращение технического долга.

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

Научно-исследовательские институты и центры

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

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

Какой тип компании лучше всего соотносится с вашими карьерными целями?

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

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

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

1.2. Типовые карьерные пути в сфере разработки ПО

Внутри одной компании программисту предлагается два простых варианта развития карьеры: линейный путь или с развилкой (и двумя путями).

Линейный карьерный путь

Подобный карьерный путь для индивидуального контрибьютора (individual contributor, IC) и менеджера обычно выглядит следующим образом:

Типичный линейный карьерный путь. С каждым уровнем растут как ожидания, так и оплата труда

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

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

Карьера с двумя путями

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

Типичная карьера с двумя путями. Как всегда – больше обязанностей, больше и оплата труда²³⁴

В компаниях, предлагающих карьерный рост с двумя путями, существует несколько возможностей продвижения:

1. Индивидуальный контрибьютор (IC). Продвижение от разработчика начального уровня до сеньора и выше.

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

3. Переход с позиции IC в менеджеры. Возвращение к роли программиста после работы менеджером и, возможно, обратный переход в будущем. И такая ситуация далеко не редкость.

Каждый карьерный путь уникален

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

Карьерный путь Тани Рейли (Tanya Reilly), автора замечательной книги «The Staff Engineer’s Path»⁵, на протяжении всех двадцати лет остается довольно линейным, развиваясь в рамках деятельности разработчика:

• системный администратор (Fujitsu, Eircom)

• разработчик (Google)

• сеньор-разработчик (Google)

• системный стафф-разработчик (Google)

• принципал-разработчик (Squarespace)

• сеньор принципал-разработчик (Squarespace).

Двадцатилетняя карьера Никки Райтсон (Nicky Wrightson), на момент публикации книги занимающей должность руководителя отдела разработки, развивалась в чисто инженерном русле. Однако в конце концов Никки перешла в менеджмент:

• разработчик ПО (консалтинговая компания)

• специалист-консультант и разработчик (телекоммуникационные компании)

• разработчик (BNP Paribas, JP Morgan, Morgan Stanley)

• шестимесячный саббатикал⁶

• принципал-разработчик (Financial Times, River Island, Skyscanner)

• технический директор (венчурная студия Blenheim Chalcot)

• руководитель разработки (topi).

Карьерный путь Марка Цимельзона (Mark Tsimelzon), на момент публикации директора отдела разработки WhatsApp, складывался более тридцати лет – с позиции разработчика до основателя стартапов и руководителя проектов:

• разработчик

• технический менеджер

• основатель стартапа (позже приобретенного компанией Akamai)

• продакт-менеджер (Akamai)

• основатель стартапа (позже приобретенного компанией Sybase)

• директор разработки (Yahoo)

• корпоративный предприниматель (entrepreneur in residence) венчурной фирмы

• вице-президент по разработке (стартап приобретен Yahoo)

• старший директор отдела разработки (Yahoo)

• вице-президент по разработке (Syapse)

• главный директор по разработке (Babylon Health)

• директор отдела разработки (Meta).

Наиболее распространенные пути развития карьеры

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

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

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

3. Маятник «специалист – универсал». Такое происходит, когда разработчик, специализирующийся на какой-либо технологии, переходит на позицию, требующую более широкого спектра навыков, и наоборот. Опять и снова, снова и опять.

4. Разработчик специализируется в нишевой области. Например, разработчик становится SRE- или дата-инженером, работа которых частично связана с программированием, но тем не менее значительно отличается от стандартной разработки ПО.

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

6. От разработчика к техлиду. Программист становится руководителем команды, но при этом может и не брать на себя решение управленческих задач. И даже при смене места работы такие специалисты рано или поздно оказываются на позиции техлида.

7. От разработчика к техническому менеджеру. Переход на позицию технического менеджера и последующее развитие по данной карьерной ветви.

8. От разработчика к основателю/владельцу компании. Разработчик, длительное время проработавший в какой-либо сфере, основывает (в одиночку или с партнерами) собственную компанию.

9. Разработчик переходит на должность, не связанную с разработкой ПО. Например, в другую технологическую область – на позиции специалиста по связям с разработчиками (DevRel), продакт-менеджера, технического продакт-менеджера (TPM), рекрутера и др. Опыт работы разработчиком на данных позициях остается актуален, но, в свою очередь, открывается возможность исследовать интересующие сферы деятельности.

10. Маятник «разработчик – менеджер». Разработчик сначала становится техническим менеджером, а затем возвращается на инженерный путь, и так несколько раз. Такой карьерный путь встречается все чаще, а подробнее он описан в книге технического директора Чарити Мэджорса (Charity Majors) «The Engineer/Manager Pendulum»⁷.

11. Комбинация нескольких путей. Например, разработчик сначала становится техническим менеджером, затем продакт-менеджером, а уже после – основателем собственной компании.

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

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

1.3. Оплата труда и «уровни» компаний

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

Что можно измерить, так это общий уровень оплаты труда, хотя и тут могут возникнуть трудности, например с оценкой пакетов акций частных компаний. Опираясь на свой опыт рекрутера, я выделяю три уровня компаний и их компенсационных пакетов, что подтверждается многочисленными данными, добровольно предоставленными пользователями на сайте TechPays.com – платформе, которую я создал для публикации этой книги. Схематично эти уровни можно представить так:

Трехуровневое распределение зарплат разработчиков объясняет, почему аналогичные позиции в разных компаниях могут оплачиваться по-разному. Уровень 1 – местные компании; уровень 2 – лидеры внутреннего рынка; уровень 3 – лидеры регионального рынка

Данные показывают, что заработная плата на аналогичных должностях в компаниях разных уровней может различаться в 2–4 раза. Например, сеньор-разработчик в Google, скорее всего, получает как минимум вдвое, а то и вчетверо больше, чем сеньор в нетехнологической компании или небольшом семейном бизнесе. Общая заработная плата складывается из трех составляющих:

• базового оклада;

• денежного бонуса;

• акций компаний – в публичных компаниях они ликвидные, а в частных стартапах и скейлапах – неликвидные.

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

Уровень 1: внутренний рынок

В группу компаний, ориентирующихся на внутренний рынок, входят:

• местные стартапы;

• малые компании без венчурного финансирования;

• традиционные компании, не относящиеся к технологическому сектору, но имеющие технологические отделы;

• государственный сектор;

• некоммерческие организации;

• консалтинговые, аутсорсинговые компании и студии разработки;

• научно-исследовательские институты и центры.

Уровень 2: лидеры внутреннего рынка

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

• некоторые средние технологические компании, которые подстраивают предлагаемую ими заработную плату под ожидания внутреннего рынка;

• некоторые скейлапы;

• некоторые стартапы, обычно с хорошим финансированием и региональной направленностью;

• некоторые традиционные компании с технологическими отделами, особенно те, что активно инвестируют в технологии.

Уровень 3: лидеры регионального/мирового рынка

Компании, предлагающие самую высокую оплату труда на региональном или мировом уровне и конкурирующие не с местными компаниями, а с аналогичными им компаниями третьего уровня. Сюда относятся:

• технологические гиганты (Big Tech);

• большинство средних технологических компаний;

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

• хорошо финансируемые стартапы, которые нанимают специалистов из перечисленных выше групп компаний.

Заработная плата в компаниях третьего уровня обычно складывается из трех компонентов:

• базового оклада;

• акций компаний, выпускаемых ежегодно;

• ежегодного денежного бонуса.

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

Многие стартапы и скейлапы также предоставляют своим разработчикам долю акций компании. Но акции частных компаний не являются ликвидными и приносят только бумажную прибыль до тех пор, пока компания не выйдет на биржу или не будет приобретена. После выхода на биржу ее первые сотрудники, держащие значительный пакет акций, могут заработать целое состояние, что и произошло, например, с командой Uber. Конечно, работа в таких компаниях связана с большими рисками, ведь многие из них так никогда и не выходят на биржу: это случилось, например, с компанией Foursquare в 2023 году. Срок ее акций просто истек через 14 лет после ее основания⁹.

Подрядчики и фрилансеры

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

Работа подрядчиков и фрилансеров оплачивается согласно заранее установленной ставке за час или за день. Они не являются сотрудниками компании, выполняя необходимую работу по контракту на предоставление услуг по разработке ПО в рамках B2B-соглашения (business-to-business). Выбор между понятиями «подрядчик» и «фрилансер» зависит от страны – в США и Великобритании используется термин «подрядчик», тогда как во многих европейских странах таких специалистов называют «фрилансерами». Автор этой книги придерживается термина «подрядчик».

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

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

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

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

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

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

Достоинства и недостатки различных уровней

А как же в зависимости от уровня компании меняется ее подход к оплате труда? Ответить на этот вопрос объективно достаточно сложно, поскольку каждая компания уникальна, а разные условия труда имеют свои плюсы и минусы. Ниже приведены некоторые наблюдения, характерные для сотрудников полного рабочего дня. Подрядчиков в данном случае мы не рассматриваем ввиду отсутствия у них каких-либо возможностей для продвижения. Тем не менее успешные подрядчики обладают многими качествами, о которых мы в дальнейшем поговорим в разделах о сеньор- и стафф-разработчиках.

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

Сравнение трех уровней компаний

1.4. Центры затрат и центры прибыли

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

Центры прибыли – это команды или отделы компании, которые являются непосредственными генераторами дохода. Классический пример – отдел рекламы в Google, который приносит бо́льшую часть доходов компании. Кроме того, существует и ряд отдельных команд, которые также участвуют в этом процессе, например команда поиска, которая привлекает пользователей на сайт. Однако без отдела рекламы, создающего различные инструменты и сервисы для рекламодателей, которые те приобретают исходя из своего бюджета на рекламу, доходы Google были бы значительно ниже.

К центрам затрат, в свою очередь, относятся те отделы, которые не приносят доход напрямую, но необходимы для бесперебойной работы компании. В качестве примера можно привести команду разработчиков, ответственных за соблюдение компанией правил обработки персональных данных (General Data Protection Regulation), установленных в Европе. Их деятельность важна для существования компании, но не приносит дохода, поэтому с точки зрения бизнеса они относятся к центрам затрат.

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

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

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

• Переход на другую позицию внутри компании. Вполне естественно, что какие-то сотрудники стремятся работать в центрах прибыли. Однако не всем это интересно: многие разработчики заинтересованы в выполнении сложных и неординарных задач, свойственных проектам с высоким риском, которые еще не стали центрами прибыли. Центры прибыли могут показаться одними из самых «скучных» отделов в компании, поэтому к ним желает присоединиться меньшее число специалистов. Представьте, что вы устроились в Meta и выбираете себе команду для работы: вы бы предпочли работать над инфраструктурой рекламы и увеличить доход от рекламы на 0,005 % или в молодой команде, разрабатывающей инновационный способ общения пользователей с друзьями?

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

• Гарантия занятости. Центры затрат в первую очередь подвергаются сокращениям в целях экономии средств.

Итак, как же определить, является ваша команда или отдел центром прибыли или центром затрат? Вот несколько способов:

• Отчитывается ли ваша команда или отдел о доходах, полученных за конкретный период времени? Если да, то, скорее всего, вы работаете в центре прибыли.

• Как ваша компания зарабатывает деньги и какие подразделения приносят доход? Все опирается на отдел продаж или, если вы работаете в банке, на фронт-офис? Учитывается ли вклад технологического отдела в генерацию дохода? Какие команды в технологическом отделе считаются «более важными»?

• Изучите организационную структуру компании. Как высоко в иерархии организации находится технологический отдел? Кому подчиняются разработчики и продакт-отдел? Сколько вице-президентов в отделе разработки по сравнению с отделами маркетинга, финансов, операций и другими командами?

• Какие отделы генеральный директор на общих собраниях называет «стратегическими» и благодарит за увеличение доходов? Входит ли ваша команда или отдел в их число?

• Является ли ваша компания публичной? Если да, просмотрите квартальные отчеты, чтобы понять, на чем сосредоточено внимание организации, – скорее всего, там и находятся центры прибыли.

Разработка ПО может быть как центром затрат, так и центром прибыли:

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

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

• В консалтинговых компаниях и агентствах разработка ПО является основной услугой, предоставляемой компанией, и, следовательно, центром прибыли.

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

1.5. Альтернативные подходы к оценке карьерного роста

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

• ваши коллеги и отношения внутри команды;

• ваш менеджер и отношения с ним;

• ваше положение в команде и компании;

• корпоративная культура;

• миссия компании и ее вклад в общество;

• возможности для профессионального роста;

• ваше психическое и физическое здоровье в рабочей среде;

• гибкость. Можно ли работать удаленно? Если да, то как часто и нужно ли об этом уведомлять?

• работа в выходные или «по вызову». Насколько это напряженная работа и источник стресса?

• личная жизнь. Получается ли «оставлять работу на работе»?

• личная мотивация.

Графически это можно представить так:

Альтернативные подходы к оценке своего места работы

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

Глава 2. Управляйте своей карьерой

Лучший совет для любого программиста-разработчика – это

УПРАВЛЯЙТЕ СВОЕЙ КАРЬЕРОЙ!

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

В этой главе мы рассмотрим, что значит взять карьеру в свои руки:

1. Вы сами в ответе за свою карьеру

2. Будьте тем, кто всегда добивается результатов

3. Ведите журнал выполненных задач

4. Запрашивайте обратную связь

5. Сделайте своего менеджера своим союзником

6. Не изнуряйте себя

2.1. Вы сами в ответе за свою карьеру

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

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

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

• С некоторыми людьми было проще, чем с другими. Мне было легче общаться с теми сотрудниками, кто знал, чего хочет, чем с теми, кто еще не определился или вообще не хотел об этом думать.

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

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

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

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

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

2.2. Будьте тем, кто всегда добивается результатов

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

Достигайте целей!

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

Достигайте значимых целей

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

Убедитесь, что всем известно о ваших результатах

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

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

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

2.3. Ведите журнал выполненных задач

Над какими задачами вы работали на этой неделе? А на прошлой? А десять месяцев назад? Конечно, недавние задачи вспомнить легко. Однако с течением времени детали начинают забываться, что обычно не приносит каких-либо проблем. Но не всегда.

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

Вместо этого можно каждую неделю записывать ключевые достижения в своей работе, включая важные изменения, внесенные вами в код, код-ревью, проектную документацию, обсуждения и планирования, помощь коллегам, постмортемы инцидентов и все, что имеет значение. Бывший разработчик Stripe Джулия Эванс (Julia Evans) называет такой документ «список достижений»¹⁰ (brag document)¹¹.

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

Пример журнала выполненных задач. Шаблон можно найти тут¹²

Самые продуктивные разработчики, с которыми мне только доводилось работать, ведут такого рода журнал. Вот как это помогает им:

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

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

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

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

Ведь это глупо – вести журнал выполненных задач

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

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

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

То же самое касается и ведения журнала выполненных задач или «списка достижений». Это занятие может казаться глупым, занимать время, но просто попробуйте вести записи в течение двух месяцев, каждую неделю отмечая всю проделанную вами работу. И периодически показывайте их своему менеджеру на индивидуальных встречах. По прошествии двух месяцев вы поймете, почему это так полезно. Я еще не встречал ни одного человека, который бы пожалел о том, что начал вести журнал!

2.4. Запрашивайте обратную связь

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

Всегда собирайте обратную связь

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

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

• Идеи и предложения. Делитесь своими предложениями или идеями по проекту с коллегами и спрашивайте их мнение.

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

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

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

• «Что можно сказать о моем коде на основе последних пул-реквестов? Что я мог бы изменить? Были ли случаи, когда я нарушил рекомендации?»

• «На твой взгляд, как я провел встречу по планированию архитектуры? Что понравилось, или, может, есть какие-то предложения, как в будущем сделать подобные встречи более продуктивными?»

• «По поводу вчерашнего сбоя, отладку которого я проводил: как ты думаешь, я все правильно сделал? Это был мой первый сбой, поэтому хочу скорректировать свои действия, чтобы в будущем решить проблему более эффективно».

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

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

Проводить анализ своей работы – отличный способ учиться и самосовершенствоваться, и обратная связь помогает в этом.

Давайте обратную связь другим

Предоставление обратной связи способствует профессиональному росту коллег, но как правильно давать фидбэк, а особенно в случаях, когда проще промолчать? Вот несколько подходов, которые, по моему опыту, могут помочь:

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

• Будьте конкретны. Расскажите, что именно вам понравилось. Слова вроде «молодец» или «отлично» – это не очень полезный фидбэк, поэтому будьте конкретны в том, что в особенности вам понравилось и почему.

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

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

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

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

• Давайте негативную/конструктивную обратную связь лично. Недоразумения и недопонимания намного чаще возникают, если обратная связь предоставляется по электронной почте или в переписке. Поговорите с коллегой лично или по видеосвязи, чтобы была возможность видеть его реакцию.

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

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

• Завершите обсуждение на позитивной ноте. Цель предоставления любой обратной связи – помочь коллеге и команде. Не забывайте, что если от вашего комментария отношения в коллективе ухудшатся, то это вряд ли поможет команде. Поэтому старайтесь завершить обсуждение на позитивной ноте, удовлетворительно для всех сторон. Например, можно закончить обсуждение искренним положительным фидбэком или простой благодарностью за то, что они были так открыты в разговоре с вами.

Как «расшифровать» плохо составленный фидбэк

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

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

• Уточните последствия. Зачастую не всегда ясно, зачем вам предоставили тот или иной фидбэк. Например, коллега может сказать: «Думаю, что тебе не надо было проводить этот рефакторинг». В таком случае спросите, какое влияние это оказало на него и на других членов команды.

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

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

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

2.5. Сделайте своего менеджера своим союзником

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

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

Как же улучшить эти отношения?

Старайтесь проводить регулярные 1: 1

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

Не думайте, что ему все известно, а рассказывайте сами

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

Расскажите обо всем сами! Для этого и нужны регулярные встречи 1: 1.

Узнайте о целях

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

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

Выполняйте договоренности и предупреждайте о задержках

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

Менеджеры всегда делят членов команды на надежных и ненадежных. Старайтесь быть в группе «надежных сотрудников». Для этого лучше избегать задач, своевременное выполнение которых вы не можете гарантировать.

Доверяйте друг другу

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

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

Добивайтесь признания своей работы

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

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

• Приходили подготовленными на наши встречи 1: 1 и сообщали мне о проделанной ими работе, выполненных задачах, по необходимости запрашивали помощь или обратную связь.

• Выполняли задачи, связанные с их карьерным ростом. Например, если мы договорились, что через две недели они предоставят мне свои профессиональные цели на будущее, они обязательно это делали.

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

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

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

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

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

В общем, значительно облегчали мне мою менеджерскую задачу помочь им!

2.6. Не изнуряйте себя

Спортсменов учат поддерживать оптимальную интенсивность тренировок и не изнурять себя, чтобы подойти к соревнованиям в наилучшей форме и не закончить спортивную карьеру раньше времени. А что же делать программистам, которым обычно приходится трудиться гораздо дольше, не до 40 лет, как спортсменам? Выгорание для разработчиков ПО представляет не меньшую опасность, чем травма для спортсмена. Так какие уроки мы можем извлечь из профессионального спорта, которые помогли бы нам построить успешную карьеру без выгорания?

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

Стретчинг

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

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

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

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

Рабочий режим

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

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

После периода стретчинга (перенапряжения) возвращение к выполнению привычных задач помогает снизить риск выгорания. Я много раз наблюдал, как люди, работая в бешеном темпе, составляют список дополнительных задач, которые накапливаются и накапливаются, так что со временем их количество становится непомерным. Поэтому они просят коллег взять на себя какую-то часть работы и отказываются от новых проектов. Они сообщают своему менеджеру, что им надо сделать перерыв или сосредоточиться на уже имеющихся задачах, чтобы сохранить работоспособность и избежать выгорания.

Расслабление

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

Однако работа в таком темпе более 2–3 дней негативно влияет не только на «отдыхающего», но и на продуктивность всей команды и даже может угрожать проекту. Коллеги сразу замечают, когда кто-то «выпал», и перестают на него рассчитывать. А чтобы уложиться в сроки, его работу приходится выполнять другим членам команды. Инертный сотрудник почти не развивается профессионально и со временем теряет свои навыки.

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

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

Глава 3. Перформанс ревью

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

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

1. Первые шаги: оценка ситуации и постановка целей

2. Сила привычки

3. Подготовка к перформанс ревью

4. Перформанс ревью

3.1. Первые шаги: оценка ситуации и постановка целей

Каждая компания уникальна. Что ценится в вашей и что вознаграждается? Как оцениваются результаты? Ответы на эти вопросы варьируются от одной организации к другой, и к сотрудникам в молодых стартапах могут предъявляться иные требования, чем, например, в техногигантах.

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

Определите и проанализируйте ключевые показатели

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

• Спросить у своего менеджера. Пожалуй, самое очевидное. Узнайте, каковы цели вашей команды и как они связаны с целями компании в целом. Также спросите о личных целях самого менеджера и о том, что важно лично для него. Чем больше вы будете помогать в достижении этих целей, тем более ценным сотрудником станете.

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

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

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

• Разобраться в системе перформанс ревью. Существует несколько наиболее распространенных систем перформанс ревью, однако все равно в разных компаниях они функционируют по-разному, ведь все организации стараются адаптировать их под свои потребности, меняющиеся по мере роста и развития бизнеса.

Какая система перформанс ревью используется в вашей компании?

Среди наиболее распространенных систем перформанс ревью можно выделить следующие:

• Неструктурированное ревью / ad hoc. Менеджер проводит перформанс ревью, но без какой-либо реальной структуры и периодичности. Время от времени он дает обратную связь, но только в период повышения заработной платы. Такая система более свойственна небольшим компаниям, где перформанс ревью не имеет большого значения. Преимущество тут в том, что вам не придется особо беспокоиться и тратить свое время на подготовку. Однако есть и недостаток – ваша оценка в основном зависит от личного мнения вашего менеджера.

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

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

• Официальный и комплексный процесс. Большинство Big Tech компаний, а также некоторые стартапы на более поздних этапах развития внедряют более сложный процесс перформанс ревью в целях обеспечения непредвзятости. В таком случае вы обычно предоставляете обратную связь о работе своих коллег, затем оцениваете собственную работу (селфревью), а затем уже ваш менеджер составляет письменную оценку на основе полученных данных. Преимущество такого процесса в том, что предоставляемая вам обратная связь обычно конкретна. Недостаток – для проведения такой оценки необходимы значительные временны́е и трудовые затраты.

Убедитесь, что вам известна следующая информация о проводимом в вашей компании перформанс ревью:

• Кто принимает окончательное решение? Почти наверняка ваш менеджер, но все же стоит уточнить.

• Кто оказывает значительное влияние на вашу оценку? В зависимости от принятой системы это могут быть ваши коллеги и наиболее крупные стейкхолдеры либо же только ваш менеджер.

• Когда проводится оценка? Основные сроки? В организациях со структурированными процессами оценки обычно устанавливается крайний срок предоставления обратной связи и селфревью, а формирование оценки и оглашение результатов происходит в конкретный период времени.

• Как обеспечить справедливый результат перформанс ревью? Поговорите с более опытными коллегами как внутри вашей команды, так и за ее пределами. Возможно, они могут дать вам пару советов о том, что именно может способствовать справедливой оценке, а что помешать.

Обсудите свои цели с менеджером

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

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

Согласуйте свои цели с менеджером

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

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

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

3.2. Сила привычки

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

Фиксируйте свои достижения

Чаще всего оценка в перформанс ревью страдает от «эффекта недавности»¹⁵. Когда наступает время ревью, вы и ваш менеджер зачастую вспоминаете лишь недавние успехи и результаты. А задачи, выполненные несколько месяцев назад, могут быть упущены из виду.

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

Ведите журнал выполненных задач

Это простой способ отслеживать всю вашу успешную работу, а не только лишь особые достижения. Я заметил, что большинство людей, использующих этот метод учета, ведут документ, в который записывают все значимые задачи, выполненные ими, добавляют ссылки на соответствующие страницы и фиксируют результаты своей работы. Обо всех преимуществах ведения журнала выполненных задач подробно рассказано в части I, в главе 2 «Управляйте своей карьерой», там же можно найти и пример такого журнала.

Делитесь своим прогрессом с менеджером

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

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

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

Достигайте реальных результатов

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

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

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

Помогайте другим

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

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

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

Фиксируйте свою помощь

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

Принципал-разработчик Таня Рейли (Tanya Reilly) называет регулярную помощь коллегам «склеивающей работой» (glue work). Все ее плюсы и минусы она рассматривает в своей статье под названием «Being Glue» («Быть клеем»).

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

Периодически запрашивайте конкретную обратную связь

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

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

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

Вот в каких случаях можно получить полезную обратную связь:

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

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

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

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

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

• Критика чужого кода. Ваш коллега предоставил на ревью код со множеством ошибок, и вы сообщаете ему об этом. Но не слишком ли вы были резки или, наоборот, слишком мягки? Попросите более опытного коллегу оценить тон и содержание вашего фидбэка.

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

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

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

3.3. Подготовка к перформанс ревью

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

Можете ли вы рассчитывать на поддержку вашего менеджера?

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

• Ваши отношения с менеджером. Какого он о вас мнения: считает ли он, что вы соответствуете ожиданиям, недотягиваете до них или, может, превосходите? Самый простой способ выяснить это – спросить напрямую.

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

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

• Положение вашего менеджера в компании. Как долго он тут работает и насколько влиятелен среди своих коллег? Чем больше влияние и опыт вашего менеджера, тем успешнее он продвигает нужные результаты на этапе калибровки оценки.

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

Помните о сроках

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

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

Соберите обратную связь от коллег

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

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

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

Составьте селфревью

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

Составьте документ, в котором перечислите:

• Что? Включите сюда все результаты, которых вы достигли за определенное время, и во избежание «эффекта недавности» упомяните и более ранние достижения. Здесь будет полезен журнал выполненных задач.

• Как? Здесь нужны конкретные примеры, такие как помощь коллегам, менторство, усовершенствование, принятие прагматических решений и т. д.

• Исходные цели и результаты. Укажите цели, которые вы изначально ставили, и те, что вам уже удалось достичь.

• Примеры компетенций. Если в вашей компании есть список конкретных компетенций для вашей позиции, покажите, как вы им соответствуете.

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

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

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

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

3.4. Перформанс ревью

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

Помните, что это ваша оценка лишь за конкретный период времени

Такая оценка показывает вашу продуктивность лишь на данном этапе. Конечно, она важна, но на самом деле имеет мало значения для вашей карьеры в целом.

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

Узнайте общую динамику оценок

Как правило, около 20 % людей получают оценку выше среднего, 60–70 % среднюю и примерно 10–15 % оцениваются ниже среднего.

Оглянитесь вокруг, посмотрите на членов своей команды, на других сотрудников компании. Скорее всего, все они – мотивированные люди, которые хотят получить отличную оценку. Но некоторых из них ждет разочарование.

Чтобы этого избежать, установите реалистичные ожидания. Лично я в случаях, когда все считали, что около 80 % сотрудников получат средние или высокие оценки, всегда ожидал для себя среднюю. Я в любом случае знал, что соответствую ожиданиям, а все остальное воспринимал как приятный бонус.

Не делите шкуру неубитого медведя

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

Предвзятость существует

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

• Эффект недавности: во внимание принимается лишь ваша недавняя работа.

• Завышенные требования: чрезмерные требования при оценке работы некоторых членов команды.

• Любимчики: завышенная оценка работы некоторых членов команды.

• Ложка дегтя в бочке меда: негативный отзыв в какой-то одной области затмевает все положительные результаты.

• Рыцарь в сияющих доспехах: одно важное достижение значительно улучшает всю оценку. Часто возникает, когда кто-то «спасает» важный проект.

• Личное сходство: ваш менеджер дает лучшие оценки людям, похожим на него.

• Равенство и братство: ваш менеджер старается оценивать всех членов команды одинаково, потому что это кажется ему более справедливым.

• Ошибка контрастной оценки: менеджер сравнивает вас с вашими коллегами, а не с ожиданиями, установленными именно для вашей позиции.

Помните, что не все менеджеры одинаково хорошо умеют давать обратную связь:

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

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

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

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

Умейте принимать критику

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

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

Помните, что вы и ваш менеджер в одной лодке

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

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

Играйте вдолгую

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

Мыслите глобально

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

Глава 4. Повышение

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

При наличии различных уровней возникает естественный вопрос: что нужно сделать, чтобы перейти на следующую ступень? В этой главе мы рассмотрим:

1. Как принимаются решения

2. Процедура повышения

3. «Терминальный уровень»

4. Повышение в Big Tech компаниях

5. Советы: как получить повышение

6. Долгосрочные перспективы

4.1. Как принимаются решения

В каком случае кто-то получает повышение? Оснований для этого может быть несколько:

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

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

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

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

• Повышение планки рабочих показателей: это редкая ситуация, но бывает, что некоторые компании рассматривают кандидатуры для повышения, пытаясь ответить на следующий вопрос: «Сможет ли этот специалист, перейдя на следующий уровень, задать более высокие стандарты работы?»

Однако, как показывает практика, на получение повышения также оказывают влияние и некоторые дополнительные факторы, например:

• Мнение о вас. То, как другие воспринимают ваш вклад в развитие компании, может оказаться даже важнее реального положения дел. Это особенно актуально, когда компания растет, и со временем становится сложно определить непосредственный вклад отдельно каждого сотрудника.

• Поддержка. Повышение возможно только при поддержке вашей кандидатуры вышестоящими лицами, ответственными за принятие решений. Кто эти лица – зависит от масштаба компании, будь то стартап на пять человек или корпорация с тысячами сотрудников.

• Внутренняя политика. Это касается положения кандидата на повышение в компании. Чем больше лиц участвуют в процессе принятия решения о повышении, чем сложнее устройство компании и чем выше должность, тем труднее получить повышение.

• Механика процесса повышения. При разных процедурах повышения ваш вклад в деятельность компании может оцениваться по-разному.

4.2. Процедура повышения

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

Неформальная процедура повышения

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

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

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

Упрощенная процедура повышения

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

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

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

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

Сложная процедура повышения

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

• селфревью кандидата на повышение;

• его оценка от менеджера;

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

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

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

Смешанные модели

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

4.3. «Терминальный уровень»

Понятие «предельного», или «терминального», уровня (terminal level), иногда также называемого «квалификационным уровнем» (career level), встречается в ряде технологических компаний. Это профессиональный уровень, который разработчики должны достичь за определенный период времени, причем продвижение выше не гарантируется.

Так, например, в 2015 году предельным уровнем в Google был L5, в Meta – E5, а в Uber – L5A. Все эти уровни соответствовали на тот момент позиции сеньор-разработчика. Программисты, которые в отведенный срок не достигли квалификации, достаточной для данных позиций, либо увольнялись из компании сами, либо попадали под действие плана по повышению производительности (PIP). Это своего рода система «расти, или уволят».

За последние годы все три компании несколько изменили свой подход. Google сменил L5 на L4, что на уровень ниже сеньора. Meta и Uber также смягчили свои требования, больше не заставляя своих программистов развиваться профессионально для соответствия уровням выше E4 / L4.

Определение терминального (или квалификационного) уровня имеет две цели:

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

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

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

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

• полностью самостоятельны;

• способны решать возникающие проблемы;

• способствуете успеху команды, занимаетесь менторством, поддерживаете джуниор-разработчиков.

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

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

4.4. Повышение в Big Tech компаниях

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

Заработная плата и повышение

Подход Big Tech компаний к карьерному росту своих сотрудников и их компенсационному пакету, состоящему из базового оклада, бонусов и вознаграждения в виде акций компании, имеет свои особенности:

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

• Требования для получения повышения. В большинстве компаний для получения права на повышение требуется проработать на текущей должности как минимум 12 месяцев. Кроме того, обязательным правилом является то, что только лучшие сотрудники (верхняя половина рейтинга) могут быть выдвинуты на повышение. И хотя большинство компаний публикуют свои критерии для повышения, некоторые организации могут устанавливать и более строгие требования, например касающиеся срока пребывания на должности.

• После повышения заработная плата устанавливается на нижней границе следующего диапазона. Диапазоны оплаты определяют базовый оклад, а также целевые показатели общей заработной платы. Когда кого-то повышают, его зарплата возрастает минимум на 8–10 %, в результате чего он перемещается на нижнюю границу компенсационного диапазона следующего уровня. При таком подходе сотрудникам, получившим повышение, также полагается дополнительное вознаграждение акциями, которое может произойти на цикл позднее и зачастую оказаться меньше, чем ожидалось.

• Сотрудник с высокими показателями на более низком уровне может зарабатывать больше, чем сотрудник со средней продуктивностью на более высоком уровне. Удивительно, но те, кого признают лучшими сотрудниками, – обычно это 3–5 % от всех программистов – могут зарабатывать больше, чем сотрудники со средней продуктивностью на более высоком уровне. Это связано с тем, что лучшие сотрудники получают значительные денежные бонусы и гранты в виде акций.

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

Требования для повышения

Определенные требования к вкладу в деятельность компании и компетентности – это распространенный способ, с помощью которого Big Tech компании устанавливают зависимость между вероятностью повышения сотрудника и его продуктивностью. Подобные требования предъявляются к разработчикам и техническим менеджерам всех уровней. Чтобы получить повышение, кандидаты должны продемонстрировать свое соответствие следующему уровню по двум критериям:

• «Что?» – профессиональный вклад. Программист должен продемонстрировать свой вклад в деятельность компании на уровень выше текущего. Например, стафф-разработчик выполняет долгосрочный проект, решающий крупную проблему на уровне компании. Степень влияния обычно легче измерить в работе, связанной с клиентским продуктом, чем в работе над платформой. Работа над продуктом часто связана с ключевыми показателями эффективности компании (KPI), такими как рост дохода и сокращение затрат. Работа над платформой обычно связана с KPI на один уровень ниже: например, снижение задержки системы, увеличение надежности или повышение продуктивности разработчиков.

• «Как?» – оценка компетенций. Каждая компания определяет навыки, владение которыми ожидается от сотрудников на каждом уровне, – компетенции. Например, для работы в Uber требуется уметь разрабатывать ПО, архитектуру, достигать результатов, сотрудничать, обеспечивать эффективность компании и участвовать в ее жизни. Работа на следующем уровне в этих областях почти всегда предполагает эффективное взаимодействие со стейкхолдерами и коллегами. С практической точки зрения одни компетенции оказываются важнее других, а их набор уникален для каждой компании, процесса продвижения в ней, а иногда даже и для отдельных команд.

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

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

Однако по мере «взросления» компании количество таких возможностей сокращается, а решение возникающих проблем становится более сложным и затратным по времени. Сотрудникам настолько редко предоставляется шанс проявить себя, что у них нет права на ошибку, иначе эта редкая возможность будет упущена.

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

Разработка ради повышения

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

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

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

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

Разработка для повышения – одна из причин, почему все Big Tech компании создают собственные решения практически для всего: от инструментов для программирования и наблюдения до перепроектирования систем, которые не оправдали ожиданий. И я не преувеличиваю: за 16 лет Google создал 20 разных чат-продуктов, а некоторые из них даже создавались одновременно¹⁶. Можно с уверенностью сказать, что каждый из этих проектов помог десяткам разработчиков и менеджеров перейти на следующий уровень, только чтобы потом какая-то другая группа, вместо того чтобы усовершенствовать уже существующее решение, начала новый сложный проект.

4.5. Советы: как получить повышение

Надеетесь на повышение в следующем цикле и хотите повысить свои шансы? Вот несколько полезных рекомендаций:

• Будьте реалистами. Как прошло ваше последнее перформанс ревью? Превзошли ли вы ожидания? Если нет, вероятность повышения невелика. Постарайтесь превзойти ожидания в следующем цикле оценки.

• Узнайте, как проходит процесс повышения в вашей компании. Кто отбирает кандидатов, кто принимает решения, каковы критерии отбора и какова процедура повышения в вашей компании?

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

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

• Получите обратную связь от коллег. Попросите более опытных сотрудников оценить вашу работу, особенно тех, кто занимает более высокие позиции. Для получения повышения вам, скорее всего, понадобится их поддержка. Заранее поговорите с теми, кто может дать вам обратную связь. Вот что можно у них спросить: «Какие навыки, на ваш взгляд, я бы мог усовершенствовать? Соответствует ли моя работа требованиям следующего уровня? Какие недочеты вы замечаете? Можете ли дать какие-то советы по их устранению?»

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

Организация работы

Согласно мнению продакт-лида Шрейяса Доши (Shreyas Doshi), модель «создавай, организуй, публикуй» (Produce, Organize, Publish) является отличным способом структурировать ваш рабочий процесс. Ведь недостаточно просто хорошо выполнять свою работу – необходимо взаимодействовать с другими специалистами и обязательно публиковать (то есть делать общедоступными) результаты своей деятельности, чтобы сотрудники компании были осведомлены о вашем вкладе в общее дело. Вот как на практике можно применить эту модель:

Модель «создавай, организуй, публикуй»: чем выше ваш уровень, тем больше вам нужно организовывать и публиковать для перехода на следующий

«Создавай»: день за днем выполняйте порученную вам работу, создавайте артефакты – код, дизайн-документы, постмортемы, код-ревью и т. д.

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

«Публикуй»: предавайте гласности свою работу и продвигайте ее через встречи 1: 1, презентации на уровне отдела или компании, сессии обмена знаниями и другие внутренние и внешние мероприятия.

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

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

О важности взаимодействия с менеджером

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

Заручитесь поддержкой своего менеджера. Если он не поддерживает вашу кандидатуру, повышение получить будет сложно, а то и вовсе невозможно. Поэтому начните с этого. Как же можно его убедить, что вы заслуживаете продвижения? Что заставит его поддержать вашу кандидатуру?

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

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

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

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

Будьте реалистами

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

Будьте реалистами относительно своих шансов на повышение. Чем выше уровень, на который вы нацелены, тем сложнее его достичь. В большинстве Big Tech компаний около 30–40 % заявок на повышение до уровня сеньор-разработчика отклоняются. Для более низких уровней процент отказов, как правило, ниже, а для более высоких – выше.

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

Помогайте другим, чтобы помогали вам. Что посеешь, то и пожнешь. Помощь другим – это не только благородное дело, но и способ сформировать положительное отношение к себе. Вот несколько примеров, как вы можете помочь другим:

• Станьте ментором для кого-то на уровне ниже и помогите ему подняться до вашего уровня.

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

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

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

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

4.6. Долгосрочные перспективы

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

Ваша должность не должна определять вашу самооценку

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

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

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

Не идите по головам ради повышения

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

Многие вложения в карьеру окупаются не сразу

Посмотрим на двух разработчиков.

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

• Разработчиком Б движет чистое любопытство, а должности и уровни его волнуют значительно меньше. Он занимается разработкой ПО и в рамках своей компании получает повышение до позиции сеньора. Затем он меняет свой технологический стек, желая поработать над чем-то новым, и снова становится рядовым разработчиком, но уже в другой компании и в другой среде. Такую кривую обучения он проходит несколько раз. Позднее широта и глубина его профессиональных знаний заметно выделяют его на фоне других специалистов, и он получает предложения на должности уровня стафф+ в перспективных компаниях.

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

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

Удовлетворенность своей работой не определяется должностью

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

Глава 5. Достигаем успеха в любых условиях

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

1. Продуктовые команды и разработчики, ориентированные на продукт

2. Платформенные команды

3. «Мирное» и «военное» время

4. Типы компаний

5.1. Продуктовые команды и разработчики, ориентированные на продукт

Продуктовые команды – это команды разработчиков, которые создают продукт для внешнего потребителя. Они заметно отличаются от платформенных команд, работающих на внутреннего потребителя, и сервисных команд, которые сами не создают продукт, а предоставляют услуги клиентам или участвуют в создании продукта косвенно.

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

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

Разработчики, ориентированные на продукт

Ниже представлены некоторые качества, которыми обладают такие разработчики:

• Активно высказывают идеи и свое мнение о продукте. Такие разработчики не довольствуются простым выполнением полученных задач, вместо этого они постоянно предлагают новые идеи своему продакт-менеджеру. Зачастую выдвигаемые ими инициативы не соответствуют текущим характеристикам продукта, что подталкивает команду к поиску более эффективных подходов.

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

• Любопытство и искренний интерес («почему?»). Постоянно задают вопросы вроде «Почему мы реализуем именно эту функциональность, а не какую-либо другую?», консультируются с продакт-менеджером и коллегами по другим вопросам, связанным с продуктом. У таких разработчиков всегда много вопросов, но они выстроили гармоничные отношения с командой, а потому их любознательность никого не раздражает.

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

• Открыты для компромиссов относительно продукта и его разработки. Имея глубокое понимание как продукта, так и технической стороны его создания, такие инженеры могут сделать – и делают! – предложения, устраивающие всех участников процесса.

• Прагматичный подход к граничным случаям. Такие разработчики быстро выявляют граничные случаи и предлагают способы решения, не требующие дополнительных трудовых затрат, тем самым уменьшая рабочую нагрузку. Придерживаются концепции «минимально привлекательного продукта» (minimum lovable product), в соответствии с которым оценивают влияние граничных случаев, а также усилий по разрешению возникающих в связи с этим проблем. Они всегда предлагают хорошие компромиссные решения, заранее определяя, что может пойти не так, и указывая, какие случаи необходимо учесть еще до выпуска первой версии продукта.

• Быстрые циклы валидации продукта. Прежде чем разрабатываемый ими функционал будет готов к выпуску, такие разработчики находят креативные способы получить предварительную обратную связь. Это может быть тестирование продукта среди коллег, демонстрация разрабатываемого функционала продакт-менеджеру, организация командной баг-бэш-сессии для бета-версии и др. Они всегда задаются вопросом: «Как можно убедиться, что данный функционал будет использоваться так, как мы предполагаем?»

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

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

Как стать разработчиком, ориентированным на продукт

Если вы работаете над продуктом для пользователей, вот несколько советов, как прокачать свой «продуктовый навык»:

• Разберитесь, в чем и почему ваша компания успешна. Узнайте ее бизнес-модель, как зарабатываются деньги, какие области наиболее прибыльны и быстро развиваются и почему. Где в этой структуре находится ваша команда?

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

• Участвуйте в исследовании пользователей, поддержке клиентов и других подобных мероприятиях. Будьте активны в своем стремлении узнать, как работает продукт. Сотрудничайте с архитекторами, UX-специалистами и специалистами по анализу данных, коллегами из команд техподдержки и другими людьми, взаимодействующими с пользователями.

• Предлагайте осуществимые идеи. Как только у вас появится хорошее понимание бизнеса, его стейкхолдеров и самого продукта, смело берите инициативу в свои руки. Например, вы можете предложить небольшие улучшения в текущем проекте или же более крупные изменения, обозначив как технические, так и продуктовые задачи, что облегчит их последующую приоритизацию в бэклоге команды.

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

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

5.2. Платформенные команды

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

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

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

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

Приведем несколько примеров платформенных команд:

• Команда инфраструктуры в скейлапе. Предоставляет вычислительные мощности и ресурсы хранения для других команд на собственной платформе или помогает командам в использовании и управлении облачными средами.

• Команда платформы платежей в крупной технологической компании. Предоставляет внутренние SDK (пакеты средств разработки ПО), которые затем другие команды могут интегрировать в свои продукты для обработки платежей. Взаимодействует с поставщиками платежных систем, освобождая остальные команды от необходимости этим заниматься.

• Команда CI/CD в большинстве компаний. Отвечает за управление процессами непрерывной интеграции и развертывания. Часто способствует внедрению таких практик, как автоматизированное тестирование, линтинг и другие подходы, повышающие качество ПО, а также предоставляет обратную связь по этим вопросам.

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

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

Преимущества работы в платформенной команде

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

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

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

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

• Уровень сотрудников. Платформенные команды обычно привлекают для работы разработчиков уровня сеньора и выше, так как опыт более старших специалистов позволяет им эффективно выполнять стоящие перед ними задачи. Это подойдет тем разработчикам, которым нравится работать с более опытными коллегами.

Недостатки работы в платформенной команде

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

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

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

Как добиться успеха в платформенной команде

Я заметил, что успешные разработчики из платформенных команд действуют следующим образом:

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

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

• Работают плечом к плечу с пользователями платформы. Большинство разработчиков платформы работают исключительно со своей командой. Однако наиболее выдающиеся из них иногда переходят на «другую сторону» и сотрудничают с продуктовой командой, работая над интеграцией или реализацией платформы. Постарайтесь по возможности делать так же, ведь это улучшит понимание того, как другие команды используют вашу платформу. А еще это очень интересно!

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

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

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

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

5.3. «Мирное» и «военное» время

Когда я присоединился в 2016 году к Uber, компания успешно развивалась – по крайней мере так это выглядело со стороны, особенно после того, как она привлекла $5,6 млрд инвестиций при оценке в $66 млрд, полученной несколькими месяцами ранее. Но внутри царила полная неразбериха, в результате чего многие проекты воспринимались как вопрос жизни и смерти.

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

И когда в Uber началось «мирное время», мы сразу это почувствовали. В конце 2017 года пост генерального директора занял Дара Хосровшахи (Dara Khosrowshahi), и темп работы стал стремительно снижаться. В начале 2018 года он обозначил приоритеты компании, и мы начали более детально планировать свою работу. Появилось ощущение стабильности, которого раньше не было.

Итак, что же такое «мирное» и «военное» время в компаниях и как данные термины получили свое распространение? В начале 2010-х годов Бен Хоровиц (Ben Horowitz), соучредитель венчурной компании Andreessen Horowitz, опубликовал статью «Peacetime CEO/Wartime CEO». В ней он пишет:

Не так давно Эрик Шмидт (Eric Schmidt) покинул пост генерального директора Google, и основатель компании Ларри Пейдж (Larry Page) занял его место. Многие тогда обсуждали, способен ли Пейдж стать «лицом Google», ведь он более стеснительный и закрытый по сравнению с общительным и красноречивым Шмидтом. И хотя это важный вопрос, однако он упускает из виду главное. Эрик Шмидт был не просто лицом Google; являясь генеральным директором в «мирное» время, – он возглавил крупнейшее технологическое расширение компании за последние десять лет. Ларри Пейдж, напротив, кажется, решил, что Google пора ступить на тропу войны, и явно настроен возглавить компанию в «военное» время, что станет серьезным изменением не только для Google, но и для всей индустрии высоких технологий.

Хоровиц определяет «мирное» и «военное» время следующим образом:

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

Военное время наступает, когда компания сталкивается с какой-либо неизбежной угрозой, исходящей от различных источников, включая конкурентов, резкие макроэкономические изменения, изменения на рынке, перебои в цепочке поставок и т. д. Выдающийся генеральный директор военного времени Энди Гроув (Andy Grove) подробно описал все те «силы», что могут привести компанию от мирного времени к военному в своей книге «Only The Paranoid Survive»¹⁷.

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

Различия между двумя фазами:

Сравнение режимов «военного» и «мирного» времени

Как ведет себя руководство в режиме «военного» и «мирного» времени:

Типичное поведение руководства в режиме «военного» и «мирного» времени

Как добиться успеха в режиме «военного времени»

Как преуспеть в компании, функционирующей в режиме «военного времени»? Вот несколько подходов, которые могут вам помочь:

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

• Урегулирование конфликтов: не бойтесь спорить, если это ускорит работу. Но не принимайте все конфликты на свой счет – они вызваны обстоятельствами «военного времени», а не личной неприязнью.

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

• Офисная политика: если у вас хорошие отношения с вашим менеджером и руководством, то все в порядке.

• Приоритеты: работайте только над тем, что нужно прямо сейчас.

• Стабильность: работайте так, будто на кону вся ваша карьера, – может, это действительно так.

• Темп работы: постоянная «гонка» может плохо кончиться, поэтому следите за своей нагрузкой.

• Выгорание: высокий риск выгорания. Помните об этом и старайтесь избегать перенапряжения.

Как добиться успеха в «мирное время»

Для работы в компаниях с менее напряженной обстановкой подойдут другие подходы:

• Выполнение задач: качественно выполняйте свою работу. Медленно и надежно – лучше, чем быстро и кое-как.

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

• Союзники: налаживайте отношения с командами, с которыми вы работаете, так как это не только позволит вам лучше выполнять задачи, но и будет способствовать вашему карьерному росту.

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

• Приоритеты: работайте над долгосрочными проектами, которые принесут пользу компании.

• Стабильность: работа стабильна, что дает вам время и пространство для качественного выполнения задач.

• Темп работы: медленный и спокойный темп может стать слишком медленным, поэтому не забывайте иногда «встряхнуться».

• Застой: в «мирное время» на работе можно и заскучать – старайтесь избегать этого!

Чередование режимов

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

• Основание компании – «военное время». Основатели работают сверхурочно, чтобы создать прототип стартапа и привлечь первых клиентов.

• Фандрайзинг – «военное время». Команда работает круглосуточно, чтобы привлечь инвесторов.

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

• Между раундами финансирования – тот же ритм, что и на предыдущем этапе. Но если деньги заканчиваются, а конкуренты появляются, то вновь начинается режим «военного времени».

• За год до IPO – «военное время». Последний рывок, чтобы достичь нужных бизнес-показателей, а поэтому компания полностью сосредоточивается на областях, важных для инвесторов.

• После IPO – по обстоятельствам. Если IPO прошло успешно и цена акций растет, то в компании начинается «мирное время». Однако если IPO прошло неудачно и компания сталкивается с трудностями, «военное время» продолжается.

• Деятельность в качестве публичной компании: если компания продолжает успешно развиваться на рынке, темп работы в ней будет соответствовать «мирному времени». Хотя, конечно, это уже зависит от руководства.

Режимы «военного» и «мирного» времени постоянно сменяют друг друга не потому, что так захотели топ-менеджеры, а по объективным условиям. Вполне вероятно, что некоторые руководители предпочли бы, чтобы их компания всегда работала в режиме высокой продуктивности, то есть в режиме «военного времени». Однако у этого есть несколько негативных последствий:

• намного выше текучесть кадров;

• талантливые сотрудники уходят из-за выгорания, хотя если бы уровень стресса был ниже, они бы остались;

• трудно реализовать долгосрочную стратегию компании, так как в приоритете краткосрочные задачи;

• сложно мотивировать людей продолжать работать в режиме «военного времени», если бизнес процветает.

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

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

5.4. Типы компаний

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

Big Tech и крупные технологические компании

Техногиганты обычно работают следующим образом:

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

• «Мирное» vs «военное» время: такие компании обычно работают в режиме «мирного времени», так как успех бизнеса поддерживает их рост. Однако иногда они все же переходят в режим «военного времени», это сразу легко заметить по следующим признакам: сокращение персонала, более строгие перформанс ревью, изменения в руководстве, а «сверху» сообщают, что всем необходимо поднапрячься.

Советы для успешной работы в крупных технологических компаниях:

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

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

Скейлапы на среднем или позднем этапе развития

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

• Продуктовые vs платформенные команды: такие компании в основном состоят из продуктовых команд. Платформенные команды, если они вообще существуют, обычно находятся на самых ранних этапах развития.

• «Мирное» vs «военное» время: таким компаниям свойственна работа в режиме «военного времени». Чтобы понять, так ли это в вашей компании, пообщайтесь с коллегами и обратите внимание на поведение руководства.

Советы для успешной работы в быстрорастущих компаниях:

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

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

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

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

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

Молодые стартапы

• Продуктовые vs платформенные команды: платформенных команд в стартапах почти никогда нет. Большую часть работы выполняют продуктовые команды.

• «Мирное» vs «военное» время: большинство стартапов работают в режиме «военного времени», поэтому многое зависит от руководства компании: одни стараются обеспечить менее напряженные и более сбалансированные условия работы, а другие – нет.

Советы для успешной работы в молодых стартапах:

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

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

Помните, что стартапы – это всегда риск. Среди всех типов компаний стартапы чаще всего увольняют своих сотрудников и рискуют обанкротиться, исчерпав все свои ресурсы.

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

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

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

Стратегии для успешной работы в любой компании

Есть несколько стратегий, которые помогут вам добиться успеха вне зависимости от типа компании, в которой вы работаете:

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

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

• Не сжигайте мосты. Старайтесь разрешать конфликты мирным путем, уважительно относитесь к другим и учитесь выражать свое несогласие корректно и этично. Зачем? По той же самой причине – мир тесен.

Глава 6. Смена работы

Разработчик ПО, проработавший в одной компании на протяжении всей своей карьеры, – крайне редкий случай. И даже Сатья Наделла (Satya Nadella), который в 2014 году занял пост генерального директора Microsoft, за 22 года до этого устроившись на работу в техногигант в качестве простого разработчика, начинал свою карьеру в Sun Microsystems.

Итак, как же разумно подойти к процессу смены работы и как понять, что подошло время двигаться дальше? В этой главе мы рассмотрим следующее:

1. Изучение новых возможностей

2. Надеяться на повышение или уходить?

3. Подготовка к техническому собеседованию

4. Переход на позицию ниже

5. Переход на позицию выше

6. Онбординг в новой компании

6.1. Изучение новых возможностей

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

Активный поиск работы

Самый очевидный случай – это когда вам просто нужна работа. Например:

• Вы только что закончили учиться и хотите начать работать.

• Вы потеряли работу и теперь ищете новую.

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

• Вас не устраивает ваше текущее место работы, например из-за проблем с руководством и командой, из-за условий труда, – в общем, это все те проблемы, которые переход внутри компании решить не может.

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

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

Не ищете работу активно, но открыты для предложений

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

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

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

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

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

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

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

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

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

Бывало, что я, будучи доволен своей работой, упускал какие-то возможности, а потом жалел об этом. Так, в 2011 году я отклонил предложение от небольшого стартапа, который только что привлек $8 млн на начальное финансирование. От лица стартапа со мной хотел поговорить кто-то со специализацией «QA-тестирование» и предложить поработать над созданием приложения для Windows Phone. Тогда я не придал этому особого значения, и только через несколько лет понял, что это был Ян Кум (Jan Koum), генеральный директор компании WhatsApp. Вы наверняка о ней слышали: в 2014 году Facebook купил WhatsApp за рекордные $19,3 млрд, когда компания насчитывала около 50 разработчиков. На тот момент я был доволен своей работой, но если бы мог предвидеть будущее, то обязательно бы согласился пройти собеседование.

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

6.2. Надеяться на повышение или уходить?

Что делать, если вы считаете, что созрели для перехода на уровень выше? В таком случае нередко возникает соблазн найти новую работу с желаемой позицией, вместо того чтобы остаться в старой компании и в ближайшие несколько месяцев проходить изнурительную процедуру повышения. Почему бы не пройти пару собеседований? Может, вам удастся получить оффер с желаемой позицией и более высокой зарплатой? Выбор тут очевиден, особенно при таком «разогретом» рынке труда, как в 2021–2022 годах. Однако, прежде чем откликаться на вакансию, необходимо учесть некоторые нюансы.

Повышения обычно ретроспективны

Для получения повышения вам необходимо в течение 6–12 месяцев демонстрировать продуктивность на уровень выше занимаемой вами позиции. В таком случае повышение становится подтверждением, что вы соответствуете этому уровню. Это также означает, что вы можете сменить место работы, чтобы перейти на более высокий уровень и зарабатывать больше. Ну а если вы сможете перейти в компанию более высокого уровня (согласно трехуровневой модели, рассмотренной нами в главе «Карьерный путь»), ваша заработная плата возрастет значительно.

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

Чем выше ваш уровень, тем более рискованно менять работу

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

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

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

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

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

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

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

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

Чем выше ваш уровень, тем сложнее получить повышение

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

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

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

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

6.3. Подготовка к техническому собеседованию

Как подготовиться к собеседованию на должность разработчика ПО? К счастью, в интернете доступно множество материалов для подготовки. В этом разделе мы рассмотрим, чего можно ожидать от типичного собеседования на позицию сеньор-разработчика.

Средние и крупные технологические компании обычно используют схожие схемы собеседований, которые иногда называют «как в Google», поскольку они напоминают собеседования, проводимые этой Big Tech компанией.

Типичные этапы собеседования на позицию сеньор-разработчика¹⁸¹⁹

Рассмотрим все этапы собеседования.

Предварительный отбор

Цель этого этапа – понять, стоит ли приглашать кандидата на технический отбор. Решение принимается на основе следующих критериев:

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

• Наличие необходимых «гибких» навыков (soft skills) – подтверждается в ходе первого разговора с рекрутером или менеджером по найму.

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

Предварительный отбор проводит рекрутер, менеджер по найму или сорсер.

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

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

Предварительный отбор делится на два этапа: просмотр резюме и первый созвон с менеджером по найму.

Просмотр резюме: на основе резюме принимается решение, соответствует ли кандидат базовым требованиям для конкретной позиции. Уже только по этой причине стоит хорошо поработать над своим резюме разработчика ПО. Этому важному делу я посвятил целую книгу «The Tech Resume Inside Out».

Вот несколько рекомендаций для написания сильного резюме:

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

• Обратите внимание на опыт, релевантный для той позиции, на которую вы претендуете. Расскажите только то, что рекрутеру важно знать.

• Адаптируйте резюме под каждую вакансию. Не отправляйте везде одно и то же резюме. Лучше иметь готовый шаблон и изменять его под конкретную вакансию.

• Используйте хорошо структурированный шаблон. Чем проще рекрутеру или менеджеру по найму прочитать ваше резюме, тем лучше. Избегайте сложных форматов и макетов с двумя колонками. Ознакомьтесь с шаблоном резюме от «The Pragmatic Engineer»²⁰, который соответствует всем требованиям.

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

• Положительные рекомендации гораздо важнее безупречного резюме. Для этого обратитесь за помощью к вашим знакомым.

Больше полезных рекомендаций можно найти в моей книге «The Tech Resume Inside Out».

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

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

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

Технический отбор

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

Цель технического отбора – убедиться, что кандидат:

• Обладает достаточными техническими навыками для конкретной позиции. Знаком ли кандидат с основными технологическими концепциями и умеет ли работать с технологиями?

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

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

Технический отбор почти всегда проводится разработчиками, реже – техническими менеджерами. К наиболее распространенным формам проведения данного этапа относятся:

• Задание по программированию в режиме реального времени. Кандидат присутствует на собеседовании лично или через видеозвонок и решает задачу в режиме реального времени – пишет код и общается при этом с интервьюером, который сам является разработчиком (лайвкодинг).

• Задание по программированию «на дом». Такое задание кандидат выполняет в удобное для него время. Но задание может быть ограничено по времени – например, на его выполнение дается 90 минут. Некоторые задачи могут иметь и менее жесткие требования и сопровождаться инструкциями о том, сколько времени обычно требуется на их выполнение, предоставляя кандидату возможность самому спланировать свою деятельность.

• Другие форматы проверки технических навыков. Некоторые компании предпочитают проводить собеседования, на которых интервьюеры обсуждают технологические концепции, но не требуют от кандидатов написания собственного кода. Компании также могут предложить своим кандидатам пройти технический тест, а некоторые проводят сеанс отладки кода. Никаких строгих правил нет, поэтому многие компании придумывают свои форматы.

Как подготовиться к техническому отбору:

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

• Узнайте критерии оценки. Что важнее – функциональность кода, его качество или тестирование? Имеет ли значение выбор языка программирования? Получите ответы на эти вопросы до начала собеседования. В данном случае рекрутер – ваш лучший источник информации.

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

• Согласуйте сроки выполнения задания. Тестовое задание, предоставляемое кандидату «на дом», может отнять много времени, поэтому вам будет необходимо распланировать все заранее. Согласуйте сроки с рекрутером.

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

Очное собеседование

Заключительный этап процесса отбора зачастую представляет собой личную встречу в офисе работодателя. В данном случае возможны следующие форматы:

Собеседование по программированию (кодинг интервью). Проверка навыков кандидата в написании кода и его отладке. Это может быть алгоритмическое тестовое задание или решение задачи из реальной практики.

Существует множество ресурсов для подготовки к таким интервью. Я рекомендую следующие книги:

• Гейл Лакман Макдауэлл (Gayle Laakmann McDowell), «Cracking the Coding Interview»²¹.

• Эмма Бостиан (Emma Bostian), «De-Coding the Technical Interview Process».

Собеседование по проектированию систем (system design интервью), также известное как «архитектурная секция». Оно направлено на проверку того, насколько хорошо кандидат может спроектировать систему с нуля на основе предоставленных бизнес-требований, а также на оценку его умения справляться с проблемами масштабирования.

Книги для подготовки к такому интервью:

1. Алекс Сюй (Alex Xu) «System Design Interview – An Insider’s Guide»²².

2. Алекс Сюй (Alex Xu), Сан Лэм (Sahn Lam), «System Design Interview – Volume 2»²³.

Более глубокая проверка ключевых навыков. Такое собеседование проводится с целью оценки, насколько хорошо кандидат владеет ключевыми технологиями, необходимыми для данной позиции. Например, для бэкенд-разработчика это может быть знание распределенных систем и языка программирования Go. Для разработчика iOS – навык работы в Swift и более продвинутой разработки мобильных приложений. Как правило, интервьюеры затрагивают ключевые для конкретной позиции концепции как в собеседовании по программированию, так и в собеседовании по проектированию систем.

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

• мотивация;

• поведение в конфликтных ситуациях;

• подход к разрешению сложных ситуаций;

• насколько кандидат разделяет корпоративные ценности.

Собеседования с менеджером по найму сильно различаются в зависимости от компании, и даже разные менеджеры внутри одной компании могут демонстрировать разные подходы. Чтобы помочь вам лучше подготовиться к данному этапу, я записал видео под названием «Confessions of a Big Tech Hiring Manager»²⁴.

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

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

Процесс собеседования на позиции уровня стафф+

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

Собеседования для разработчиков уровня стафф+ обычно включают несколько дополнительных этапов, таких как:

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

• Собеседование с продакт-менеджером – оценивается, насколько кандидат способен эффективно работать с командой по продукту.

• Собеседование с директором, которое может выполнять функции собеседования с бар-рейзером или менеджером по найму.

• Второе собеседование по проектированию систем, которое проводит разработчик уровня стафф+.

6.4. Переход на позицию ниже

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

Я называю это «американскими горками программиста».

Американские горки программиста

Почему стоит «пожертвовать» своей позицией и предпочесть высокую заработную плату:

• Переход в компанию более высокого уровня. Конечно, такие компании предъявляют к своим сотрудникам более строгие требования, но вместе с этим приходит и рост заработной платы. И хотя вы перейдете на уровень ниже, ваш доход возрастет.

• Требования к одной и той же позиции в разных компаниях могут различаться. Например, ожидания к сеньор-разработчику в Big Tech компании выше, чем в небольшой студии разработки, нетехнологической компании или стартапе.

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

• Смена компании и технологии. Нетехнологические компании или агентства разработчиков, которые оценивают своих кандидатов по их опыту работы с конкретной технологией, могут предложить более низкую должность кандидату, который имеет, например, только год опыта работы конкретно с Java, даже если он проработал разработчиком десять лет. Такое понижение уровня особенно распространено, когда собеседование на позицию целиком посвящено определенной технологии.

Понижение уровня часто происходит при первом переходе программиста в Big Tech компанию, поскольку требования там обычно высоки, а процесс онбординга дольше, чем в небольших компаниях. Кроме того, техногиганты всегда ищут специалистов, которые смогут «поднять планку» на каждом уровне.

Как смириться с понижением должности

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

Понижение позиции при переходе в компанию более высокого уровня – это обычная практика. Разные компании предъявляют своим потенциальным программистам разные требования на каждом уровне. На вершине находятся такие компании, как Google, Meta и другие техногиганты, где разработчик каждым своим действием влияет на миллионы пользователей. Поэтому ожидается, что программисты будут следовать большему количеству установленных процессов и практик, чем в компаниях, руководство в которых далеко от технологий или в которых инженерные проблемы имеют меньшее значение.

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

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

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

Когда я был менеджером по найму, у меня было несколько случаев, что кандидаты опротестовывали понижение уровня. И каждый раз это заставляло меня пристальнее присматриваться к деталям собеседования и требованиям к должности. Иногда мы пересматривали свое решение.

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

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

6.5. Переход на позицию выше

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

Когда я работал в Microsoft, я занимал позицию разработчика уровня L62, что на один уровень ниже L63 – сеньор-разработчика. Однако затем я получил оффер от Skyscanner на должность принципал-разработчика, что было уже на уровень выше сеньора. Как такое произошло?

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

Чтобы получить оффер на более высокую позицию, необходимо следующее:

• Хорошо показать себя на собеседовании. Убедите членов комиссии по найму, что вы выдающийся кандидат на данную позицию.

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

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

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

6.6. Онбординг в новой компании

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

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

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

Ниже представлены несколько способов взять процесс адаптации в свои руки еще до вашего первого рабочего дня.

В любой компании и на любом уровне

Полезные советы:

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

• Прочтите книгу «The First 90 Days»²⁵ Майкла Уоткинса (Michael D Watkins). Там вы найдете отличные советы о том, как с первых дней работы сформировать о себе положительное впечатление.

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

• Ведите еженедельный журнал и записывайте в него три темы, в которых вы разобрались, и три, которые пока не понимаете.

• Определите свои цели на первый месяц, последующие три месяца и первые шесть месяцев работы.

Онбординг в небольшой компании

В стартапах и небольших организациях можно сделать следующее:

• Еще до начала работы уточнить, чем именно вы будете заниматься.

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

• Не предполагать, как в компании все устроено, а задавать вопросы. Это особенно важно, если вы перешли из крупной компании. Ваши предположения в новом контексте могут оказаться неверными.

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

Онбординг в крупной компании

Адаптироваться в крупных компаниях уже сложнее, тут придется усердно работать с самого первого дня:

• Найдите себе «наставника по онбордингу», если вам его не назначили. Это должен быть человек из вашей команды, к которому вы сможете обращаться с вопросами и который готов помочь вам освоиться.

• Ведите некую «шпаргалку», куда будете записывать все новое: расшифровки аббревиатур, команды сборки, ссылки на важные ресурсы и др. Это не только ускорит ваше обучение, но и впоследствии может быть приложено к журналу онбординга.

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

• Поначалу многое будет казаться вам запутанным и непонятным, особенно если вы перешли из небольшой компании. Не волнуйтесь, это нормально!

Онбординг на позициях уровня сеньор и выше

Более опытным разработчикам в период адаптации на новом месте следует также:

• связаться с коллегой уровня сеньор или выше, чтобы узнать, как он организует работу и измеряет ее результаты;

• активно работать с кодовой базой команды;

• обговорить со своим менеджером, что он ожидает от вас после 3, 6 и 12 месяцев работы;

• разобраться в текущих и будущих проектах, приоритетах команды. Чем занимается ваша команда, почему это важно и как это вписывается в стратегию и приоритеты компании?

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

• составить список команд разработчиков, с которыми необходимо познакомиться. Как только вам рассказывают о какой-то группе, сразу добавляйте ее в этот список. Затем представьтесь кому-то из этой команды и узнайте, чем они занимаются и как связаны с вашей работой. Для новичков в компании это особенно просто, у вас есть повод представиться: вы новый сотрудник! Вместе с тем это поможет вам лучше понять деятельность компании и наладить полезные контакты на будущее.

Онбординг на позициях уровня стафф+

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

• Познакомьтесь с командой как можно раньше и произведите благоприятное впечатление.

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

• Позиции уровня стафф+ различаются в зависимости от компании, поэтому выясните, что от вас ожидается на новом месте, а что нет.

• Уточните у вашего менеджера (а также, по возможности, у менеджера вашего менеджера) цели на 3, 6 и 12 месяцев работы. Каковы главные приоритеты команды и какие наиболее значимые проблемы необходимо решить?

• Общайтесь с сотрудниками из продуктовых команд, чтобы понять их текущие проблемы и планы.

Выводы

IT-индустрия стремительно развивается, и множество программистов каждые несколько лет меняют место работы. В то же время большинство из нас проработают в IT десятилетиями. В своей статье «A forty-year career»²⁶ технический директор и публицист Уилл Ларсон (Will Larson) размышляет об обычном трудовом пути человека, не работающего в IT:

Мой отец несколько лет назад вышел на пенсию, большую часть своей жизни проработав профессором в Университете Северной Каролины в Эшвилле. С тех пор я на удивление много размышлял о его выходе на пенсию и его завершенной карьере, а особенно о том, что я тоже могу строить свою карьеру на протяжении сорока лет. Не четыре IPO, не четырнадцать двухлетних отрезков, а сорок лет.

Странно осознавать, что я совсем забыл о модели сорокалетней карьеры, потому что долгое время я только ее и знал ‹…› Поэтому если вы начали строить долгосрочную карьеру, постарайтесь не оступиться на этом пути и продолжайте двигаться – к успеху, покупке недвижимости и, в конечном итоге, к пенсии.

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

Самое главное, что вам нужно уяснить:

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

Дополнительную информацию по этой теме можно найти в бонусной главе онлайн²⁷:

«Working at a Startup vs in Big Tech» («Работа в стартапе vs работа в Big Tech»).

pragmaticurl.com/bonus-1.

Часть II. О компетентном разработчике ПО

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

Вариантов того, как в компании называется позиция разработчика, несколько, но наиболее распространенные следующие:

• Инженер-программист (Software Engineer, SWE, SWE 2) – в большинстве Big Tech компаний, а также в некоторых стартапах и скейлапах.

• Разработчик ПО (Developer, Software Developer, SDE, SDE 2) – в традиционных компаниях, некоторых стартапах и скейлапах.

• Технический сотрудник (Member of Technical Staff, MTS). Некоторые компании, основанные в 1970-х и 1990-х годах, позаимствовали подобное название у легендарной Bell Labs (Лаборатория Белла), которая присваивала его опытным сотрудникам. Сегодня такое наименование позиции используют, например, в компаниях Oracle и OpenAI. В OpenAI «техническими» называют всех сотрудников, подобно тому как другие компании используют для этого термины «разработчик ПО» или «инженер-программист».

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

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

Наиболее распространенные ожидания от разработчика ПО начального уровня

Глава 7. Выполнение задач

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

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

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

1. Фокусируйтесь на важном

2. Находите решение проблем

3. Разбивайте задачи на этапы

4. Оценивайте сроки выполнения задач

5. Найдите менторов

6. Поддерживайте свой «баланс помощи»

7. Проявляйте инициативу

7.1. Фокусируйтесь на важном

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

Именно поэтому стоит упростить свой рабочий процесс. Спросите себя: «Какая задача на данный момент самая важная?» Нет, правда, подумайте: если бы на этой неделе вам можно было выполнить только одну задачу, то какую бы вы выбрали? Ответьте на этот вопрос.

Так вы и узнаете, какая задача является вашим приоритетом № 1. Сфокусируйтесь на ней и выполните ее к заданному дедлайну.

Сначала всегда выполняйте наиболее приоритетную задачу

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

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

Научитесь говорить «нет»

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

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

Поэтому рано или поздно вам придется научиться отказывать. Этот навык – а это именно навык – приходит с опытом, и чем раньше вы научитесь говорить «нет», тем больше пользы вы извлечете.

Самый простой способ для этого – сказать: «Да, я бы с радостью помог, НО…» Например, если продакт-менеджер просит вас немедленно заняться багом, но у вас есть более срочная задача, вы можете ответить так: «Да, я бы с радостью помог, НО сейчас я работаю над реализацией функциональности Zeno, и это моя приоритетная задача. Я смогу заняться багом только после того, как закончу текущий пул-реквест, либо мне придется отложить работу с Zeno, потому что я не могу делать оба дела одновременно».

Или еще пример: другая команда пригласила вас на планерку, но у вас нет на это времени. Ответьте: «Да, я бы охотно пришел, НО у меня много незаконченной работы. Можете прислать заметки со встречи, я ознакомлюсь с ними позже? Буду очень благодарен. Спасибо большое!»

Не обязательно отказываться от всего подряд, но если вы не успеваете выполнить приоритетную задачу, умейте сказать «нет». Или лучше: «Да, я бы с удовольствием помог, НО…»