Решение конфликтов, эмпатия и понимание цели: soft skills руководителя команды разработчиков

Управление командой специалистов — непростая задача. О том, как превратить группу разработчиков в единую команду, проведя ее через все этапы развития, мы недавно рассказывали в подробной статье на «Хабре».

Сегодня поговорим о том, какие soft-скиллы должны быть у руководителя, как, где и почему их необходимо применять. Эта тема затрагивается не так часто, поэтому сегодня мы при помощи Андрея Рыжкина, ИТ-директора Agima, решили расставить все точки над i.

AGIMA

Менеджер или технический специалист?

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

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

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

Оптимальный вариант — назначить руководителем команды разработчиков человека с хорошей технической базой, опытом и заметными лидерскими/административными качествами.

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

  • Работа с командой: найм, онбординг, развитие, увольнение сотрудников, one2one, обратная связь, распределение задач, лидерство, фасилитация, управление конфликтами.
  • Работа с продуктом: понимание бизнес-ценности, целей, понимание потребностей клиента и потребителей; совместное с PO управление беклогом.

  • Обеспечение функционального качества проекта: процесс тестирования и управление инцидентами.
  • Обеспечение технического качества: оптимизированный и поддерживаемый код, работа с техдолгом, архитектура проекта, техническая документация, работа над отказоустойчивостью и производительностью проекта.
  • Автоматизация цикла разработки: настройка CI/CD, понимание и внедрение лучших практик.
  • Административные обязанности: схемы ведения проекта, улучшение процесса, метрики производства.
  • Выстраивание отношений с людьми внутри и вовне команды: эмпатия, умение договариваться, находить компромиссы и отстаивать интересы.

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

Примеры из практики? А пожалуйста

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

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

В итоге было принято решение провести неформальную беседу, обсудив не его текущие задачи по работе, а цели, которых человек хочет достичь лично для себя, плюс разобрать методы, которые будут применяться для достижения этих целей. Расставить все точки над “i” в разрезе того, что входит в его зону ответственности и что ему нужно делать, чтобы быть успешным тимлидом: решать конфликты внутри команды, согласовывать план спринта с проджект менеджером, разговаривать с сотрудниками про повышение и т.п. После разбора всех этих моментов тимлид был воодушевлен, записал себе кучу заметок и сказал что пойдет переваривать, чтобы с завтра начать реально работать над вновь открытыми для него обязанностями.

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

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

AGIMA

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

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

В целом, хороший руководитель должен:

  • Понимать необходимость принять то либо иное техническое решение и нести за него ответственность.
  • Уметь управлять людьми и постоянно прокачивать этот скилл.
  • Быть готовым к таким вызовам:
  • Распределять задачи, а не самостоятельно все решать, замыкая на себе процессы.
  • Общаться с людьми, а не отписываться в тикете.
  • Принимать решения в условиях недостаточной информированности и брать на себя за это ответственность.
  • Принимать очень непростые решения: увольнение, повышение в должности сотрудника или отказ в повышении, перевод сотрудника на другой проект.
  • Уметь видеть, закладывать и минимизировать риски.

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

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

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

В профессиональном плане такой человек может быть суперменом, но это мало чем поможет в управлении организационными и бизнес-процессами.

Софт-скиллы руководителя команды разработчиков

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

  • Эмпатия, поскольку придется много работать с людьми: пытаться им помочь, ободрять, развивать, давать обратную связь, договариваться в случае возникновения конфликтных ситуаций.
  • Решительность, т.к. руководитель должен оперативно решать возникающие проблемы, даже в том случае, если информации недостаточно.
  • Тайм-менеджмент. Задач будет всегда больше, чем руководитель может решить самостоятельно. Поэтому нужно четко понимать, что реально решить, а что нет, плюс адекватно оценивать время, которое потребуется для каждой из новых задач.
  • Умение делегировать и принимать задачи. Этот скилл тесно связан с тайм-менеджментом. Плюс ко всему, следует научиться говорить «нет».
  • Стрессоустойчивость. Этот скилл очень нужен для того, чтобы долго и успешно работать в режиме многозадачности. Руководителя часто дергают — приходят обсудить важные вопросы, звонят по телефону, пишут в мессенджерах и на e-mail, прилетают новые задачи в трекере.
  • Системное мышление — необходимо уметь строить реальную объективную картину происходящего в отделе, чтобы находить проблемы и улучшать процессы.
  • Умение строить стратегические и тактические планы.
  • Самостоятельность. Решения нужно принимать самостоятельно, не надеясь на чудо, когда проблема или конфликт разрешатся сами собой.
