Вітаю! Я — Валентин Полонуєр, Head of TechOps у компанії HOSTiQ. Сьогодні я хочу поділитися власним досвідом управління технічними командами, виділити деякі складнощі та практичні поради, що можуть стати у пригоді тим, хто планує професійне зростання та прагне підвищити свій рівень у команді.
Шлях до позиції керівника відділу: чи збіглися очікування й реальність?
Свій шлях до керівника технічного відділу я починав із двох років роботи в ролі Customer Support Specialist. Згодом у нас, у відділі підтримки, розпочалась ініціатива з розподілу команди на рівні L2, L3 і CS. Так я спочатку став L2 — це спеціалісти служби підтримки, які мали бажання й могли допомогти клієнтам саме в технічних задачах. Згодом уже отримав підвищення до L3, і, відповідно, перейшов у технічний відділ. Багато часу пропрацювавши в ролі L3, одного разу отримав пропозицію від хеда технічної команди перейти на посаду менеджера TechOps-відділу.
На той момент це було дуже вчасно для мене, оскільки тривалий час я не отримував якихось технічно цікавих і складних завдань, мені було нудно на своїй позиції. Тому вирішив, що менеджерська роль може бути цікавою.
Я мав рацію, принципово нових завдань стало набагато більше. І серед них people management, який дається мені легко, бо я знаю свою команду, і маю в ній певний авторитет. А ось організаційні питання, написання звітів — для мене дуже непроста частина роботи. З одного боку, тому, що я звик раніше отримувати task і працювати над одним завданням, не відволікаючись на інші справи. А тут багато різних маленьких завдань, які я не можу нікому делегувати, це саме менеджерська робота. І по-друге, досить важко структурувати ці задачі.
На цей час до зони моєї відповідальності входить розвиток відділу, отримання високорівневих задач від бізнесу, узгодження планів вирішення цих завдань, подальша сегментація на окремі таски й розподіл таких тасків на команду, доведення співробітникам очікувань від тієї чи іншої задачі. Моя команда зараз складається з десяти людей: п’ять спеціалістів рівня L2, п’ять — L3, і я. Отже, я зараз займаюся організаційною роботою, майже не залучений безпосередньо до технічної роботи. Це дуже сумно для мене. Я відчуваю, як із часом втрачаю свої технічні навички просто тому, що не користуюся ними зараз.
Як ми вигадали розподіл на L2 і L3 — що це і як працює така структура?
Коли я тільки почав працювати у відділі Customer Support, у нас був поділ на «техів» — технічних спеціалістів, і «цеесів» (від Customer Support, скорочено — CS) — працівників служби підтримки клієнтів.
Згодом наші «цееси» почали цікавитися виконанням простих технічних завдань і всіляко лобіювали делегування їм саме таких обов’язків. Оскільки робочий час «теха» коштував дорожче, для компанії це було вигідно — віддати прості технічні таски на відділ підтримки, вивільнивши більше часу «техів» для розв’язання складніших задач.
Отже, L — це level. Кожна компанія затверджує всередині себе власну зручну структуру служби підтримки клієнтів. Але загально заведена така градація:
- L1 — фактично наш Customer support, що займається підтримкою клієнтів, надає послуги sales, billing і подібні задачі,
- L2 — технічна підтримка, низькорівневий технічний саппорт,
- L3 — інфраструктурні завдання.
Цей розподіл у нас у компанії було запроваджено з метою звільнити L3 необхідності мати будь-який контакт із клієнтом і залишити таким спеціалістам лише моніторинг серверів і виконання інфраструктурної роботи. Вивільнити час, позбутися відволікальних чинників. Тому L2 повинні були забрати на себе більшість клієнтських запитів, щоби збільшити кількість часу технічних спеціалістів.
На практиці в нас зараз недостатньо спеціалістів рівня L2, й іноді L3, який на зміні, працює як shift-lead. Тобто він розподіляє роботу по зміні, займається моніторингом, навіть іноді спілкується з клієнтами. В ідеальному світі кількість людей рівня L2 має вдвічі перевищувати L3, щоби повністю звільнити L3 від спілкування з клієнтами.
Але тут дуже важкий момент: якщо L2 не беруть участі в більш складних і цікавих задачах, їхня робота стає рутинною, вони постійно займаються одним і тим самим, це збільшує плинність кадрів у відділі, бо їм стає нудно і вони звільняються, нові приходять. Тому, щоб якось підтримувати інтерес і не ламати команду, потрібно залучати L2 до інфраструктурної роботи, що теж досить непогано себе показало. Люди отримують задачі, які їм нові й цікаві, відрізняються від їхньої щоденної роботи, тому якийсь позитив від цього є.
Подібний розподіл на рівні L2 і L3 буде актуальним для багатьох компаній. Але потрібно брати до уваги специфіку діяльності. Наприклад, ми як хостингова компанія насамперед орієнтуємося на саппорт — це наша фішка, що найсильніше відрізняє від конкурентів. Нам потрібно витрачати дуже багато ресурсів на підтримання підтримки на високому рівні. У такому випадку потрібен фокус на L2 саме тому, що вони взаємодіють із клієнтами насамперед як частина технології.
А якщо це, наприклад, компанія, яка продає хмару й не має окремої саппорт-команди взагалі, а лише надає клієнтам ресурси для користування, то там, звичайно, варто робити фокус на L3, тому що такій компанії не потрібно розв’язувати дрібні або рутинні питання клієнтів по більшій частині. Там насамперед є необхідність розвивати та підтримувати в актуальному стані свою інфраструктуру.
Сюрпризи в процесі пошуку людей і як їх уникнути
Я вже казав раніше, що залучення спеціалістів L2 до виконання інфраструктурних завдань L3 має свої переваги та недоліки. Найголовніше, що люди мають можливість зростати професійно, виконувати складніші завдання, що врізноманітнюють уже знайому рутину. З іншого боку, такі спеціалісти стають більш кваліфікованими. Це означає, що їм потрібно платити більшу зарплату, переводити на рівень L3. Інакше є ризик втрати кваліфікованого працівника. Маємо таке замкнене коло:
- ти хочеш покращити рівень своїх працівників L2
- відправляєш їх на навчання до L3
- вони стають overskilled для своєї посади та йдуть в іншу компанію, бо твоя потреба в спеціалістах L2 нікуди не зникла.
Питання пошуку нових людей у команду — мій найбільший біль.
Цей процес потребує дуже багато часу й високої залученості. Пошук кандидатів — це величезний шматок роботи, у той час, як інші робочі задачі нікуди не зникають. Я завжди відчуваю стрес у цьому процесі.
Потрібно бути залученим у наступні етапи:
- надати рекрутерам список вимог до кандидата, якого ми шукаємо в команду, актуалізувати критерії пошуку. За можливості — показати їм приклади резюме тих людей, які вже працюють у відділі;
- за потреби — створити та відправити рекрутерам тестове технічне завдання для кандидатів;
- переглянути ті CV, які нам надсилають рекрутери в процесі пошуку. Зазвичай я ще можу обговорити ці резюме з лідерами команд, щоби вирішити, чи запрошувати кандидата на співбесіду;
- безпосередньо співбесіда;
- якщо людина нам підходить, далі ми запрошуємо її на випробувальний термін, під час якого відбувається навчання та менторинг людини, пояснюються всі нюанси роботи компанії загалом і відділу безпосередньо, щоб у результаті ми отримали саме того співробітника, який нам потрібен.
На жаль, на моїй практиці було багато випадків, коли на співбесіду приходить кандидат, який узагалі не відповідає тому, що він написав у CV. Відверто набрехав у резюме й на технічні питання зовсім не може дати відповідь. Був випадок, коли ми взяли людину на випробувальний термін, але вона взагалі не хотіла навчатися й вдаватися в специфіку роботи. З такими кандидатами ми прощаємось, бо шанс отримати того, хто потрібен у команді, мінімальний.
Тому необхідно створити дуже гарний фільтр як для рекрутерів (критерії пошуку), так і для себе — за допомогою внутрішнього тесту на посаду.
Комунікація в команді: як створити таку атмосферу, коли кожен відчуває себе потрібним?
Оскільки я маю певний авторитет у команді та пропрацював тут досить довго, мені вдалося побудувати систему стосунків у відділі, за якої я не відірваний від процесів усередині команди, а постійно спілкуюся з людьми.
Для співробітників важливо знати, що компанія їх цінує, що на них звертають увагу, що вони мають чіткі задачі та розуміють, що менеджер від них хоче отримати. Саме тому я збільшив кількість особистих зідзвонів із кожним членом команди — практика 1:1. Поки що ми зустрічаємося раз на місяць. На таких мітингах я озвучую результати QA — quality assurance, результати тайм-трекінгу, а також збираю фідбек від кожного з працівників щодо їхнього відчуття роботи в колективі: чи комфортно, чи є якісь пропозиції щодо технічного покращення роботи. Це дає мені змогу вчасно реагувати на зміни психологічного клімату в колективі. Якщо я протягом певного проміжку часу отримую негативний фідбек щодо конкретної людини, я одразу можу оперативно подумати, чи є потреба поговорити з працівником, які тренінги йому призначити, щоб підтягнути його рівень до рівня всієї команди, щоб більше не було негативного фідбеку.
Такі зустрічі потрібні й мені також. Саме для того, щоб кожен у команді відчував себе цінним для компанії та менеджменту й не шукав нового роботодавця.
Балансування високопріоритетних завдань — як встигати
Викликом для мене виявилось балансування технічних та адміністративних задач, їхня пріоритезація та якісне виконання.
Фактично технічні й організаційні завдання, як паралельні лінії в рекламі Zanussi, не перетинаються, їх не можна порівнювати. Якщо в тебе є технічна пріоритетна задача, то вона має свій план, конкретні кроки, які потрібно зробити, щоб розв’язувати це питання. Тобто її можна взяти та виконувати. Навіть якщо необхідно додатково обговорити з командою, зібрати ідеї — ти вже маєш знайомі інструменти.
А коли я отримую якусь високорівневу, пріоритетну задачу від бізнесу, її спочатку треба обговорити, поставити купу запитань додаткових, щоби зрозуміти специфіку. Тут недостатньо мого інструментарію, часто необхідно більше вхідних даних, щоби взагалі довести цю бізнес-задачу до технічного рівня.
Тому, коли мені критично бракує часу, я делегую всі технічні завдання на відділ, а сам займаюся адміністративною роботою. Спочатку ось це делегування команді давалося дуже складно. Завжди є така дилема: я зроблю це краще, ніж хтось. Але я так думав рівно до одного моменту.
На старті мого менеджерського шляху у відділі мені надійшло технічне завдання, яке я почав швидко виконувати. Але десь наполовину написану таску довелося делегувати команді, бо далі надходили ще більш пріоритетні адміністративні задачі, що потребували моєї залученості. І яким же було моє здивування, коли я побачив, що хлопці виконали ту таску набагато краще, ніж той підхід, що я обрав спочатку.
Ця ситуація допомогла мені зрозуміти, що буває навпаки. Можна і треба довіряти команді, бо вони висококваліфіковані співробітники. Фактично я кожного з них наймав, тому нема чого переживати.
Ще один виклик для мене — це підтримувати свої технічні знання на гідному рівні, бути в курсі актуальних технологій або конфігурацій. Мені не вистачає часу на навчання, я роблю це у вільний від роботи час. Фактично зараз я можу бути залучений до технічної роботи лише у випадках форс-мажорів, наприклад, коли щось «впало» вночі або DDoS якийсь. Я відчуваю, як рівень моєї майстерності падає, і це дуже сумно.
Але досі не було ситуації, коли я не зміг допомогти комусь із команди. До мене приходять за консультацією, я завжди знаходжу рішення. Отже, знання ще не втрачено.
Моя найбільша мрія — це делегувати комусь адміністративну роботу й більше займатися технічними питаннями. Мені такого роду завдань бракує зараз. Але я розумію, що адміністративка дуже важлива для бізнесу. На основі моїх звітів, графіків ефективності команди, ефективності витрачання робочого часу, бізнес ухвалює рішення щодо подальшої стратегії розвитку компанії.
Поради для менеджерів технічних команд
- Нульова, базова порада — не сприймати робочі ситуації близько до серця. Якщо певні моменти переносити на себе, то надовго тебе ментально не вистачить. Коли ти як менеджер зробив кроки назустріч розв’язання проблеми з певним співробітником, але з того боку у відповідь — тиша й небажання тебе почути, то навіщо відчувати провину в таких ситуаціях?
- Також із серії банальних порад. Якщо плануєш стати менеджером у команді — будь готовий до того, що доведеться дуже багато писати. І необхідно знати Excel. Це база. Писати потрібно банально з метою не забути щось важливе, не проґавити суттєві деталі щодо задач. А знання таблиць допоможе в найрізноманітніших організаційних питаннях: від створення робочого розкладу команди на наступний місяць до більш вагомих звітів з адміністративної роботи команди.
- Для створення атмосфери довіри та взаємопідтримки в команді менеджер повинен мати авторитет у колективі. Класно, якщо він якісно володіє технічною частиною роботи й розуміє на практиці, чим займається кожен із його команди, які задачі виконує. У такому випадку до менеджера будуть звертатися за порадою, обговорювати шляхи вирішення завдань, пропонувати власні ідеї покращення роботи. Сформується атмосфера довіри в колективі.
- Але необов’язково мати авторитет лише в технічній частині. Можна бути класним адміністратором і майстерно керувати командою, робити декомпозицію великих задач на менші, розподіляти їх між працівниками. Або просто влучно та зрозуміло створювати описи виконання тих чи інших тасків. Авторитет керівника базується на різних складових.
- Потрібно багато спілкуватися зі своєю командою, тримати руку на пульсі, відчувати найменші зміни у психологічній атмосфері відділу й оперативно приймати рішення для покращення ситуації.
- Також для кожного працівника з колективу важливо бути почутим, мати можливість впливу на те, що відбувається. Тому менеджер повинен як адекватно сприймати фідбек щодо членів команди, так і бути готовим почути пропозиції щодо зміни підходів у роботі, або вирішенні тієї чи іншої задачі. Коли є діалог і відкрите ставлення до нових ідей, це буде позитивно впливати як на розвиток команди, так і на розвиток керівника відділу. Взаємовигідна штука.
Ну і наостанок — гумор. Гумор рятує завжди. Зміна без жартів — погана зміна. Багато хто в команді обожнює мануали, написані мною, бо я там часто жартую. Тому моя фінальна порада — завжди потрібен гумор у складній ситуації. Треба шукати якусь іронію в житті.