Коли і як ІТ-спеціалісту просити підвищення зарплати. Думка компаній і колег

ІТ-компанії конкурують одна з одною за фахівців. Один зі способів утримання спеціалістів — підвищення зарплати, виплата бонусів чи преміювання. До того ж це гарний спосіб мотивувати працівника брати на себе більше обов’язків, якісно виконувати роботу, професійно розвиватись.

Проте навіть високі результати роботи та розвиток не гарантують, що зарплата зросте автоматично. Інколи свій запит треба озвучити. Та як зробити це правильно?

У цій статті розглянемо поради HR-спеціалістки щодо підготовки до розмови про підвищення компенсації, зарплатну політику ІТ-компаній та історії фахівців, котрі досягли бажаного підвищення.

Ілюстрація Уляни Патоки

Підготовка до процесу перегляду зарплати

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

Перший — це ваші внутрішні відчуття і переживання щодо цієї теми. Адже стосунки з грішми пов’язані з певними психологічними особливостями, які сформувались протягом життя. Це і усвідомлення власної цінності, потреб, і контакт зі своєю агресією для їх задоволення, і уміння вибудовувати та відстоювати власні кордони.

Тому, якщо вам некомфортно просити підвищення, варто з’ясувати питання: як ви відчуваєте свою цінність як людини та як фахівця? Чи вважаєте себе достойними отримувати певні блага: статус, гроші, увагу інших? Чи можете чітко і впевнено описати свої сильні професійні сторони? Чи можете присвоїти собі власні досягнення: вдале навчання, класно зроблені проєкти, цікаві ідеї, які були реалізовані?

Якщо із самооцінкою не дуже, то й просити про підвищення вам буде складніше, ніж більш упевненим в собі колегам. Адже якщо ви не особливо цінуєте самі себе, то й не вірите, що вас будуть цінувати інші (фінансово в тому числі). А відмова може здатися підтвердженням відчуття, що ви десь не дотягуєте.

А як у вас з усвідомленням потреб і побудовою кордонів? Чи легко говорити оточенню, що вам подобається, а що ні? Просити, якщо щось потрібно? Відмовляти, якщо чогось робити не хочете?

Якщо тут існують певні труднощі, то й говорити про гроші буде непросто. Адже ви ризикуєте стикнутись із неприємними емоціями, наприклад, страхом, що вам відмовлять, а ви не зможете наполягти на своєму. Або із власним безсиллям вплинути на ситуацію. Чи зі страхом конфлікту.

Що робити:

  • Щонайменше усвідомити такі свої особливості. В момент, коли їх зауважили та визнали — ви уже рухаєтесь до вміння з ними правильно обходитись.
  • Можна працювати з психологом — це принесе тривалі та стійкі результати. Фахівець ознайомить вас із вашими особливостями і дасть навички, як з ними жити гармонійно. Це позитивно вплине на всі сфери життя, не тільки на професійну і фінансову. Але це не швидкий процес.
  • Якщо результат потрібен швидко, поговоріть з кар’єрним консультантом. Це буде коротший і прицільніший шлях для отримання підвищення. Проте не розв’яже питання з психологічними особливостями та загальною якістю життя.
  • Самостійно підготуватись до такої розмови. Це додасть упевненості. Про це й поговоримо далі.

Другий момент — підготовка. Незалежно від того, як почуваєтеся з приводу розмови про підвищення, підготовка зміцнить вашу перемовну позицію.

У такому разі раджу:

  • Аудит сильних професійних сторін і досягнень. Подумайте над проєктами, які вам класно вдались, цікавими ідеями, які реалізували тощо. Це і підсилить самооцінку, і стане аргументом в перемовинах.
  • Аналіз ринку зарплат. Подивіться, як оплачуються спеціалісти вашого рівня. Джерела інформації: аналітичні дані сайтів на зразок DOU, вакансії інших компаній (вас же регулярно кличуть на співбесіди, правда? :), власні контакти.
  • Аналіз ринку спеціалістів. Ви вузький спеціаліст, якого важко знайти та важливо втримати? Ви спеціаліст, яких не мало, але на яких великий попит? Таких, як ви, багато, і вибір для працедавця не проблема?

Ці нюанси важливо розуміти, коли формуєте перемовну стратегію: про яке підвищення можете просити, на які поступки працедавцю готові піти, якщо озвучена сума буде неприйнятна, чи готові змінити працедавця у разі відмови тощо.

Третій — правильно обраний час. Навіть якщо почуваєтеся впевнено і підготувались, усе може зіпсувати неправильно підібраний момент. Оптимальними можуть бути:

  • За деякий час до щорічного перегляду зарплати, якщо такий у компанії існує. Зазвичай це відбувається або в січні, або у квітні. Це дасть можливість менеджеру закласти нові цифри в бюджет, і процес мине більш гладко.
  • Після вдалого завершення проєкту, коли вами задоволене керівництво.
  • Після проходження навчання, яке суттєво підвищило ваш професійний рівень, або після виконання внутрішніх корпоративних умов для переходу з одного професійного рівня на інший.
  • Після отримання цікавого оферу. Це більше про потребу компанії вас утримати. Але я б не рекомендувала зловживати цим підходом з метою отримати підвищення на поточному місці. А швидше тоді, коли ви справді не можете визначитись: залишитись чи прийняти офер від іншого роботодавця. І тому хочете почути альтернативну пропозицію від власної компанії.

