Різниця у soft skills між рівнями Junior, Middle та Senior

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Всім привіт! Мене звати Оксана. Я керую командою аналітики в українській продуктовій компанії Jooble. В аналітиці я вже дев’ять років і за цей час мені доводилося працювати зі спеціалістами всіх рівнів від Intern/Trainee до C-level в багатьох напрямках та сферах.

Я багато часу проводжу в робочому нетворкінгу і досить часто отримую такі питання:

• А що мені вивчити, щоб від Trainee перейти до Junior? Киньте посилання.
• Скільки часу треба чекати, щоб стати Middle?
• Тимлід каже, що я Middle. Як йому довести, що п’ять років досвіду — це вже Senior?
• Працюю найдовше в команді, а керівником зробили зовсім нову людину! Хоча в неї менше досвіду в професії! Що за дурне рішення, я ж довше працюю аналітиком!

Ці питання крутяться навколо кількості років досвіду фахівця та його рівня сеньйорності.

Та чи завжди кількість років = певний рівень сеньйорності? Я впевнена, що ні, й час відходити від цих стереотипів.

Я, звичайно, розумію, чому люди хочуть отримувати вищі рівні — це напряму впливає на їхній дохід. А ще є цей момент, коли змінюєш в LinkedIn Middle на Senior в заголовку — 10 хвилин гордості за себе.

Загалом, підвищення позиції — це безкоштовна для компанії мотивація спеціаліста. До прикладу, якщо людина займає роль тимліда, а далі їй змінять позицію на Head of без зміни у зарплаті, то я впевнена, що сама зміна назви позиції дасть людині буст в мотивації! Тому визначати зростання за допомогою назв рівнів або позицій — непогана практика. Це ачівки, що підкреслюють результат власної роботи, яким можна пишатися.

Я маю понад п’ять років досвіду в менеджменті й в цій статті хотіла б поділитися власним, випрацьованим за цей час баченням трьох звичних нам в IT етапів розвитку професіоналів — Junior /Middle / Senior.

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

Чотири вершники сеньйорності

Я для себе виділяю чотири основних критерії для визначення рівня спеціаліста:

• відповідальність;
• рівень абстракції проблем, з якими спеціаліст працює автономно;
• калібр ініціативи відповідно до впливу на бізнес;
• технічні доменні навички.

Як ви можете помітити, про хард скіли тут лише один пункт, але він є і це 25%, що немало.

Проте почнемо з цікавішого.

№ 1. Відповідальність

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

Від Junior я очікую відповідальності на рівні його конкретної задачі

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

Наведу кілька прикладів з реального досвіду, де рівень відповідальності не був на Junior-рівні.

• Аналітик зробив помилку в коді і зламав дешборд. Коли я це помітила і ми почали розбиратися, виявилося що спеціаліст не знав, як виконати задачу. Тому він вирішив спробувати метод, який йому здавався найкращим з усього, що він придумав, хоча він розумів, що той не покриває всі потреби.

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

Але навіть на Junior-рівні людина має нести відповідальність за якість своєї роботи та ставити питання, коли має сумніви у власній спроможності її виконати. Перевіряти свої здогадки та псувати інструменти, якими користуються інші колеги — досить безвідповідально.

• Інший приклад: Junior-спеціаліст тиждень мовчав і в п’ятницю, день дедлайну, з’ясувалось, що у нього зовсім немає ідей, як виконувати задачу. Він кілька днів подумав і перемкнувся на менш пріоритетну задачу, яку знав як зробити. Те, що людина не звернулася раніше з питаннями, свідчить також про те, що вона не готова нести відповідальність за частину роботи, яку їй довірили.

Наведу також приклади, де повністю проглядається потрібний рівень відповідальності.

