Повна версія

🎧 Текстова версія войсчату «Як ІТ-спеціалісту стати менеджером (і для чого)»

Публікуємо текстову розшифровку войсчату про менеджмент в ІТ.

DOU Podcast · Менеджмент в ІТ — DOU voicechat

Спікери:
🔹 Олекс Майстренко, Head of Engineering в IntellectEU (більш відомий як співведучий подкастів DOU)
🔹 Сергій Пірогов, QA Manager в BlaBlaCar (також відомий як автор телеграм- каналу automation-remarks)
🔹 Богдан Кіт, Head of Product в Tumblr (почитайте його статті на DOU до речі)

— Розкажіть, як ви опинились на посадах, на яких ви зараз (6:10).

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

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

З цим усвідомленням почався правильний шлях в управлінні командою і менеджменті.=. Зараз у мене 150 людей, команда розподілена по всьому світу. Моя позиція наближена до engineering manager.

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

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

Ще в гуртожитку з друзями і сусідами по кімнаті ми створювали інтернет- магазини. Це був 2012 рік, e-commerce тільки починався в Україні.

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

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

Повернувшись в Україну, я шукав спосіб пробитись в індустрію. В мене горіли очі, але не було ні досвіду, ні знань. Я почав навчання, багато чого запускав сам, різні продукти. Ходив на багато зустрічей і івентів.

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

Ми заснували власну компанію і робили дотичне до того, з чим працює Олекс — створювали торговий софт для банків і компаній. Тоді криптовалюта переживала першу хвилю свого підняття. Нам не вдалось побудувати успішний продукт у В2В секторі, але вдалось продати технологію. Ми успішно продали бізнес. Після цього вирішили фокусуватись на інших проєктах. Певний час я працював в компанії Ring. Зараз працюю в компанії Thumblr.

Мало хто знає цю компанію в наших широтах, але це та компанія, яка стоїть за WordPress і є одним з найбільших контриб’юторів до опенсорсного фреймворку WordPress. Зараз я там займаю пост Head of Product. В моєму підпорядкуванні близько 10 людей, і вони можуть збільшитись в короткій перспективі. В основному, це інженери.

Моя роль — engineering manager і Head of Product усього продуктового напрямку, який стосується підписок на Thumblr — це для нас нова ніша, бізнес-можливість. Історично так склалось, що всі соцмережі монетизуються через рекламу, а ми хочемо перефокусувати бізнес відповідно до нових тенденцій на ринку. Хочемо деверсифікувати бізнес і мати два напрямки — один із підписок, а інший з реклами. Я займаюсь усім, що стосується підписок, продукту, інжинірингу.

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

Сергій: У мене шлях не такий цікавий, як у хлопців. Я був Junior, Middle, Senior, потім Lead, а потім знайомий покликав мене в компанію BlaBlaCar, де я став менеджером. До цього я ще працював архітектором та на інших посадах, але потім я зайняв цю позицію, на якій працюю зараз. Я, як і хлопці, ніколи не хотів (і в мене досі немає бажання) керувати армією людей, впливати на всіх. Особливо я не люблю тих менеджерів, які вважають: «Я тут начальник, а ви повинні мене слухати». В мене підхід інший. І я не працюю з такими людьми, якщо вони поводяться так. Не люблю слова «командувати».

— Чим ви займаєтесь? Які у вас обов’язки? Як виглядав ваш день на неменеджерських посадах, а як зараз? (17:45)

Сергій : Коли я був Junior, день був простий: ти приходиш, у тебе зранку якийсь стендап, далі задачі, Jira — береш і робиш. І так десь до Senior. А потім, коли ти Lead чи Manager, у тебе день уже «рваний». Ти інколи робиш всього багато, а наступного дня, коли в тебе стендап, нічого сказати. Зазвичай «я зробив цю таску, щось закомітив, зробив те і те ». З одним говорив, іншому допомагав.

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

Головне — зміна в сприйнятті, зміна майндсету: ти не обов’язково сам повинен все робити, як раніше. Головне, щоб твоя команда могла і знала, як це зробити.

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

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

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

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

