Шлях до Head of QA: важкий вибір між IC та менеджером

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

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

Хвиля звільнень 2023–2024 років навчила нас чогось жорстокого: із мого досвіду компанії першими скорочують middle-менеджерів. Не тому, що вони погано працюють — часто навпаки. Вони побудували системи, які працюють добре, і через це виглядають «менш потрібними», коли бюджети ріжуть.

Мене не звільнили. Але я спостерігав, як це відбувається по всій індустрії. І це змусило мене серйозно переосмислити вибір, який я зробив вісім років тому.

Є питання, яке я хотів би, щоб мені хтось поставив до того, як я обрав менеджерський шлях. Не «Що потрібно компанії?» Не «Який наступний логічний крок?» Навіть не «У чому ти красава?»

Питання повинно було б бути: «Чого насправді хочеш ТИ?»

Якби я міг повернутися в минуле, сказав би собі в той період: «сиди на двох стільцях» настільки довго, наскільки це можливо — або йди в IC-трек глибше. Не тому, що менеджмент — це помилка, а тому, що я зрозумів дещо на власному досвіді: на сьогоднішньому ринку сильний Individual Contributor з глибокою технічною експертизою часто в більшій професійній безпеці, ніж сильний middle-менеджер.

Розкажу, як я це зрозумів — ставши саме тим A-player’ом, якого всі хотіли «клонувати», а потім усвідомивши, що це насправді означає.

Трохи про мене: я Дмитро Лук’янчук, Head of QA в Payments by Wix, де провів 8+ років, будуючи інфраструктуру якості для важкої пеймент-платформи, що обробляє мільярди платежів через 100+ payment service providers. Провів більше ста професійних інтерв’ю, менторив QA-інженерів від джуніора до сінйора, від автоматизаторів до девів, та будував automation frameworks з нуля в найскладніших доменах fintech.

Від першого дня до незамінності

Я прийшов у Payments by Wix у 2016 як перший QA engineer. Пʼятий член команди R&D. Продукт був ще на стадії A/B тесту, коли команда зрозуміла, що має бути хтось, хто відповідав би за якість.

До 2025 року Payments by Wix обробляв $12.5 мільярдів річного GMV. За фінансовими звітами Wix.com, Payments став одним із топ-2 джерел доходу для всієї компанії. Я був там з першого дня цієї подорожі.

Спочатку я відповідав за все — quality усього продукту from A till Z. Onboarding. Checkout. Settlement. Fraud detection. API. Web. Mobile. You name it. Ми інтегрувалися з усіма величезними payment service providers — спершу 10, потім 50, врешті понад 100 PSP на одній платформі. Stripe. Adyen. PayPal. PagSeguro. LeumiCard тощо. Якщо воно існувало — ми його інтегрували, або «воно» хотіло інтегруватися із нами. Також Пейменти були by default вибором будь-якої нової (та і старої також) вертикалі (бізнес-пропозиції) на платформі.

Я побудував automation framework з нуля, який забезпечив повноцінний швидкий CI/CD. Втілив shift-left методологію, що дозволяла рухатися швидко без компромісів з якістю. Мене знали як «того впертого» щодо quality metrics — і я носив це «імʼя» з гордістю.

«А тестувати Пейменти — це важко?» Ну такоє ...

Уяви 100+ PSP і лише один checkout flow. У кожного провайдера різні API, різні edge cases, різні failure modes, error codes, sandboxes, etc. Як це тестувати? Як покрити автоматизацією? Як гарантувати, що зміна для одного провайдера не зламає N інших, враховуючи back-end хеві архітектуру платформи?

В мене вийшло побудувати таку модель, яка працювала добре. І менеджмент це помітив.

Коли компанія росла — від 10 до 150 людей, від 5 інженерів в R&D до 80 — я став go-to person, коли розмова заходила про якість. Не тільки для своєї команди. По всій QA-організації Wix із 150 інженерів усі знали: якщо маєш питання, дотичні до платежів — йди до Діми, він або сам відповість, або буде точно знати, хто зможе за нього то зробити.

