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

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

Я так понял, это доклад был на HighLoad 2017 Moscow. Вот ссылка кому интересно на видео версию: https://youtu.be/Ygfwwd490mk?t=1h2m7s

Супер! Отличный доклад, схранил

Я правильно понял, что в итоге тимлид таки назначается, причём для него это неожиданно, даже если зам? Да, вы его готовили в лиды, да, со всеми вашими функциями справлялся, но согласен ли быть лидом постоянно вы забыли спросить или написать?
Спасибо за комментарий, действительно пропустил этот момент в докладе и в статье.
Конечно же, в итоге тимлид назначается, и событие это вполне ожидаемо для сотрудника. Еще на этапе работы заместителем он четко понимает, что эта обязанность — испытание перед потенциальным назначением.
И начинает подыскивать заместителя себе? )
После вступления в должность — безусловно :)

Я имел в виду, что если человек понимает, что получение должности зама тимлида — это, по сути, лишь испытательный срок на тимлида, то заместителя себе он по вашим советам должен начать выбирать когда получает должность зама, а не когда тимлида :)

Два с половиной года назад я пришел в Badoo разработчиком, со временем вырос до тимлида, а потом (skipped) стал руководителем направления

Сорян, но несколько месяцев опыта на должности в одной-единственной компании — это очень мало, чтобы сделать выводы и начать раздавать советы. Ничего личного.

Я буду очень рад, если Вы поделитесь конкретными советами или покритикуете что-то предметно :)

Я, в общем, не хотел бы критиковать предложенный подход. В целом лично я со всем согласен и более того, мне это все близко по духу. Но имхо решение получилось слишком "переспецифицированным", а от этого — не универсальным и трудным в воплощении (а не легким, как может показаться).


Правильных решений задачи — много. И других важных задач тоже много.


Что же до, собственно, где найти и как выбрать тимлида. Мое мнение, тимлид — это первый человек в иерархии, который никогда ничего не оставляет на самотек. От этого и пляшем. Все остальное сильно варьируются от проекта к проекту и должно решаться индивидуально в конкретной точке пространства и времени. Принципы, конечно, есть, но исключений гораздо больше.

И ещё один важный момент: нужно донести до тимлида, что мягкость приводит к тому, что люди садятся на шею

Надеюсь и уверен, что вы пропустили "паталогическая" перед словом "мягкость". Мягкость это хорошо, мягкость в отношениях — это когда не царапает и приятно. А вот реагировать на мягкость агрессией, или попытками сесть на шею — это глупость, которая должна превентивно наказываться, я так думаю ;)

Как вы отличите попытку разработчика сесть на шею от попытки разработчика убрать с себя неинтересные обязанности?

По глазам, конечно же.

А если серьезно — разработчик — "тоже человек". Если это коллега — человек, с которымм каждую конкретную неделю я трачу на общение больше времени, чем могу провести со своей семьей (даже если это удаленная работа). Мотивы, желания, интонации, правда на правду, курилка, реакции других людей, мимика, глаза, но, самое главное — мое желание его узнать — все вместе сильно повышает прозрачность того, что собеседнику интересно, а что нет.


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

Мой вопрос скорее был не в том, как выявить ситуацию когда человек сознательно хочет сесть на шею, а когда он пытается рационализировать свою деятельность, а вами это воспринимается как попытка сесть на шею. Ведь это понятие достаточно субъективное. Скажем, от топ менеджмента есть требование ежедневных отчётов по состоянию текущих задач, отменить его вы не можете. Сначала вы решаете, что разработчики будут делать свои отчёты сами, а вы, как тимлид, их агрегировать или даже просто контролировать, чтоб никто не забывал. Но тут вам поступает предложение "а давай ты будешь их писать, ты же и так в курсе кто чем занимается, ты и говоришь кому чем заниматься". Один человек воспримет это как попытку сесть на шею, а другой как рациональный ход — разработчики будут разрабатывать, а я, как менеджер, отчёты писать.

Ну я могу судить только по себе.
Реальность всегда сложнее абстрактных предположений, общий алгоритм такой:


  1. Постараюсь понять, не пытается ли мне сесть на шею топ менеджмент. Решаем ли мы реальную проблему, или начальство и так уже имеет инструмент, но не знает как им пользоваться. Постараюсь помочь в обоих случаях, безусловно.
  2. Постараюсь уловить момент, когда я сам пытаюсь сесть на шею. В первую очередь — оценить, принесет ли сбор отчетов пользу и мне и начальству и разработчикам одновременно.

В данном конкретном случае — реальная задача "прозрачность" и польза ее решения очевидна. Сделать идеально (если совсем пусто) на раз не получится. Предложу для начала, действительно, писать отчеты, но не постфактум. А фиксировать шаги заранее и во время действий. Хорошая привычка, в любом случае. А отчет получается просто бонусом. Но этого мало, надо автоматизировать, чтобы ничто не отвлекало — это факт. Следующий шаг — настроить системы (ведения проекта, version control, CI, документации) так, чтобы по ним сразу получалась относительно ясная картина. Чтобы если и разговаривать (писать отчет) с руководством и командой — не по рутинным причинам, а именно для обсуждения конкретных и важных моментов.

Простите, но это разве не одно и то же? Я имею ввиду, что если убирать с себя неинтересные обязанности (то есть дела, которые нужно делать именно этому сотруднику), они никуда не денутся, и их должен будет делать кто-то другой.

