Дрібне начальство за +20%? Чому тімлід має більше влади над системою, ніж архітектор
До мене регулярно приходять сеньйори на кар’єрне консультування. І майже всі хочуть одного — стати архітектором. Мрію формулюють приблизно так: «Коли я стану Solution Architect, я нарешті прийматиму всі важливі рішення й перестану писати лайнокод». Звучить як вершина кар’єри: ти вже не в окопах, ти на пагорбі з картою, і всі рухаються так, як ти намалював. Так от — це міф.
Якось я вже писав, чому шлях у тімліди простіший, ніж у техліди. Найгучніше заперечення в коментарях було таке: тімлід — це дрібне начальство за +20% до зарплати, ходу нагору немає, тож краще лишатися сильним спеціалістом. Здавалося б, до чого тут мрія про архітектора? А до того, що мрія про архітектора й зневага до тімліда — це одна й та сама помилка. В її основі лежить переконання, що влада живе в титулі «архітектор», а тімлід — це той, хто проміняв код на статуси в Jira. А чи варті ті +20% свічок суто по грошах — окрема тема, до якої я повернуся в наступній статті.
Я говорю про це не зі сторони. Я сам був архітектором у Luxoft. Був і розробником, і тімлідом. А сьогодні я директор освітньої IT-компанії FoxmindEd, яка навчає і архітекторів, і звичайних розробників, і водночас співвласник та CTO аутсорсингової компанії FoxmindEd Software, де цих людей ще й наймаю. Тобто це погляд не «теоретика, який ніколи не малював діаграм», і не «менеджера, який ніколи не писав код», а людини, яка посиділа на всіх стільцях по обидва боки барикад.
Ось до чого я прийшов. Влада в розробці вимірюється не красивими діаграмами й рядком у підписі пошти, а однією річчю — чий код опиняється на проді. А вирішує це не той, хто малює, а той, хто робить delivery. Сьогодні поясню, чому саме тімлід, а не архітектор, насправді володіє вашою системою.
Архітектор в аутсорсі — це пресейл-інженер
Почнемо з аутсорсу, бо там роль архітектора видно найчіткіше. У переважній більшості випадків це технічний продавець експертизи: намалювати клієнту красиві UML-схеми, переконливо виступити на пресейлі, інколи курувати PoC. Без цієї роботи компанія не виграє контракт, а навички тут легко переносяться між компаніями.
Але щойно клієнт затвердив дизайн, архітектор іде на наступний пресейл. Він не живе з цим кодом роками й не прокидається о третій ночі від алерту про впалий продакшен. А далі за справу береться команда: тімлід легітимно адаптує схему під реальні обмеження — спрощує складні вузли, добирає інші інструменти, переконфігуровує базу під бюджет і навички девів. Бо саме він відповідає перед бізнесом за те, щоб усе працювало й вкладалося в дедлайн.
Це не означає, що архітектор продав клієнту пустушку: його схема дає реальну цінність на старті. Просто це vision і стартова рамка, а не незмінний закон. Реалізує її й володіє нею вже тімлід зі своєю командою.
Архітектор у продукті — хранитель легасі
У продукті картина інша, але фінал схожий. Тут архітектор — це часто засновник, хтось із його наближених або «хранитель» ядра, написаного п’ять-десять років тому (на Заході в Big Tech це гілка Staff/Principal Engineers, трек Individual Contributor). Його задача — захищати своє архітектурне «дитя» й гарантувати, що ніхто не поламає core. І тут є пастка: його навички прив’язані до конкретного продукту — він частина корабля, і його експертиза майже не переноситься в інше місце.
А головне — він зазвичай навіть не бачить, що роблять прикладні команди. Він править тільки ядро. В одній великій продуктовій компанії, де я працював, архітектори сиділи буквально на окремому поверсі, куди перепустки звичайних розробників навіть не відчиняли двері. Команда не бачила жодного архітектора в очі, а про зміни в ядрі дізнавалася лише з розсилок на пошту. А весь прикладний код, який бачить користувач, команда писала сама, підлаштовуючись під те, що архітектори змінили в core. Реальну систему під клієнта будували команди з тімлідами.
Пастка Staff та Principal Engineers
«Стоп, — скаже хтось, — а як же Staff і Principal? Це ж і є технічна вершина». У світовому Big Tech — так, це справді впливові ролі (як працює
У більшості випадків Staff або Principal — це пожежники. Їх кличуть, коли все палає, сервери лягають, а звичайні розробники безпорадні. Поки людина в цій ролі, вона не впливає на щоденну роботу команди: приходить на пожежу, гасить — і йде. А прикладну розробку — переважну більшість коду, який бачить користувач, — веде команда на чолі з тімлідом, і її рішення вже ніхто не заветує, бо саме вона деліверить код у прод.
Цей трек упирається в стелю. В аутсорсі над Principal немає наступної сходинки взагалі: «вища» точка — це пресейл-архітектор, тобто не системна вершина, а продавець експертизи. У продукті трек упирається в того самого хранителя легасі, який лише оберігає core, — і це кінцева точка.
Але є ще одна стеля — тонша й цікавіша. Вона вже не про кар’єру, а про те, що реально тримає інженера в проєкті роками, чому він зранку відкриває ноут. Чому Staff і Principal у неї впираються та що лежить вище — це окрема велика тема, якій я присвятив наступну статтю.
Хто реально ухвалює рішення щодня
Поки архітектор оперує ідеальними картинками, тімлід живе в суворих технічних і часових обмеженнях. Працює простий принцип: архітектор каже, що робити («тут буде Circuit Breaker»), а тімлід вирішує як — яку бібліотеку взяти, як її налаштувати, чи не буде це overkill для нашої задачі й чи потягне команда це прямо зараз. Вибір і реалізація Enterprise- та Microservices-патернів на практиці лежать на ліді й команді. Тому і в аутсорсі, і в продукті висновок однаковий: реальні щоденні рішення про систему ухвалює команда на чолі з тімлідом.
Тут зазвичай починають сперечатися про назви посад, тому одразу: ми говоримо не про запис на бейджі, а про функцію. Якщо у стартапі «архітектор» сам кодить, керує командою й особисто визначає всі рішення, бо вас лише п’ятеро, — це тімлід, хай на візитці хоч CTO. А «тімлід — архаїзм, у нас Engineering Manager» нічого не спростовує: EM здебільшого й робить те, що ми описуємо, а поділ ролей (EM + Tech Lead, Tech Lead Manager, Team Lead) — штука company-specific. Назва змінюється від компанії до компанії, а функція «хто щодня вирішує, як працює система через команду» лишається.
Дизайн на рівні коду + hands-on контроль
Архітектор зазвичай сліпий усередині сервісу. Він оперує великими кубиками й малює стрілочки між базами та мікросервісами, але диявол ховається в деталях. Помилки в розподілі відповідальності, криві абстракції, tight coupling — усе це вилазить уже на рівні коду. Рятувати ситуацію доводиться тімліду — через щоденний Code Review, де він стежить, чи правильно розбиті класи й чи не порушено інкапсуляцію, оперуючи не абстракціями, а SOLID, GRASP і GoF. Він же вирішує, як налаштувати рев’ю так, щоб воно не стало пляшковим горлечком.
Сюди ж — увесь hands-on: CI/CD, рівень покриття тестами, лінтери, стандарти розробки. Бо архітектура без інженерної культури — це просто малюнок на серветці. Можна намалювати ідеальну подієво-орієнтовану систему, але якщо команда комітить прямо в main і не знає, що таке інверсія залежностей, вона розвалиться під власною вагою за два місяці. Саме тімлід будує культуру, яка робить архітектуру життєздатною.
Висновок: розвилка вибору
Я не намагаюся знецінити архітекторів — це важлива професія зі своїми чіткими межами. Тут просто є чесна розвилка. Хочеш малювати високорівневі діаграми, виступати перед замовниками на пресейлах і не відповідати за баги на проді о третій ночі — твій шлях в архітектори, і це абсолютно нормально. Хочеш реально визначати, як працює система зсередини — від патернів у коді до того, що піде в реліз, — твій шлях у тімліди.
Справжній архітектор системи у 2026 році — це не той, хто намалював гарну схему на старті й пішов. Це той, хто щодня вирішує, що саме піде в реліз. Тобто тімлід. Практичний крок «на завтра»: подивися на свою систему й чесно дай відповідь — хто ухвалив останні п’ять реальних рішень про те, як вона влаштована: архітектор зі своєї схеми чи твоя команда під час код-рев’ю в окопах? Ця відповідь і покаже, хто нею насправді володіє.
Але хто володіє системою — лише половина історії. Сама влада — ще не причина її хотіти. Навіщо вона тобі й що реально тримає інженера в проєкті роками — у наступній статті.
31 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарівНа жаль, ця публікація виглядає радше як матеріал рівня жовтої преси, ніж як фахова дискусія про ролі в інженерних командах.
Протиставляти архітектора і тімліда в такому спрощеному вигляді — некоректно. Архітектор апріорі має значний вплив на систему, оскільки саме він визначає її рамки: архітектурні принципи, ключові технічні рішення, обмеження, інтеграційні підходи, нефункціональні вимоги та довгострокову еволюцію платформи.
Роль тімліда не менш важлива, але її фокус інший — насамперед delivery: організація роботи команди, якість виконання, технічна координація, підтримка інженерів і доведення задач до результату.
Крім того, залучення AI до SDLC лише посилює роль архітектурного мислення. Коли написання частини коду дедалі більше автоматизується, цінність зміщується не в бік «ручного кодингу», а в бік постановки правильних рамок, декомпозиції, системного дизайну, контролю якості рішень і розуміння trade-offs.
Тому дискусія про «хто важливіший» сама по собі хибна. Значно продуктивніше говорити про зони відповідальності, контекст і зрілість інженерної організації.
Едуарде, розумію, чому рамка «тімлід vs архітектор» могла сприйнятись спрощено — заголовок навмисно провокативний, це кар’єрний текст, не org design whitepaper.
Але, здається, ми все ж говоримо про різні питання. Я не ставив «хто важливіший» — я розбирав кар’єрний міф: сеньйори часто йдуть в архітектори, очікуючи щоденної влади над системою, а на практиці ця влада у тімліда й команди, яка деліверить.
Зони відповідальності — згоден, вони різні й доповнюють одна одну. Архітектор задає рамки — тімлід і команда вирішують, що реально піде в реліз під бюджет, дедлайн і навички людей. Саме це я називаю «владою над системою» в щоденному сенсі.
Щодо AI: коли код пишеться швидше, ціна помилки в рамках і trade-offs лише зростає. Але хто перевіряє, що згенерований код не ламає інкапсуляцію, не тягне зайвий coupling і проходить рев’ю — знову команда в окопах, не схема з пресейлу.
Ваш приклад «якщо тімлід розбирається в архітектурі — архітектор не потрібен» — це якраз моя теза про функцію, а не титул. У багатьох компаніях це одна людина.
У наступній статті серії (скоро на DOU) піду в інший бік: навіщо взагалі хотіти цю владу, якщо гроші — не єдиний мотиватор. Там — про 4 рівні залученості й чому «x2 full-time» — пастка, а не лайфхак.
Так це ж архітектор має правильно вибрати підходи і паттерни, а лід відповідно визначити, що пріоритетно.
Далі — якщо цей «тімммм-лід» не розбирається в архітектурі, а «архітектор» піде, і все стане — то нащо йому така «влада». Ще й за баги відповість, не знаючи звідки вони взялись :)
А якщо ж він розбирається на достатньому рівні — то «архітектора» на цьому етапі вже й не треба.
можу додати трошки з власного досвіду\домену
наш інструмент — це один з лідерів ринку для Enterprise Architecture, тобто моделювання, симуляція, презентації, звіти, інтеграції з всякими тулами і так далі.
ну і наш кор-юзер — це Enterprise Architect
ці люди постійно жаліються, що «nobody listens us, nobody wants to work with us, we never get to influence the real decisions». Чуваки незважаючи на титул, формальні\неформальні права — мають дуже обмежений імпакт на тех-стак.
чи так всюди? ні. Але з мого досвіду за 8 років роботи з клієнтами з США, ЄС, Африки і Близького Сходу — ну 90%. Буквально вчора сиділи на колі з Архітектором з Водафон і він жалівся, що кожна група там по своєму всьо рішає і централізованого підходу до Architecture в них нема.
це звичайно трішки інша роль але багато людей думають, що коли стануть Enterprise Architect, то вони зможуть там вирішувати якісь нано-технологічні-перделки і всі бізнес юніти підуть за ними. По факту, їм кажуть підтертись своїми кредлами і сертифікатами та займатись 100500 речами поза архітектурою)
Станіславе, ваш кейс з Enterprise Architect — це майже ілюстрація до статті, тільки на іншому рівні абстракції.
«Влада» тут — провокативний заголовок для кар’єрного тексту, не org design. Я мав на увазі не політичну владу в корпорації, а хто щодня визначає, як система реально працює в проді.
EA і Solution Architect — різні тварини, згоден. Але мрія сеньйора «стану архітектором — і всі підуть за моєю схемою» часто б’ється об ваше «nobody listens to us» — незалежно від титулу.
Про top-down: якраз навпаки — я за те, щоб рішення народжувались у команди, яка релізить, а не в вежі, яка раз на квартал скидає PDF. Ivory tower — це якраз те, проти чого стаття.
Solution Architect це трохи не то..
Ну в общєм і целом це все залежить від конкретної людини і компанії
Але на рахунок більше влади, ну найбільше влади у мідлменеджмента, стереотипних товстих потних індусів якщо це бігтек, з акцентом. Чому ніхто не хоче бути такими? А «влада» архітекторів як і будьяких інженерів — це влада рибок над тим де рити норку в акваріумі.
Фреймворк статті й упор на владу мене не влаштовує. Це поверхнево. Люди більш багатогранні за це. Це попахує старими топ-даун ієрархіями управління і твердолобим интирпрайз де рішення спускаються зверху погоничам, а ті нагайками свистять. Системи менеджмента теж більш різноманітніші за це.
ivory tower підхід, є вежа де сидять супер-розумні-архітектори і скидають вниз якісь плани\доку\стандарти раз на пару місяців але самі вже забули як кодити і що робить бізнес
але Solution Architect не приймає рішень взагалі і не робить технічних як то зкрема то не є технічна роль за розкладом
... мені цікаво навіть стало от жеж що каже ші )) “what is Solution Architect”
як класика же ж ))
SA це кастмерфейсін роль, архітектурити бізнес солюшен для кастомера в рамках того що тому кастомеру хочуть впарити і допомогти кастомеру реалізувати велю який він очікує
не приймає рішень і не технічна роль — це теж не зовсім правильно.
Але це не інженер-тех-архітект звісно
А коли кастомера нема — а білдять якийсь копроентерпрайз?
Ну можна звісно навіть прибиральницю назвати солюшен архітектором чистоти
Звучить гарно, але толку нуль і суть роботи не міняється
Ніхто звісно не забороняє нікому роздавати які хочеш гарні лички
Олександре, так — класичний SA в аутсорсі ближчий до customer-facing, ніж до «людини, яка щодня тримає архітектуру в коді». Саме тому сеньйори, які мріють «приймати всі технічні рішення», часто промахуються з очікуваннями ролі. Рішення там є — але іншого типу: рамки, scope, trade-offs для замовника, а не класи й рев’ю щодня.
Роль тім-ліда може виконувати хоч QA, хоч PM, хоч BA. Обов’язки цієї ролі — вести команду до цілі.
Посада Тех.Ліда — це посада з завданням вирішувати як той чи інший функціонал, який робить команда дійде до користувача, і що робити якщо щось пішло не так. Часто це найсенйорніший розробник в команді, але не обов’язково. Можуть бути спеціалісти які більш сенйорні в якійсь частині (наприклад, DevOps, FE, BE, DS, і т.д.), і його задача звести все докупи.
Часто це поєднують і вимагають від Тех.Ліда, ще виконувати роль Тім.Ліда. Але коли на проекті бардак, то Тех.Ліду найважче, бо треба і системою займатись, і технічні проблеми, і комунікацію, і процеси...
тоді вже не «вести» но просто слідкувати як вона «іде» щоб здебільшого «доповідати начальству» бо то імхо є край специфічна до «(вітчизняного) аутсорсингу» роль
... у бізнесі такого нема не зовсім зрозуміло що таке буде «тім лід» узагалі яка саме його функція по відношенню до «тіма»?
... кіно Hidden Figures там був colored computer group яким фактично виконувала роль супервайзера одна жінка але формально їй не давали саме титул як формальний саме «супервайзера»
так само інженерно є lead engineer але воно не стосується до team
тож знову ж таки то є відноситься виключно до вітчизнаного аутсорсу імхо
Тепер і тех лід теж не модно називати, а Delivery Manager або Product Manager. Знову таки Lead аттавістична застаріла лиска минулих класичних ієрархічних ситстем керування в ІТ, без розділень повноважень і т.д. — ленійний керівник.
Сьогодні в західному світі ролі розділяють, як би не хотілось а коли в проекті 200 людей займатись 1 to 1 та обговорбювати фідбеки, тенінги та зарплати технічному керівнику який відповідає за реалізації цілей бізнесу просто нема коли. От цю роботу передають Engineering Manager.
В аутсорсі там по різному буває і від акаунту залежить. Десь в мобайлі це личка яка відповідає L5 Senior dev в BigTech. В інших акаунтах тієї самої компанії, це може бути рівень L6 Staff. Десь на шхуні це може бути рівень CTO чи Princepal в BigTech, тобто людина реально має повноваження на рівні визначення ІТ екосистеми. Це умовно «командир кулеметного катеру», по факту це лейтенант, однак рівень його повноважень на цьому катері — визначний.
Володимире, ви фактично розклали те, про що стаття: тімлід != техлід, але на більшості аутсорс-проєктів це одна людина — і саме вона тримає delivery. Engineering Manager на Заході — та сама функція, інша личка. Назва міняється, питання «хто релізить» — ні.
Все ж просто — йди в контору класом вище.
Все ж просто — йди в контору де платять більше, а вимагають на гора видавати менше
український мілтек рулить!
Обидві лиски можуть означати як абсолютно нічого так і абсолютно усе при чому залежить від проекту.
Як вірно зазначено народ хоче вибратись на рівень персон які приймають рішення (отримати владу якщо перефразувати), як би не називалась лиска будь то : Vice Presendent, Fellow, Генерал або Адмірал.
А тут вже діють рішуче інші речі, ніж наприклад знати патерни та принципи проктування на зубок, чи вміння організувати комунікації та вибудовувати процесси із CI/CD та DevOps. Якщо давати поради собі в минулому, то в бізнесі найбільш важлива навичка лише одна — вміння заробляти гроші. Інщі питання насправді не принципові і їх просто делегують найманим працівникам, зокрема які фізично знаходятся в інщій країні від тієї в якій ведеться бізнес і коштують такі працівники 10 і більше разів дешевше. А то і в одному офісі знаходятся, але від білих співробітників в синіх корпоративних худді ходять в рожевих худді із лоховськими червоними бейджиками контрактора (www.inc.com/...ation-california-law.html) бо народився десь в Бангалорі і закінчив не Стенфорд. Бо «Нижним чинам и собакам, вход в Крондштадский парк воспрещен».
І далі йде здоровенний допис про те, що архітектори безполєзні, або сейлзи або сидять на лєгасі, а все цікаве у тімліда. Okay
Сергію, справедливе зачеплення — і, мабуть, моя недоробка в формулюваннях.
У статті я говорив про посаду «архітектор»: Solution Architect на пресейлі, хранитель core, окремий поверх без доступу до прикладного коду. А у вступі написав, що FoxmindEd «навчає архітекторів» — і там це слово в іншому значенні: архітектура як інженерна навичка, а не титул на візитці.
Ми вчимо людей розбиратися в архітектурі — trade-offs, патерни, системний дизайн, рамки. Щоб інженер міг бути архітектором за змістом роботи, а не обов’язково йти на посаду з цим словом у назві. Тімлід або техлід, який щодня вирішує, як влаштована система і що піде в прод, — це і є архітектор у нормальному інженерному сенсі. Саме про таку функцію йшла мова, коли я писав, що «справжній архітектор системи — це той, хто деліверить».
Стаття — не про те, що архітектурне мислення марне. А про те, що сеньйори часто плутають титул «архітектор» з очікуванням щоденної влади над системою в коді — а на практиці ця влада у того, хто релізить. Посада архітектора має інші межі, і це нормальний шлях, якщо ви розумієте, що саме купуєте.
Розділити «посада архітектора» і «архітектор як функція» варто було чіткіше в самому тексті. Дякую, що підсвітили.
В статті намішані ролі (не позиції, а саме ролі):
* тімліда, котрий соває дошкою тікети в Джирі, та апрувить хайри, файри й лікарняні. І ще й слідкує, щоб команда була щасливою й не пересварилася.
* техліда, котрий овнить компонент, над яким працює команда — або делегує овнершіп субкомпонентів.
Власне, техлід повинен бути найдосвідченішим розробником, і він переймає дизайн від архітектора (якщо один архітектор припадає на декілька команд), проробляє деталі, й слідкує за якістю та гнучкістю імплементації.
І оці дві ролі не повинні перетинатися на проектах з технічно складними доменами — інакше отой один «універсальний лід» сидітиме на роботі по 12 годин майже щодня, і все одно або на менеджерську роль, або не технічну не вистачатиме часу. Я це бачив.
По результату ролі розділяються: тімлід рухає срам дошкою й грає в Манчкіна, а технічним керівництвом займається якийсь бородатий сіньор — може й не зовсім офіційно.
Альтернатива для невеликих проектів — це не відпускати архітектора. Тоді він може побачити, як його архітектура розвивається з часом, і отримати справжній фідбек про якість своїх рішень.
Ось стара стаття за різні типи архітектів 6it.dev/...-to-coding-architects-626
А якщо цікавить початитися на різні навколо-архітектурні чи -менеджерські теми, то заходьте на чай t.me/swarchua
Лиска Lead взагалі застарілий рудимент IBM, якого нема навіть в самому IBM. Як колись поруччики, корнети та ротмістри були. Сучасні тайтли якщо рівнятись на BigTech як безумовних лідерів індустрії, доки їх китайці не стратили.
Googe:
The Individual Contributor (IC) Track
- L3: Software Engineer II — (The “New Grad” Level) — standard entry-level tier for recent university graduates or engineers with less than two years of industry experience
- L4: Software Engineer III
(Mid-Level) — The mid-level engineer who can operate with minimal day-to-day hand-holding. This is often where incoming PhD graduates are placed. - L5: Senior Software Engineer — The “terminal level” at Google, meaning there is no pressure to advance past this point. Many engineers spend the rest of their careers happily at L5.The “terminal level” at Google, meaning there is no pressure to advance past this point. Many engineers spend the rest of their careers happily at L5.
- L6: Staff Software Engineer — This is a highly competitive tier that represents a major shift from executing projects to setting long-term technical direction
- L7: Senior Staff Software Engineer — an elite technical tier. Reaching L7 requires proven, multi-year impact that shapes an entire organization or product division (e.g., Google Search or YouTube Infrastructure).
- L8: Principal Engineer — this is an executive-level technical role. Principal engineers own entire core technologies or product directions. They serve as the highest technical authorities in their respective domains and provide technical guidance directly to Vice Presidents and directors
- L9: Distinguished Engineer — a rarefied title reserved for engineers who shape company-wide architecture and innovate at an industry-defining level.
- L10 & L11: Google Fellow / Senior Google Fellow — the pinnacle of the technical ladder, equivalent to a Vice President or Senior VP. There are very few Google Fellows globally (notable examples include internet pioneers like Vint Cerf and AI pioneers like Jeff Dean).
Починаючи ще зУ Microsoft така сама система, а Amazon назвиває Distinguished — Partner.
Архітектуру підсистем розробляють на рівні L6. Senior Staff Engineer що приблизно відповідає рівню військового звання Полковника чи Капітана першого рангу. Загальна архітектура систем The Ecosystem на рівні вже L8 / L9 в інших компаніях це зазвичай рівень CTO, це рівень генералів та адміралів у військовому еквіваленті, які планують операції і т..д.
Як ми усі знаємо в IT аутсорсі, чи в BigTech чи на віть в усіх арміях усього світу існує “glass wall” (or geographic ceiling) — тоб то ті рівні які генеральські, вони в локаціях типу : Києва, Кракова або Бангалора не доступні взагалі, вилючно преїзд із підвищеням до метрополії куди небудь в Сан Франциско або Вашингтон ДС. Шоби бути елементрно поряд із керівництвом/командуванням або клієнтом, а не різниця в часі в 7 годин наприклад. Тому часто рекламують NCO напрямки, хоча тут усе те саме Account Manager/Delivery Manger рівень — це якщо компанія з українским корінням тільки.
P.S. Так американський бізнес прямо копіює структуру командування збройних сил США.
Денисе, згоден на 90%.
У складних доменах тімлід (люди, процеси, щастя команди) і техлід (дизайн компонента, якість імплементації) не повинні бути однією людиною — інакше 12 годин на день. Саме тому в статті я свідомо говорив про функцію, а не про бейдж.
На українському ринку ці ролі часто зливають в одну «Team/Tech Lead» — і тоді саме ця злита роль володіє тим, що йде в прод. Архітектор, який лишається на проєкті й бачить еволюцію своєї схеми — це вже ближче до техліда, ніж до класичного пресейл-архітектора. Ваш варіант «не відпускати архітектора» — якраз про це.
Дякую за лінк на 6it.dev — гарне доповнення.
На Лінкедіні в цій компанії 11 associated members, включно з part-time CEO.
Маленька шхуна на сленгу, це теж насправді нічого не каже — ключове питання скільки забробляє цей бізнес, тобто AUM per employee. BlackRock в 1988 починався як 8 людей, зараз Персонал приблизно 24900 людей, тобто $558 мільйонів капіталу на одного співробітника. Але і вони не чемпіони, це Geode Capital Management — під управлінням понад $1.5 трлн, їхній штат становить всього близько250–300 людей. Це дає астрономічні $5–6 мільярдів на одного співробітника. Хоча при цьому чиста маржинальність бізнесу 25%.
Є ще чемпіони із маржинальності безнесу, де абсолютний глобальний чемпіон це NVIDIA по загальних показниках. Існує ще прихована маржинальність : ARM та Qualcomm мають маржинальність в 90%.
Ну якщо із усіх випускників школи найняли 10 людей — то ніби-то щось не так чи зі школою, чи з випускниками, чи зі шлюпкою. І чим тоді тут хвалитися?
Загальна тенденція серед випусників курсів в ІТ в усьому світі роботу знаходять 2% від тих хто був на старті. До кінця курсу доходе і виходит на ринок праці не більше 5%, 50% кидають к другому місяцю по комлексу причин як то брак часу і невідповідності очікувань, виявляється це складна інженерна спеціальність.
Сергій пішов в медійку і системну рекламу своїх навчальних послуг, з елементами інфоциганства не без цього. Та те що зараз гонять інші курсоділи, яких я відключаю геть — там ну просто пісець. Зарплата $50 на годину ми допоможемо із працевлаштуванням в кінці. Англійську знати не треба, математику не треба і т.д. і т.п. Так ІМХО курси повністю мертва бізнес модель станом на зараз із цілої низки зовнішних факторів яка поховала цей бізнес.
«Оберігач», хоча «хранитель» теж присутньє, але мені здається це ближче до суржику. Сорі що вліз.
Берегинь