• Junior-спеціаліст насетапив зі своїм ментором 30 хвилин сінки кожні два дні, щоб показувати прогрес у важкій та новій для нього задачі та ставити питання, як тільки вони з’являються. Таким чином він виконав навіть мідловську задачу і до того ж вчасно. Це стало можливим, тому що людина вчасно зорієнтувалася, що їй потрібна допомога, і організувала цю допомогу!
• Або ж був кейс, коли людина прийшла до мене на зустріч і сказала, що не дуже впевнена у власній реалізації, розповіла, як вона перевірила свій варіант, і запитала, чи нічого не упустила. Виявилося, що спеціаліст все врахував, але така обережність в тому випадку була не зайвою, тому що зміна впливала на дані для роботи багатьох команд.

Відповідальності на Middle-рівні

Як для мене, Middle-спеціаліст уже працює на рівні потреб команд, а не конкретних задач. Тобто він може і сам сформувати власні задачі або навіть беклог з задач, розуміючи потреби своїх колег або суть ініціативи, з якою команда працює.

Коли до мене приходить мідл і каже: ой задача погано описана, чи можемо ми її не робити в такому випадку? Я відразу розумію, що відповідальність не на мідл-рівні.

Адже якщо Junior дійсно не завжди може зорієнтуватися, у кого варто уточнити умови і як саме, то мідл взагалі може мінімально базувати своє рішення на описі задачі, якщо воно не якісне. І відразу прояснювати контекст виникнення задачі у команди або у людини, яка її поставила.

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

Яскравий приклад такої роботи був в одній з кроскоманд, де я працювала. Ми збиралися на зустрічі та розбирали епіки, які потрібно команді реалізувати. Обирали шлях розв’язання проблем і накидували високорівневі задачі для кожного напрямку: дизайн від Івана, аналітика від Оксани, пропозиція по технічній реалізації від Інни.

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

Senior — це вже рівень відповідальності на рівні компанії

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

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

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

Негативним прикладом була ситуація, коли людині я довірила ресерч нової системи візуалізації. Ми домовилися про критерії, яким вона має відповідати.

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

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

Підсумовуючи, спеціаліст рівня

• Junior бере відповідальність на рівні задачі;
  
• Middle — на рівні команди;
• Senior — на рівні компанії.

Хочу тут додати поради, які мені допомогли розвивати цю компетенцію в собі та прокачувати її в інших спеціалістах:

1. Змиріться з тим, що той, хто щось робить — той буде помилятися. Помилок не уникнути, вас будуть за них сварити або не будуть, але готуйтеся морально. Я все ще засмучуюсь, коли щось не виходить, але період від «я поганий спеціаліст і все зламала, навіщо я це взагалі взяла» до «а як вирішити ситуацію, в якій ми опинилися» скоротився в рази.
2. Беріть проєкти «на виріст», завжди страшно брати щось більше ніж до цього, але інакше розвитку не буде. Пам’ятайте правило: цікаво vs страшно має бути 50 на 50.
3. Будьте чесними з собою та колегами: коли не справляєтесь, залишайте для себе можливість повідомити, що потрібна допомога. Тільки робіть це щойно ситуація стала погіршуватися, адже ваше зайве геройство може коштувати компанії грошей.

З відповідальністю зрозуміло, це дуже складно, але дуже потрібно.

№ 2. Рівень абстракції проблем, з якими працює спеціаліст

Тут все простіше.

Junior працює з конкретно локалізованою проблемою і з її описом уже на рівні дій

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

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

Middle — це рівень абстракції «ми маємо проблему і вона десь тут»

І уже мідл шукає, а що ж там не так, і вигадує план розв’язання проблеми. Але він знає приблизну проблемну зону та розуміє, з чим пов’язане питання.

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

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

Senior знаходить проблеми сам або ж вигадує покращення

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

У мене був кейс, коли я прийшла в команду і мені СМО сказав: «Оксана, зроби щось з продуктивністю команди аналітики, щось вона дуже повільно працює».

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

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

Кілька порад тут:

1. Вивчайте компанію, в якій працюєте, та вчіться розуміти бізнес. Компанія — це не дизайн, не аналітика і не код. Це інвестиції та їх окупності, тож потрібно знайомитися з іншими командами та їхніми задачами і складати максимально повну картинку. Я люблю «напрошуватися» на мітинги інших команд, щоб розуміти їхній контекст та розширювати своє розуміння того, як працює компанія.
2. В рамках компанії змінюйте команди або напрямки. Це додасть експертизи. В моїх командах я практикую перехід аналітиків між департаментами, рік в Aquisition, рік в B2B, потім участь в Продукті.
3. Не бійтеся спілкуватися з C-рівнем або з лідерами напрямків. Ставте питання, прояснюйте незрозуміле. Люди зазвичай відкриті та готові допомогти розібратися людині в бізнес-контексті, адже це забустить її спроможність розв’язувати складні задачі. Я люблю збирати питання і потім запрошувати спеціаліста на зустріч, де намагаюся з’ясувати на них відповіді.

№ 3. Калібр ініціативи відповідно до впливу на бізнес

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

Ініціатива на рівні Junior — це пропозиції відносно невеликих покращень в рамках своєї конкретної роботи

Тобто людина пропонує те, що зробить її життя на роботі легшим. Це вже дуже круто.

Колись дуже давно я працювала в компанії, де моя робота здебільшого складалася з щоденного заповнення певних звітів. Це було не цікаво і рутинно. Я запропонувала ідею, яка після реалізації вивільнила 30% мого часу. Звичайно, +30% часу джуна — це не game changer для компанії, але ця оптимізація була на рівні доступного мені горизонту.

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

Middle-спеціаліст має пропонувати ідеї, які повпливають не лише на його роботу

Це може бути також оптимізація, але яка вивільнить 30% часу всієї команди. Коли людина вже має досвід та розуміння бізнесу, насправді таких ідей можна запропонувати не мало. Тут важливо не полінитися та ескалювати їх.

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

Senior має пропонувати такі зміни, які впливають на роботу багатьох команд

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

Ніхто не просив цю людину займатися таким ресерчем, але він побачив можливість і запропонував її використати. Це змінило підхід до експериментів для 100+ людей в компанії! Важливо, що на рівні сініор я очікую якісно пропрацьовану ідею, не лише підсвітку проблеми.

Абсолютно інший кейс: я прийшла в компанію як консультант, де мені хвалилися суперкомандою Senior-аналітиків. А коли я запитала, чому досить багато речей працюють абсолютно не сучасно і не оптимізовано, мені відповіли — так було ще до того, як ми пришли.

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

Як розвивати ініціативність

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

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

Тому головна тут порада: пропонуйте свої ідеї, спілкуйтеся з колегами в рамках компанії та поза нею, ніколи не обмежуйте пропозиції власною доменною областю.

№ 4. Коротко — про технічні навички

Junior — на середньому рівні володіє основним набором технічних навичок для виконання задач. Переймає досвід у колег, час від часу виконує роль менті та вчиться і ще раз вчиться! З кожної спеціальності тут свій набір інструментів та рівень володіння ними.

Middle — має високий рівень технічних навичок, достатній для виконання всіх задач в доменній області. Навчає нових спеціалістів рівня Middle та є ментором для Juniors.

Senior — є експертом у своїй сфері, може бути лідером напрямку та обирати найкращі та найбільш актуальні для бізнесу рішення. Senior створює задачі для себе або ж навіть для своїх колег Junior/Middle-рівня.

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

Мені здається, в епоху ШІ ми маємо швидко відходити від оцінки людей за hard skills, тому що їх замінити найпростіше, і маємо стимулювати спеціалістів розвиватися з бізнесовим та проактивним мисленням. Саме це замінити або ж зробити краще за людину ще буде досить довгий час нікому.

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

Щоб ви ще сюди порадили додати? Чи використовуєте схожі підходи? Досить неоднозначна тема, буде цікаво почитати думки.