AGIMA

И напоследок — несколько советов тем читателям, кто хочет стать хорошим руководителем команды разработчиков:

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

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

0
36 комментариев
Написать комментарий...
Мария Петрова

нереально полезная статья, спасибо!!

Ответить
Развернуть ветку
Андрей Рыжкин

Рад, что пригодилось :)

Ответить
Развернуть ветку
Ilya Rovda

Отличная статья, спасибо. Прочувствовал весь объем ответственности ТЛ)

Ответить
Развернуть ветку
Андрей Рыжкин

И вам спасибо, что прочитали и нашли время на комментарий :)
Вместе с большой ответственностью приходят и большие возможности ;)

Ответить
Развернуть ветку
Scott Freak

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

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

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

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

Ответить
Развернуть ветку
Андрей Рыжкин

А я больше склоняюсь к мнению, что категоричность всегда идет рука об руку с недостатком опыта или максимализмом :)
Нет ничего абсолютного: нельзя утверждать, что иерахичная система - the best, также как и не стал бы я утверждать, что бирюза везде будет еще лучше.
У вас видимо были свои примеры из опыта, у меня свои.
Я например знаю одну очень крутую компанию которая выросла из стартапа с такой вот бюризой, а теперь когда столкнулись с ростом и сопутствующими проблемами как лекарство "открыли" для себя рациональный менеджмент и иерархии, хотя вот уж казалось бы :)

И то и другое (и классические иерархичные системы управления и гибкие) надо уметь готовить, так же как и в методологиях разработки ПО: если заставить менеджера/тимлида/специалиста который всю жизнь работал по T&M провеести проект по waterfall (или наоборот) - скорее всего он его завалит.

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

Ответить
Развернуть ветку
Scott Freak

Да, условия определяют выбор инструмента.

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

А по поводу вашего примера - самоорганизация предполагает бОльшую ответственность!

Посмотрите например https://biryuzovie.ru/primery/stroitelstvo-kalininskoj-atomnoj-elektrostancii/

Ответить
Развернуть ветку
Андрей Рыжкин

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

Ответить
Развернуть ветку
Олег Малахов

И тут Гикбрейнс...
Но речь не об этом, кажется, что сейчас у ТЛ большая часть работы — это коммуникация, а ведь когда-то мы кодили 

Ответить
Развернуть ветку
Андрей Рыжкин

Ностальгия по былым временам? :) 
Я чаще встречаю на собеседованиях романтические заблуждения вроде "когда я стану тимлидом - буду пилить только самые интересные задачи" :) 

А по поводу коммуникаций - 100% это так, поэтому наравне с хард-скиллс нужно качать и умение слушать, слышать и говорить свою правду так, чтобы люди хотели меняться, а не набить тебе морду :)

Ответить
Развернуть ветку
Bulat Ziganshin

я хочу быть течлидом именно для этого. а зачем ещё?

Ответить
Развернуть ветку
Андрей Рыжкин

Так в статье - про тимлидов :)
Но имхо не обязательно становится ни тем ни другим (ни тимлидом, ни техлидом), чтобы иметь возможность пилить самые интересные задачи, и вместе с этим такая возможность есть у обоих ролей - все зависит от ваших навыков тайм-менеджмента, и управления сроками и ожиданиями ;)

Ответить
Развернуть ветку
Bulat Ziganshin

так тимлид и есть по-моему течлид + тайм-менеджмент

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

Ответить
Развернуть ветку
Vitaliy -

Так и есть. Если человеку не интересны менеджерские задачи - ему не стоит идти в тимлиды

Ответить
Развернуть ветку
Svetlana Nesterova

Есть похожая статья для руководителя аналитиков?

Ответить
Развернуть ветку
Andrey

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