Не одно. Сесть на шею означает переложить свои обязанности на другого, числятся на тебе, а делает другой. Рационализировать свою деятельность — убрать из списка обязанностей непрофильные, так сказать.

все верно, а тимлид рационализирует деятельность команды, так?

Да. Тимлид отвечает за результаты работы команды в целом, распределяет обязанности между её членами, включая себя.

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

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

Забавно, что никто не пишет в чем состоят обязанности тимлида.

Такое ощущение, что тимлид это должность на которую спихивают, всю ответственность, что только могут спихнуть. Создание ТЗ, проверку комитов, ведение версий, слежку за сотрудниками, отчеты перед заказчиками, штрафы и изредка премии и всю прочую работу менеджеров, аналитиков, дизайнеров, тестеров и что еще умудрятся повесить.
Причем желательно без повышения оплаты, и с предыдущими обязанностями по девелопингу.
Тимлид (как и другие управленцы) ответственность на себя берет сам, ему ее не «спихивают». А вот как он дальше эту ответственность реализует, как раз и отличает условного тимлида от условного топ-менеджера.

Ну, на практике, всё-таки бывает и спихивают, ставят перед фактом "ты несёшь теперь ещё ответственность и за это".

Т.е. четко прописанных обязанностей у этой должности нет?
Вырисовывается эдакий, за все отвечающий, во всем виноватый, назначенный сверху(в статье так написано) мальчик для битья.
Или все же у него есть некий конкретный круг ответственности, обязанностей и бонусов?
Компании не нужен «мальчик для битья». Хорошей компании, конечно, ведь случаи разные бывают.
От наказания особой пользы нет. Нужно чтобы чел решал задачи компании. Отсюда и формируется список обязанностей. У кого-то он может быть сильно формальным и расписанным от и до. У кого-то более-менее размытый.
А ответственность должна вознаграждаться соответственно, иначе ее мало кто на себя согласится взять. Но все измерять деньгами конечно же не нужно. Деньги — слабый и краткосрочный мотиватор. Факторов в уравнении сильно больше.
Компании не нужен «мальчик для битья». Хорошей компании, конечно, ведь случаи разные бывают. От наказания особой пользы нет. Нужно чтобы чел решал задачи компании.

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

иначе ее мало кто на себя согласится взять.

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

Но все измерять деньгами конечно же не нужно

Не все конечно, но примерно 70-90% именно деньгами. Процент от опыта/возраста зависит. Поэтому все так любят брать на работу молодежь — им еще можно лапшу повесить про корпоративные ценности, работников месяца и набирание офигенного опыта, который сам по себе дороже всех денег.

Скорее это не ощущение, а прямая и главная обязанность тимлида нести ответственность за результаты работы команды. Всё, что ожидает вышестоящий менеджмент и заказчики от команды, должен обеспечить тимлид. Ну или явно заявить им "под моим управлением моя команда этим заниматься не будет" или "в ожидаемый вами срок все эти задачи выполнить не получится из-за недостатков таких-то и таких-то ресурсов". А уж кто конкретно в команде будет делать эту работу, обеспечивая ожидаемые результаты — решение тимлида. Он может, по крайней мере в теории, и полностью всё сам делать, и полностью всё делегировать на членов команды, оставляя себе чисто руководящую и контролирующую роль.

Всё, что ожидает вышестоящий менеджмент и заказчики от команды, должен обеспечить тимлид.

Звучит!
А может все таки можно конкретизировать задачи и ответственность? А так как сказал Решелье — «Все значит никто».
И также бонусы, они как вычисляются? зарплата сеньера * 2? или зарплата CEO/2?

Задачи и ответственность определяет топ-менеджмент. Даже в СССР, при всей его регламентации,, задачи и обязанности руководителя группы (по-моему больше всего соответствует среднему "тимлиду") определялись на месте и могли отличаться даже у руководителей двух схлжих групп в одной лаборатории

Смотря кто кому на шею сядет :)

У вас выбор города/страны немного неправильный. а конкретнее города Крыма. какой бы не был город, везде пишет <мой_город>/Украина. Просьба поправить.
vsh А можете раскрыть тему «текущая ступень развития сотрудника в компании». По каким критериям оцениваете и есть ли у вам маттерилаы где эта тема раскрыта?
Если речь в данной статье идет не только о техническом лиде а и об проектном, в том числе и коррекция взаимоотношений внутри команды, то я бы добавил свои пять копеек.
После работы с англичанами и с нашими я увидел большую разницу в построении общения. Наши люди часто жестко конкурируют на работе, подсиживают, воспринимают порой несуществующие обиды от коллег очень близко к сердцу да так что начинают строить козни. Этого всего я почти не увидел у англичан. Видимо их с детства учили что нужно быть максимально сдержанным и дипломатичным, особенно на работе и в отношении чужих людей.
Так что у наших тим лидов и менеджеров больше работы чем у английских коллег.

Бытует стереотип, что сдержанность и дипломатичность у англичан только внешняя, а внутри такие страсти творятся, что любая "широкая русская душа" позавидует. Не противоречит вашим наблюдениям?

Ну они люди конечно, но у них уже на подсознательном уровне выдрисировано что нужно вести себя сдержанно, и я скажу что это даёт ощутимые плоды
Зарегистрируйтесь на Хабре, чтобы оставить комментарий