Софт скіли для технічного спеціаліста — це не просто nice to have. Це must to grow

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

Привіт! Мене звати Влад Мусаєлян, я Backend Engineer у компанії Headway Inc. Наразі працюю над розвитком Nibble — застосунка із короткими інтерактивними уроками, що допомагають всебічно розвиватися в різних сферах: від математики до мистецтва.

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

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

Що таке софт скіли та чому вони важливі

Cофт скіли (soft skills) або гнучкі навички — це набір нематеріальних навичок, що допомагають людям ефективно взаємодіяти одне з одним.

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

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

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

Важливо розуміти: софт скіли не замінюють технічну експертизу, а підсилюють її. Senior інженер стає Team Lead саме завдяки розвитку м’яких навичок. Але без сильної технічної бази софт скіли не принесуть очікуваного ефекту.

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

Ключові гнучкі навички та їх роль у професійному зростанні

За результатами опитування Business Name Generator, у якому брали участь понад 1000 співробітників, найціннішими софт скілами визнано:

Це лише п’ятірка лідерів. Також у рейтингу є уважність до деталей, гнучкість, креативність, вміння адаптуватися тощо.

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

Ефективна комунікація

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

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

Без чіткої комунікації навіть добре написаний код може не виконати свою функцію належним чином. Результат — згаяний час на пошук та виправлення проблеми.

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

Емпатія

Питання важливості емпатії в IT-сфері неодноразово розглядали у різноманітних дослідженнях — наприклад, такого, як провела компанія Ernst & Young. Його респонденти вважають, що взаємна емпатія між керівництвом та співробітниками призводить до низки позитивних змін, а саме: підвищення ефективності праці, покращення креативності та задоволеності роботою.

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

Це особливо помітно під час code review. Якщо дати фідбек сухо чи різко — колега може сприйняти це як критику особистості, а не коду. Натомість емпатія допомагає сформулювати фідбек так, щоб воно звучало конструктивно: не «Ти зробив неправильно», а «Можемо спробувати інший підхід, бо він зменшить складність функції». Такий підхід будує довіру і пришвидшує розвиток усієї команди.

Командна робота

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

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

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

Проактивність

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

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

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

Я мав змогу переконатися в цьому на власному досвіді. Саме завдяки проактивності мені раніше вдалося пройти відбір у Genesis School of Digital Business, де лише 1-3 % кандидатів отримують шанс приєднатися до спільноти.

Виклики та їх подолання

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

Small talks та networking. Для деяких інженерів знайомства на подіях чи small talk можуть здаватися виснажливими. Тут допомагає метод «малих кроків»: почати з короткої розмови з одним колегою, а не одразу з натовпом. З часом це переростає у звичку, яка відкриває нові можливості для співпраці.

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

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

До найголовнішого — як прокачати м’які навички по повній

Універсальних порад з розвитку софт скілів не існує, проте я поділюся підходами, які спрацювали для мене.

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

Короткий лайфхак. Якщо ви бачите групу людей, які стоять не щільним колом, а залишають відкритий простір, це, швидше за все, The Pac-Man Rule в дії. Тобто вони підсвідомо запрошують вас приєднатися до спілкування.

Це правило отримало назву завдяки популярній грі Pac-Man, де головний персонаж має форму кола з «відкушеним» шматком. Воно полягає у тому, що команда залишає вільне місце, щоб кожен охочий міг доєднатися до обговорення.

І тут не варто соромитися. Якщо бачите умовного Пакмана — скористайтеся можливістю!

Ходіть з колегами на каву. Чашка кави під час обідньої перерви — це не просто приємна пауза, а й чудова можливість поспілкуватися з колегами. В нас, наприклад, сформувалася ціла культура «кави з колегою», адже такі неформальні зустрічі допомагають ламати бар’єри, розвивати навички комунікації та підтримувати легку, природну розмову.

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

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

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

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

Особисто я знаходив менторів через платформи Projector та The Ways — і це було влучне рішення. Завдяки менторству я навчився чітко структурувати думки й лаконічно презентувати свої ідеї. Це одні з найцінніших навичок, які я виніс із цього досвіду.

Будьте активними. В компанії ми часто кажемо: «Сміливі завжди мають щастя». Не бійтеся ставити запитання, брати участь у дискусіях, пропонувати рішення та, найголовніше — помилятися. Адже іноді найцінніший досвід приходить саме через помилки.

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

