Я специально говорю что согласен на озвученную вилку (они в 95% ниже действительно рыночной зп), чтобы потом уже пытаться главным боссом договориться на нормальные деньги, если пройду все собесы.
И еще интересный момент - в обеих статьях вы рассказываете какие плохие кандидаты, в прошлой статье взяли джуна на требования мидла с целью «научим» (это как раз говорит о том что зарплата рыночная только в голове руководителя или кто там у вас зп определяет).
Так вот, если в итоге нанимают «плохих» кандидатов, то как компания вообще работает и как двигаются проекты? Если судить по тому как написано - так можно только в носу ковыряться. Это у вас там случаем не «завод, где ИТ - непрофильный, убыточный отдел»?
Интересно, но свою текущую компанию не нашел - продуктовая, но не биг тех. По описанию вроде похоже, но у нас нет метрик и процессы не очень. Не нравится, что продукты пилятся как лоскутное одеяло. Но в такой компании я в итоге работаю дольше всего - 6 год пошел, раньше было 2-3 года.
Я делал подобные штуки для прода. И я вообще вижу кривое задание. То как описано не заработает в проде, будет race condition за необработанные записи, потому что между условным статусом "новый" и "обработано" пройдет некоторое время.
Нужен либо дополнительный статус "в обработке", либо булева колонка "в обработке", а еще лучше lockID и lockExpirationDate. Там надо апдейтить записи в транзакции с блокировкой по строкам и проставлением статуса "в обработке", чтобы параллельный поток не взял в обработку записи, которые уже взял другой поток.
И уже на основе этого построить сначала правильный запрос в зависимости от БД - надо смотреть документацию. Запрос, в том числе, должен исключать записи со статусом "в обработке", а если сделали с колонкой lockExpirationDate - то и фильтр по ней. А потом уже думать над индексами. Ну и нагрузочные тесты.
Тем временем, Microsoft проводила масштабные увольнения: примерно 15 тысяч рабочих мест волнами с мая по июль 2025 года; скорее всего это было сделано, чтобы компенсировать прямые потери из-за CoreWeave перед следующей видеоконференцией о доходах.
Таки что увольнения все-таки из-за ЭйАй, только не в том виде как всем рассказывают?
Помусолить ее с чатом-гпт или любой другой ИИ-шечкой, по копипастить код руками, устать и задолбаться
Попробовать какой-нибудь агент, встроенный в IDE - например github copilot в режиме чата, понажимать tab, устать и задолбаться
Скачать и локально поставить Codex или аналог, подключить папку с проектом, сделать отдельную ветку в гите, скопипастить в чат описание задачи из таск трекера, немного причесать, вставить свои мысли, подсказки, ключевые точки (файлы, классы, методы) с которых стоит начать, попросить в первую очередь просканировать файлы и написать план
Одобрить или скорректировать план, запустить, пойти попить кофе, вернуться, восхититься, сделать код ревью, причесать, закомитить, отправить на ревью другому кожаному мешку
Profit
Ну а там уже дальше видно будет, всякие скилы покопать, и вот такие плагины/субагенты
Я не тим-лид, обширного опыта построения команд у меня нет, просто приходилось участвовать постольку-поскольку.
Давным-давно я официально был тех лидом пару лет и немного совмещал с тим-лидерством (не официально). Мне просто повезло с командой. И тогда же, в связи с некоторыми событиями пришлось осознать, что это две разные роли: компании, которые предлагали вакансий чистых тим-лидеров и собеседования - там совершенно другие вопросы, почти никакой техники, зато куча вопросов "а что бы вы сделали в такой ситуации {описание конфликта интересов в команде и/или с вышестоящим руководством}", на которые я не мог достойно ответить. Но таких компаний на самом деле меньшинство.
Есть 5+ летний опыт ведения продуктов, сначала в одиночку (не считая CTO), а затем в две команды со скрам мастером, продукт овнером (причем он пришел позже меня), на данный момент уже пятью программистами и 2-3 тестировщиками и недостатком ресурсов при этом (все у нас очень плотно, работы больше чем людей).
И я все еще не тим-лид и даже официально не тех-лид, просто ведущий разработчик, чтобы это не значило.
Из-за недостатка ресурсов - сразу видны проблемы с некорректным распределением обязанностей. Даже если бы у меня было желание именно тим-лидить, у меня тупо не было бы на это времени.
По моему мнению структура должна быть следующей:
Роль, которая управляет (лидит) людьми. Неважно как ее назовут (тим-лид или начальник отдела по старинке). Он нанимает, увольняет (кстати у тим-лидов зачастую таких щедростей нет, а значит и меньше рычагов влияния), он проводит 1-на-1, отслеживает настроения, думает как уладить конфликты, думает про мотивацию, обучение, выгорание, и все такое. У нас это CTO.
Роль, которая управляет (лидит) продуктом - это тот самый продукт овнер, выше я описывал то, чем он примерно должен заниматься, и я, до недавних пор, подобным занимался с продукт овнером на пару, но больше из-за того, что я был раньше. Сейчас с меня сняли эту когнитивную нагрузку
Роль которая управляет техническими решениями - опять же, не важно какое название (главный программист, тех-лид, архитектор). В начале это может быть один человек-оркестр (архитектор-программист-тестировщик). И у меня на этой позиции много работы - подумать как мы будем делать то, что хочет продукт-овнер, мониторить и тушить прод, разруливать выполнение крос-командных задач (всех пинать, чтобы задачи делались), оптимизировать, кодить непосредственно фичи, вытаскивать общие вещи на уровень компании, чтобы переиспользовать в других продуктах компании, придумывать как мы будем делать кросс-функционал типа сквозного логирования бизнес потоков через все продукты (у нас они связаны, там как-бы эко система и события перетекают из одного в другой). Ну и по мере развития продукта это потом можно разложить на отдельные роли и людей и появится команда аналитиков-программистов-тестировщиков. Что же касается взаимодействия с людьми - я могу пару-тройку раз сказать человеку что не так, но вряд ли это будет звучать мягко и дипломатично, и если ничего не меняется - я сообщаю 1-ой роли о проблемах
И главное - нужно разделить эти роли по разным людям. В целом совместить можно, но ничего хорошего не выйдет.
Я в какой-то момент (когда стартовал новый продукт) совмещал 2-ую и 3-тью роли. Когда клиентов пара-тройка - это возможно, когда их уже пара десятков, то слишком много времени уходит на саппорт, нет времени кодить фичи и там уже надо начинать строить отдел тех поддержки.
Что касается 1-на-1 - по моему, если отбросить всю мишуру, задача минимум чтоб не уволили, задача максимум чтоб повысили зп. У нас эти созвоны раньше были каждые полгода, сейчас кажется перешли на годовые. Так же у нас есть опросники, C-level опрашивают что хорошего/плохого скажешь о компании и что хорошего/плохого скажешь о {фио сотрудника}.
Короче, я с этой штукой сижу еще с net 5.0 на активном проекте в проде.
Просто по умолчанию сборка закоменчена в .csproj файле и не запускается, поэтому все хорошо.
Но если ее раскоментить...
Во-первых - раньше она дико тормозила, открываешь файл или пишешь символ в студии и оно подвисает на 1-2-3 секунды. Это крайне раздражает!
Во-вторых - сейчас, по прошествии стольких-то лет, стало вроде бы лучше (оптимизировали что ли), но теперь 12 ядерный проц грузится на 20% (и там висит в первых рядах RoslynCodeAnalisysService), коменчу сборку обратно и падает до 3-4%. На ноуте это будет жрать батарейку как не в себя.
В-третьих
Уберите комментарий и отлаживайте кодогенератор как и любой другой код на C#.
Я это прекрасно знаю и писал об этом в своей статье, но прикол в том, что это срабатывает через раз. Тупо просто не заходит, помогает перезагрузка студии например, или как потом выяснилось переключение Debug > Release > Debug.
В любом случай путь эскалации примерно такой: сами > обратиться к техническому авторитету (тех-лид / сениор) > обратиться к дипломату-психологу (тим-лид / начальник отдела).
Если это был локальный конфликт за табы/пробелы, то решат сами или с авторитетом, а если это было триггером в затянувшемся скрытом конфликте (один из них не моется и воняет) - тех лид тут не разрулит. Там может и растаскивать придется путем перевода в другую команду / отдел или увольнением.
Думаю ответ на все один - обязанности и ответственность каждой роли и распределение ролей между людьми.
Я сюда пришел почитать добротную статью про тех лида (было уже 30 плюсов), а что я вижу в первых абзацах? Кривое распределение обязанностей и ответственности.
Продакт отвечал за поставку и описание фич, за развитие софтов команды
Продакт как роль не должен отвечать за развитие софтов команды. Его задачи (здесь и далее в том числе, конечно же, ответственность за принятые решения) - мониторить рынок, аудиторию/потребителей, конкурентов, цены, разрабатывать гипотезы и обкатывать их с использованием каких-нибудь там тестов (типа A/B), разрабатывать схему приоритезации фич (по охвату, по потенциальном доходу и т.п.), расставлять в итоге приоритеты, готовить материалы для продажников, анализировать источники новых идей (как минимум их два - это запросы на новые фичи и саппорт (баги) от текущих клиентов) и тому подобное.
При таком обширном наборе обязанностей - если человек с ролью "продукт" действительно ответственно относится к своим обязанностям, ментально глубоко погружается в свои задачи, чтобы сделать их качественно - у него не останется когнитивных и/или временных ресурсов делать что-то еще.
Мало того, крайне желательно оставлять человеку с любой ролью пространство, чтобы у него не создавалось впечатление бесконечной работы, чтобы это в итоге не привело к выгоранию.
Идем дальше
за развитие софтов команды
Это чисто работа тим-лида. Теперь вопрос, получается ваш руководитель (как человек) взял на себя роль продукта и роль тим-лида. Тогда почему вы себя называете тим-лидом? У вас что два тим-лида? Как предполагается это будет работать? Если вы все же на самом деле не тим-лид, то может быть тогда уберете из статьи слово "тим-лид", и она наконец станет соответствовать заголовку?
Дальше
мне выделили ... развитие технических скиллов команды
Можете мне не верить, но это тоже задача и ответственность тим-лида. Только исполнять ее будет не он или не только он. Задача тим-лида в этом случае организовать развитие технических скиллов команды. Как? Ну например выбить бюджет на обучение, огласить условия всей команде, рекомендовать тем или иным сотрудникам пройти те или иные курсы (на основе фидбека, собесов 1-на-1 и других источников). Или например попросить тех-лида (или сениора за отсутствием) раз в месяц делать презентации о том, какие технические челленджи были и как победили.
То есть реально, у вас в команде два тим-лида. Вы назначили роли к людям как многие-ко-многим.
мне выделили техническое оснащение продуктов (архитектура, стабильность, сопровождение, оптимизация работы сервисов)
Тут наконец добрались до обязанностей тех-лида в той или иной мере.
Теперь по вашему коменту
Почему техлид не может решать межличностный конфликт, если он непосредственный участник его?
Может, в какой-то мере и будет, раз его касается, но, с другой стороны, а почему тех-лид не может попросить совета у более разбирающегося в психологии человека?
Почему техлид не может проводить 1-1
Это не его обязанность как роли. На собесе 1-на-1 нужно учитывать психологические особенности конкретного сотрудника. Обработать его запросы (на повышение зп) и возражения. Это психология. Прежде чем это делать - нужно обладать определенным качествами и/или почитать книжки по психологии и переговорам. Просто походу далеко не все это осознают и делают как придется, у кого-то получается. Это реально тонкая грань. Можно повысить зп человеку так, что он уволится в скором времени после этого.
А вот тим-лид обязан это делать. А до этого он еще должен собрать фидбек по сотруднику (путем опроса например), и если развивать эту идею - то в целом организовать систему грейдов и сбора фидбека.
Как тимлид будет развивать команду, если он "психолог", а не технарь?
Чуть выше привел пример с организацией обучения и делегированием некоторой части.
Ну не может тимлид забивать на техническую часть, ведь к нему в любом случае будут приходить с вопросами - "не работает сервис", "а тут бага"
Как раз таки нет, к нему не должны ходить с такими вопросами, у него куча других забот. Это к тех-лиду.
Вот тут не понял, разве можно потерять навык, если ты проводишь собесы?
Да, потому что сениор, который один раз провел собес, а все остальное время тушит прод - это не тим-лид. Это сениор, который один раз провел собес.
У тим-лида, по аналогии с продуктом (см выше) тоже много обязанностей и по хорошему они займут 80% его рабочего дня, каждый день. И если человек взял на себя одновременно обе роли и при этом у него горит прод - он не сможет успеть и там и там. Очевидно, что здесь и сейчас он пойдет чинить сломанный прод (он не потерпит) и так каждый раз, а сотрудник-человек может и потерпеть, а что потом? Кто и когда будет "чинить" "сломанного" сотрудника?
Да, и тех-лид тоже ходит к тим-лиду на 1-на-1, ведь он такой же сотрудник, как и все остальные и хочет побольше зп.
Сквозь всю статью прослеживается, что вы автор путаете тех лида и тим лида и перескакиваете с одного на другое, будто это одно и то же. Следовательно статья не соответствует заголовку.
Запомните раз и навсегда - тех лид и тим лид это две разные роли:
Тех лид отвечает за технические решения / кругозор / менторство, но никогда не занимается развитием команды, решение межличностных конфликтов, разговоры 1-на-1 и тому подобное. Тех лид в первую очередь читает техническую литературу
Тим лид, напротив - ему абсолютно все равно, что там происходит в технической части. Его задача развивать и подбирать команду для наибольшей эффективности, решать личные конфликты, быть более дипломатичным, проводить ревью 1-на-1. Тим лид в первую очередь читает литературу по психологии
При этом есть компании, в которых выделяют эти роли, а есть такие, где мешают в одного человека. Но по правде сказать это хрень. Такой человек не будет делать хорошо ни то, ни другое, у него не хватит времени и/или когнитивная нагрузка будет слишком высока. Пока такой человек проводит собесы или решает конфликты как тим-лид, в то же самое время он теряет техническую экспертизу и наоборот.
Меня относительно недавно (хотя наверное уже полгода-год прошел) - впечатлила их вакансия системного архитектора космической инфраструктуры. Судя по описанию искали Королева не меньше 😅 Интересно нашли ли, и что это за человек?
А что там за верхняя вилка? Я в интернетах читал что-то типа 360 (не знаю на руки или нет).
Но ради такой зп, по-моему, нет смысла рвать жопу на собесах в яндексе. Такая же компания как и другие - спрашивают программистов за алгоритмы (только, как оказалось, их пишут аналитики - статья аналитика из яндекс такси), тонны легаси (статья про переход с mysql 5.7), а что там с рабочей атмосферой - вообще не понятно, кажется что самая токсичная, какая может быть.
На финале руководитель - парень лет 23. Пообщались норм. Заодно он сказал что команда у них чисто продуктовая, и молодая - средний возраст 21-22.
Видимо на ту щедрую зп никто не идет кроме бывших студентов (пускай даже они с каких-нибудь МГУ / МГТУ). Обычный народ на опыте зарабатывал больше, перекладывая json-ы. Ну а рок-звезды, которые и взрослые, и опытные, и щелкают лит-код hard без подготовки - видимо уж и подавно в гробу видали это Яндекс.
Исключать резюме, где указаны только курсы в любом виде (как высшее, как место работы, как курсы)
Запрашивать и проверять подтверждение высшего образования
Запрашивать и проверять подтверждение опыта (трудовая книжка, договора, акты, оплаты, письма)
Просить приехать в офис для собеседования (даже для удаленной работы из других регионов - технически это можно сделать)
Проводить офф-лайн собес, там точно (не)будет видно всяких AI помощников.
Очередь FIFO
Думаю, комбинируя эти опции различным образом - каждый сможет найти для себя баланс количества входящих резюме и качества кандидатов.
Но это HR-ам действительно придется работать.
Главный вопрос - а переводчик с письменного врачебного языка на русский встроен? 😅
Вот с такого
В таком случае быть nice guy и работать в полсилы на двух аналогичных работах с клаудом под мышкой за две зп - выход 😏
Это уже набило оскомину, но дефицит низкооплачиваемых высококвалифицированных специалистов. В первой статье наняли джуна на роль мидла.
Я специально говорю что согласен на озвученную вилку (они в 95% ниже действительно рыночной зп), чтобы потом уже пытаться главным боссом договориться на нормальные деньги, если пройду все собесы.
Но это не соответствует тому, кого в итоге берут.
И еще интересный момент - в обеих статьях вы рассказываете какие плохие кандидаты, в прошлой статье взяли джуна на требования мидла с целью «научим» (это как раз говорит о том что зарплата рыночная только в голове руководителя или кто там у вас зп определяет).
Так вот, если в итоге нанимают «плохих» кандидатов, то как компания вообще работает и как двигаются проекты? Если судить по тому как написано - так можно только в носу ковыряться. Это у вас там случаем не «завод, где ИТ - непрофильный, убыточный отдел»?
Интересно, но свою текущую компанию не нашел - продуктовая, но не биг тех. По описанию вроде похоже, но у нас нет метрик и процессы не очень. Не нравится, что продукты пилятся как лоскутное одеяло. Но в такой компании я в итоге работаю дольше всего - 6 год пошел, раньше было 2-3 года.
Я делал подобные штуки для прода. И я вообще вижу кривое задание. То как описано не заработает в проде, будет race condition за необработанные записи, потому что между условным статусом "новый" и "обработано" пройдет некоторое время.
Нужен либо дополнительный статус "в обработке", либо булева колонка "в обработке", а еще лучше lockID и lockExpirationDate. Там надо апдейтить записи в транзакции с блокировкой по строкам и проставлением статуса "в обработке", чтобы параллельный поток не взял в обработку записи, которые уже взял другой поток.
И уже на основе этого построить сначала правильный запрос в зависимости от БД - надо смотреть документацию. Запрос, в том числе, должен исключать записи со статусом "в обработке", а если сделали с колонкой lockExpirationDate - то и фильтр по ней. А потом уже думать над индексами. Ну и нагрузочные тесты.
Таки что увольнения все-таки из-за ЭйАй, только не в том виде как всем рассказывают?
Когда будет очередная задача на работе, то
Помусолить ее с чатом-гпт или любой другой ИИ-шечкой, по копипастить код руками, устать и задолбаться
Попробовать какой-нибудь агент, встроенный в IDE - например github copilot в режиме чата, понажимать tab, устать и задолбаться
Скачать и локально поставить Codex или аналог, подключить папку с проектом, сделать отдельную ветку в гите, скопипастить в чат описание задачи из таск трекера, немного причесать, вставить свои мысли, подсказки, ключевые точки (файлы, классы, методы) с которых стоит начать, попросить в первую очередь просканировать файлы и написать план
Одобрить или скорректировать план, запустить, пойти попить кофе, вернуться, восхититься, сделать код ревью, причесать, закомитить, отправить на ревью другому кожаному мешку
Profit
Ну а там уже дальше видно будет, всякие скилы покопать, и вот такие плагины/субагенты
Я не тим-лид, обширного опыта построения команд у меня нет, просто приходилось участвовать постольку-поскольку.
Давным-давно я официально был тех лидом пару лет и немного совмещал с тим-лидерством (не официально). Мне просто повезло с командой. И тогда же, в связи с некоторыми событиями пришлось осознать, что это две разные роли: компании, которые предлагали вакансий чистых тим-лидеров и собеседования - там совершенно другие вопросы, почти никакой техники, зато куча вопросов "а что бы вы сделали в такой ситуации {описание конфликта интересов в команде и/или с вышестоящим руководством}", на которые я не мог достойно ответить. Но таких компаний на самом деле меньшинство.
Есть 5+ летний опыт ведения продуктов, сначала в одиночку (не считая CTO), а затем в две команды со скрам мастером, продукт овнером (причем он пришел позже меня), на данный момент уже пятью программистами и 2-3 тестировщиками и недостатком ресурсов при этом (все у нас очень плотно, работы больше чем людей).
И я все еще не тим-лид и даже официально не тех-лид, просто ведущий разработчик, чтобы это не значило.
Из-за недостатка ресурсов - сразу видны проблемы с некорректным распределением обязанностей. Даже если бы у меня было желание именно тим-лидить, у меня тупо не было бы на это времени.
По моему мнению структура должна быть следующей:
Роль, которая управляет (лидит) людьми. Неважно как ее назовут (тим-лид или начальник отдела по старинке). Он нанимает, увольняет (кстати у тим-лидов зачастую таких щедростей нет, а значит и меньше рычагов влияния), он проводит 1-на-1, отслеживает настроения, думает как уладить конфликты, думает про мотивацию, обучение, выгорание, и все такое. У нас это CTO.
Роль, которая управляет (лидит) продуктом - это тот самый продукт овнер, выше я описывал то, чем он примерно должен заниматься, и я, до недавних пор, подобным занимался с продукт овнером на пару, но больше из-за того, что я был раньше. Сейчас с меня сняли эту когнитивную нагрузку
Роль которая управляет техническими решениями - опять же, не важно какое название (главный программист, тех-лид, архитектор). В начале это может быть один человек-оркестр (архитектор-программист-тестировщик). И у меня на этой позиции много работы - подумать как мы будем делать то, что хочет продукт-овнер, мониторить и тушить прод, разруливать выполнение крос-командных задач (всех пинать, чтобы задачи делались), оптимизировать, кодить непосредственно фичи, вытаскивать общие вещи на уровень компании, чтобы переиспользовать в других продуктах компании, придумывать как мы будем делать кросс-функционал типа сквозного логирования бизнес потоков через все продукты (у нас они связаны, там как-бы эко система и события перетекают из одного в другой). Ну и по мере развития продукта это потом можно разложить на отдельные роли и людей и появится команда аналитиков-программистов-тестировщиков. Что же касается взаимодействия с людьми - я могу пару-тройку раз сказать человеку что не так, но вряд ли это будет звучать мягко и дипломатично, и если ничего не меняется - я сообщаю 1-ой роли о проблемах
И главное - нужно разделить эти роли по разным людям. В целом совместить можно, но ничего хорошего не выйдет.
Я в какой-то момент (когда стартовал новый продукт) совмещал 2-ую и 3-тью роли. Когда клиентов пара-тройка - это возможно, когда их уже пара десятков, то слишком много времени уходит на саппорт, нет времени кодить фичи и там уже надо начинать строить отдел тех поддержки.
Что касается 1-на-1 - по моему, если отбросить всю мишуру, задача минимум чтоб не уволили, задача максимум чтоб повысили зп. У нас эти созвоны раньше были каждые полгода, сейчас кажется перешли на годовые. Так же у нас есть опросники, C-level опрашивают что хорошего/плохого скажешь о компании и что хорошего/плохого скажешь о {фио сотрудника}.
ОО, меня тут заминусовали...
Короче, я с этой штукой сижу еще с net 5.0 на активном проекте в проде.
Просто по умолчанию сборка закоменчена в .csproj файле и не запускается, поэтому все хорошо.
Но если ее раскоментить...
Во-первых - раньше она дико тормозила, открываешь файл или пишешь символ в студии и оно подвисает на 1-2-3 секунды. Это крайне раздражает!
Во-вторых - сейчас, по прошествии стольких-то лет, стало вроде бы лучше (оптимизировали что ли), но теперь 12 ядерный проц грузится на 20% (и там висит в первых рядах RoslynCodeAnalisysService), коменчу сборку обратно и падает до 3-4%. На ноуте это будет жрать батарейку как не в себя.
В-третьих
Я это прекрасно знаю и писал об этом в своей статье, но прикол в том, что это срабатывает через раз. Тупо просто не заходит, помогает перезагрузка студии например, или как потом выяснилось переключение Debug > Release > Debug.
Не уверен, что всегда тех лид...
В любом случай путь эскалации примерно такой: сами > обратиться к техническому авторитету (тех-лид / сениор) > обратиться к дипломату-психологу (тим-лид / начальник отдела).
Если это был локальный конфликт за табы/пробелы, то решат сами или с авторитетом, а если это было триггером в затянувшемся скрытом конфликте (один из них не моется и воняет) - тех лид тут не разрулит. Там может и растаскивать придется путем перевода в другую команду / отдел или увольнением.
Думаю ответ на все один - обязанности и ответственность каждой роли и распределение ролей между людьми.
Я сюда пришел почитать добротную статью про тех лида (было уже 30 плюсов), а что я вижу в первых абзацах? Кривое распределение обязанностей и ответственности.
Продакт как роль не должен отвечать за развитие софтов команды. Его задачи (здесь и далее в том числе, конечно же, ответственность за принятые решения) - мониторить рынок, аудиторию/потребителей, конкурентов, цены, разрабатывать гипотезы и обкатывать их с использованием каких-нибудь там тестов (типа A/B), разрабатывать схему приоритезации фич (по охвату, по потенциальном доходу и т.п.), расставлять в итоге приоритеты, готовить материалы для продажников, анализировать источники новых идей (как минимум их два - это запросы на новые фичи и саппорт (баги) от текущих клиентов) и тому подобное.
При таком обширном наборе обязанностей - если человек с ролью "продукт" действительно ответственно относится к своим обязанностям, ментально глубоко погружается в свои задачи, чтобы сделать их качественно - у него не останется когнитивных и/или временных ресурсов делать что-то еще.
Мало того, крайне желательно оставлять человеку с любой ролью пространство, чтобы у него не создавалось впечатление бесконечной работы, чтобы это в итоге не привело к выгоранию.
Идем дальше
Это чисто работа тим-лида. Теперь вопрос, получается ваш руководитель (как человек) взял на себя роль продукта и роль тим-лида. Тогда почему вы себя называете тим-лидом? У вас что два тим-лида? Как предполагается это будет работать? Если вы все же на самом деле не тим-лид, то может быть тогда уберете из статьи слово "тим-лид", и она наконец станет соответствовать заголовку?
Дальше
Можете мне не верить, но это тоже задача и ответственность тим-лида. Только исполнять ее будет не он или не только он. Задача тим-лида в этом случае организовать развитие технических скиллов команды. Как? Ну например выбить бюджет на обучение, огласить условия всей команде, рекомендовать тем или иным сотрудникам пройти те или иные курсы (на основе фидбека, собесов 1-на-1 и других источников). Или например попросить тех-лида (или сениора за отсутствием) раз в месяц делать презентации о том, какие технические челленджи были и как победили.
То есть реально, у вас в команде два тим-лида. Вы назначили роли к людям как многие-ко-многим.
Тут наконец добрались до обязанностей тех-лида в той или иной мере.
Теперь по вашему коменту
Может, в какой-то мере и будет, раз его касается, но, с другой стороны, а почему тех-лид не может попросить совета у более разбирающегося в психологии человека?
Это не его обязанность как роли. На собесе 1-на-1 нужно учитывать психологические особенности конкретного сотрудника. Обработать его запросы (на повышение зп) и возражения. Это психология. Прежде чем это делать - нужно обладать определенным качествами и/или почитать книжки по психологии и переговорам. Просто походу далеко не все это осознают и делают как придется, у кого-то получается. Это реально тонкая грань. Можно повысить зп человеку так, что он уволится в скором времени после этого.
А вот тим-лид обязан это делать. А до этого он еще должен собрать фидбек по сотруднику (путем опроса например), и если развивать эту идею - то в целом организовать систему грейдов и сбора фидбека.
Чуть выше привел пример с организацией обучения и делегированием некоторой части.
Как раз таки нет, к нему не должны ходить с такими вопросами, у него куча других забот. Это к тех-лиду.
Да, потому что сениор, который один раз провел собес, а все остальное время тушит прод - это не тим-лид. Это сениор, который один раз провел собес.
У тим-лида, по аналогии с продуктом (см выше) тоже много обязанностей и по хорошему они займут 80% его рабочего дня, каждый день. И если человек взял на себя одновременно обе роли и при этом у него горит прод - он не сможет успеть и там и там. Очевидно, что здесь и сейчас он пойдет чинить сломанный прод (он не потерпит) и так каждый раз, а сотрудник-человек может и потерпеть, а что потом? Кто и когда будет "чинить" "сломанного" сотрудника?
Да, и тех-лид тоже ходит к тим-лиду на 1-на-1, ведь он такой же сотрудник, как и все остальные и хочет побольше зп.
Сквозь всю статью прослеживается, что вы автор путаете тех лида и тим лида и перескакиваете с одного на другое, будто это одно и то же. Следовательно статья не соответствует заголовку.
Запомните раз и навсегда - тех лид и тим лид это две разные роли:
Тех лид отвечает за технические решения / кругозор / менторство, но никогда не занимается развитием команды, решение межличностных конфликтов, разговоры 1-на-1 и тому подобное. Тех лид в первую очередь читает техническую литературу
Тим лид, напротив - ему абсолютно все равно, что там происходит в технической части. Его задача развивать и подбирать команду для наибольшей эффективности, решать личные конфликты, быть более дипломатичным, проводить ревью 1-на-1. Тим лид в первую очередь читает литературу по психологии
При этом есть компании, в которых выделяют эти роли, а есть такие, где мешают в одного человека. Но по правде сказать это хрень. Такой человек не будет делать хорошо ни то, ни другое, у него не хватит времени и/или когнитивная нагрузка будет слишком высока. Пока такой человек проводит собесы или решает конфликты как тим-лид, в то же самое время он теряет техническую экспертизу и наоборот.
Положил в закладки, на следующий собес, если будет вопрос, я дам ссылку на эту статью.
Меня относительно недавно (хотя наверное уже полгода-год прошел) - впечатлила их вакансия системного архитектора космической инфраструктуры. Судя по описанию искали Королева не меньше 😅 Интересно нашли ли, и что это за человек?
А что там за верхняя вилка? Я в интернетах читал что-то типа 360 (не знаю на руки или нет).
Но ради такой зп, по-моему, нет смысла рвать жопу на собесах в яндексе. Такая же компания как и другие - спрашивают программистов за алгоритмы (только, как оказалось, их пишут аналитики - статья аналитика из яндекс такси), тонны легаси (статья про переход с mysql 5.7), а что там с рабочей атмосферой - вообще не понятно, кажется что самая токсичная, какая может быть.
Видимо на ту щедрую зп никто не идет кроме бывших студентов (пускай даже они с каких-нибудь МГУ / МГТУ). Обычный народ на опыте зарабатывал больше, перекладывая json-ы. Ну а рок-звезды, которые и взрослые, и опытные, и щелкают лит-код hard без подготовки - видимо уж и подавно в гробу видали это Яндекс.
Настоящая женщина с первого раза не соглашается, а настоящий мужчина два раза не предлагает (с) 😅