Как стать автором
Обновить

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

Время на прочтение 6 мин
Количество просмотров 5.1K
Всего голосов 27: ↑10 и ↓17 -7
Комментарии 13

Комментарии 13

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

интроверт — не будь интровертом
плохой сотрудник — будь хорошим

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

ну откуда? смотрите какие милашки у них там в тимлидах.

Добрый день!

Спасибо, что поделились своим опытом.

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

Ходить вместе обедать — пунктик, который хорошо сработает в синергии с другими. Но я бы не стал рассчитывать исключительно на него.

Про токсичных тимлидов статейки нет. Можете поделиться примерами таких руководителей? Интересно.

Либо человек в команде, либо это человек-команда, тогда его "я интроверт до мозга и костей" не помеха работе.

Если корректив не нравится, то это косяк тимлида, что не предвидел - как пример, странно ждать вливание в коллектив студентов человека 65+

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

Спасибо за статью, не со всеми тезисами согласен, но было интересно. В последнее время все больше сотрудников работают на удаленке и поддержание неформального общения становится затруднительным, что не может не радовать))))

"Тимлид назначил Мише встречу, чтобы провести онбординг: погрузить в дела компании, проекты и рабочие процессы. А Миша не подготовился — не подумал, о чем важно спросить: например, как оплачивают работу или по каким принципам ведут проекты. В итоге он генерировал вопросы на ходу, что задержало разговор на 20 минут, а тимлид волновался, как бы успеть на следующие запланированные встречи и обед. "

Дев задавал слишком много вопросов на встрече? И это плохо?
По-моему Вы ошибаетесь.

Тимлид выделил мало времени, но виноват в этом дев. Странная логика.

НЛО прилетело и опубликовало эту надпись здесь

Из статьи прекрасно понятно, как обращаться с тимлидом. Но теперь стало непонятно, а зачем в команде вообще такой тимлид. Если разработчики прекрасны, открыты, последовательны, подготовлены, проактивны, и очень конкретны в общении — то нафига им тимлид? Чтобы что, чтоб приходить зарплату получать?

Спасибо за комментарий!

Тимлид нужен, чтобы контролировать работу команды, ставить командные цели, рассказывать о важных новостях и изменениях в компании или продукте, поддерживать тиммейтов, если что-то не так. В том числе — платить зарплату (через финотдел, конечно).

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

Что думаете?

Тимлид нужен, чтобы контролировать работу команды

Зачем, если у вас и так все ответственные?


ставить командные цели

Аналогично — все же открытые, прозрачные, собрались и поставили себе целей на вырост, распределив их по команде как надо.


рассказывать о важных новостях и изменениях в компании или продукте

Я и не знал, что на роль RSS теперь нужно нанимать человека.


поддерживать тиммейтов, если что-то не так

Так они же все как на подбор правильные, что у них может пойти не так? Друг друга поддержат, опять же, зачем для этого человек с отдельной ролью и на отдельную зарплату?

НЛО прилетело и опубликовало эту надпись здесь

А Миша не подготовился — не подумал, о чем важно спросить: например, как оплачивают работу или по каким принципам ведут проекты.

Точно не подготовился - спрашивать о порядке оплаты нужно на собеседовании, а не на онбординге.

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

Становится очевидно, что Миша это медведь - тимлид боится слово сказать, лишь бы не нервировать его.

Через несколько дней после провального созвона Миша снова отличился. Он неправильно написал код автоматического тестирования, которое должен был провести в четверг. И до пятницы молчал, пытаясь самостоятельно разобраться с проблемой.

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

А жив ли вообще?

И тимлид и команда стараются лишний раз в берлогу не заглядывать - зима на носу, вдруг Миша спать залёг, а его потревожат.

«... Был на трех встречах с командой, обсудили кучу полезных тем». У тимлида выступили вены на лбу и полопались капилляры в глазах.

Судя по всему Миша единственный, кто остался из команды после этих встреч, если до тимлида только сейчас дошёл факт его коммуникации с остальными.

Это всё шутка, но статья демонстрирует крайне странные процессы в команде, куда попал Миша.

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

  2. Одна из обязанностей тимлида - иметь представление о том, что происходит с задачами, которые выполняет команда. Это можно реализовать либо ежедневными встречами команды (дейли-митинги) либо, если команда не хочет собираться каждый день на 10-20 минут, ежедневным обновлением в таск-трекере задач с записью актуального состояния. Но в любом случае, независимо от того, какой процесс принят, новичёк требует повышенного внимания - онбординг не завершается одной встречей.

  3. Новичку в общем случае нельзя давать задачи с близким и жёстким дедлайном - у него не может быть знания кодовой базы проекта, в котором ему нужно работать.

  4. Программист не должен быть проактивным в вопросах бизнеса - он должен быть проактивным в вопросах разработки в проекте, куда он пришёл. Но на начальном этапе трудно быть обоснованно проактивным по объективным причинам. И на общие обеды ходить он не обязан - у него может быть свой особый график питания или диета. И ожидание помощи от того, кто только-только попал на проект, странно - это ему нужно помогать поскорее влиться в команду.

  5. "Главное — заранее обговорить формат встречи: если рабочий — готовим цифры и факты, а если личный — завариваем кофеек." Вспоминается Шелдон Ли Купер с его соглашениями об отношениях. На работе взаимодействия должны быть рабочими. Личные взаимодействия могут происходить между людьми, которые являются коллегами, но не могут быть частью рабочих процессов.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий