Что должен делать тимлид: роли, обязанности и навыки

Решение: самоорганизующиеся команды

В PropellerAds есть продуктовые команды, которые стоят в центре системы компании. В них входят:

  • Владелец продукта (Product Owner) — это человек, который разбирается в продукте, работает с бизнесом, строит бэклог, менеджерит риски, пишет User Story и прочее;

  • Разработчики, scrum-мастер;

  • Тестировщики;

  • DevOps.

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

Где же руководители? Они есть у каждой функциональной группы (PO, разработчиков, тестировщиков, DevOps).

Что такое функциональный руководитель? Это тренер функции: тренер разработчиков, тренер тестировщиков и т.д. В его задачу входит растить своих людей и поддерживать их уровень. 

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

Дополнительные материалы

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

Здесь я приложу список релевантных этой статье постов из канала. Это ни в коем случае не самореклама. Статья самодостаточная и без этих материалов, так что это просто факультатив, для тех, кто хочет узнать еще немного больше.

  • Матрица доверие-прозрачность https://t.me/general_it_talks/78

  • Ситуационное лидерство https://t.me/general_it_talks/59

  • Чайка-менеджмент, микроменеджмент https://t.me/general_it_talks/28

  • Обучение, приоритеты и иллюзию компетентности в этом деле https://t.me/general_it_talks/60 https://t.me/general_it_talks/41 https://t.me/general_it_talks/116

  • Овертаймы и подбор темпа работы https://t.me/general_it_talks/42 https://t.me/general_it_talks/61

  • Теория разбитых окон https://t.me/general_it_talks/48

Шаг номер 4. Полезные качества для тимлида

Полезные качества, которые надо в себе взращивать:

Умение не сойти с ума при многозадачности.
Обычно у тимлидов очень много разных задач по всем фронтам. Например, утром нужно встретиться с заказчиком, в обед обсудить задачу с командой, на полдник написать 100500 писем, на ужин пообщаться с глазу на глаз с начальником, а еще хотелось бы кой-чего и самому подкоммитить. И это еще легкий день. Заказчиков обычно много, так же как и задач, встреч и всего остального

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

А тимлид приходит и понимает, что они говорят об одном и том же, объясняет это такими словами, что все и поймут о чем речь, и разберутся, что делать, чтобы достичь необходимый результат.
Умение говорить «нет».
Прям обязательное умение. Без него вы быстро будете погребены под тоннами задач со всех фронтов. И ладно бы просто вы, а еще и ваша команда, потому что заказчикам вы тоже отказывать не умеете. Иной раз умение сказать «нет», а заодно и предложить какой-то более простой вариант, про который заказчик не подумал, может сэкономить целые человекомесяцы труда и соответствующее количество денег.
Дисциплина.
Чтобы успешно управлять не только своим трудом, но и работой всей команды, нужна система. А чтобы система работала, нужна дисциплина. Стоит только чуть ослабить дисциплину, как появляются и начинают множиться разбитые окна. Чтобы дисциплина в команде появилась и закрепилась, безусловно, нужно заниматься просвещением и контролем, но лучше всего начинать с личного примера. Покажите людям, как приносит пользу ваша самодисциплина, и это будет убедительнее многочасовых теоретических рассказов.

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

Алгоритм подбора подходящего руководителя

Я не зря сменил способ выражения. Надеюсь, что к этому моменту вы уже поняли, что не бывает руководителей с плохим или хорошим стилем. Стили бывают только подходящими или нет. Равно как нанимающих менеджеров учат на собеседовании подбирать подходящих, а не идеальных кандидатов, так и я буду говорить о том, как найти подходящего, а не идеального руководителя. А для того, чтобы определиться, какой руководитель вам подходит в конкретной ситуации, нужно ответить на вопросы:

  1. Какие из стилей предпочитаете лично вы, как сотрудник?

  2. Какой стиль подходит команде, которую вы рассматриваете в данный момент?

  3. Какой стиль будет подходить команде через год, два, пять (зависит от того как на долго вы собираетесь с ней остаться)?

  4. Какой стиль использует руководитель?

  5. Способен ли он менять свой стиль?

