«Кар’єрне зростання не означає успіх». Експерт з Engineering-лідерства — про вміння брати на себе відповідальність та принципи побудови карʼєри

У новому епізоді подкасту про Engineering-менеджмент Going Beyond Development ми занурилися в суть позиції Engineering Manager та дослідили, які особливості та виклики тут є.

У межах проєкту ми запрошуємо досвідчених Engineering-менеджерів з різних куточків світу. І цього разу поспілкувалися з Патом Куа — знавцем з Engineering-лідерства, колишнім СТО, який раніше був технічним консультантом у Thoughtworks і має досвід роботи головним науковим співробітником TIER і N26. У випуску Пат розповів, що мотивувало його перейти на позицію Engineering-менеджера і який вплив вона має.

👉🏼 Підписуйтесь на YouTube, щоб не пропустити нові інтерв’ю

«Engineering-менеджер — це людина, яка відповідає за результати роботи технічної команди». Про роль

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

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

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

Якщо відкрити вікіпедію і ввести там «Engineering Management», можна прочитати, що цей термін ввів у шістдесяті роки, здається, один з університетів США. Але чому ми досі не маємо єдиного визначення в нашій галузі? Вважаю, що однією з причин є те, що це все ще молода галузь, і у нас є багато людей, які постійно навчаються.

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

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

Є кілька відомих книг, як-от «Людський фактор» Тома ДеМарко і «Вальсуючи з ведмедями» Тімоті Лістера. Це класика, зокрема тут згадано про те, чому команди не можуть працювати швидше, а це поширене питання, з яким доводиться мати справу Engineering-менеджерам. Чимало описаних там проблем досі залишаються незмінними.

«П’ять архетипів Engineering-менеджерів». Про те, якими бувають Engineering-менеджери

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

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

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

Якщо взяти хорошого Tech Lead Engineering-менеджера, він має так само добре розуміти, як працює організація. Але він, ймовірно, не витрачатиме на це більшу частину свого часу, бо повинен бути заглибленим у практику. Можливо, це складна система, і Engineering-менеджери цих двох архетипів справді мають писати код, щоб управляти ризиками. Техлід проводитиме набагато більше часу як Individual Contributor. А тимлід, ймовірно, витратить на це мінімум часу, бо може покластися на когось іншого, щоб подбати про інші аспекти.

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

Четвертий архетип — Product Engineering-менеджер. Цю роль ми переважно бачимо у двох ситуаціях. Коли ви втратили продакт-менеджера, тобто Engineering-менеджер повинен заповнити цю прогалину, переконатися, що команда працює над важливими речами. Іноді правильним рішенням для цієї людини буде визнати, що команди самодостатні. Фахівець збирається працювати з усіма іншими стейкхолдерами та виконувати цю роль, поки, можливо, не знайдеться хтось більш постійний. Іноді він ще займається продакт-менеджментом, відповідає за планування, комунікацію, взаємодію зі стейкхолдерами, можливо, за маркетинг- чи PR-запуск продуктів.

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

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

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

«Лідерські навички є ключовим елементом для гарного Engineering-менеджера». Про риси, які потрібні Engineering-менеджеру

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

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

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

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

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

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

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

«Чимало людей вважають, що їм потрібно керувати окремими людьми, а насправді вони мають управляти системою». Про підводні камені в роботі

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

Наприклад, Engineering-менеджер має зробити так, щоб команда отримувала регулярний зворотний зв’язок. Багато Individual Contributor’ів можуть впродовж всієї кар’єри не мати потреби вдосконалювати навички надання та отримання ефективного фідбеку. А від Engineering-менеджера очікують, що він забезпечуватиме людей своєчасним зворотним зв’язком.

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

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

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

Коли я перейшов на керівну посаду, зрозумів, що, по-перше, братиму найменш цікаві завдання. Треба переконатися, що команда працює і всі проблеми вирішено. По-друге, ви можете досягти більшого з командою, оскільки ви не Individual Contributor, який має 24 години на добу, тут є команда. Отже, лідер стає своєрідним мультиплікатором. Він каже: гаразд, нам доведеться рухатись далі, і ми маємо створити більше речей за той самий час.

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

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

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

Ще одна думка: Engineering-менеджер, як і всі айтівці, має продовжувати навчатися та збирати більше інструментів для команди, які можна застосовувати зараз і в майбутньому.

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

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

CTO Honeycomb.io Чаріті Мейджорс говорить про маятник: Engineering-менеджер переходить до Individual Contributor і навпаки. Якщо ви бажаєте повернутися до IC, думаю, ви маєте знати основні принципи, які все ще діятимуть, а далі все залежить від практичних можливостей у компанії.

«Ви будете нести більшу відповідальність за більші результати». Про кар’єрне зростання

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

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

Коли я був керівником і зараз, коли тісно співпрацюю з багатьма СТО, вкрай важко мати правильний баланс між роботою та особистим життям. Реструктуризація, звільнення — деякі речі відбуваються дуже швидко, і ви — людина, яка це робить. Не всі готові мати справу з такими ситуаціями.

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

Коуч з менеджменту Лара Хоган говорить про створення і формування мережі підтримки. Engineering-менеджер у команді, але почувається досить самотньо, на відміну від того, коли він IC і може звернутися до когось, хто майже в такій самій ситуації, та поговорити. У Engineering-менеджера може так не вийти.

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