Зарплатна політика ІТ-компаній

Редакція DOU розпитала ІТ-компанії про зарплатну політику. З нами поспілкувались Scalors, Uptech, S-PRO, threadUP: вони регулярно переглядають рівень компенсації через певний проміжок часу (наприклад, пів року чи рік) незалежно від рівня фахівця, проєкту чи інших факторів. Зазвичай цьому передує постановка цілей для розвитку фахівця на певний період. У різних компаніях за це відповідає PM, HR або кар’єрні консультанти (HR People Partner). Вони роблять зрізи та аналізують ринок, передають аналітику тімлідам або техлідам. Якщо цілей досягнуто, прогрес є — зарплату підвищують. Якщо ні — залишають на тому ж рівні.

З переваг такого підходу — прогнозованість і більш-менш чітке розуміння фахівця, як отримати підвищення. Серед недоліків — можлива зміна цілей (залежно від пріоритету продукту або в разі зміни проєкту).

Хто визначає рівень зарплати

Кандидат на підвищення (ініціатива йде від нього). Людина вивчає ринок і має уявлення про актуальні заробітні плати за знання певних технологій. Тоді, згідно з установленим процесом у більшості IT-компаній, спеціаліст спочатку звертається до менеджменту з проханням підвищення. Зазвичай основними факторами є висока продуктивність, рівень «сеньйорності» та екстрадосягнення на проєкті.

Контрофер як спосіб підвищення зарплати. Якщо спеціаліст отримав пропозицію від іншої компанії, йому можуть зробити контрофер.

Клієнт. Не завжди підвищення зарплати відбувається з подачі компанії. У Scalors розповіли, що здебільшого кожна компанія має чітко прописану матрицю KPI, на основі якої клієнт може ініціювати плановий перегляд заробітної плати.

Наприклад, нещодавно клієнт Scalors та Co-founder австрійського startup-проєкту підвищили Senior-розробника до CTO компанії. Важливими показниками стали лояльність і значний внесок у проєкт. З кар’єрним підвищенням зросла і зарплата.

Команда. Коли член команди вирішує, що час для розгляду його компенсацій настав, то пише лист колегам, які оцінюють його рівень. Насправді це досить нестандартний підхід, який в українських ІТ-компаніях трапляється рідко.

В Uptech, наприклад, це відбувається так: фахівець пише лист про свої досягнення та помилки, внесок у розвиток компанії і те, яких цілей планує досягти, трьом-чотирьом колегам. Команда зі свого боку надає зворотний зв’язок за шістьма критеріями: розвиток технічних навичок, робота з клієнтом, командна робота, вклад у зростання і розвиток компанії, допомога колегам, досягнення особистих цілей. Коли всі поділилися своїми міркуваннями, кандидат підбиває підсумки та збирає комісію із тих самих 3-4 колег для представлення результатів. Фінальне рішення, наскільки підвищувати, залишається за самим співробітником, інші учасники лише оцінюють його діяльність. Зазвичай такий процес триває близько двох тижнів.

З переваг підходу — децентралізація влади, заохочення до швидшого та усвідомленого вдосконалення фахових навичок членів команди. Серед недоліків — непередбачуваність. В Uptech розповідають, що у квітні 2018 року під час перегляду зарплати Android-розробника команда рекомендувала підвищити компенсацію на 30% при запиті 20%. Як завжди, фінальне рішення було за співробітником, який обрав надбавку у 25%. За три роки траплялись випадки, коли суму збільшували майже вдвічі: наприклад, з $600 до $1100.

А ось що розповідають ІТ-фахівці про власний досвід: як говорити про підвищення

Егор Шевченко, Software Developer в SEDNA Systems

Как ІТ-специалист я развиваюсь в Англии. Возможно, мой опыт разговоров с руководством по поводу повышений отличается от украинских реалий (хотя вряд ли). Я лично иду просить, только когда на 100% уверен, что заслуживаю этого, когда понимаю, что вырос профессионально. Также нахожу моменты, когда более заметна моя полезность для компании. Иду с настроением: «Я уверен, что ничего неправильного не прошу. Если руководители решат не повышать, то это покажет их отношение ко мне. Тогда смогу со спокойной душой отвечать всем рекрутерам, которые мне пишут».

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

Первое повышение. Работа в стартапе (около 40 человек). На момент разговора о повышении я проработал 1,5 года. Начал как интерн, продолжал работать как студент-джуниор. За полтора года был сильный прогресс: сделал успешный проект, который сперва предложили как эксперимент. Меня стали больше слушать, я делал сложнее задачи. И мои результаты оценивали люди на высоких должностях в компании.

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