О том, как ответить на эти вопросы мы поговорим ниже, а пока разберемся, как интерпретировать ответы:

  1. Запишите ответ на первый вопрос, скорее всего у вас выйдет несколько предпочтительных стилей.

  2. Стили из вопросов 2-4 должны быть из списка ваших предпочтительных.

  3. Ответы на вопросы 2 и 4 должны совпадать.

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

Какие знания и навыки у него должны быть

Какие личностные качества должен иметь тимлид? Список довольно обширный, но ведь и ответственность у руководителя большая:

  • трудолюбие, целеустремленность;
  • адаптивность, гибкость;
  • инициативность, креативность;
  • самостоятельность, ответственность, пунктуальность;
  • коммуникабельность;
  • стрессоустойчивость, терпеливость, дипломатичность.

Teamlead должен иметь минимум 5 лет опыта в IT области. Что потребуется ему для успешной работы:

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

И это список только наиболее важных требований. Работа требует навыков работы с Linux based дистрибутивами, знания Agile, PHP, Scrum, MySQL, JavaScript. Могут еще встречаться условия, имеющие отношение к конкретной сфере работы заказчика.

Какие требования чаще всего звучат в описании вакансии тимлида:

  • высшее техническое образование (это точно будет преимуществом, но не всегда является обязательным требованием);
  • достаточное количество знаний и навыков в своем стэке (их мы перечислили выше);
  • умение проводить код-ревью и менторинг;
  • опыт работы от 5 лет;
  • управленческие навыки.

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

Давайте теперь подумаем, как бороться с отвлечением и управлять вниманием

В чем проблема борьбы с отвлечением для тимлидов? В том, что классические подходы к тайм-менеджменту – focus time, помидорка, скалирование времени и другие – не работают, если сотрудники не уважают ваше время.

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

Крайне важно не забывать ответить

Я предпочитаю способ переноса времени: если вам написали, а вы программируете, то вы отвечаете через пятнадцать минут

Крайне важно не забывать ответить

Для тимлидов отметим важный момент: пишем «через 15 минут» правильно.

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

Рассмотрим еще одну проблему – возврат в контекст.

Вы программируете, у вас в голове: «Задача-метод-класс». Вас отвлекли, контекст пропал. Вы ответили сотруднику, нужно вернуться в контекст.

Одно из самых эффективных решений – микродекомпозиция. Это когда вы берете листочек/one note, где можно сделать древовидную структуру и декомпозировать свою задачу вплоть до псевдокода или формулировки «сделай вот это».

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

На виртуальном рабочем столе программирования у вас может быть открыт IDE, браузер, требования.

На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.

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

Описание должности

Кто такой тимлид и чем он занимается? Само название имеет английское происхождение (team leader – «лидер команды»). Этот человек – координатор команды разработчиков. Он определяет сферы ответственности своим подчиненным и контролирует их работу, организовывает обучение и обеспечивает возможности профессионального роста для специалистов, а также ведет переговоры с заказчиком.

Тимлид – не профессия, а должность. Лидером команды, как правило, становится программист-разработчик. Соответственно, программист – это профессия, а тимлидер – занимаемая им должность.

Кроме непосредственно профессиональных, на тимлида возложены функции менеджера:

  • заключать договоры с заказчиками;
  • вести документацию, касающуюся проекта;
  • оценивать объемы и планировать сроки работы;
  • рассчитывать бюджет;
  • определять приоритеты задач и разбивать их на более мелкие задания;
  • грамотно делегировать полномочия внутри команды, чтобы достичь максимума продуктивности;
  • создавать и выпускать релизы;
  • быть продюсером проекта (контролировать разработку, дизайн и маркетинг);
  • давать каждому члену команды возможность развития.

Ключевой момент в работе тимлида – мощная мотивация команды и умение вдохновлять ее на успех. Разумеется делать это нужно личным примером.