Конкретні інструменти та техніки

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

📌 Для комунікації — техніка активного слухання

Це вміння не лише чути слова співрозмовника, а й віддзеркалювати його думки, уточнювати й перефразовувати. Наприклад, коли колега пояснює ідею, можна відповісти: «Правильно розумію, що ти пропонуєш...?». Такий підхід зменшує ризик непорозумінь і показує повагу до іншої людини.

📌 Для емпатії — user story mapping

Ця техніка використовується у продуктових командах для кращого розуміння потреб користувачів. Коли інженер залучається до створення user story map, він вчиться дивитися на продукт очима користувача, що формує емпатію та розширює контекст мислення.

📌 Для розвитку командності — shadowing

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

Практичні кейси для різних рівнів

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

Junior:

  • Як правильно ставити питання на code review, щоб воно було конкретним і зрозумілим.
  • Коли і як просити допомогу, не чекаючи, поки проблема стане блокером для всієї команди.

Middle:

  • Ведення технічних дискусій: уміння аргументувати свої ідеї та слухати альтернативні підходи.
  • Менторинг джуніорів: передавати знання так, щоб підтримати, а не відлякати.

Senior / Lead:

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

The last but not least — не забувайте за теорію

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

📚 «Ненасильницьке спілкування», Маршал Розенберг

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

📚 «Радикальна відвертість», Кім Скотт

Як бути чесним, не втрачаючи людяності? Авторка — топменеджерка Google, Apple і консультантка Dropbox — ділиться рецептом лідерства, побудованого на довірі й емпатії.

📚 «Thanks for the Feedback», Дуглас Стоун та Шейла Хін

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

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

Підіб’ємо підсумки. Софт скіли — ключ до успіху у світі технологій

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

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

День 1–10: спробуйте техніку «віддзеркалення» в діалогах — перефразовуйте, щоб переконатися, що правильно зрозуміли співрозмовника.
День 11–20: проведіть «shadowing» колеги з іншого департаменту. Це дає унікальний погляд на їхні задачі.
День 21–30: запитайте у трьох колег фідбек, як вони відчувають вашу взаємодію.

А щоб відслідковувати прогрес, тримайте короткий self-assessment чеклист:

  • Чи я намагався(лася) зрозуміти, чому колега мислить саме так?
  • Чи я запитував(ла) про потреби, а не лише про задачі?
  • Чи я помітив(ла), коли комусь було складно, і запропонував(ла) підтримку?

Сподіваюся, мій досвід був корисним, а наведені приклади надихнули вас на розвиток власних софт скілів. У Headway Inc ми щодня вчимося й ділимося досвідом — і саме ця культура допомогла мені рости як інженеру та людині. Працюючи над Nibble, я бачу, що наші рішення впливають на мільйони користувачів по всьому світу. І тут особливо помітно: без сильних софт скілів навіть найкращий код не стане продуктом, що змінює життя.

Якщо маєте власні інсайти чи виклики у розвитку м’яких навичок — буду радий почути й обговорити. Feel free to reach me out!

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Суперська стаття! Дуже дякую!

Дякую! До списку літератури ще можна додати «Емоційний інтелект» Деніела Ґоулмана.

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

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

Во-во-во! Оце ви якраз і зачепили ключове.
Воно то МАЄ БУТИ.
А по факту — не так, далеко не кожен його має. Бо воно, як виявилося, «само по собі» не формується.

А по факту — не так, далеко не кожен його має. Бо воно, як виявилося, «само по собі» не формується.

А галера его сформирует, да...
По факту есть два уровня социализации.
Первый это обычное умение вести себя в обществе. С соседями, с коллегами, с противоположным полом.
Второй — профессиональный, уровень актера, продавана и менеджера. Это умение находить контакт с кем угодно, часами ездить по ушам и выступать со сцены. Для такого уровня нужны не только навыки, но и определенный майндсет и темперамент. И вот такой уровень НЕ ОБЯЗАТЕЛЕН.

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

формуються самі по собі

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

Ще недавно вийшов блог Stop Avoiding Politics на схожу тему
terriblesoftware.org/...​1/stop-avoiding-politics

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

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

На жаль, гарна людина це не професія.

Всі софт скіли зводяться до того наскільки добре ти прогинаєшся під контору/замовника

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

По факту це і є «прогинання» — лідерство, якщо воно додатково не оплачується, а в не дружнє середовище не пішов би й навіть за гроші

Вибачай, це звідки такая аналогія, що «лідерство» це саме «прогинання»? Здивований.

Повторюю. Якщо за це не ПЛАТЯТЬ додатково.

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

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

Так, кеп. Але мова саме про те, щоб ці скіли розробляти в собі. А ти назвав це таким образливим словом як «прогинання».

А якщо ринок не бажає винагороджувати софт скіли додатково — не такі вони вже і скіли

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

в тобі немає скілів

І тут якраз з’являється оте протиріччя, про яке каже Андрій. Бо

ці скіли розробляти в собі

може бути для декого (залежно від індивідуального світосприйняття, хто як бачить цей світ)

образливим

, бо це є

«прогинання»

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

образливим

Виходить, практично вся наша кар’єра (впевнений, для більшості так) є

образливим

способом життя, бо ми би хотіли десь пивко/коктейль/смузі (виберіть по смаку) потягувати на Гаваях/Канарах/у селі на бекярді (виберіть по смаку), але оскільки ми ніщеброди за походженням, то доводиться демонструвати, або хоча би імітувати,

наскільки добре ти прогинаєшся

щоб керівництво оцінило ці старання і

щоб вибити собі підвищення зарплатні

«Як коучі коучать і книшка кише»
Десь щось таке може працювати якщо балакучого гіперактивного ХРа запхати в зграю колишніх студентів.

В реальності головний софт скіл — «don’t be jerk»..
А можна по іншому? Звісно можна!

Можете в команді домовитись про «альтернативну суспільним цінностям культуру» і вкрай продуктивно працювати під непристойні жарти

Може в вас бидло контора і бидло менеджер а інших варіантів нема

А може ви самі дитя совкового виховання криками і ременем і по іншому мотивувати не вмієте.

Реальність багатогранна штука, з часом помічаю певні патерни (ну або це маразм починається).
Наприклад — над командою «ванільних пухнастиків» майже завжди сидить нарцис-соціопат, десь на рівні директора, ВП.

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

Ооо, давно на доу не было «старожилов» с нормальными мозгами)))

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

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

Це вірно з точки зору _продажу_ сервіса. А з точки зору _надання_ сервісу, інженер спілкується з командою замовника та з самим замовником по своїх питаннях. Проксіювання (ховання) інженера перед замовником не є правильною практикою, скоріше, антипатерн.

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

І що, ці тези невірні?
(Щонайменше, іноді)

Дотепно, але в штангу.

Менеджменту нужны были бэкэндеры, которые могут немножко во фронтэнд, потом стали нужны фуллстэки, теперь — full software development life cycle чуваки. Интересно что будет дальше.

питання напевно відносно саме developer role в часи AI, тобто якою її бачать

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

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

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

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

Моя раціональна частина хоче погодитись з автором з приводу того, що soft skills підвищують шанси на кар’єрний успіх. Хотілося б щоб так дійсно було. Але мій досвід життя (в тому числі професійного) каже, що люди отримують не те, на що заслужили, а просто шо попало. Я б залюбки прочитав про здобутки автора (бажано вимірювані і нетривіальні), які стали можливими в тому числі завдяки soft skills.
Особисто бачив як люди, завдяки soft skills мігрували з middle в senior. Але мені здається, що soft skills не особливо допоможуть здійснити кар’єрний прорив на кшталт «з архітектора — в СТО».
Я ні в якому разі не знецінюю авторську думку, просто не хочу, щоб люди переоцінювали soft skills.

Багато великих компаній (Fortune 100 та Fortune 500) розглядають необхідний рівень софт-скілів як must’ve. Недостатньо бути чудовим програмістом або вчасно виконувати свої задачі. Треба вміти комунікувати з колегами та, при необхідності, проявляти інші якості, наприклад, лідерства, чи ораторство, чи вміння вирулити конфліктну ситуацію.

Якщо ці компанії можуть намалювати кар’єрну драбину аж до CTO/VP of engineering, чітко написати які навички потрібні для досягнення кожного рівня і будуть цього дотримуватись — я готовий навчитися і проявити будь-що. Але якщо ніякого росту немає, а від людини вимагають все більше і більше навичок — нам не по дорозі.

Дякую за статтю.

Headway з екосистеми Genesis, тож очікую, що має схожі болячки — потребу ходити в офіс та перепрацювання:

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

Підписатись на коментарі