Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Бути гарним слухачем. Тренерка з Engineering-лідерства — про значення менеджменту, довіру в команді та звільнення

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

У межах проєкту ми запрошуємо досвідчених Engineering-менеджерів із різних куточків світу. І цього разу ми поспілкувалися з Лаурою Тако — тренеркою з Engineering-лідерства, яка працює з багатьма стартапами, а також з Engineering-менеджерами у Pfizer, GitHub і Apple та мала досвід роботи в таких компаніях, як Nova Credit, Codeship і CloudBees. У випуску Лаура поділилася, як стала Engineering-менеджеркою і чим важлива ця позиція.

Кожного другого тижня Лаура на своєму сайті випускає безплатний інформаційний бюлетень «Engineering-лідерство» із запитаннями, які отримує під час навчання або у ​​Twitter, щоб люди могли отримати користь від її тренерського досвіду.

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

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

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

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

Вони є засновниками або співзасновниками компанії — і ось опиняються на посаді СЕО. Їм потрібно найняти програмістів, а оскільки менеджментом вони ніколи раніше не займалися, потребують додаткової допомоги. У мене чимало таких клієнтів, а також інших, які переходять від Individual Contributor’а до менеджера, тому що хочуть бути примножувачем для інших людей, а не просто працювати над своєю роботою.

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

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

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

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

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

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

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

Іншою важливою здатністю є експериментальне мислення та розуміння помилок. Скажімо, у нас є гіпотеза, яка після перевірки виявилася помилковою або не підтвердилася. Це не обов’язково провал. Це — вдалий експеримент.

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

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

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

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

Менеджмент — це специфічна сфера, яка передбачає надання команді можливостей і допомоги виконувати роботу найкращим для неї чином. Ви дійсно маєте високо ставити потреби команди, іноді вище від своїх.

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

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

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

Але проджект- і делівері-менеджери — це значно спеціалізованіший тип управлінської ролі, ніж в Engineering-менеджера.

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

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

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

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

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

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

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

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

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

«Роль Engineering-менеджера полягає не в тому, щоб казати: «Агов, повертайся до роботи». Про те, що необхідно для формування довіри до Engineering-менеджера у віддаленій команді

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

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

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

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

Ви маєте круті маленькі штучки Lego, які можна поставити на фон свого відео. І це чудовий момент згуртування команди. Приємно поєднувати офлайн і онлайн, коли у вас є віддалена команда.

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

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

«Моя робота полягає в тому, щоб допомогти членам команди стати кращими». Про залученість/присутність менеджера в команді

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

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

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

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

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

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

«У підсумку це стає правильним вчинком для людей, які залишаються в команді». Про звільнення

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

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

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

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

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

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

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

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

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

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

Деякі люди йдуть у Engineering-менеджмент і думають: «Гаразд, це чудово». На наступній роботі я збираюся повернутися до IC. Для цього дуже важливо залишатися активним у відпрацюванні своїх технічних навичок. Але якщо ви прагнете посади директора чи віцепрезидента розробки, практичні знання програмування стають менш важливими, а на перший план виходять інші навички. Тож, можливо, немає сенсу витрачати стільки часу на те, щоб бути в курсі специфіки мови, і доцільніше зосередитися на архітектурі та загальних тенденціях.

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

Підписуйтесь на наш YouTube, щоб не пропускати нові випуски.

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

Схожі статті




4 коментарі

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

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

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

Лаура каже:

робота полягає в тому, щоб допомогти членам команди стати кращими

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

Продукт менеджерів з інженерії є ефективна розробка продуктів, насамперед. Тобто, як досягти неперевершених результатів за конкурентоспроможні кошти. Це все ще про «як то зробити», але на організаційному рівні, на рівні фреймворків та організаційних систем. Вдала робота на цьому рівні дає приріст ефективності до 35%. Для розуміння, краще спілкування команди розробки, на що переважно дивиться Лаура, дає до 14%. Тобто, ОК, якщо триндеть та єйчариити надає задоволення. Для професійних організацій то не є осяг, а лише частина обов’язків менеджера з інженерії.

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

Дяки за коментар.

Люди по-різному розуміють хто такий Engineering Manager та які задачі цього спеціаліста. Такий менеджер не є продуктовим менеджером. Лаура більшість свого часу працєю з продуктовими командами. Для розмаїття та повноти картинки треба пошукати Engineering Manager з великих сервісних компаній (наприклад, з Accenture). Дякую за таку думку.

В плані визначення задач та обовʼязків Engineering Manager — перший випуск подкасту їх досить добре висвітлює.

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

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

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

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

У разі розвитку ІТ-сектора так само. Якщо дивитися, на зріст долі ВВП та потребу у ефективності, як складову конкурентного змагання регіонів й бізнес моделей, то, по-перше, неминучий перехід від елітарних розробників ПО (математики, фізики з вченими званнями) у 1960х до плебсу (на фронтенді фізкультурники, що щойно зістрибнули з канату) у наші часи. Фізик-СхО мав змогу і розум робити багато речей. Фізкультурнику все одразу не вдається, потрібно фокусуватися на відокремленій кількості функцій. По-друге, на глибоке фахове розгалуження впливає ресурсна база, тобто розмір хоста (компанії). А ефективний розмір компанії залежить від її бізнес моделі.

Так от, на шкалі розміру хоста бізнес модель Accenture знаходиться поряд з аутсорсом. Погляд, звісно, буде трохи іншій, але не суттєво. Щоб здобути більш рафіновану ЕМ форму буде доречно звернутися до великих продуктових розробників ПО.

Дякую за те, що поділились досвідом. Корисна стаття.

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