Team leader – не только менеджер и продюсер, но и один из лучших программистов. Его деятельность, кроме управленческих задач, предполагает участие непосредственно в разработке проекта. Ему надо постоянно держать руку на пульсе: знать, на какой стадии находится работа в данный момент, рассматривать все предложения членов команды, аргументированно принимать их или же отвергать.

Технические задачи тимлида:

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

Team leader может устроиться на работу в крупную брокерскую или финансовую компанию, бизнес-корпорацию, банк либо в IT-фирму. Интересно, что официальная должность тимлида есть не во всех айти-компаниях. И все же в любой команде должен быть главный. Занять этот пост обычно предлагают самому опытному разработчику или руководителю отдела, в небольшом стартапе – техническому директору или начальнику SEO-отдела. В крупной компании разработчики могут сформировать сразу несколько команд, каждая из которых получит своего формального тимлидера. В таком случае для руководства лидерами команд учреждается дополнительная должность – тимлид тимлидов.

Есть много позиций/уровней, которые близки к тим лиду. Можешь ли пояснить, чем тимлид отличается от сеньора, техлида, продакт менеджера?

В моём понимании:

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

Какие навыки нужны тимлиду

Должность тимлида находится на стыке разработки и менеджмента. Поэтому бизнес ждет от него мощных хард- и софт-скиллов. 

  • Опыт работы от 3-5 лет – и желательно, чтобы он включал опыт руководства хотя бы небольшой командой.

  • Опыт проведения код-ревью, менторинга – потому что придется помогать другим разработчикам, подтягивать джуниоров.

  • Умение принимать решения и брать на себя ответственность – все, что происходит с проектом, становится головной болью тимлида.

  • Аналитические способности и критическое мышление – для правильной оценки сложности задачи, расстановки приоритетов.

  • Навыки делегирования – чтобы грамотно распределять задачи между членами команды.

  • Знание HR – нужно разбираться в кадровой политике, потому что точно придется участвовать в формировании команды и наборе сотрудников.

  • Умение мотивировать сотрудников – и вообще общаться с людьми, в том числе предотвращать конфликты.

  • Тайм-менеджмент – для выставления реальных сроков решения задач.

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

Самостоятельность

По большей части самостоятельность это мера обратно пропорциональная вашей авторитарности. Как и необязательность – зависимость от решений разрушает связи внутри команды. Зачем решать что-то вместе, если можно обратиться к начальнику?

Что измерять?

Еще одна интерпретация «рычага власти»

Представим рычаг, груз авторитета с одной стороны и независимость  –  с другой. Где вы? Даже команда с высокой степенью зрелости может быть задавлена высокой авторитарностью. Куда будет двигаться опора  –  решать вам, но текущее положение можно оценить по принимаемым решениям и вашем положении (или вашего предшественника) в них.

Обучающий стиль

 Мы стараемся мотивировать всех на рост. Для этого у нас выстроен честный и прозрачный процесс. У нас есть понятная карта компетенций, разбитая по навыкам и уровням, везде есть примеры того, что можно делать для достижения определенного уровня. И для каждого мы строим индивидуальный план развития на полгода. У всех он разный, кто-то ориентируется на продвижение в одной компетенции за раз, кто-то хочет развивать сразу несколько. И это уже является элементом обучающего стиля управления.

Мы верим в то, что сможем достигать крутых результатов, если будем развивать индивидуальные навыки своих сотрудников. Для этого каждые полгода мы проводим performance review. Оно включает в себя отзывы от коллег, self-review и 1-1 с руководителем для рефлексии. После этого мы составляем план на полгода таким образом, чтобы сотрудник знал, что ему делать для улучшения своих навыков. Каждый пункт этого плана является целью и ставится по фреймворку SMART. Например, если одной из целей является крупный рефакторинг, то мы определяем definition of done этого рефакторинга. Так он станет конкретным и измеримым. Планируем объём работ: реально ли закончить этот рефакторинг за 3-6 месяцев? И думаем о том, какую пользу он принесет компании.

Девиз обучающего стиля

Откуда берутся лиды

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