І ще — не забувайте про фідбек. Спробуйте зрозуміти, чи людина, з якою ви щойно розмовляли, почула і зрозуміла вас.

Пам’ятайте, що зміни, які ви впроваджуєте, не відбувається одразу. Це вимагає певного часу та повторень. Мені подобається принцип CRY (continually repeat yourself) — постійно нагадувати собі про важливі речі.

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

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

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

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

«Не відчуваю, що мені чогось бракує з ІС у кар’єрі». Про те, чого бракує з ІТ-минулого

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

Я часто працював з Data Science, але сам не робив цього. Мені пощастило мати досвід у консалтингу, бо мав нагоду займатися різними проєктами й у різних галузях. Я не відчуваю, що мені чогось бракує з досвіду Individual Contributor’а, бо багато чого навчився. Мені було дуже весело. Впевнений, що на цьому шляху я написав якийсь жахливий код. І мені шкода тих, хто змушений його зараз підтримувати. Однак ми працюємо і навчаємось водночас.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному1
LinkedIn



7 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

В розділі про архетипи десь загубився третій.

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

Вибачайте але якась ахінея з цим розвелась. Я розумію так по простому, по білогвардійські. Є технічний експерт який відповідає в команді за результат перед бізнесом, техлід це коли декілька команд, чи тім лід коли одна команда не важливо. Головне щоб для команди така людина одна, щоб не порушувати принцип єдино-начальства в так далі одина для програми і для портфелю і там вже один CTO. Там вже десь можуть бути сініори тобто старші розробники яким делегуються якась відповідальність і повноваження тощо. Є бізнес керівник — відповідальний за виконання бізнес, зокрема і фінансових цілей діяльності, така людина теж може бути лише одна. Якщо программа чи потфель — великі звісно існує певний рівень ієрархії із делегацією повноважень. Та от не задача — клієнти вимагають усих сініорів (що власне ідіотизм в професійній організації мають бути спеціалісти усіх рівнів, якщо команда з одних сініорів скоріше за усе в ній все все погано із процесами та все йде не туди, така контора не розвивається і системно не займається підвищенням кваліфікації власних співробітників та це неможливо пояснити народу який платить погодинно а не порезультатно) їм їх малюють синіорів з 23 літніх випускників та студентів. Там є такі сініори які по роботі «це не я — це код Васі» чи «я не буду писати юніт тести, мені треба закрити 8 пойнтів у цей спринт якщо писатиму тести то не встигну». Більш не меньше досвідченим виконавцям, це кому років так 26-27, через це надають різноманітні лиски як то Team Lead, Tech Lead і тому подібне, тобто щоб якось вирізняти, хоча в їх роботі нема ніякого leader ship як такого, вони виконавці і нічим не керують крім можливо менторінга пари джунів чи мідлів. А от лінійним менеджерам, у кого раніше і було в лисці написано — lead тобто керівник, тепер дають лиску менеджера, старший менеджер, сініор архітект і тому подібне. Що змінилось в роботі крім лиски — а нічого не змінилось, це усе старі добрі ліди команд, та прожект менеджери. Ще бувають сініори — це в кого якась під система, чи якийсь бізнес процесс і може ще один-два падавани, тобто під команда, відділення, взвод etc. Тут підтримую долину і Google які просто по вводили аля військові звання не прив’язані до посади. Software Engineer 2, Software Engineer 3, Senior Software Engineer, Staff Software Engineer, Senior Staff, Principal ... Fellow careerkarma.com/...​ngineering-salary-google и т.д. Там ніде не написано — lead, тільки показано, що лиска це рівень кваліфікації яка відповідає певній вилці зарплатні. P.S. Успіх в бізнесі вимірюється грошима і тим скільки зусиль знадобилось для їх отримання, усе іньше від лукавого.

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

Александр, был бы безмерно рад узнать определение понятию «успех», используя исчисляемые параметры.

Що таке успіх взагалі ? Це досягнення поставленої цілі, чи навіть перевершення її. А тут швидше мається на увазі скоріше американський шкільний термін, про «успішність» — тобто принципову перевагу над конкурентами чи опонентами. Скажімо Стів Джобс та Стів Возняк як і Білл Гейтс та Пол Алан були далеко не єдині хто займався темою персональних і мікро-комьютерів, та софту до них. Так само як Ларі Пейдж та Сергій Брін не єдині хто займався пошуковиками і рекламою в інтернет тощо. І так само Едісон, Форд, Рокфеллер, Морган тощо. Та саме вони із своїми ідеями і методами роботи стали лідерами ідей і ринків. те саме скажімо Лінус Торвальдс, який теж далеко не єдиний хто розробляв ядра ОС. Те саме: Кенеді, Ганді чи Шварцнегер, Тайсон брати Кличко тощо. Тобто термін який означає, що ти у своїй справі загально відомий експерт/чемпіон/лідер найкращій чи один із найкращих і на голову випередив конкурентів, на тебе рівняються наступні покоління вивчають твої методи і способи. Я десь навіть чув навіть шкільні уроки в молодшій школі (вважай дитячому садку) на тему «як стати зіркою» і малась на увазі «популярність в школі» o_O.

От тут дають, www.linkedin.com/...​ine-life-eugene-adu-wusu «attaining wealth, prosperity and/or fame» тобто досягнення заможності, процвітання або слави. І йдеться про старий добрий тріумф родом з Риму.

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