Второе повышение. Компания — стартап (около 30 человек). На момент разговора я проработал в компании два года. Пришел сюда на третьем курсе, а после выпускного мне уже начали поднимать зарплату. После этого проработал год и сильно прогрессировал. Попросил COO компании поговорить о повышении.

Мне казалось, что двух джунов используют нерационально, что им сложно, сотрудники не получают опыт, а компания — возможных результатов. Я рассказал об этом и предложил варианты, как изменить ситуацию: у новеньких не было менторов, никто особо не разговаривал с ними про их сильные и слабые стороны. Их просто «закинули» в команду. Сеньоры не знали, что они должны менторить джунов, поэтому не выделяли на это время. А те брали сложные задачи, тратили кучу времени, делали неправильно и оставались очень расстроенными. Я предложил за каждым закрепить ментора и выделять время на конкретное обучение. Если бы джун после этого не прогрессировал, дальше бы думали, что с ним делать, а не просто держали в команде.

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

Максим Шнуренок, Senior .NET Developer в ITOMYCH STUDIO

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

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

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

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

Для мидлов это уже сложнее: стоит начинать resume-driven development и не прекращать его. Имею в виду, не влепить технологию любой ценой, потому что модно, а хорошо в этом разобраться на практике. С другой стороны, лепить что попало на данном этапе пока и не дадут (и слава Богу), поэтому цель — выбирать интересные проекты и пытаться получать задачи, которые максимально прокачают и повысят вашу ценность для компании. Также на этом уровне перестаёт работать церемония под названием «план развития», потому что реальное развитие вы получаете не от того, что читаете туториал по технологии, который благополучно забудете через месяц. А от задачи с использованием этой технологии.

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

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

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

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

Андрей Мирошниченко, Front-end Developer

Я — свитчер, попал сразу на зарплату ~$600. Это была небольшая студия, в которой была пара относительно больших стабильных проектов и много мелочи с Upwork. В первые месяцы компания повышала зарплату каждый месяц, об этом не надо было просить. Шеф, который курировал один из больших проектов, решал, что в этом месяце твой скилл вырос вот на столько и теперь зарплата — такая :) Так продолжалось примерно год, по итогам которого зарплата оставалась средней по рынку, согласно виджету ДОУ. Плюс в том, что она повышалась постоянно, а не скачкообразно по прошествию года.

Потом проект закончился. Я попал на другой: там была немного другая политика повышения зарплаты, а ещё — деньги :) Это очень важно понимать: прибыльно ли то, над чем работаешь. Зная, что ответ утвердительный, можно и себе просить хорошую зарплату. Так, каждые 3-4 месяца я просил повышения и получал его. Но нюанс в том, что прирост был не на основе моих знаний, а на основе работы, которая выполнялась. То есть нельзя сказать, что я стал лучше с точки зрения скиллов.

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

Договориться о внеплановом сильном повышении зарплаты практически нереально. Отсюда такой популярный выход за +500 к конкурентам. В частности, моя зарплата выросла всего на ~$800 за полтора года. Все разговоры о нормальной прибавке упираются в «получи сеньора, мы тебя дороже продадим, тогда повысим зарплату», кекеке.

Иван Ролик, CTO в Genesis

Пересмотр оклада сотруднику зачастую сводится к обсуждению трех ключевых моментов: 1) изменение рынка; 2) изменение зоны ответственности; 3) изменение сложности выполняемой работы. Все остальные причины уникальны и индивидуальны для каждого сотрудника или связаны с наличием организационных или других проблем внутри компании.

Когда менеджер приходит ко мне как к СТО и говорит, что хочет пересмотреть сотруднику оклад и повысить его на 15%, мой стандартный вопрос: «За что?». В ответе я ожидаю определить одну из трех основных причин.

Если причина в рынке, значит, аргументы просты: когда мы нанимали Ивана, средняя стоимость специалистов его уровня на рынке была Х, сейчас, спустя 12 месяцев, Y, что примерно на 15% больше. Иван соответствует ожиданиям по результативности, уровню хард и софт скиллов, поэтому повышение оклада оправдано рыночной ситуацией.

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

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

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

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

Підсумок

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

Похожие статьи:
Нещодавно з’явилася інформація про нову ініціативу Мінцифри — Diia City. Це вільна економічна зона для креативного бізнесу. Наразі проєкт...
У випуску: Mozilla працює над розширенням наукового стеку в браузері, як працюють модулі, трішки WebAssembly, Python метакласи. Новини Roberto Rosario...
В выпуске: тренды, паттерны, микросервисы, оркестрация. Netflix, Stack Overflow, Mesos, Kubernetes, gRPC, Envoy! Давайте полезно проведем выходные! Если...
Всем привет! Меня зовут Виктор Антоненко, я Senior Unity-разработчик в Genesis, команда Obrio. И я действительно люблю игры. С юного...
Уже известно, что компания Samsung вскоре планирует выпуск большого планшета под названием Galaxy View. Модель получит экран с...
Яндекс.Метрика