Тоді я почав чути від основних стейкхолдерів — VP of Product, Head of Company, Operations: «Нам треба якось клонувати Діму». Це звучало як лячний комплімент, звісно. Я був настільки цінним IC. Настільки незамінним. Настільки хорошим.

Пам’ятаю, як один чудовий менеджер відповів на моє пряме питання: «Як ти оцінюєш лідерів?» Він сказав: «Люди ростуть поряд з хорошим лідером».

Тоді дещо клікнуло. Компанія хотіла не просто щоб я залишався красавчиком у своїй справі. Вони хотіли, щоб я зрозумів, як створити більше таких, як я. Вони хотіли, щоб я масштабувався (як би дивно то не звучало).

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

Рік 3: роздоріжжя

Мій менеджер побачив це раніше за мене. Payments-платформа стрімко росла. Компанія масштабувалася від 30 до 50 людей. Разом із Head of R&D і Head of Ops ми побудували команду з 1 QA до 5 і зрозуміли, що прийшов час налаштовувати лідерство.

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

Коли повернувся, він виклав три варіанти:

1. Стати developer’ом — перейти в код.
2. Рости як IC — стати tech lead’ом, залишитися hands-on.
3. Стати менеджером — все про людей: growth, PDPs, making sure everything works smoothly.

Я обрав третій варіант, спираючись на дві причини: люди — це моя пристрасть, і компанії це було потрібно.

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

Я не знав, на що підписуюся. Думав, що розумію, що означає менеджмент. Помилявся майже в усьому. Ось що змінилося в день, коли я став менеджером.

Жорстока правда: провали твоєї команди — це твої провали

Коли ти IC, твоя цінність очевидна. Ти відповідаєш за домен чи інфру. Вирішуєш проблеми. Випускаєш якісну роботу. Люди це бачать. Ти це відчуваєш.

Коли стаєш менеджером, правила змінюються за одну ніч.

Є така приказка: «Успіхи твоїх людей — це твої успіхи. Фак*пи твоїх людей — це твої фак*пи.»

Звучить красиво. Читається добре. Але жити з цим — інша справа. Особливо коли відповідаєш за якість на платформі з $12.5 мільярдами.

Стрьомна сторона

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

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

Невидима сторона

Коли все йде добре? Твоя команда сяє. І так має бути. Це робота.

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

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

Ось парадокс менеджера: роби свою роботу занадто добре — і доведеш, що ти не потрібен.

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

Пастка делегування

Ми будували нову фічу. Я обожнював домен checkout у платежах — знав його зсередини і ззовні. Кожен edge case. Кожну точку інтеграції. Кожен спосіб, як воно може зламатися на 100+ payment providers. Це була найкритичніша, найскладніша, user-facing, integration-heavy частина платформи. Безцінні знання, які можна застосувати в будь-якій fintech-компанії.

Коли middle QA із моєї команди почав брати ownership над тестуванням checkout, я не міг втриматися. Постійно перевіряв його роботу. Ставив занадто багато питань. Занурювався в деталі, які мав відпустити. Він почав відсторонюватися. Я це відчував. Він думав, що я йому не довіряю. Ми йшли до справжнього конфлікту, бо мікро-менеджмент — то дно. Для усіх.

Я вчасно спіймав себе. Відкрився. Сказав йому правду: «Знаєш, зараз мені важко з цим. Я новачок у лідерстві. Звик знати все та робити усе сам, і зараз той час, коли я вчуся делегувати правильно. Іноді це вдається ...»

Ця розмова змінила все. Я перейшов від виконавця і контролера до помічника і експерта. Перестав QA-їти його роботу і почав підтримувати його зростання. Забив на IC.

