Перевод статьи «What a 20 Year Career in Tech Has Taught Me About Getting Promoted».
Моя карьера разработчика началась в начале 90-х. В то время мои цели выглядели так:
- хорошо справляться со своей работой
- быть полезным людям, с которыми я работаю
- получать признание моих усилий в виде повышения на более сложные позиции.
С тех пор, как я начал свой карьерный путь, в IT кое-что изменилось. Например, несколько улучшилась градация тайтлов от джуниора о сеньора. Но путь перехода с одной позиции на другую по-прежнему сильно отличается в разных компаниях.
За годы работы я очень многое узнал о том, как разработчику получить повышение. Многие из этих вещей совершенно не интуитивны. Но их справедливость подтверждается многолетними наблюдениями, так что, надеюсь, они и вам помогут продвинуться по карьерной лестнице.
Повышение в IT
Тема повышения, особенно в сфере технологий, может быть очень запутанной. На то, как и когда вас могут повысить, влияет число сотрудников в вашей компании, стадия ее развития, ее культура и стиль управления. Методология и философия продвижения по службе может отличаться в разных компаниях, и стратегия, которую вы применяли в одной, может совершенно не подходить для другой.
Если брать за основу данные статьи на Indeed.com, в США примерно половина людей работает в крупных компаниях (со штатом больше 1000 человек). Остальные работают в маленьких и средних. Но в историях о повышениях чаще всего рассматриваются крупные компании, где куда лучше определены уровни и должности. В результате примерно половина людей (и особенно это касается новичков) не имеет четкого представления о карьерном росте и повышениях.
И есть же еще одна переменная, способная оказать влияние на ваше продвижение. В результате слияния, поглощения или реорганизации компании ваши навыки могут быть переоценены, и вы можете опуститься на уровень ниже. Или вы можете сменить компанию и перейти на более высокую позицию, а при новой смене компании вернуться на старый уровень. На момент написания этой статьи я достиг уровня директора. Но если бы я захотел стать одним из директоров в Facebook, то чтобы меня сочли возможным кандидатом, мне нужно было бы иметь уровень вице-президента. А если бы меня наняли, то из вице-президента я бы превратился в директора.
Все это не хорошо и не плохо. Просто, разрабатывая свою стратегию продвижения по карьерной лестнице, все эти моменты нужно учитывать.
На чем нужно сосредоточиться
Когда я начинал карьеру в сфере разработки, ситуация с тайтлами была довольно запутанной. Я работал по контракту, и в разных компаниях меня называли и веб-мастером, и веб-разработчиком, и UI/UX дизайнером. В конечном итоге мои тайтлы все больше конкретизировались по технологиям. Некоторое время я был мультимедиа-разработчиком (когда был популярен Flash), затем старшим PHP-разработчиком (когда PHP был на пике популярности).
Когда я начал работать над более крупными и сложными масштабируемыми системами, я стал разработчиком ПО (Software Engineer), затем старшим разработчиком. Причем все эти изменения в тайтлах не обязательно были повышениями. Многие были результатом того, что в компании просто не были разработаны процедура повышения и градация тайтлов. Во многих компаниях по-прежнему ничего этого нет.
Сейчас я директор по разработке, руковожу менеджерами, которые руководят командами. И я все еще учусь. Но несмотря на всю запутанность темы повышений, за 20 с лишним лет я все же нащупал некоторые способы обозначить, чего я хочу и чего заслуживаю.
Вот несколько стратегий, которые помогут вам в продвижении по карьерной лестнице.
Концентрируйтесь на собственном влиянии, а не на результате работы
В начале моей карьеры я уделял слишком много внимания результатам. Я даже добровольно брал на себя больше работы, чем следовало, засиживался допоздна, работал по выходным — и все это для того, чтобы довести какой-нибудь проект до финиша. Тот же паттерн поведения я наблюдал и у других. Все мы хотели стать т. н. «десятикратными» разработчиками.
Подобные усилия могут приносить пользу в маленьком стартапе (и в течение некоторого времени), но так вы не нарастите свое влияние и не получите повышения как разработчик. Горькая истина в том, что компании могут просто купить результат, наняв фрилансеров, контракторов или отдав часть работы на аутсорс. Таким образом, результат совершенно не обязательно является показателем для повышения.
Значение имеет ваше влияние. Причем, как я усвоил за годы работы, в разных компаниях под этим понимаются разные вещи. Если вы хотите сфокусироваться на собственном влиянии, а не на результате, вот несколько идей:
- Решая задачу, старайтесь вникнуть в ее мельчайшие детали. Найдя ответы на все «почему?» относительно того, над чем работаете, вы зачастую сможете предлагать более умные и быстрые альтернативные решения.
- Рассказывайте о том, что делаете, как можно раньше и как можно чаще. Особенно это касается проектов, длящихся немного дольше обычного. Как бы вы ни были уверены в своем подходе и решении, не нужно забывать, что одна голова хорошо, а две — лучше. Если ваши коллеги будут в курсе вашей работы, они смогут посоветовать какое-нибудь улучшение или вовремя заметить возможные риски.
- Ищите способы автоматизировать повторяющиеся действия. Подумайте о людях, которые придут вам на смену и будут улучшать или расширять вашу работу. Постарайтесь найти способы повышения эффективности, чтобы вашим преемникам работалось быстрее и проще.
- Старайтесь не быть единой точкой отказа, а для этого делитесь знаниями с коллегами. Рассказывайте и документируйте то, что вы делаете, продумывайте крайние случаи и нюансы, касающиеся вашей работы, указывайте контекст — в общем, делайте все, чтобы другие разработчики могли продолжить вашу работу, если вдруг что.
Работайте правильно и занимайтесь правильными вещами
Работал я однажды в одном стартапе, где мы создавали видеоигры. Я решал множество сложных проблем и помогал другим делать то же самое. В конечном итоге у меня собрался целый сборник рецептов с подходами к решению различных задач. Я чувствовал себя настоящим героем: я знал, что я чертовски хорош в своем деле.
Позже мне случилось устроиться на работу в куда более крупную компанию по производству видеоигр. И я решил поделиться своим сборником рецептов с коллегами, чтобы спасти их от неизбежных ошибок. Но мои рецепты оказались в корне неподходящими. Их применение в этой компании напоминало попытку теннисистов сыграть в футбол на бейсбольном поле. В конечном итоге мой сборник стал более гибким и обогатился различными рубриками.
Я понял, что понятия «правильная работа» и «правильный способ что-то делать» — это движущиеся цели. Тем не менее, можно установить некоторые рамки, чтобы, проявляя гибкость, не слишком отклоняться от того, что считаете «правильным».
Вот несколько вопросов, которые можно задать себе, чтобы отфильтровать «правильные» вещи:
- То, что я делаю, приоритетнее других вещей, которыми я мог бы заняться? Каков был приоритет этих вещей на совещании, посвященном планированию?
- Эта работа где-то отлеживается? Есть ли для нее четко определенные требования и критерии успеха?
- Моя команда знает, чем я занимаюсь? Если я что-то изменил, решая проблему производительности, рассказал ли я об этом всем остальным?
А вот вопросы, которые можно себе задать, чтобы определить, правильно ли вы делаете то, что делаете:
- Будут ли другие команды пользоваться тем, что я создаю, и должен ли я учесть их особые нужды?
- Каковы требования по масштабированию? То, что я создаю, будет использоваться в течение долгого времени, или это часть первой фазы разработки? Будут ли этим пользоваться сотни, тысячи или миллионы людей?
- Есть ли у нас опыт, возможности и интерес к созданию этого функционала, готовы ли мы его поддерживать? Или лучше обдумать возможность покупки готового решения?
Ответы на все эти вопросы не всегда будут очевидными, даже если обсуждать их с командой. Во многих ситуациях у вас будет лишь несколько ответов и необходимость приступить к делу сразу же.
Самое важное здесь — общение. То, что вы задаете эти вопросы себе и команде, уже само по себе повышает шансы на то, что вы будете работать над правильными вещами и правильным образом. А это один из факторов, способствующих повышению вашего влияния.
Безжалостно отдавайте приоритет собственному развитию
Я наверняка никого не удивлю, если скажу, что непрерывная учеба всегда будет существенным компонентом вашего успеха. Я знал и принимал это как данность с самого начала своей карьеры. Но я кое-что упустил из виду, и это меня замедлило. Мне следовало чаще запрашивать обратную связь.
Теперь я знаю, что фидбэк выступает в роли коэффициента личного развития. Если вы ищете способ ускорить свою учебу и развитие, это именно то, что вам поможет. Я не осознавал этого, пока не получил свою долю критических отзывов, которые заставили меня засунуть подальше свое эго и сосредоточиться на сборе как можно большего количества мнений других людей.
Не следует просто тихонько «работать свою работу»: рассказывайте обо всем, что делаете, причем как можно раньше. Делитесь своими мыслями, предчувствиями и догадками, решениями и тем, как вы пришли к этим решениям. Рассказывайте о том, как вы подходите к общению на какие-то темы и о том, как думаете вести какие-то беседы. Делитесь всем этим с более опытными людьми и слушайте, что они скажут.
Помимо установки на постоянную учебу я стал целенаправленно запрашивать обратную связь о том, чего мне следует делать меньше, а чего — больше. Я не оценивал эту обратную связь. Я ее анализировал, что-то выбрасывал и применял остальное. А затем просил следующий фидбэк.
Каждая компания и команда, к которой вы присоединяетесь, — это школа. Ищите школы, которые помогут вам раскрыть ваши возможности и восполнить пробелы в знаниях. Если у вас не возникает никаких сложностей или вы не получаете достаточного количества обратной связи, найдите школу получше.
Фокусируйтесь больше на команде, чем на себе
У нас у всех есть склонность сравнивать себя с другими. Мы смотрим на более опытных разработчиков, работающих рядом с нами, и задумываемся, что бы мы делали, будь мы такими же. Я не раз ловил себя на подобных мыслях, работая в разных компаниях и разных командах. Но это было лишь напрасной тратой времени и эмоциональной энергии.
Однажды я работал с очень талантливым разработчиком, который специализировался на базах данных. Мы работали в паре, создавая специфические функции, и все, что мы делали вместе, выходило просто потрясающе. Я завидовал умениям моего коллеги, и очень сильно старался научиться у него как можно большему по части работы с базами данных, чтобы как-то приблизиться к его уровню.
А вот он поступал иначе. Он учился у меня только тому, что позволило бы ему продолжить работу с того места, где я закончил, — не больше. Когда я спросил его, почему так, он ответил: «Это не моя роль, а твоя».
Он рассматривал нас как команду. Мы дополняли умения друг друга и вместе являли собой нечто большее, чем просто сумму двух частей. Поэтому мне стоило сосредоточиться именно на своей роли, как делал он.
Когда я это понял, я осознал, что между мной и другими разработчиками на аналогичных позициях тоже есть различия. Наш набор навыков не одинаковый, но мы дополняем друг друга. И при необходимости мы можем поддерживать друг друга за счет этих различий.
Вы должны хорошо разбираться в своей специализации и знать, чего от вас ожидают. Учитесь у других и фокусируйтесь на совершенствовании в сферах, за которые вы отвечаете. Когда у членов команды разные знания и разные уровни навыков, возможности этой команды выстраиваются в диаграмму Венна. Ваши знания и навыки будут перекрываться во многих местах, но все то, что не перекрывается, является основой для озарений, инноваций и креативности.
Найдите то, чем вы отличаетесь от других, и совершенствуйте эти знания и умения. Это поможет вашей команде подняться на новый уровень.
Наращивайте организационную осведомленность
Продвигаясь по карьерной лестнице разработчика, со временем вы начнете замечать некий паттерн. Вы обнаружите, что одни люди интересуются тем, что происходит за пределами команды, а другие — нет.
Встав на путь менеджмента, я получил возможность посмотреть на этот паттерн под другим углом. Люди, которых просили присутствовать на совещании или участвовать в обсуждении, часто жаловались, если тема была мало связана с их непосредственными обязанностями. А другие, напротив, жаловались на то, что их не приглашают принять участие в таких совещаниях и обсуждениях. Им хотелось бы посидеть, послушать и узнать немного больше о том, что происходит где-то еще помимо их команды.
Непросто найти баланс между желанием быть в курсе событий и нежеланием отвлекаться от работы. Но могу сказать, что существует некоторая корреляция между повышениями и тем, из какого вы «лагеря».
Я сделал вывод, что нужно избегать крайностей и придерживаться золотой середины. Ваши тимлиды и команда стараются оберегать ваше время и делать все, чтобы вы могли сосредоточиться на работе и не отвлекаться. Доверяйте им в этом.
И если они считают, что вам будет полезно узнать что-то дополнительно и проявить интерес к происходящему за пределами команды, — доверяйте и в этом тоже.
Если вы будете полагаться на мнение тимлидов и более опытных коллег, вы усилите собственный фильтр и научитесь фокусироваться на нужной информации, и информация — это сила.
Заключение
Конечно, есть много других вещей, о которых можно было бы рассказать, да и ситуации у всех разные. Все описанное в этой статье сам я узнавал постепенно и, конечно, не применял с первого дня своей карьеры. Но узнавая что-то, я начинал это применять, и со временем эти знания слились в целую стратегию.
Кое-что из того, чем я поделился, помогало мне получать повышения. Большая часть изложенного в конечном итоге привела меня в менеджмент. Но, что лучше всего, знание всех этих вещей позволило мне помочь другим людям получить повышение.
За годы работы я заметил, что порой повышение нужно прямо-таки зубами выгрызать, а иногда вам помогают. Поднимаясь по карьерной лестнице разработчика, не забывайте помогать другим.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]