«Я швидше зроблю це сам». Як тімлід власноруч душить команду (і себе)

Привіт! Мене звати Сергій Немчинський. В індустрії розробки софта я працюю вже понад 30 років. За цей час встиг побувати на різних позиціях, від джуніора-розробника до засновника власної школи ІТ-професій FoxmindEd. Декілька разів у різних компаніях та проєктах я вставав на посаду тімліда. Те, про що я розповідаю в цій статті — висновки з мого власного досвіду.

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

Так робити не треба. І зараз я розповім, чому. А ще — як цьому зарадити і стати нормальним, ефективним тімлідом.

«Я сам»: як тімлід заганяє себе в пастку

Як розробник стає лідером команди? Зазвичай дуже просто: через роль того чувака, який «порішає».

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

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

Дивись: ось ти сидиш о 22:07 і дописуєш фічу. Хочеш, вгадаю, чому? Не тому що дедлайн сьогодні. Не тому що більше нема кому. Навіть не тому, що нарешті дали світло (якщо так, то питань до тебе нема, ти молодець). Але швидше за все тому, що ти вже подумки порахував: «Пояснювати джуну — хвилин 30–40. Ще потім перевіряти його роботу, знаходити помилки, вертати на доробку або фіксити самому. Ой, краще я сам зроблю хвилин за 15».

І ти робиш.

А завтра ще раз.

І післязавтра.

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

У який момент все пішло не так?

Трохи неприємної математики

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

Головна помилка в тому, що ти рахуєш тільки короткострокові наслідки. Якщо ти зробив сам за 15 хвилин, замість півгодини спілкування із джуном, ти зекономив час. Один раз. Але наступного разу тобі знову доведеться обирати, робити самому чи возитися з джуном. Знову вибереш самостійність? Це прямий шлях до того, щоб робити це завжди. Кожен баг, кожну фічу, кожен рефакторінг.

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

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

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

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

«Вони зроблять гірше»: правило 70%

Найчесніша причина, чому ліди не делегують, звучить так: «Вони зроблять гірше». Це правда. Скоріше за все, так і буде. Розробники рівня джуніор-мідл не зроблять ідеально, як може зробити сіньйор.

Тільки ось ще одна неприємна новина: нікому не потрібно ідеально. Прод не стає в 10 разів стабільнішим від того, що ти назвав змінну правильно. Архітектура не розвалюється від того, що рішення не таке елегантне. Милиці потворні, але працюють.

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

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

Як вбити команду: правило автобуса

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

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

І це теж правда. Але це не допомагає. Пояснюю на пальцях.

1. Одна людина не здатна створити великий продукт самотужки. Для цього потрібна команда.
2. Команді потрібні мотивація і розвиток. Цікаві задачі, розвиток у процесі роботи, відчуття росту — все те, про що красиво пишуть у вакансіях. Я завжди кажу, що в програмуванні не можна мотивувати лише грошима.
3. Коли тімлід забирає всі складні задачі собі, джуни не ростуть. Мідлам теж стає нудно. Вони прийшли не верстати умовні кнопки. Вони «скисають», а найкращі йдуть туди, де можна ухвалювати рішення.
4. У підсумку ти сидиш посеред команди, яка нічого не може без тебе, і злишся, що «ніхто не тягне». Сюрприз: це ти таку систему побудував.

А тепер уяви, що ти зник. Поїхав у відпустку, захворів, потрапив (боже збав) під автобус. Проєкт без тебе встане? Якщо так — вітаю, твій bus factor дорівнює одиниці. І це погано.

Коли все зав’язане на одну людину — це не лідерство. Це single point of failure, точка провалу. Так не має бути.

Що насправді має робити тімлід

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

До речі, саме на нормальних лідівських програмах — наприклад, у нас в FoxmindEd на курсі для тімлідів, — вчать всяким матрицям делегування, рівням відповідальності й цим нудним штукам. Бо «на інтуїції» ми всі скочуємось у «я сам». Інтуїція нас стабільно підставляє.

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

Техніка безпеки при делегуванні

Давайте одразу поговоримо про іншу крайність: коли лід делегує геть усе. Ну знаєте, надихнувся статтями про делегування, як ось ця, і думає: «Окей, нехай команда все робить, а я буду стратегувати».

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

Формування команди

Почнемо з очевидного, але чомусь постійно порушуваного. Формування команди. Так, в більшості компаній є відділ HR. Але людей найкраще знає безпосередній керівник, тобто тімлід. Тому найм, звільнення, перегляд зарплат, управління конфліктами, регулярні 1-to-1 — все це тімлід або робить сам або бере в цьому активну участь.

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

Кризові ситуації

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

Стратегічні питання

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

Все інше можна і треба делегувати. Навіть якщо здається, що це занадто складно або «краще я сам».

Алгоритм для тих, кому страшно почати

Якщо все це так просто й очевидно, чому ліди все одно не делегують задачі? Не через лінь. Майже завжди — через страх:

• хтось зробить не так;
• впаде прод;
• доведеться переробляти;
• погано виглядатимеш перед керівництвом або клієнтом.

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

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

Ключ до всього цього — це чітке розуміння, як виглядає готова задача. Працює? Покрите тестами? Не кидає інші частини? Є документація? Якщо є зрозумілий Definition of Done, спосіб досягнення результату перестає бути критичним.

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

Висновок. Вбий у собі «героя»

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

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

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.