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

Хочу стати Team Lead. Як зрозуміти, що це твоє, до чого готуватися і навчатися

Привіт, мене звати Анастасія-Нікіта Бансал, я директор Enterprise Solutions у SmartyAds — компанії, яка займається розробкою adtech-платформ для програматик-реклами.

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

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

Хто такий тимлід і чим він відрізняється від техліда

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

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

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

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

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

Задачі тимліда і техліда

Тимлід

Техлід

Контролює дотримання стандартів якості та пріоритетів

Визначає технологічний стек під кожне завдання чи конкретний проєкт

Організовує командну роботу та комунікації — у команді та між відділами (з замовниками продукту)

Вибудовує, впроваджує та розвиває інженерні процеси та практики

Ставить зрозумілі завдання та окреслює проблему з погляду бізнесу

Формулює стратегію технологічного розвитку продукту

Відповідає за професійний ріст розробників у своїй команді та ставить їм цілі на розвиток

Створює інфраструктуру, в якій розробники мають можливість розвиватися

Розподіляє зони відповідальності у команді, навантаження, характер тасків та стежить за дисципліною

Слідкує за дотриманням технічних стандартів виконання завдань

Що означає бути тимлідом у вашій команді

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

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

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

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

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

Які взагалі є шляхи розвитку для IT-професіонала

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

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

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

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

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

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

  • Планування. Необхідно вміти правильно ставити цілі та пріоритети.

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

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

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

  • Менеджмент. Наприклад, з’ясувавши, куди розробник хоче розвиватися, тимлід визначає, як компанія може допомогти в досягненні цілей. Тимлід визначає KPI, виконання яких дасть бажані результати (підвищення, премія тощо).

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

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

Дорожня карта розвитку до позиції тимліда

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

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

  • виписуєш усі компетенції, які тобі потрібно вивчити;
  • визначаєш поточний рівень володіння кожною та вказуєш пріоритетність — наскільки вона важлива;
  • описуєш дії, які потрібно виконати, щоби освоїти компетенцію;
  • ставиш дедлайн (місяць/ пів року/ рік і т.д.).

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

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

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

Якості ідеального лідера

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

Екосистема комунікації всередині команди

З одного боку, тимлід повинен мати емпатію: прислухатися до співробітників, співпереживати їм і допомагати розбиратися з проблемами. Без цього неможливо бути гарним наставником. Крім того, без емпатії, атмосфера всередині команди може стати токсичною — а це призводить до низької продуктивності, вигоряння.

З іншого боку, щоб стати хорошим тимлідом необхідно бути вимогливим і грамотно реагувати на складнощі, що виникають.

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

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

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

Ефективність команди, оцінка продуктивності і технології управління

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

Ми створили чіткий та зрозумілий воркфлоу та підтримку ефективності команди. Це значно спрощує управління та менеджмент для тимлідів, а також забезпечує стандартизацію процесів, а отже і якість виконання завдань. Також кожен член команди має власні KPI, які розробляються тимлідом на певний період, як правило, пів року — рік.

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

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

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

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

Проведення мітингів, де озвучуються потреби бізнесу — це теж дуже корисна практика. Наприклад, у нас було завдання автоматизувати певний процес, на мітингу розробник може зацікавитись такою можливістю та запропонувати свою участь.

Висновок

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

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

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

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному13
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Пмм попробовать себя в тимлидах может любой, кому не лень
А там уж будет понятно, а этот гемор вообще нужен или лучше в этот менеджмент совсем не соваться

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

Гарна стаття, дякую

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Щось у мене зовсім іньше розуміння. Як я розумію техлід старший за тімліда, а якщо у программі є ще і пул системних архитектів то старший і за них. Фактично голова технічної команди розробки, який має тайтл по типу Senior Solution Architect чи щось таке. І техлід і тім ліди, так чи інакше керівники які відповідають за розробку ПЗ, тоді як проектні і програмні менеджери відповідають за бізнес. Якщо у вас техлід то такий такий собі старший сініор , що фіксить баги на продакшені — то lead з назви посади можна прибирати, бо ніякого leadership в посаді нема. Краще якось назвати staff software engineer чи ще якось.

Вот позволю себе не согласится. Почему это «техлид старше тимлида»? во первых, наоборот, во вторых — у них разные зоны отвественности. Тимлид — не всегда самый технически подкованный человек в команде, его основной абилкой является умение пасти стадо котов-разработчиков, достигая поставленных целей разумными средствами. Техлид же есть как раз наиболее подкованный человек в команде — при этом ему хорошо бы, но необязательно (для этого есть тим-лид) уметь внедрять своё техническое видение/инструменты/технологии. Добавлю при этом, что ни тим-лиду, ни тех-лиду не обязательно быть самым подкованным в плане предметной области — им может быть человек технически вообще малограмотный.
В каждом и любом случае задача решается при помощи людей — которыми рулит тим лил, а техлид просто обеспечивает команду наиболее подходящим набором инструментов. Да, это тоже важно, но слесарь-инструментальшик всегда подчиняется начальнику цеха, хотя его мнение, безусловно, очень ценно и значимо.

