П’ять речей, які повинен знати майбутній інжиніринг-менеджер

Вітаю! Мене звати Вадим Поспєлов, я співпрацюю із компанією Uklon та виконую роль Engineering Manager вже понад рік.

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

Якщо говорити про досвід в нашій компанії, то роль EM сформувалась природно у результаті динамічного росту у певний період і потреби планового скейлінгу IT-департаменту. Крім формально сформованих обов’язків (delivery management, people management, processes improvements etc.), людина на цій ролі закриває широкий спектр завдань, який залежить від конкретно поставлених бізнес-цілей.

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

Про те, як це робити, і не тільки ми говорили з колегами Іваном Пашком з Preply та Володимиром Лисюком з Grammarly на мітапі «Engineering manager: balancing people, technology and product».

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

Але спочатку — хто такий інжиніринг-менеджер в нашій команді

Структура компанії поділяється на бізнесову і технічну вертикаль. Тому основа основ роботи Engineering Manager — партнерська робота на результат разом з Product Owner, технічними лідами, архітекторами й звісно командами. Якщо говорити стисло, то EM відповідає за питання «Як ми розробляємо?» та «Коли буде зроблено?». А також має фокусуватись на пошуку оптимального шляху для досягнення цілей розробки й організувати ефективну взаємодію між своєю та іншими командами розробки.

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

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

То що ж має знати інжиніринг-менеджер перед тим, як братися до обов’язків?

По-перше, корисно знати з чим працюєш, хоча б базово

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

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

По-друге, важливо не втрачати фокус обов’язків

Як я вже казав, головне завдання інжиніринг-менеджера — координувати та зв’язувати процеси, щоби усі ініціативи вчасно «деліверилися». Перед тим, хто має намір зростати в EM-напрямку часто виникає питання: «Чи зможу я далі кодити у цій ролі?»

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

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

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

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

По-третє, необхідно мати підходи до співробітників

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

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

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

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

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

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

По-п’яте, не зламайте те, що вже добре працює

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

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

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

Що можна порадити тим, хто поставив собі за мету рости в сторону EM

Якщо в мене запитують поради, робити чи не робити і як робити, в 90% випадків моя відповідь буде: «треба пробувати». Тут так само: не спробуєш — не зрозумієш. Але інше питання: як спробувати?

В мене навіть був кейс, коли інженер підходив до мене і ставив питання: «Я хочу спробувати, але що буде, коли в мене не вийде, або мені просто не зайде? Хто це все буде розгрібати?» І ці страхи та питання цілком зрозумілі, у випадку EM — це в першу чергу про менеджмент людей. Це не Git, де можна зробити реверт і швиденько передеплоїти робочий стан репозиторію. Так, трохи боляче, але не критично.

Ціна помилки в менеджменті — досить значна. Є приказка: «Люди приходять в компанію, а йдуть від менеджера». Звісно, вона досить умовна, але в ній є і цілком здоровий глузд. І давайте відверто: скільки з нас, технарів, вчилися на менеджерів чи хоча б був курс в універі? В мене, до речі, був, але сенсу з того, мʼяко кажучи, — 0. Так може треба спочатку піти на MBA? Так, можна, але знову ж таки — а як не зайде? Та й вічну відмазку «немає часу» ніхто не скасовував.

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

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

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

Мотивація

Треба хоча б спробувати зрозуміти свою реальну мотивацію. Розумію, що для декого це досить складно зробити. Але важко тоді, коли мало інформації. Зберіть максимум, до чого зможете дотягнутися: знову ж таки, люди в поточній компанії, книжки, подкасти, статті на DOU ;). Зберіть максимум і порефлексуйте, бажано, на свіжу голову у відпустці. Якщо питання в маткомпенсації, то повірте, цього недостатньо, бо можна заробити ± так само і на інших посадах IT, але питання, де ви будете отримувати задоволення від роботи, адже цього не купити.

Якщо ділитись власним досвідом, то мені пощастило спробувати багато різних речей на посаді Location Manager в невеликій аутсорс-компанії. Довелося бути й тимлідом, і керівником офісу, і керувати операційкою, і бути керівником юридичної особи, планувати бюджети й, звісно EM, але все це було дуже розмазано. І для мене було справжнім викликом виділити з цього всього спектру те, що саме мене драйвить. Що я зробив — пішов від зворотного: я відкинув все, що мені не заходило, зібрав все, що залишилось і знайшов на ринку IT-посаду, яка це б все обʼєднувала. Так і з’явилось моє CV на посаду EM :).

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

А що по технічному бекграунду? Для мене тут все просто — він в мене є і це мені дуже допомагає в розумінні (хоч в якісь прийнятні мірі) того, що відбувається в моїх командах в технічному плані. Допомагає в спілкуванні з бізнесом. Допомагає будувати девплани моїм тиммейтам. Зміг би я працювати на цій посаді без техбекграунду — сказати важко, бо не пробував. Але є на ринку випадки, коли EM обходяться і без цього. Знову ж таки — як і писав вище — «it depends».

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

Словом, пробуйте!