Comments 79
Еще подстветил бы важный момент: узнать у бизнеса чего они ожидают от тимлида, какие роли берет на себя эта должность. Я четыре раза становился из разработчика тимлидом, и все четыре раза это была разные тимлиды.
Да, это важный момент, но когда я начинал, я и сам не знал, что от меня требуется и такой проблемы не было. Но сейчас, если проходишь собеседование на лидовую позицию, то это главный вопрос к интервьюерам. Спасибо.
Большинство бизнес-оунеров вам никогда не скажут что они хотят от тимки, т.к. в принципе не знают что сказать.
Не только от бизнеса, но и от технического руководителя.
Кстати, как к бизнесу, так и к технарям желательно приходить со своим видением. Вполне возможно, они его одобрят с некоторыми корректировками, и вы будете заниматься тем, что озвучили.
А потом регулярно синхронизироваться, чтобы понять, а в одну ли сторону мы все гребем?
Когда разработчик становится тимлидом, это значит, что в вашей команде теперь на одного разработчика меньше. Это ключевой момент, который нужно четко уяснить в своей голове, а также обязательно обсудить с бизнесом.
Не согласен. Сколько Тимлидов за жизнь перевидал — вынес следующее: Лучший Тимлид — "Играющий тренер".
Тимлид вообще странная позиция и непонятно чего от неё ждут. Я всегда думал что это мечта программиста пока не попробовал - в моём случае это была какая-то смесь сеньора, архитектора и менеджера. Ничего хорошего в этом нет, по сути это попытка сделать менеджера понимающего продукт до малейших мелочей, но на выходе в лучшем случае средненький техлид и средненький менеджер.
Играющий тренер - Это скорее сеньер с правами на управление тасками.
Я кстати наоборот, считаю что для бизнеса лучший тимлид это тот, который даже не знает технологию на которой пишет команда. И его задача сформировать команду, которая сможет работать без его технической экспертизы.
И его задача сформировать команду, которая сможет работать без его технической экспертизы.
не всегда бизнес такое может себе позволить
вот я тимлид, у меня 4 миддлов и 2 джуна, постоянно норовят начать чертовщину какуюто кодить в сторону от архитектуры проекта… а сеньора найти пока не могут
на прошлой работе у меня в команде было 3 сеньора… вот это было прям счастье великое, там я реально почти не кодил
На мой взгляд это уже тогда не тимлид, а скажем менеджер. Тимлид, даже если сам не пишет код, должен быть как минимум в состоянии в этом самом коде разобраться.
Это, опять же, к вопросу об умении делегировать.
+1
Ага, особенно понравилось пусть команда сама решает, не вмешивайся в задачи. Видел я во что превращается проект при таком подходе. Потом столько же времени рефакторить и оптимизировать....
Хорошие советы, вспомнил свои первые пол года - столкнулся ровно с тем же
Я бы поспорил с названиями. Что значит не занимайтесь планированием? Планированием то заниматься как-раз теперь надо. Но планированием, а не разбором поддержки и техдолга. И желательно даже не приоритезацией.
А четвертый пункт лучше было бы обозначить "научитесь делегировать".
"Не быть узким горлышком" можно и работая по 20 часов в сутки, но через пол года бизнесу придется искать нового тимлида - это не очень выгодный обмен
не занимайтесь планированием?
Вас только этот заголовок смутил? В заголовках сказано что не нужно делать. Не нужно не заниматься планированием.
Кстати да, некоторые на руководящих должностях стараются все замыкать на себя, а потом рвут попу пытаясь отбивать возросший поток запросов, становясь узким горлышком во всех процессах. Встречал мнения что такое бывает от неуверенности и по глупости: неуверенные так пытаются стать незаменимым звеном.
А как же пункт "помогать всем и вся одновременно"?
Сколько времени тимлид может и должен уделять кодингу — зависит от размеров команды и опытности разработчиков в команде. Если вся команда — 4 человека — тимлид не может не кодить. А если 16 человек — не может кодить. И чем менее опытны разработчики — тем больше времени тимлид должен уделять управлению ими.
Ощущение что мало кто понимает что такое тимлид, чем он отличается от проектменеджера. Хотя это вроде как то, с чего надо начинать. Как можно определить свои обязанности, не понимая что ты должен делать? Как можно назначать человека на должность не понимая, какую роль она выполняет?
Я когда-то достаточно комфортно для себя определил понимание что это такое через генезис тимлида в команде как самостоятельной роли. Есть небольшая команда из одного разработчика, у него есть ПМ и архитектор. Разработчик кодит, остальные подкидывают ему задачи на вход: архитектор говорит что и как должно получиться на выходе, ПМ что и к каком сроку должно быть сделано, планирует ему загрузку, все прекрасно. Объем задач в единицу времени возрастает и в какой-то момент разработчику перестает хватать физического времени все сделать. Он легко может написать разные участки кода на один продукт, но в один момент он может сделать только что-то одно из. Тогда мы берем и добавляем ему дополнительную голову и пару рук, в виде второго кодера, который сможет писать эти отдельные участки кода параллельно с первым. С первого снялась задача писать часть кода, но появилась задача админить второго: ставить ему конкретные задачи какие куски писать, сроки, контролировать выполнение. Для выполнения того же объема работ администрирвоание второго занимает значительно меньше времени, чем собственно написание кода. И админство это совсем другая работа: ты должен контролировать старт и финал того куска, который отдаешь второму кодеру. С довеском: надо контролить компетентность второго, оценивать риск его ошибок, предпринимать меры к их минимизации и исправлению.
Далее мы масштабируем первого кодера до тех пор, пока ему не остается больше ничего, кроме как админить команду, непосредственно под его руководством пишущую код.
То есть тимлид это такой своего рода размноженный смасштабированный кодер, который координирует написание кода так, как если бы писал его сам, но сбрасывая непосредственное написание на рядовых кодеров, коллективный кодер из вышеупомянутой схемы с ПМа и арзитектора. И коммуницирует он с внешней командой как тот самый, первый, одинокий разраб в самом начале, изолируя непосредственных исполнителей от этой задачи.
Отсюда и следуют требования к нему.
Из этого следует, то что простые разработчики общаются только между собой и тимлидом. Простые разработчики не хотят на созвоны с ПМами и прочими паразитами. Это тимлид должен создавать задачи по написанию кода и думать о том как выполнять их параллельно.
А ПМ должен вести переговоры с бизнесом (выступать в роли БА) или самому генерировать требования.
Здесь ПМ - это ПРОДУКТ менеджер, который отвечает за коммерческий успех продукта.
Сюда может добавиться бизнес аналитик, который будет заниматься документированием требований. И вот когда его нет, обязанности аналитика делятся между ПМ и Тимлидом.
Все недопонимание происходить из-за того, что некий глава этого продукта не хочет или не может полностью за него отвечать, а вместо того, что бы нанять ПМ/БА скидывает это все на ТимЛида
Либо другой вариант, ПМу нечем заняться и от интересуется что там с задачами создает и двигает карточки, созывает бесполезные созвоны.
Ну, я рассматриваю здесь именно ролевую модель. На практике эти роли могут быть растянуты на разных людей в произвольных пропорциях. Причем эти пропорции будут ситуативно меняться. Функциональная, или ролевая, модель, совпадает с организационной только в сказках. А все благодаря неравномерной/непредсказуемой нагрузке на каждую роль. Хотя на больших масштабах можно добиться близкого сходство с ролевой, если грамотно рулить балансировкой нагрузки на разных юнитов, в разумных пределах конечно.
В целом ролевой состав команды, разумеется, не ограничивается тем, что я описал в комментарии, и продукт, и аналитик, и КАМ участвуют в процессе, и топменеджмент в виде исполнительного, технического и финансового руководства, и прочая и прочая. Я для простоты намеренно ограничил зону видимости стороной ТЛ на этапе кодинга. Так то он еще и в разработке ТЗ может поучаствовать например, в качестве эксперта.
Интересная модель. Но про тимлида хоть что-то разумное нагуглить можно. А я, к примеру, тут уже месяц мутирую из эмбеддера в инженера проекта, и пока вообще непонятно, про что это всё
А еще с конторой надо на берегах договориваться о том, что для них "тимлид"
Я пытался стать им 3 раза, и всегда это были "и жнец и чтец и на дуде игрец".
Я думал, всегда, что тимлид пишет код своими и чужими руками. И только. Но доходило и до постоянных поездок к заказчику, чтобы "выпросить у него открыть tcp порт"
И совещания по 5 раз с менеджерами заказчиков, которые одно и то же говорят по 5 раз.
И даже покупание всяких странных софтин и переговоры с отделом продаж!
А еще мне как-то подсунули рандомного парня и сказал - "ты его будешь теперь обучать"
А я сказал, что я не буду его обучать, потому что 1) Он мне не нужен и я не просил 2) Я не курсы по программированию
Ага, и чем он отличается от начальника отдела. У нас на отдел из 10 человек + начальник бизнес хочет выделить 2 тимлидов по направлениям ТП и разработки. Причем именно выделить, а не нанять, то есть и так задач чуть больше, чем сделать можем, а теперь еще двоих в руководство перевести.
Это кажется от того, что они понимают, что начальника отдела умахали совещаниями и рисованием графиков выполнения задач за/на прошлый/будущий квартал и на работу с сотрудниками у него времени нет.
Усложнение иерархии это всегда потери КПД для отдела, и идти на него можно (нужно) только тогда, когда объем задач вырастает (или их характер усложняется) достаточно, чтобы потери на их индивидуальное администрирование суммарно начинают превосходить потери на выделение отдельного администратора/координатора процессов. Если большинство времени рядовых сотрудников идет на непосредственное решение задач, а не на их обеспечение, значит структура отдела для такого объема сбалансирована. Выделять начальника это всегда вырезать чистое время исполнения из общего вала, которое он выполнял, будучи исполнителем.
Другими словами, если производительность падала из-за внутреннего хаоса и неразберихи, такое решение может быть эффективно. А если нет, то нет.
Если же ваше предположение верно, то меньшим злом было бы выделить ему одного исполнительного зама вместо двух тимлидов, которые на самом деле не тимлиды. Хоть минус один, а не минус два.
толково расписал, плюсану, проходили
Отличная статья, узнаю себя в ней. Особенно первый пункт. Относительно недавно стала продактом и мне до сих пор страшно забыть как кодить;(
Очень хорошо всё расписано, немного дополню.
По п. 1 — кодить всё равно приходится, но нужно брать только те задачи, которые невозможно делегировать. Как правило, это самые «мутные», плохо сформулированные задачи. Как только задача стала яснее (например, её удалось декомпозировать) — нужно постараться сразу отдать хотя бы часть.
По п. 2 — есть примерно такая формулировка: «Инструменты разработчика — компилятор, IDE, линтер и т. п., инструменты тимлида — прежде всего другие разработчики, а потом уже компилятор, IDE, линтер и т. п.». Музыканты ещё говорят, что дирижёр — это такой музыкант, который играет «на оркестре».
По п. 3 — планирование всегда больной вопрос. Во-первых, на планирование надо выделять отдельное время. Например, полчаса с утра для того чтобы подвигать задачи на своей личной канбан-доске. Во-вторых, рекомендация для других людей «планировать встречи, глядя в ваш календарь» — очень спорная. К сожалению, некоторые коллеги страдают болезнью «скучно? собери совещание!», и ты вдруг понимаешь, что у тебя вообще весь календарь расписан какими-то непонятными встречами. И поэтому в-третьих, следует приучить коллег, что вопросы надо решать в порядке приоритета - коротким сообщением в мессенджер, письмом, звонком, и если только не получается договориться - собирать совещание.
В порядке обмена опытом — если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана (или в дополнение) хороша техника «ментальных карт» (mind maps). Особенно полезна при сложных миграциях, где надо обеспечить непрерывность сервиса.
По п. 4 — да, всё так, стоит тимлиду расслабиться, и проектная команда начинает вешать на него принятие всех мелких и не очень мелких решений. Нужно уметь «возвращать» вопрос, т. е. спрашивать «а что бы сделал ты? а почему так? а какие вообще ты здесь видишь варианты? какие из них лучше?» Именно так сотрудники и развиваются. Также нужно учить сотрудников «не держать информацию в себе» — сообщать тимлиду о проблемах — немедленно, другим участникам проекта — какие решения приняты и почему.
В мутных задачах и разбираться долго и мутно. Точно не стоит вешать на себя, если ты тимлид. Потому что становишься бутылочным горлышком, а тебе ещё на остальные свои дела время надо. Лучше выделить достаточно умного разработчика с предложением решить как-нибудь, а в процессе решения добавить ясности.
Мутная задача — прежде всего плохо поставленная задача. Разделить её на понятные, т. е. которые можно делегировать подчинённым «по S.M.A.R.T.» — это и есть задача тимлида. Парадокс, но иногда для этого надо немного покодить :)
Ваш п.2 только подтверждает п.1. Любой дирижер сам умеет играть, а то и на нескольких инструментах - но его функция в оркестре совсем другая.
если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана
если задачи выстраиваются друг за другом и их взаимное влияние очевидно, то почему канбан, а не диаграмма Ганта?
Ну автор в статье упоминал канбан, я так понял, ему «зашло». Диаграмма Ганта — она скорее для оценки времени выполнения целого проекта или большого этапа проекта, а канбан — для структурирования входящих запросов и выстраивания приоритетов.
Потому, что она нифига не влезает на печть. Логично что упорядоченный столбик удобнее читать, чем диагональ.
Я тимлид уже пару лет, и меня до сих пор фрустрируют моменты от "не особо много пишу код" до "бывают дни, когда не ясно, что за результат". В этом плане статья прям в точку попала.
Глобально ошибок две:
Не делегировать когда это надо делать
Делегировать когда это не надо делать
А вот понять когда что это сложно.
Нет четкого определения кто такой тимлид и что должен делать. Поэтому много вопросов на этот счёт. По нашему это называется руководитель группы разработки. Т.е. очевидно, человек должен руководить процессом разработки в своей группе. В зависимости от типа компании, состава команды, специфики заказчиков, типа проектов, процесс разработки может быть сильно отличающимся. Задача руководителя разработки сделать так, чтобы работа была сделана как можно качественнее за как можно меньшее время. Он должен уведомлять вышестоящее руководство о проблемах, которые требуют их участия, например, нехватка программистов, нехватка компетенций, проблемы с аналитикой тестированием и т.п. Если для решения этих задач ему надо программировать, он должен программировать. Не вижу противоречий. И не могу представить тимлида который сказал бы что не хочет ни в коем случае писать код. Например, он решил что надо попробовать новую либу или новый подход. Он может поручить исследование разработчику. Если разработчики заняты, может исследовать сам, почему нет. Если ему постоянно приходится выполнять роль обычного разработчика делая задачи спринта большую часть своего времени, значит в команде не хватает разработчиков, его задача послать сигнал руководству. В конце концов, сами смотрите что надо делать, конечная задача ясна.
>Постарайтесь в первые 6 мес. выбрать из команды своего заместителя,
>который будет заменять вас в отпуске или во время болезни. Хочу
>отметить, что назначение заместителя ничего не имеет общего с
>делегированием задач.
Надеюсь, это "назначение" не принудительно, а по согласию? )
Надеюсь, за это приплачивают? )
>Можно делегировать любую задачу любому
>разработчику (например, отправить вместо себя на встречу).
А вот такое я лично не люблю. С таким же успехом можно попросить окна помыть или сбегать за пивом. Тут надо сразу на берегу оговорить обязанности подчиненных. В зрелых компаниях есть четкая должностная инструкция и/или что-то типа матрицы компетенций/обязанностей. Понимаю, что все трудно учесть и формализовать, но требовать от разрабовать выполнять ваши "лидерские" задачи...ну, такое...)
Назначение скорее добровольное, потому что обычно есть, чем заинтересовать разработчика побыть и.о.
Делегирование задач разработчику - так, чтобы окна помыть или забор на даче поправить, не бывает) Обычно я отправляю вместо себя разработчика, если вопрос и так его затронет и нужна его экспертиза или если это поспособствует его развитию.
Делегировать нужно аккуратно, тут я согласен.
Интересно, чем можно заинтересовать разработчика побыть и.о.?
Обычно в команде есть кто-то, кому интересно брать на себя ответственность за команду, релизы. Основной и единственный мотиватор: пробовать себя в роли лида и развивать управленческие и софт скиллы. Это все выясняется и обсуждается на 1то1 встречах.
Upd. Добавлю контекста)
Вы же разработчика не бросаете на растерзание менеджеров. Перед своим уходом своего разработчика нужно погрузить в текущие задачи, добавить на необходимые встречи и т.д. Т.е. нужно все подготовить так, чтобы и.о. по минимуму трогали всякие управленцы, и он был сосредоточен на команде и предстоящем релизе. Т.е. и.о. работает в лайт режиме.
Обычно, это интересно коллегам. Но если нет, то могут просто по-дружески заменить, если в коллективе хорошие отношения.
В статье отсутствует упоминание какое количество людей в команде. На старте и сейчас.
На самом деле, для того чтобы управлять командой требуется профильное образование. Образование руководителя. Образование менеджера. И какими-то 'курсами менеджеров' это не закрыть. И как не печально это осознавать, у подавляющего большинства руководителей отделов в России это образование отсутствует. Полностью отсутствует.
Дальше вопрос где это образование получить. Есть множество ВУЗов специализирующихся на подготовке управленцев разных направлений. Как правило это элитные специальности с дорогим обучением. Дальше тоже печальная ситуация, подавляющее большинство идут на эти специальности для получения корочек, а не знаний, и любыми способами стараются купить зачеты и экзамены, а не сдать.
Отсюда получается что ВУЗы готовят огромное количество управленцев, а в реальных компаниях управленцев катастрофически не хватает, при чем, на любом уровне управления.
В среде управленческого образования инфоцыган даже больше, чем в среде айтишного образования. Научим MBA по фотографии без рекламы и СМС, прошу прощения за сарказм. Да и, строго говоря, откуда взяться профессорам в этой области? Нет никакой базы, все управление по принципу естественного отбора.
Поэтому управленцы в РФ на 99% самоучки, как раньше в IT. Отечественные мануалы по этому вопросу сводятся либо к мотивирующим мантрам, либо к набору скриптов без малейшего объяснения физики процесса, в лучшем случае - отрывочные знания работающие только в контексте, которого нет. Хотя не понимаю тут чего то мегасложного, работа с командой в принципе то же самое, что и пусконаладка/балансировка масштабируемой микросеврисной архитектуры.
Самое страшно, на мой взгляд, это то, что второе поколение собственников и управленцев, имея соответствующие возможности, отправляется на обучение в западные управленческие школы, и в большинстве своем, в лучшем случае, не становятся хуже. И я не могу понять, то ли наши без соответствующего бекграунда в принципе не способны воспринять тамошнюю парадигму управления, то ли тамошняя парадигма - такой же голый король как и у нас, и все решает личные качества.
А расскажи что именно вы разрабатываете?
Тимлид - это дополнительный головняк практически за те же деньги что и у девелопера. Слово "карьера" слишком громко звучит для данной позиции.
Если просто, то тимлид - это прораб. Основная личная задача, которая именно на нем - рабочий процес разработки. Если человек еще не понял, как это сделать - он максимум сеньор.
Остальное - по желанию/возможности. Есть gap в части архитектуры - заполняй. Есть время кодить - бери тикеты.
Выглядит как будто рабочие пчелы обсуждают обязанности Королевы улья)) Де-факто тимлид - точка входа к прогерам. Что такое техлид, я даже и представить боюсь. Но можно с натажкой представить, что это тот, кто когда-то назывался "начальник отдела эксплуатации"
А де-факто все зависит от того, насколько формальные коммуникации на проекте совпадают с неформальными. И вот это зависит чаще всего от техдира, реже - от фаундера или owner'а.
В целом, основная проблема рассуждений про обязанности лидов - в крайне расплывчатой формулировке этого понятия, которое очень сильно различается от компании к компании.
К примеру - есть два созвучных термина, ТимЛид и ТехЛид. Это одно и то же или это разные вещи? Большинство компаний просто выбирают один из этих терминов и не парятся по поводу деталей. Сама же идея того, что команде нужен технический руководитель, мягко выражаясь, не нова, вот и берётся современный термин для старой, как IT, концепции.
Лучше всего, в теории, на этот вопрос могли бы ответить компании, которые в штатном расписании имеют и тех и других. Я знаю две таких компании.
В первой команды разрослись до неприличных размеров и их реорганизовали, добавив дополнительный уровень иерархии. "Большую" команду возглавляет ТимЛид, а "маленькие", из которых состоит "большая", возглавляет "техлид". Но с таким же успехом можно было бы объявить "большую" команду - "отделом" или "направлением", которую возглавляет "руководитель направления", это было бы даже честнее.
Во второй компании использовали post-spotify матричную модель, в которой ТимЛиды возглавляли команды, а ТехЛиды - технические направления (backend, frontend, devops и т.п.). Эти товарищи просто использовали термин "ТехЛид" для обозначения относительно новой роли, которую правильнее было обозвать "лидерами профессий" или, опять же, "руководителем технического направления", в зависимости от предназначения.
Как правило же используется только один термин из двух, но если мы считаем их разными, то как этот выбор влияет на процессы? Как компании заполняют выпадающую экспертизу и ответственность?
К примеру, мы можем решить, что TeamLead это TechLead+. Т.е. это такой техлид, который дополнительно отвечает за организационные вопросы (скажем, найм, увольнение, распределение премий, мотивацию и развитие). Тогда компании, в которых есть только техлиды, перекладывают эти обязанности на руководителей направлений/отделов.
Однако это, в свою очередь, поднимает другой вопрос - откуда берутся ТимЛиды, эти сверхчеловеки, как они ухитряются поддерживать профессионализм в нескольких слабо связанных направлениях одновременно, откуда черпают мотивацию для столь высокой работоспособности и почему мы все не можем такими быть?
Или мы можем решить. что TeamLead это TechLead +/-, т.е. это технарь, который отвечает за организационные вопросы, но при этом не несёт основной ответственности за архитектуру и принятие технологических решений.
В этом случае ответственность за подобные решения несёт... кто-то ещё. Кто-то вводит роль архитектора направления/отдела, реже команды (тогда это техлид?). Кто-то полагает, что техническую экспертизу должны предоставлять ведущие разработчики (а иначе зачем они вообще нужны?), а в случае, если они не могут прийти к единодушному решению, то его принимает ТимЛид (а иначе зачем нужен он и его технарское прошлое?).
И только определившись с терминологией и, так сказать, штатной организацией, можно серьёзно разговаривать о конкретных обязанностях и проистекающих из этого затруднениях.
Техлид — это разработчик, который первым осваивает новые технологии до уровня, достаточного для перевода на них основных проектов, и помогает это сделать всей команде. Это человек, который пишет библиотеки, которые потом использует вся команда, отвечает за кодовую базу, разрабатывает протоколы. А тимлид отвечает прежде всего за решение задач — строит и согласовывает планы вместе с менеджерами, распределяет задания, детализирует задачи до нужного конкретному разработчику уровня, контролирует выполнение задач, решает спорные ситуации в разработке. Во вторую очередь он отвечает за подбор и развитие, и мотивацию разработчиков. В небольших командах тимлид может также выполнять функции техлида, в больших — работает над технологиями совместно с одним или несколькими техлидами, во многом полагаясь на них.
Техлид — это разработчик, который первым осваивает новые технологии до уровня, достаточного для перевода на них основных проектов
Возможно, в вашей компании всё так и есть. Но я вот не согласен с таким определением - на мой взгляд, это определение ведущего разработчика, они для этого и нужны.
Больше того - нет никаких причин, по которым таких "техлидов" в команде не могло бы быть несколько. И даже больше того - в кроссфункциональной команде их и должно быть несколько (в общем случае).
Но так как единого ГОСТ-а с определениями нет, то каждая компания вправе изобретать свои собственные определения и наполнять их своим смыслом. И всё бы ничего, но при переходе из компании в компанию такие штуки порождают множество wtf-ов с обеих сторон. :)
Если так нравится кодить и не получает грамотно управлять людьми, почему бы не вернуться в разработку?
Первоклассный программист намного лучше посредственного управленца.
Навскидку приходит только один ответ: меркантильность и нарциссизм. Пусть буду больше вредить компании, зато получать на 3 серебряника больше.
@ar2code хотел поинтересоваться каким софтом/cредой/тулзами ты пользовался для ведения личного беклога (списка дел, входящих вопросов, идей и мыслей). Возможно что-то секкюрное, локальное и вероятно гибкое?
А нет ли впечатления от рынка (русскоязычного по меньшей мере), что все сейчас в роль "лид", "VC" и хоть что, хотят играющих не то что тренеров, а вы сразу должны быть стадионом всех? При этом как все в сумме вы получать не будете 😀
#4 - это микроменеджмент. От него страдают все :)
Хорошая статья, примерно полгода эти вопросы так или иначе всем приходится решить и понять для себя
Почему я чуть не запорол свою карьеру тимлида. 4 совета начинающим