Про підкованість мабуть так але про хто начальнік то ні

Дозволь внести перспективу західну

Начальнік і хто в команді старше — поняття виключно ментальності радянської і може 60-80х

В командах рішення приймають консенсусом, а не пропихуються (крім коли це пропихується зверху звісно)

Тому з моєї точки зору абсолютно неважливо хто тім а хто тех. На будьякому колі стейкхолдерами будуть обоє

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

Попрацював я досить довго і з американцями і з англійцями. Те, що ви тут описуєте це те, що вони називають тактичністю. В них прийнято не ображати, м’яко висловлюватись, не робити не тактичних зауважень по типу «це лайно, алгоритм O! треба переробити». Замість цього буде якесь, на наш погляд, підсміювання по типу «на мою думку цей код, міг би працювати в тисячу разів швидше, якщо алгоритм мав би складність О1. Хто ще так думає ?». Насправді це жодним чином не пропозиціч — а прямий наказ і його надано тому, кому натякнули, що це власне йому треба так думати. Реальність — це втричі більше жорстка система ніж в нас. Якщо щось не так — ніхто на вас не кричатиме і ні в чому не звинувачуватиме, просто зроблять ключові речі — приберуть з програми, не продовжуватимуть контракт, не нададуть рекомендацій тощо. Як відрізнити головного — по грошах, в кого право розпоряджатися бюджетом той і є головний — персона приймаюча рішення. Техлід це зазвичай його головний технічний консультант, якому делегована розробка. А системи де є багато головних, тобто ні одного, людство в ході своєї еволюції відкинуло. Вижили лише системи де головний обирається громадою тимчасово, на якийсь термін для отримання якогось конкретного і вимірюваного результату і системи де лідерство передається від володаря до приймача, наприклад в спадок але необов’язково. Перша більше розповсюдження в Європі, друга в Азії. Скажімо в Японії навіть є традиція усиновлювати топових менеджерів.

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

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

Тут вы в терминологию уходите. В реальности лычки даже в рамках одной компании, но разных отделов могут означать совершенно разные вещи. А тем более когда речь идёт о сравнении контор скажем на 15 человек и на 60 тысяч. Можно сказать одно, почти во всех организациях капиталистических стран, при производстве организуется работа с главным человеком, который отвечает за бизнес и человеком который отвечает за производство. Второму делегируются управление командой производства, но не управление бизнес целями. Хотя может быть и кто то вроде: Стив Джобса, Билла Гейтса, Сергея Королева или Гейба которые совмещают. Потому как или команда маленькая или бизнес процессы относительно простые. Абсолютно точно, если у сотрудника нет никаких подчинённых (subordinate) которым он ставит задачи и делегирует полномочия, может поверить и наказать, то у него просто в тайтле lead написано. Идёт речь о просто квалифицированном исполнителе, лидерства в его должности нет никакой.

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

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

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

Бонус тимлида — перестать работать руками

Так это далеко не для всех бонус. В том и дело, что если любить организационную работу и лидерство больше, чем «технику» — тогда имеет смысл сознательно менять направление карьерного развития в сторону менеджерства. Для тех же, кому нравится педалить, я бы со стороны компании предусмотрел следующие ступени именно в инженерном треке, чтобы было куда расти карьерно без «перевоплощения» в менеджера.

Так хорошие деньги можно зарабатывать и в инженерном треке. И горе той галере, которая не предусматривает для высококвалифицированных технарей такие же возможности финансового роста, как и для руководящих позиций

то інженери — гребуть руками по твоєму, а тімлід не гребе?

зазвичай картіна зовсім інша — тімлід на додачу до гребти (хоч звісно й менше) отримує додатково 100500 напрямів головняка, регулярні вправи на шпагат, забитий календар, додаткові бонусні овертайми, весь онкол-трафік з продакшена, а ну і бажане кар’єрне зростання звісно

Это только первая ступень, вторая ещё менеджер. И ещё, и ещё

И ещё, и ещё

спереді сзаді свєрху і снізу, а я про шо?

Хотіти такого за умовні +1000 чи якісь навіть акції, це треба мати специфічний характер і прєдрасположенность до садомазо, акції й самому можна купити

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

Хотіти такого за умовні +1000

Кто сказал, что +1000? Добавляй нулик.

непомітно для всіх менеджити процеси на швидкості равлика, але там свої нюанси

Неплохой вариант

p.s. Ты думаешь я не напрягаюсь на работе? Но если уж вкалывать, за большие деньги!

Добавляй нулик

Мєчтай, хіба що нулік до річної, точно не до місячної ;)

за большие деньги

Я люблю вихлоп бабоса на умовний юніт головняку, а не просто вихлоп бабоса, все залежить

Ну конечно нужно тратить со вкусом, однако это достигается отключением телефона после шести вечера — нет меня

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

Менеджер який не випромінює щастя — не менеджер ;) це просто частина роботи ) у випадку з делівері чи проджект — все це підтримуючі ролі в айті, як скрам чи куа.

Core value в айті створюється програмістом який гребе. Ну чи адмінам/девопсом/дба що підтримують це все — будь який інцидент рівня p1 зразу розставляє хто є хто. Поза інженерією я б ще сказав критичний сейлс. Всьо. Решта народу в компаніях — для розгружання часу перших.

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

це мені скоріше нагадує соціальну боротьбу в табуні макак і чесання чсв

У великих компаніях бути макакою повище серед інших макак — це життєво важливо

Менеджер отвечает за финальный результат, он направляет, организовывает план по созданию плана, как добиться нужного результата, следит за выполнение и решает проблемы, которые могут помешать, оптимизирует работы на верхнем уровне, обновляет процессы.
Когда ты разработчик, твое основное желание — это поделать интересные задачи(как и на всех уровнях, в принципе). Мотивация сделать хороший продукт — конечно тоже есть, но не у всех, необязательно сильная и не всегда.

Поэтому должны быть люди, которые направляют, в какую сторону все должны двигаться, чтобы достичь долгосрочную цель, люди, которые сфокусированы на этом, замотивированы, иначе все будут просто решать интересные задачки, которые необязательно дадут большое продвижение до главной цели.
Нужны люди, которые высокоуровнево могут решить конфликты между командами, кто что должен делать.

Если проект движется в неправильном направлении — то разработчики не смогут этого исправить, просто потому что они не имеют нужных инструментов, да это и не их обязаности.

Я з усім згоден цим, і ти абсолютно прав

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

Кому хочеться і таке цікаво — то звісно супер. Але якщо я себе в ці шузи ставлю, я не бачу сенсу брати менеджерські головняки за умовну кар’єру чи умовні +скількись для інженера. Набагато краще ставати хевівейт в технічному плані, від’їдати пику і ставати distinguished senior lead principal architect

Да да, согласен, тут уже зависит от приоритетов, лично для меня драйвово, когда постоянно есть какой-то вызов, какие-то проблемы и их нужно решить, я часто переходил по ролям, даже без какого-то оговоренного повышения ЗП, просто в голове понимал, что чем больше будет мой вес в конторе, тем больше мне будут платить в скором времени, так и вышло.
Так что, да, у каждого свои мотивации, приоритеты и желания, главное, чтобы каждому нравилось, чем он занимается

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

А може й не станеш, може звільнять в кризу як і інших. Але це буде колись

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

огда ты разработчик, твое основное желание — это поделать интересные задачи(как и на всех уровнях, в принципе). Мотивация сделать хороший продукт — конечно тоже есть, но не у всех, необязательно сильная и не всегда.

У кого как. Моя цель — заработать денег побольше, а на интересные задачи *** ложил, я — же профессионал

Никто не спорит, что инженеры дают результат и что без инженеров остальные специалисты не нужны, но одним разработчикам, без менеджера, будет трудно сделать большой проект самим.
Для себя я вывел, следующее:
Разработчики в основном смотрят на проект в разрезе спринта, максимум нескольких
Тимлиды в разрезе спринта и итерации
Менеджеры в разрезе итераций и целого проекта

Когда ты имеешь несколько ролей и следишь, например, за спринтом, итерацией и проектом, то мозг начинает вскипать, потому что на каждом уровне разные инструменты и способы мышления

Саме так, і чим менша компанія тим більше цього

Когда ты имеешь несколько ролей и следишь, например, за спринтом, итерацией и проектом, то мозг начинает вскипать

І заради чого от мені й не видно сенсу.

нормальна еволюція дева

Як кажуть в народі, був непоганим девом, а став поганим менеджером, особливо в аутсорсі.

на бізнес впливати

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

Думав що там Анастасія в ліди лізе, а це якась байка для джунів

Хочу стати тим де менше робити і більше платять

трус це ви, справжні браві чоловіки вирішують все на дуелі

Становись инвестиционным брокером.

Он сказал «больше платят», тут скорее нужно создавать тренинг по инвестициям

Не нужно. Звонишь Биллу Гейтсу и говоришь — есть классная штука для инвестиций. Берешь миллиард и переводишь в AWS, оставив себе 1%. Потом звонишь Безосу и говоришь — есть классная штука для инвестиций. Берешь миллиард и переводишь в MicroSoft, оставив себе 1%.
Пару звонков в месяц — мало времени, деньги приличные.

Здрава мисля приходить, вона двигун прогрессу між іньшим. Те саме, що працювати не багато — а головою.

Коментар порушує правила спільноти і видалений модераторами.

Взводним. Що приблизно дорівнює. :))))

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