Але довелось майже зруйнувати стосунки, щоб засвоїти цей урок. І це був не останній важкий урок про менеджмент.

Що б я сказав молодшому собі

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

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

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

Я побудував QA-функцію у Payments by Wix від 1 людини до 10. Допоміг масштабував R&D-організацію від 5 до 80. Став експертом з якості платежів не тільки для своєї команди, не тільки для своєї компанії, а по всій QA-організації (гільдії) зі 150 людей.

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

Якби міг повернутися, сказав би собі: «сиди на двох стільцях». Лиши собі частину унікальних технічних, або продуктових знань. Залишайся технічним. Не втрачай експертизу тільки тому, що ти став лідером або менеджером.

Я бачив лідерів, які роблять і те, і те. Вони розуміють ризик. Чітко комунікують, що важливо особисто їм, а не тільки що потрібно компанії. Вони знають: бути сильним IC з transferable skills часто безпечніше, ніж бути сильним middle-менеджером із company-specific експертизою — особливо в нестабільні часи.

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

Я засвоїв це через досвід. Ти можеш засвоїти це прямо зараз, до того, як обереш.

Що повертає нас до питання, яке я хотів би, щоб мені хтось поставив.

Справжнє питання

Не питай, що вони хочуть від тебе. Не питай, що потрібно компанії. Запитай себе: чого хочеш ТИ?

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

Якщо не визначиш це для себе — хтось інший визначить за тебе.

І хоч це складно, хоч це важко — ти маєш бути чітким щодо того, чого хочеш.

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

Один урок, який я хотів би знати раніше

Коли ти на IC-треку і люди тебе цінують — ти чуєш фідбек. Бачиш свій вплив. Знаєш свою цінність.

Але не можеш зупинятися в розвитку. Змінюйся або помри. Це реальність.

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

Тож якщо обираєш IC-шлях — будуй системи. Ділися знаннями. Документуй свою експертизу. Не ставай тим bottleneck, яким колись був як A-player.

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

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

Підсумок

Я досі менеджер. Не шкодую, що обрав людей. Люблю дивитися, як мої люди ростуть. Отримую задоволення, коли вони сяють (від джуніка до сіньйора, від manual QA до FrontEnd developera, від мідла до ліда), а я за лаштунками роблю це можливим.

Але тепер чітко бачу: IC-трек з глибокою технічною експертизою часто потрібніший, цінніший і безпечніший, ніж middle-менеджмент.

Не шкодую, що будував Payments by Wix. Але хотів би тримати свій технічний edge гострішим, поки це робив.

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

Тож перед тим як робити вибір, постав собі справжнє питання. Не що їм потрібно. Не що добре виглядає на папері. Чого насправді хочеш ТИ?

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

Ключові висновки

Для IC, які розглядають менеджмент:

• Твоя технічна експертиза — твоя страховка. Не втрачай її повністю.
• Менеджмент робить тебе відповідальним за результати, які не можеш контролювати напряму.
• Чудові менеджери можуть зробити себе «менш потрібними» — і компанії помічають це під час скорочень.
• Співвідношення реальне: 100 IC-ролей на кожну 1 менеджерську.

Для нових менеджерів:

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

Для всіх на роздоріжжі:

• Визнач, чого хочеш ТИ, перш ніж дозволити системі визначити це за тебе.
• У нестабільні часи глибока технічна експертиза з transferable skills дає більше безпеки.
• Ти не можеш масштабувати себе — але можеш обрати шлях до зросту.
• Розглянь можливість ділити час між обома треками (наприклад: 70 на 30), замість того, щоб з головою пірнати у менеджмент. Або цілься одразу вище в МоМ-и або Heads / VP.

Ринок винагороджує те, що важче замінити — переконайся, що це ти.

Фінальна думка

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

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

Це авторський переклад статті з мого блогу. Пишу на LukiLead.com про QA leadership, automation та реальні компроміси, про які ніхто не говорить, поки не стає запізно.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.