Первая — горизонтальная система управления. Её практикуют реже, к примеру basecamp или 37 signals. Смысл заключается в том, что у вас есть ряд сильных специалистов, способных самостоятельно регулировать свою деятельность.

Вторая — иерархическая система управления.

Есть разработчик, за ним стоит platform lead, за ним CTO, далее CEO. Каждый участник курирует определенный вектор развития. Чем ниже располагается в иерархии человек, тем за более узкоспециализированный участок он отвечает. Разработчик отвечает лишь за код, который он производит. Lead отвечает целиком за платформу и за её развитие. Технический директор отвечает за техническую составляющую в компании. А генеральный директор — за развитие компании.

Чем больше становится компания, чем больше появляется процессов и участников, тем сложнее становится иерархия. Появляются дополнительные роли, такие как Mobile Lead. У него в подчинении находятся лиды мобильных платформ, которых может быть больше одного на платформе. Это зависит от количества подчиненных на конкретном уровне в компании.

Оптимальное количество людей, которых может контролировать один человек, сильно варьируется от сферы деятельности и от модели управления. В IT в классической литературе это число колеблется от 5 до 9 человек.

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

Большее ведет к тому, что контроль, обучение и другие функции становится сложнее выполнять. Необходимо добавлять новые роли.

Рассмотрим классическую ситуацию карьерного роста в IT-компании. Когда человек достигает определенного уровня квалификации, он может либо перейти на следующий уровень иерархии при наличии определенных личностных качеств, либо сменить род деятельности/область деятельности/компанию и расти дальше в технической стезе. На картинке ниже представлена классическая краткая форма развития. Следующая ступень развития разработчика — team lead либо tech lead. Первая предполагает уход в сторону менеджмента, вторая — глубокий технический рост специалиста. Team lead дальше уходит в platform lead. Из tech lead получаются архитекторы разного калибра.

Подбор: скоринг

  • Бизнес-ориентированность — насколько человек прагматичен, когда целью является результат для бизнеса, а не, скажем, уровень удовлетворённости красотой и изящностью кода. Тимлид должен в первую очередь руководствоваться принципами управления, а не личного комфорта. Простой пример: если бизнесу нужно провалидировать в рамках A/B-теста какую-то концепцию, вероятно, нет смысла делать покрытие кода тестовой группы юнит-тестами, даже если принято покрывать тестами всё, и разработчику нравится писать тесты.
  • Коммуникации. В культуре Badoo на коммуникациях построено очень многое, и умение эффективно общаться со всеми — серверниками, тестировщиками, топами, дизайнерами — просто необходимо.
  • Уровень мотивации. На мой взгляд, тимлид должен обладать сильной внутренней мотивацией, ведь превращение из разработчика в тимлида — это не переход со ступеньки на ступеньку карьерной лестницы, а перепрыгивание на другую лестницу, стоящую особняком, — лестницу управления. Без сильной мотивации любое развитие — а развитие всегда есть выход из зоны комфорта — будет очень тяжёлым.
  • История удачных/неудачных проектов. Сюда же относятся причины провалов проектов (чтобы потом проверять следующие проекты на наличие тех же паттернов провалов).
  • Уровень неформального лидерства. Руководитель должен уметь вести за собой сотрудников, мотивировать их на достижение целей. Кроме того, неформального лидера команда легче примет в качестве тимлида.

Что надо понять

Вам платят деньги не за то, что вы пишите код

Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше

Ваша основная задача — создать такие условия, чтобы команда была наиболее эффективна. Программист должен писать код, а всё остальное — ваши заботы.

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

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

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

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

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

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

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

Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.

Вы должны уметь подменять любого члена команды. Если кто-то заболел, ушёл в отпуск или уволился, и процесс разработки остановился, вся ответственность ложится на вас. Будьте готовы к этому всегда.

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

Как понять, какой из стилей предпочтителен для вас

Это самый трудный вопрос, ответ на который вам придется найти самостоятельно. Отведите себе время на рефлексию после прочтения статьи.

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

Неважно, какого уровня была организация, серьёзная она была или игровая — если она состояла из пяти или более людей, то в ней был один ярко выраженный стиль управления

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector