Мені було всього 24 роки, а моїй кар’єрі розробника – всього три. Життя було прекрасне. Я жив в маленькій квартирці в Бостоні. У мене була відмінна робота в технологічному стартапі під назвою «CloudLock». Я писав код по 12-14 годин на день. Часом я забував про час, і начальникам доводилося буквально випихати мене додому. У вільний час я грав в спортивні ігри з друзями або спав. І нічого мене не турбувало. Але тут вдарив грім.
Одного разу мій бос, наш віцепрезидент по розробці, відвів мене в бык. Він розповів, що наша команда дуже швидко зростає. А коли більш як 15 розробників з усіх питань звертаються до нього особисто, це вже складно. Нам були потрібні тімліди, щоб ми могли масштабувати свою організаційну структуру і щоб кожен розробник отримував належну увагу. Чи буде мені це цікаво?
Не буду брехати: хоча я був здивований, але про подібне замислювався і раніше.
«CloudLock» був другою моєю компанією після коледжу. Спочатку я працював в «Nuance Communications». І коли мій бос пішов на два тижні у відпустку, я мав шанс побути лідером команди. За ці два тижні у мене розширилася мережа знайомств в компанії. Дзвінки клієнтів надходили в першу чергу до мене. Я мав можливість відчути, як це: відповідати не тільки за свій код. Було дуже цікаво, і навіть начебто добре виходило!
Цей досвід я і пригадав в той день, коли Майкл заговорив зі мною про підвищення. Мені хотілося погодитися, але у мене був мільйон питань. Не пам’ятаю вже, що саме я сказав, але Майкл запевнив мене, що я впораюся, а він мені допоможе. Майкл – відмінний хлопець, я довіряю йому і поважаю його. Тому його слова були саме тим, що мені потрібно було почути.
5 кроків для створення крутої технічної команди
Мої перші кілька місяців в новій ролі
Озираючись назад, я розумію, що в той час абсолютно не розбирався у своїй новій роботі. Я просто намагався наслідувати дії інших тімлідів, з якими був знайомий.
Не зрозумійте мене неправильно: багато я робив добре. Але були й проблеми.
Для початку, щоразу при виникненні проблем технічного характеру я включав режим супермена. Відразу кидався в бій, щоб пофіксити все однією лівою. Зрештою, я був відмінним програмістом і добре розбирався в нашій системі. Мені прекрасно вдавалося допомагати іншим розробникам вирішувати проблеми, що у них виникали. Саме тому мене і підвищили, правильно ж?
Спочатку частині команди це подобалося. Вони поважали мене за те, що я не боюся забруднити руки, намагаюся допомагати та бути чуйним.
Але комусь це НЕ подобалося. Мої дії можна було сприйняти і як надмірний контроль. Та й люди, яким спочатку все підходило, згодом змінили свою точку зору. Вони здійснювали одні й ті ж помилки знову і знову, і не прогресували. Наші слабкі розробники залишалися слабкими, а сильні не росли.
Були в мене й інші помилки. Наприклад, я дуже довго чекав, щоб звільнити поганого розробника, чия поведінка шкодила всій команді.
8 речей, про які мені забули сказати
Я думаю, що лідерство це нескінченна подорож. Завжди є чому повчитися. На щастя, у мене були хороші наставники. Але до деяких відкриттів я прийшов шляхом проб і помилок. Ось список речей, щодо яких я шкодую, що не знав їх з самого початку.
1. Багато з ваших навичок не можна перенести
Жорстока іронія: сильні навички розробника і тімліда знаходяться у зворотній залежності. Чим кращий ви як розробник, тим складніше вам буде починати свій шлях в менеджменті.
75% проблем, з якими стикається тімлід – не технічного плану. Ми більше працюємо з людьми та процесами. Коли я це зрозумів, все встало на свої місця.
В нашій кодовій базі я міг виправити практично що завгодно. У мене відмінно виходило знаходити креативні рішення проблем, з якими стикалися інші розробники. Але ці та інші мої характеристики більше не були релевантні для посади.
Комплекс супермена
Якщо команда стикається з технічною проблемою (баг, блокер), хороший розробник часто інстинктивно в ту ж секунду кидається її вирішувати. Коли я чинив так, будучи розробником, колеги були мені вдячні, а керівництво вважало мене хорошим командним гравцем. Але коли ви робите те ж саме, будучи менеджером, це як раз означає, що ви НЕ хороший командний гравець.
Ми повинні не розв’язувати проблеми, а надавати нашим людям можливість вирішувати їх. Навіть якщо спочатку так буде довше. Навіть якщо інші розробники будуть допускати помилки. І навіть якщо вони не зроблять все так само добре, як зробили б ви.
Коли ви не розв’язуєте проблему самостійно, а допомагаєте команді розібратися, ви отримуєте багато переваг. Ваші люди побачать, що ви їм довіряєте. Вони більшого навчаться. Згодом вони стануть більш самодостатніми. Також вони навчаться допомагати один одному, а це зближує команду.
Додаткова порада
Всіма силами намагайтеся нікого не засуджувати. Коли ваші люди відчувають, що можуть вийти із зони комфорту і робити помилки, не боячись критики, це вивільняє їхню справжню креативність. Ви здивуєтеся, побачивши, на що вони здатні.
Ще одна додаткова порада
Навчаючи свою команду, ви можете «масштабуватися». Пояснюйте, чому вважаєте правильним те чи інше рішення. Озвучуйте свій розумовий процес при діагностиці проблеми. Розповідайте, як ви знаходите слушні варіанти рішень.
Глибока концентрація
Ще одна навичка, яка не став в пригоді мені як менеджеру, – вміння глибоко фокусуватися. Коли ви розробник, вам потрібно входити в «зону». Мені добре вдавалося відключатися від всього і фокусувати всі свої сили на розв’язанні конкретної задачі. Але коли ви тімлід, це для вас смерті подібно.
Хороші лідери вміють швидко перемикати контекст. Вони постійно в русі, вони спілкуються з великою кількістю людей. Якщо ви виявляєте, що на кілька годин загрузли в технічну проблему, ймовірно, це знак, що потрібно більше делегувати повноваження.
Коли можете дозволити собі розкіш глибоко сфокусуватися на чомусь, подумайте про стратегічні ініціативи. Наприклад, про те, як переконати раду директорів піти на нові нефункціональні вкладення або найняти ще трьох розробників.
2. Не відмовляйтеся від своїх інстинктів. Міняйте свою поведінку
У хороших розробників хороші інстинкти. Ваша інтуїція, яка відбувається з вашого досвіду, ваше знання системи та розуміння всіх процесів дозволяють вам відчувати, що відбувається. Ви відчуваєте, де в коді щось пішло не так. Ви відчуваєте, коли ітерація команди вибивається з розкладу.
Продовжуйте довіряти своїм інстинктам. Але діяти при цьому потрібно по-іншому, не так, як ви звикли.
Ваше шосте чуття тепер необхідно вам навіть більше, тому що потрібно визначати, що хтось потребує вашої допомоги. Це почуття стане в пригоді, коли почуєте на стендапі щось, що здасться вам неправильним. І коли у когось не вийде знайти причину проблеми в продакшні. І коли будете допомагати з рев’ю коду.
Але якщо не можна вискакувати, як супермен, і вирішувати проблеми, то що ж робити?
По-перше, глибоко вдихніть. Ми звикаємо діяти швидко, але для менеджера це скоріше недолік. Продовжуйте слухати та дайте собі час на обробку інформації.
Якщо не почули достатньо, ставте питання. Збирайте якомога більше відомостей, перш ніж давати поради. Часом навіть постановка правильних питань може допомогти вашому розробнику поглянути на проблему під іншим кутом і самостійно знайти рішення.
3. Більше говоріть про «чому», ніж про «що» і «як»
Як розробники ми звикли мати справу з «що» і «як». Для менеджерів це теж має значення, але куди важливіше фокусуватися на «чому». Причин для цього декілька:
Рівняння на користувача
Менеджери продуктів швидше за все виклали проблеми користувачів і use cases в історіях. Але розробники все одно можуть не побачити лісу за деревами. Якщо ви будете постійно нагадувати команді про проблему, яку вони вирішують, і про призначений для користувача досвід, ви набагато частіше будете випускати високоякісні продукти.
Додаткова порада
Коли розробнику трапляється застрягти, я запитую його: «Чи можеш ти описати, що твій користувач буде робити до, після і під час використання цієї функції?». Якщо він не може цього сказати, значить, йому потрібно надати більше інформації.
Ще одна додаткова порада
Заохочуйте розробників займатися підтримкою користувачів. З власного досвіду можу судити, що в багатьох командах про це тільки говорять, але по факту не роблять. Ми взяли собі за правило, що кожен розробник відповідає як мінімум на два дзвінки користувачів в місяць.
Рівняння на бізнес
Значна частина роботи лідера полягає в тому, щоб доносити рішення керівництва до розробників і налаштовувати команду працювати для досягнення цілей бізнесу. Я вірю, що за кожним рядком коду стоїть бізнес-рішення. Наша головна мета – залучити більше користувачів і принести прибуток? Або спробувати підвищити задоволеність користувачів? Ми робимо стратегічні інвестиції в нефункціональну роботу, щоб заощадити гроші та отримати більший прибуток? Чим більше ваші люди розуміють вплив загальної картини на їх роботу, тим більшою мірою вони зможуть мислити стратегічно і приймати кращі рішення при написанні коду.
Місія та мотивація
Більшість людей хочуть бути частиною чогось більшого. Коли ви ділитеся зі своєю командою відповідями на всі «чому», це допомагає зв’язати їх з іншою частиною компанії. Також, незалежно від того, чим займається ваша компанія, у вас є користувачі, які залежать від вашого продукту. Живі люди. Коли ви розповідаєте розробникам, «чому?», Це допомагає їм займатися чимось більшим, ніж вирішенням завдання поточного спринту. А це, своєю чергою, робить їх більш щасливими та веде до побудови сильнішої командної культури.
Кар’єра
Кращі менеджери, з якими я працював, налаштовували мене на успіх на новому робочому місці. Незалежно від того, чи захоче ваш розробник розвиватися по технічній частині або перейти на шлях менеджменту, йому потрібно буде навчитися бачити великий план картини та пояснювати всі «чому» іншим людям. У мене були наставники, які вчили мене цього, і я намагаюся «повернути борг», навчаючи інших.
4. Культура це реальна річ. І за неї відповідаєте ви
Що стосується культури, це щось цілком реальне, і саме на вас лежить відповідальність за її формування.
Чи можна дати визначення культури? Ну, її легше описати, ніж визначити. Але це не означає, що культура – щось придумане. Я думаю, вона схожа на гравітації. Щось невидиме, що не дає нам розлітатися на всі боки.
Що я точно знаю щодо культури, це те, що вона допомагає поділу цінностей. Також допомагає, коли ви ці цінності записуєте, використовуєте в щоденній роботі та повторюєте час від часу.
Ще я знаю, що культура перетікає зверху вниз і знизу вгору. Якщо ви самі в цю культуру не вірите, ваші розробники це зрозуміють. Вони побачать, що ви не живете нею. Тому все повинно бути натурально.
Що стосується мене, в справі побудови культури мені допомагають три речі:
- прояв доброти та емпатії до кожного,
- слова, що не розходяться з ділом,
- скромність і концентрація на команді.
5. Розчищайте шлях для своїх людей
Одна з моїх проблем на менеджерській позиції пов’язана з тим, що образ дій людей і комп’ютерів відрізняється. Серйозно.
Код детермінований. Ви говорите йому щось зробити. Він робить. Якщо код робить щось не так, як задумано, ви виправляєте його, і він починає робити це правильно.
Але люди влаштовані зовсім інакше! Ви не можете просто сказати їм, що робити. Це не спрацює. Сьогодні ви отримаєте один результат, а завтра можете отримати зовсім інший.
Працюючи з людьми, ви можете тільки налаштовувати їх на успіх і довіряти. І якщо вас оточують хороші розробники, краще, що ви можете зробити – розчистити їм шлях і відійти в бік.
Я знаю, що зайнявшись розблокуванням команди, витрачу час з розумом. Щотижня ми стикаємося з блокерами трьох видів.
1. Технічні
Про ці нам все відомо. Намагайтеся не розв’язувати технічні проблеми особисто. Заохочуйте розробників робити це самостійно або допомагати один одному.
2. Залежності
Як розробник ви теж мали справу з цими блокерами, але тепер ви в кращому становищі та можете передбачити, коли та де виникне проблема. Це дозволяє почати розв’язувати проблему на більш ранніх стадіях.
3. Пріоритети
Пропрацювавши деякий час в ролі тімліда, я усвідомив основну причину, з якою у команди трапляються невдачі з ітераціями. Це відбувається або тому, що розробники не зрозуміли, яке завдання має найвищий пріоритет, або тому, що були змушені відволікатися на інші завдання. В кінцевому підсумку я став контролювати, щоб кожен розробник працював над найбільшими завданнями, рішення яких допоможе нам вкластися в терміни.
Додаткова порада
Не варто витрачати час на озвучування того, хто на якому етапі роботи знаходиться: це можна зробити в повідомленні в Slack. Краще говоріть про пріоритети. Дайте вашим розробникам розповісти про те, які їхні основні пріоритети, і чи не заважає їм щось зайнятися цією роботою. Я впевнений, що це істотно підвищить залученість вашої команди в процес і в результаті ви будете куди частіше укладатися в терміни.
6. Визначення пріоритетів і естімейти займають до 50% вашого часу
Коли ви розробник, вас часто запитують, на якому етапі ваша робота. Коли ви стаєте тімлідом, вас запитують про це в 10 разів частіше.
Визначення пріоритетів і оцінка часу, необхідного для виконання завдань, забирає у мене як мінімум половину часу. Ці завдання для мене цікаві та мені подобається працювати над ними.
Про те, як правильно робити естімейти, вже написано багато статей, тому я не буду детально на цьому зупинятися. Поділюся лише кількома порадами.
Коли мова заходить про естімейт, будьте чесними та не грайте в ігри. Не кажіть людям те, що вони хочуть почути. Якщо бізнес говорить «Я впевнений, ви зможете зробити це швидше», – стійте на своєму. В іншому випадку вам доведеться розсьорбувати наслідки.
Якнайбільше прислухайтеся до своїх розробників. Намагайтеся ставити на перше місце їх нефункціональні запити, тому що в кінцевому підсумку це дозволить вам прискорити роботу над тим, що потрібно комусь ще. Знову ж таки, на вас буде тиснути керівництво і змушувати фокусуватися насамперед на розробці функціоналу для користувачів. Ви повинні довести, що якщо займетеся нефункціональними вимогами зараз, то в майбутньому зможете створити куди більше призначеного для користувача функціоналу.
Спробуйте подружитися з лідерами продукту і просвітити їх щодо того, що нефункціональна робота, якою ви хочете зайнятися, в кінцевому підсумку допоможе їм отримати бажаний функціонал набагато швидше. Об’єднавши зусилля з менеджментом продукту, ви з більшою ймовірністю зможете переконати інших.
7. Інвестуйте у свою екосистему
Коли ми отримуємо підвищення, наше коло знайомств збільшується в 3-5 разів.
Ми звикли працювати з розробниками з нашої команди, власником товару і часом з розробниками з інших команд.
І тут раптово виявляється, що потрібно мати справу з усіма іншими менеджерами, багатьма з їхніх розробників, з усіма людьми, відповідальними за продукт, з техпідтримкою, відділами продажів та HR. Не кажучи вже про вищих менеджерів в нашому власному відділі.
Ці відносини мають дуже велике значення. У вас не вийде добитися успіху на новій посаді без допомоги всіх цих людей. Як і піднятися на новий рівень кар’єри. Тому інвестуйте в відносини з цими новими знайомими. Дізнавайтеся, що для них важливо, і намагайтеся якось полегшити їхнє життя.
Наприклад, спілкуючись з людьми з відділу продажів, поцікавтеся, що може допомогти їм у проведенні демо. Попрацюйте над чим-небудь для них на своєму наступному хакатоні.
Як вивести продуктивність команди на новий рівень. Поради професора Лондонської школи бізнесу
8. Переводьте розробку на мову цифр
Ваш новий бос (директор, віцепрезидент, технічний директор) буде цікавитися не тими речами, про які вас запитували, коли ви були розробником. Швидше за все він буде куди більш зосереджений на даних та показниках, тому що саме цим цікавиться його власний начальник. Дайте йому ці дані.
Відмінні спогади
Мені подобалося бути тімлідом. Задоволення від цього було не таким, як коли постійно створюєш що-небудь сам. Але допомагати людям розкривати їх потенціал приємно. Тімлід – одна з позицій, на яких у вас найбільше можливостей. Ви можете і тактично втілювати щось в життя, і впливати на стратегію.
Два роки по тому мене підвищили до директора. Пізніше – до віцепрезидента з розробки. Я завжди прагнув до прогресу і вирішення нових завдань. Але роки, проведені в ролі тімліда, згадую з великою теплотою.
Чим вище ви піднімаєтеся по кар’єрних сходах, тим більше самотньо там буває.
Я сумую за розв’язанням проблем в команді. За нічними переробітками, щоб встигнути до дедлайну. За жартами «для своїх». Немає нічого, що зрівняється з роботою в маленькій дружній команді.