Ответить
Развернуть ветку
Андрей Рыжкин

Солидарен с предыдущим оратором.
Разве что предполагаю, что у аналитиков должно быть больше решений основанных на данных :)
Светлана, может есть какие-то конкретные вопросы? Давайте разберем :)

Ответить
Развернуть ветку
Scott Freak

Если вы руководите аналитиками, то попробуйте вот что-то, использующее самоорганизацию. Опыт руководства аналитиками по гибким подходам привёл меня к следующим мыслям об управлении самоорганизующимися командами, что описал в вебинаре

Ответить
Развернуть ветку
Андрей Рыжкин

Спасибо вам за ссылку на видео, проглядел быстро - интересно. Сегодня досмотрю в самолете.

Ответить
Развернуть ветку
Svetlana Nesterova

Спасибо большое!)

Ответить
Развернуть ветку
Scott Freak

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

Ответить
Развернуть ветку
AGIMA
Автор

По аналитике скоро запустим AGIMA.University, этот курс для прокаченных специалистов. В идеале сделать офлайн, но будем ориентироваться на ситуацию в Москве. 
Чуть подробнее тут: https://vimeo.com/207969103

Ответить
Развернуть ветку
Michael Solar

Командную работу давно уже разложили по полочкам психотерапевты. Впрочем, кто их читает...
Жизнь любой команды состоит из 4-х этапов

Ответить
Развернуть ветку
Андрей Рыжкин

Читаем, изучаем, практикуем и делаем выводы :)
Разные есть подходы и определения, например в модели Такмана (которую мы как раз решили раскрыть в нашем курсе для тимлидов, чтобы больше руководителей узнали про нее и чтобы это подтолкнуло их посмотреть и другие варианты) таких этапов целых 5-ть.
Самое главное, что мне кажется важно учесть когда изучаешь все эти модели - это не начать клеить ярлыки на людей согласно только что прочитанной книге/статье/whatever, люди иногда оказываются сильно сложнее, чем может показаться после того, как вы такую модель "освоили" :)

Ответить
Развернуть ветку
Константин Балакин

Андрей, спасибо за статью! Читал с упоением и на оном дыхании, т.к. почти каждое предложение отзывалось внутри)
Каждый день сталкиваюсь со всеми проблемами управленца.
Тут, как ты описал в статье, есть очень большая скрытая проблема для крутана, которому предложили роль управленца, а именно:
вот человек круто себя проявляет как специалист, на энтузиазме предлагает различные улучшалки процессов, технологий и т.д. Его замечают, предлагают повышение.
Дальше скорее всего в большинстве случаев люди соглашаются и не подозревают про весь тот "геморой", который на них свалится в роли тимлида. Люди любят делать что-то руками, они получают от этого кайф, удовольствие и отдушину. А тут они вдруг осознают, что у них на то, что нравилось и на то, от чего прет, больше нет времени, а почти все свое время нужно посвящать решению конфликтов, 1-1 встречам и тд и тп.) 
НО! Зарплата то больше) и с одной стороны некомфортно в новой должности, а с другой - бОльшие деньги и не хочется их терять. 
Тут я думаю у многих тимлидов есть внутренний конфликт...
Нравится кодить и пилить классные фичи в одиночку, а в реальности приходится за бОльшие деньги заниматься почти 100% коммуникациями с командой, которая выжирает почти всю энергию)
Наверное, у меня просто наболело.

Ответить
Развернуть ветку
Андрей Рыжкин

Константин, спасибо и тебе что осилил и нашел время написать комментарий :)
Прекрасно понимаю о чем ты говоришь: когда тебе предлагают повышение, ты как то больше думаешь про новые возможности, а не про новые обязанности, и иногда ожидания обманываются.
На мой взгляд самая важная задача стоит у вышестоящего руководителя: донести не столько "плюшки" от нового места, но (самое главное) новые обязанности и сложности. На некоторых собеседованиях, когда я вижу что человек излишне романтизирует должность я специально уделяю некоторое время на то, чтобы "спустить его на землю". Рассказываю, что ему кучу времени нужно будет тратить на решение конфликтов, планирование, отчеты и прочее-прочее. Только когда я убежусь, что человек это осознает - мы перейдем к обсуждению условий работы.

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

