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

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

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

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

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

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

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

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

Добрый день!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что думаете?

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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