Оскільки в нас в компанії дуже серйозна культура асинхронної комунікації, у нас дуже мало зустрічей і ми їх цінуємо.

— Які у вас KPI, показники ефективності роботи, хто і як їх визначає? (29:03)

Сергій: У нас є OKR (Objectives and Key Results), тобто цілі і ключові результати. Objectives встановлюються на пів року. І за цим вимірюється ефективність. У менеджера є Objective/ціль «щось зробити, когось навчити», а в людини є Objective, дотичний до цього. Тобто якщо людина через пів року досягла своїх цілей, то все добре, все йде за планом. Якщо ні, тоді з’ясовують, що не так, хто винен, що робити.

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

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

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

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

І останнє. Оскільки команда велика, то треба враховувати показники по ревенью, що треба реалізовувати в рамках команди. Коли ми отримали ряд проєктів, то мені потрібно їх реалізувати.

Отже, три основні показники:

1. Команда: стан, настрій, яким чином команда взаємодіє з компанією, сприймає компанію, бо, як-то кажуть, люди йдуть не з компанії, а від поганого менеджера. А це теж показник, наскільки якісно виконується його робота.
2. Зворотний зв’язок від клієнта.
3. Розмір компанії. Як ми надаємо сервіс і розвиваємось як компанія.

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

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

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

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

Вплив на бізнес і взаємодія з командою — це два моїх основних блоки.

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

— Розкажіть про найважливіші навички та вміння, щоб справлятися з роллю менеджера. (38:27)

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

А потім — комунікація: вчитися слухати. Слухати активно, прислухатися до людей, розуміти, де і чого не вистачає, де і що може бути не сказане. Мені подобається концепція Servant leadership — філософія лідерства, в якій метою лідера є служити. Є команда, і їй треба допомагати.

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

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

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

Богдан: Навички — цікава тема. Тут немає однозначної відповіді. Багато залежить від тієї ролі, яку людина хоче обійняти в майбутньому, як і куди прагне рухатись по кар’єрній драбині. Якщо це розробник, той найбільш очевидно, що далі лід, інжиніринг-менеджер, VP engineering чи CPO в майбутньому. Щоб потенційно вирости, необхідні знання технологій, орієнтація в стратегії, вміння бачити ситуацію наперед.

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

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

Але в цьому і проблема, що люди переоцінюють вагу hard skils в роботі менеджера. Успішність менеджера визначається soft-стороною, мистецькою, можна сказати, а не науковою.

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

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

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

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

Сергій: Хочу додати: багато інженерів не хочуть ставати менеджерами. Особливо після сеньйора, коли не знають, куди далі розвиватись. Але якщо ти інженер і можеш зробити 1-2 проєкти, то ставши менеджером, ти зможеш зробити 5-6 проєктів. І тоді знання набуваєш набагато швидше (я це з а собою помітив), бо працюєш в різних напрямах. Ти стаєш Helicopter View: може, технічно глибоко не все знаєш, але можеш розглядати ситуацію широко і комплексно. І це одна із причин, чому цікаво ставати менеджером. Можеш робити набагато більше речей за певний час.

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

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

В нашій компанії говорять, що Lead чи Manager — це не Promotion. У нас навіть зарплата від цього не залежить. Це роль, яку ти можеш обіймати, якщо тобі це подобається. Найкращим моментом є те, що коли людина обрала цю роль, а потім їй не сподобалося, вона може повернутись і бути інженером. Їй дозволять це зробити, без санкцій, зменшення зарплати. І це круто. Впевнений, так і повинно бути. Людина не повинна боятись пробувати щось і змінювати.

Олекс: Тут виходить ніби крок вбік: ти перестаєш виростати як технічний спеціаліст, шукаєш інший шлях розвитку (ми говоримо про інженірінг- менеджмент). Якщо говорити про проджект-менеджмент і подивитися на віджет оплати на ДОУ, то проджект-менеджер буде отримувати меншу оплату, ніж сеньйор- девелопер.

(питання від слухача): Турбує думка: менеджер має керувати 3-5 проєктами, щоб здобути різносторонній досвід. Вважаю, що це призводить до розфокусування. Далі часто лідами та менеджерами стають у 23-25 років, вони не мають великого досвіду та розвинених soft-skills для управління командою. І третє: має бути якийсь внутрішній поклик, розуміння, для чого потрібно вчитись керувати людьми (1:01:36).

Богдан : Про загальність правильно. У менеджера немає можливості вникнути глибоко в якісь задачі. Його функція в тому, щоб дати людям поле для діяльності та необхідну інформацію, задати тон і напрямок, окреслити проблему. І вже очікувати від своєї команди навіть відповідь на запитання «як». Логічно, що за 3-4 роки менеджерства програміст може втратити трохи хист до програмування, якщо у вільний час не буде ним займатись. Але ж це робиш свідомо, бо хочеш досягнути чогось іншого.

Фактор віку не головний, важлива наявність чи відсутність досвіду.

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

Сергій: А я скажу так: ми всі різні, віковий розвиток дуже різний. Якщо навіть взяти 15-річних, 20-річних, то в когось розвиток на 20, а в когось на 35. У великих компаніях є 23-річні сеньйори, 25-річні ліди, але тут є шкурний інтерес. Я, наприклад, після університету, маю ще зі школи хороші комунікаційні навички, ініціативний, у мене виходить добре координувати групу людей. І я бачу себе на цій позиції. Чому я не можу управляти? Мені байдуже на стереотипи, я стану менеджером і буду робити так, як розумію і як мені виходить — і набуватиму свій досвід.

Нещодавно я закінчив читати книжку «The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers». Там життя СЕО описується. Рекомендую почитати, кого цікавить, чим займаються менеджери високого рангу. Дуже цікаво про те, як людина в умовах невизначеності має приймати рішення. У менеджера щодня такі питання і задачі, на які немає відповіді в гуглі. Якщо ви інженер, то можна задати «Як на Java зробити щось?» — і отримаєте підказку, але ви не знайдете відповідь на питання «Як звільнити умовного Петра?». Тут потрібен досвід, своє сприйняття світу, інтуїція. У менеджера нема легких відповідей на складні запитання.

— Кому точно не треба бути менеджером, які можливі бар’єри? (1:19:58)

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

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

Сергій: Я слухав подкаст, в якому автор, хлопець з Кремнієвої долини, який працює в Google, робив інтерв’ю з дослідницею з Google. І спитав, як вона перейшла з інженера. Вона розповіла науковий факт, що у нашому мозку виробляються ферменти й відповідно, коли інженер пише код, мозок посилає сигнали, збуджує, ми отримуємо задоволення від роботи. Але з віком цих ферментів виробляється все менше. І саме тому з роками ти пишеш код, а тобі вже не так радісно, як, наприклад, у 19 років. Писав Hello world, воно компілилось і працювало. З одного боку, людина стає досвідченішою, а з іншого — організм вже так не працює, як раніше. Як стверджує героїня подкасту, згідно з науковими дослідженнями, починаючи з 37-38 років починають відбуватися зміни. До цього часу треба спланувати, чим займатися далі. Якщо набридне писати код чи вирішувати ці задачі.

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

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

— Де, крім менеджменту, можна розвиватися досвідченим IT-спеціалістам, що нового спробувати? Людина пише код, а їй набридло... (1:27:26)

Олекс: QA, BA, архітектор, Sales, продакт. Будь-яка роль в IT відкрита для IT-спеціалістів. Треба шукати, пробувати, наскільки добре вийде. У кожного буде по-різному.

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

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

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

Олекс: Комунікація може бути усна, письмова. Ті самі тікети на GitHub, в коментарях обговорити. Навіть в коментарях обговорення — без комунікації ніяк.

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

Богдан: Погоджуюсь теж: без комунікації ніяк. Будь-яка компанія — це солянка людей. І шукають teamplayer-ів, тобто людей, які вміють працювати в команді. Є така штука Hero Culture, це антипатерн до масштабування інженерних команд. Якщо у вас є людин-герой, геній, який все знає, але не може працювати в команді, вона не зможе ефективно досягати бізнес-результату. Жодній компанії така людина не потрібна, бо це не наука, та навіть і там вимагається співпраця з науковцями. Ми працюємо в бізнесі, а бізнес — це про команди.

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

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

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