Кстати, здесь кроется еще одна моя любимая ловушка: почитайте про Принцип Питера, очень интересно на мой взгляд :)

Ответить
Развернуть ветку
Константин Балакин

Андрей, спасибо, что ответил на мой комментарий. Для меня это очень ценно ;)

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

Про принцип питера - записал, ознакомлюсь. Спасибо ;)

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

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

Ответить
Развернуть ветку
Svetlana Nesterova

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

Ответить
Развернуть ветку
Андрей Рыжкин

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

Ответить
Развернуть ветку
Svetlana Nesterova

Спасибо, изучу)

Ответить
Развернуть ветку
Дмитрий Павлик

На моей практике чаще всего именно менеджер, даже с самими минимальными техническими знаниями (а-ля как поменять шрифт в ворде),  становится руководителем. Ибо специфика деятельности решает: больше общается, а не копается в коде, как следствие малых технических компетенций является возможность наобещать всяких нереальных плюшек и генерировать идеи, не ограничиваясь своими техническими знаниями. 
Коммуникационные знания у таких людей несравненно более развитые на естественном уровне, чем у прошедшего несколько профильных курсов по софт-скилам технаря. 
А далее в дело вступает самая элементарная методичка по делегированию  задач (оценка трудозатрат, реализация, консультация). Кодеры будут слишком заняты, чтобы придумывать какие-то хитрые интриги и банально им не хватит опыта чтобы как-то дискредитировать своего руководителя. Да и перед кем? 
Если чел не дурак, то через несколько месяцев он будет рулить отделом в полной степени, так как наработается опыт. Да и вышестоящее руководство не любит менять коней на переправе. 

Ответить
Развернуть ветку
Андрей Рыжкин

Какую-то мрачную картину вы описали :) 
В общем посыле ("руководителем чаще становится тот, кому ближе коммуникации, чем быть с кодом 1 на 1") - согласен, думаю это нормально. Каждому по желанию. Плохого в этом ничего не вижу, руководителю не обязательно быть самым хард-скилловым в команде, конечно это будет круто с точки зрения его авторитета, но имхо это редкость (или скажется недостаток софт-скиллов, т.к. много времени уделено хард-скиллам, или человек должен тянуть обе эти состовляющие одновременно круто - что мне кажется редким даром).
Зачем руководителю обещать "нереальные плюшки" или зачем "кодерам дискридитировать руководителя" - не понял. Нереальные плюшки приведут к невыполнению сформированных задач, а тратить время на то, чтобы дискридитировать своего руководителя мне кажется пустой потерей времени с учетом текущих потребностей рынка.
Или я вас не так понял, тогда прошу прощения :)

Ответить
Развернуть ветку
Дмитрий Павлик

Поясню:
1. Нереальные плюшки - в том плане, что технические специалисты (непосредственные исполнители) часто опираются на свои же знания, которые их же ограничивают. Они построены на прошлом опыте и на том, что они сами видели. Как в той метафоре про молоток и гвозди. Люди, отдаленные от знания технических ньюансов,  этих барьеров не видят и поэтому мыслят более широко. Далее остаётся хорошенько напрячь технических специалистов и то, что касалось крайне сложным, становится реальным. Даже если не получится сделать всё, то какая-то часть все равно будет готова и даже может произвести «вау»-эффект. Мы это часто наблюдаем, когда сначала обещают что-то крутое в продукте, но на выходе итог немного другой, с поправкой на действительность, однако, деньги получены, акции выросли, контракты получены, отдел разработки подчинён. Действительность? Да. 
2. Это уже как следствие. Не всем ит-специалистам нравится, когда ими рулит некомпетентный в разработке человек, но поделать ничего не могут - знаний и умений вести политические беседы нет.
К сожалению, я описываю практические ситуации, характерные для крупных не ИТ-компаний. 
Плохого, в целом, нет. Просто кейсы. 

Ответить
Развернуть ветку
Dmitriy Zakharchenko

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

Ответить
Развернуть ветку
Андрей Рыжкин

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

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

Ответить
Развернуть ветку
33 комментария
Раскрывать всегда