В крупных организациях разработчики должны кому-то отчитываться, а люди, которым они отчитываются, по определению становятся тимлидами. В идеальном мире тимлид — это универсальный «сержант»: и задачи раскидает, и код напишет, и команде поможет — подхватит, когда ресурсов не хватает. Конечно, желательно, чтобы они когда-то как-то участвовали в разработке ПО, но это в идеальном мире, а в реальном иногда бывает совсем не так. В реальном мире бывают тимлиды, которые совсем не помогают команде, а иногда даже вредят. Давайте об этом и поговорим — о проблемных личностях среди тимлидов.
Примечание переводчика. В статье идет речь о Development Manager, еще их называют Software Engineering Manager. Подобной роли мы не встречали на просторах российского IT, но посмотрев на функции и посовещавшись, мы в Петрович-Тех коллегиально решили, что она довольно сильно совпадает с привычной для нас с ролью тимлида. Если у вас есть предложения как назвать эту роль по-другому — ждем в комментариях.
Обычно в обязанности тимлида входит:
оценить проект, разделить на задачи и раскидать их по исполнителям;
следить, чтобы задачи закрывались вовремя;
самому писать код, например, когда кто-то заболел или взял отгул;
разрешать конфликты;
добиваться повышения зарплаты разработчикам или помогать продвигаться в карьере.
Здесь возникает разделение тимлидов на две категории: те, кто пишет код, и те, кто этого не делает.
Если тимлид все еще достаточно техничен, чтобы писать ПО вместе с разработчиками, то обычно он может эффективно управлять командой. При этом если он больше углубляется в инженерные процессы, например, занимается выбором инструментов для задач, проектов или продукта в целом, внедряет какие-то процессы, как вариант, CI/CD, углубляется в тестирование, архитектуру, автоматизацию, то может занимать роль техлида или архитектора.
Разработчики — сильные личности, и для управления ими требуется опытная рука. Такие тимлиды вызывают уважение и проблем не возникает (почти).
Если же тимлид больше не пишет код, или, что еще хуже, никогда не писал, – вопрос только в том, когда и как сильно он потерпит неудачу в эффективном управлении разработчиками. Об этом и поговорим.
Среди тимлидов встречаются 5 проблемных личностей:
Бывший разработчик
Когда-то он был разработчиком, поэтому теперь думает, что все еще разбирается в современных технологиях.
Кратко:
Может мутировать в «Стремящегося снова стать разработчиком».
Опасен в сочетании с разработчиком типа «Рок-звезда»
Вероятность исправления: высокая.
Опасность для проекта: высокая.
Проблема
Часто тимлид — это бывший разработчик. В этом случае он попадает в одну из двух категорий:
всё ещё пишет код;
уже не пишет.
Тимлид, который больше не пишет код, входит в категорию «Бывших разработчиков», но часто отрицает этот факт. Отрицая, он думает, что его мнение по-прежнему важно при принятии технических решений. На самом деле он может быть полностью оторван от текущего технологического стека, потому что технологии быстро меняются. Он может даже не стоять рядом с новыми технологиями, а смотреть издалека в бинокль.
«Бывший разработчик» — лишь один вариант названия этой категории. Более расширенный — «Злоупотребляющий техническими полномочиями». Подразумевает, что тимлид навязывает свое мнение людям, которые на него работают, используя свои полномочия. Навязывает, даже если мнение тимлида совсем не совпадает с мнением экспертов в отрасли.
Такое навязывание может принести больше вреда, если тимлид участвует в:
определении архитектуры системы;
выборе технологий для команды;
определении набора технических навыков для найма.
Лица, которые принимают нетехнические решения, например, HR, не сразу замечают негативное влияние решений «Бывших разработчиков». Поэтому они могут нанимать неподходящих людей, что только ухудшает проблему. Но разработчики это влияние чувствуют мгновенно, и даже могут уволиться, разочаровавшись в компании из-за навязанных нерелевантных действительности решений. Получается самозатягивающаяся петля.
Решение
Ведущие компании-разработчики ПО требуют, чтобы их тимлиды регулярно писали код. К сожалению, многие из них стали менеджерами, чтобы избежать программирования (см. «Метящий в менеджеры»), в результате чего типичное определение тимлида — это тот, кто раньше был техническим специалистом.
Существует 3 решения, которые решат или смягчат проблему «Бывшего разработчика»:
Требуйте, чтобы они писали код, оценивая их фактический вклад в кодовую базу.
«Указом сверху» удалите их из процесса принятия технических решений.
Попросите отказаться от процесса принятия технических решений, продемонстрировав отсутствие у них технических знаний.
Если бы это было так просто. Хотя бывшие разработчики, которые становятся тимлидами и все еще не могут расстаться с кодированием, создают проблемы для организации, но... Бывший разработчик, по крайней мере, может говорить на одном языке с командой и понимать предложения по дизайну и архитектуре от команды и архитектора. Во многом всё зависит от размера команды разработчиков и характера разрабатываемого продукта. Если вам нужен менеджер, который много кодит, действительно ли вам нужен менеджер? Для небольшой команды такая схема работает — она плоская. Но разработка — это не ракетостроение, здесь тимлиды выступают как лица, принимающие решения. Как и любой хороший руководитель, они делают обобщения или предложения и не диктуют свой выбор, основываясь на своем эго. Rémi Temmos, из комментариев. |
Нетехнарь
Если выбирать между «Бывшим разработчиком» и «Нетехнарем», я бы предпочел, чтобы у каждого тимлида был опыт разработки, независимо от того, программирует он/она сейчас или нет. Все потому, что...
«Нетехнарь» не обладает техническими знаниями, поэтому вообще не способен разобраться в управлении разработчиками.
Кратко:
Может мутировать в разработчика «Оптимиста» или «Пессимиста».
Опасен в сочетании с руководителем проекта типа «Капитан команды».
Вероятность исправления: отсутствует.
Опасность для проекта: отсутствует.
Проблема
Кажется нелогичным, что тот, кто никогда не разрабатывал ПО, может заставить разработчиков отчитываться перед ним. Но иногда в определенных ситуациях такое бывает:
Когда принято решение, чтобы все члены проектной группы отчитываются перед одним менеджером.
Когда тимлид покидает компанию, но нет технического менеджера, способного его заменить, а проект вести надо.
Когда организация не считает себя технической, например, какое-нибудь агентство. Следовательно, компания не видит необходимости вести проект техническому менеджеру.
Чтобы эффективно управлять разработчиками вы должны заслужить их уважение.
Верный способ никогда не завоевать уважения — это не ценить сложность выполняемой ими работы.
Это ярко проявляется в оценке работы. Менеджеры проектов часто обращаются за одобрением к тимлиду, когда они считают, что работа оценена неверно, но только технический менеджер может подтвердить точность оценки. И наоборот, если менеджер проектов считает, что работу оценили неправильно, только технический менеджер может эффективно защитить оценки разработчиков.
В конечном счете «Нетехнарь» бесполезен для проекта с точки зрения разработки.
Они помогают в другом — в «бумажной работе»: предоставляют отчеты о «человеческих ресурсах», отслеживают посещаемости работы, обеспечивают соблюдение политики компании, утверждают расписания и запросы на отпуск, но не оказывают негативного или положительного влияния на сам проект.
Я работаю разработчиком ПО 10 лет и согласен с утверждениями. У меня были нетехнические руководители проектов, тимлиды, и даже ревью кода, выполненное «Нетехнарем». Это так иронично, когда мне задают вопросы о том, что такое IF. В такие моменты просто не хочется тратить время на то, чтобы объяснять такие элементарные вещи человеку, который их скорее всего не поймет. hassle, из комментариев. |
Решение
Разработчики и руководители проектов часто жалуются на «Нетехнарей» при спорных оценках работы. Но они просто ищут арбитра и считают, что работа тимлида в том, чтобы быть этим арбитром.
«Нетехнарь» ощутимо не влияет на проект, кроме своей неспособности соответствовать ожиданиям. Поэтому ожидания просто необходимо обнулить. Такой тимлид просто не может выступать в качестве арбитра в технических спорах.
После обнуления ожиданий нам остается изучить две ключевые характеристики «Нетехнаря»:
Он бесполезен для проекта.
Но и не вреден.
Решение в том, чтобы просто игнорировать его существование, рассматривая его только как менеджера среднего звена.
Бессмысленно иметь:
шеф-повара, который не умеет готовить;
военного генерала, который никогда не был солдатом;
главного хирурга, который не знает, как проводить операции.
В жизни бывают моменты, когда для занятия должности вы должны обладать необходимым опытом, чтобы оправдать свое участие в этой роли. В IT-индустрии эта банальность была утрачена и заменена концепцией «Кто угодно может управлять разработчиками». Это явная ложь и симптом того, что такие тимлиды даже не знают, что они чего-то не знают.
В конечном счете, если наша работа заключается в разработке ПО, а ваша роль якобы в том, чтобы руководить разработчиками, в вас нет никакой ценности. Если у вас нет необходимого опыта для руководства вашей командой, то чаще всего вы — помеха.
«Нетеханари» скорее всего не добьются благосклонности разработчиков, занимая эту должность. По опыту моих коллег и моему (мной руководили и «Нетехнари», и технари), разница ощутима. Вы просто не можете поддерживать разработчика, если не знаете, каково это — быть им.
Ведь поддержка разработчиков — самая важная функция тимлида.
Примечание. Здесь есть еще одно решение — заменить тимлида на скрам-мастера. Тогда авторитарная модель управления, когда тимлид «сверху», а команда снизу, заменится на плоскую с коллективной ответственностью.
Работаю разработчиком 10 лет. Работал как с «Бывшими разработчиками», так и с «Нетехнарями» и предпочитаю первых. Хотя мне встречались хорошие тимлиды «Нетехнари», но они чрезвычайно редки и работают только в том случае, если человек действительно знает свое место. Нет ничего хуже, чем самонадеянный, пустословящий псевдотехнический менеджер, который думает, что знает все, но не может выполнить ни одной задачи. Они не знают, что вам действительно нужно, не могут оценивать людей, и не могут решить ни одной проблемы. В какой вселенной они могут быть полезны? Ответ: ни в какой. Легко злоупотреблять аббревиатурами и невежественно отдавать приказы. Писать код и устранять проблемы очень сложно. Сержант никогда не будет пользоваться уважением своего отделения, когда он самый слабый стрелок, самый трусливый и худший солдат. «Идите штурмовать этот бункер, ребята, я пока выпью немного кофе. О, и сделайте это к концу дня, спасибо» Rob, из комментариев. |
Карьерист
Это тимлид с амбициями, который продвигает свою карьеру, и воспринимает команду только как инструмент.
Кратко:
Может мутировать в разработчика типа «Метящий в менеджеры».
Опасен в сочетании с менеджером проекта типа «Тиран».
Вероятность исправления: отсутствует.
Опасность для проекта: чрезвычайно высокая.
Проблема
Кто бы не хотел получать больше? Рост зарплаты обычно связан с новой ролью или должностью. В организациях с четко сформулированными критериями карьерного роста сотрудники уверены, что вознаграждение и продвижение по службе придут со временем и упорным трудом.
Однако в компаниях, где решение о дополнительной компенсации принимается высшим руководством субъективно, «политическое маневрирование» рассматривается некоторыми как единственный способ подняться по корпоративной лестнице. «Карьерист» придерживается этой стратегии и рассматривает свою команду исключительно как средство для развития своей карьеры.
Важно провести различие между «Карьеристом» и тем, кто просто хочет работать эффективнее, в надежде на продвижение. Внимание первого сосредоточено только на продвижении, а не на том, что принесет пользу проекту или компании. Вполне возможно, что он ненавидит компанию, в которой работает, и не заинтересован в успехе проекта. Вместо этого он сосредоточен исключительно на своих целях — идти вверх по карьерной лестнице.
«Карьерист» не может быть честен с другими в своих целях. Иногда он даже не честен с самим собой. Так они приносят ещё больше вреда.
Они принимают сомнительные решения, которые при тщательном анализе могут быть оправданы только тем, что решения отвечают их интересам.
Их мнения и отношение меняются в соответствии с мнением руководства.
Они оценивают работу или принимают технологические решения для создания видимости бурной деятельности, чтобы получить одобрение сверху.
Такие тимлиды избегают ответственности в случае провала проекта — якобы у них не было конкретики по проекту. Если они видят, что проект терпит неудачу, они часто позиционируют себя так, чтобы занять авторитетное положение. Оказавшись в таком положении, они получают стимул ускорить провал проекта.
Решение
Увольте их.
Я видел таких на некоторых должностях среднего звена — они процветают в токсичной среде. Чтобы убрать их из проекта надо привлекать руководство, чтобы они решили, что делать. Trent Oh, из комментариев. |
Миротворец
Это тимлид, который считает, что споры контрпродуктивны, поэтому работает над подавлением дебатов любого рода.
Кратко:
Может мутировать в менеджера проектов типа «Капитан команды».
Опасен в сочетании с менеджером проектов типа «Тиран».
Вероятность исправления: высокая.
Опасность для проекта: низкая.
Проблема
Нет единственно верного способа разработки ПО.
Это приводит к спорам между разработчиками, в которых иногда должен участвовать тимлид. Требуется крепкая нервная система, чтобы терпеливо выслушивать разные мнения, разъяснять непонятные моменты и оставаться объективным, когда надо предложить оптимальное решение, особенно если оно непопулярно. Аргументы могут варьироваться от тривиальных, вроде рефакторинга, до того, кто должен участвовать в проекте.
Чаще всего люди устают и просто хотят, чтобы спор прекратился, хоть компромиссом, хоть волевым решением. «Миротворец» же, вместо того, чтобы способствовать техническому обсуждению для поиска оптимального решения, хочет только устранить сам «непродуктивный конфликт».
Содействие техническим дискуссиям — важный аспект технического руководства.
Различные уровни квалификации, опыт, конкурирующие методологии и широкий выбор технологий создают питательную среду для противоречивых мнений. Эти аргументы могут вызывать холивары, а иногда — мешать работе. Однако полное подавление аргументов нанесет ущерб моральному духу, подавит инновации и приведет к упущенным возможностям в улучшении результатов проекта.
Решение
У «Миротворца» есть две слабые стороны:
Они не могут отличить холивар от продуктивных дебатов.
Они не знают, как эффективно руководить техническими спорами.
Но эти проблемы можно решить. Начните с информирования «Миротворца» о том, что они не должны считать каждый аргумент непродуктивным, приводя наглядные примеры из опыта. С помощью ретроспективы они, вероятно, признают, что некоторые дискуссии были прекращены до того, как они пришли к логическому и потенциально продуктивному выводу.
Затем необходимо научить его проводить совещания и разрешать конфликты. Хотя это свойство присуще некоторым людям от природы, его можно развить. Книги и семинары полезны, но куда эффективнее наблюдать за организованной технической дискуссией между разработчиками в их собственной команде. С этой целью полезно привлечь внутреннего или внешнего посредника. Он не только разрешит противоречия, но и выступит как тренер для всех участников: от тимлидов до участников дебатов.
Стремящийся снова стать разработчиком
Тимлид, который понял, что работа менеджером не для него и хочет вернуться к программированию.
Кратко:
Может мутировать в «Некомпетентного» разработчика.
Опасен в сочетании с менеджером проекта типа «Статистик».
Вероятность исправления: низкая.
Опасность для проекта: низкая.
Проблема
Почти каждый разработчик сталкивается только с двумя вариантами карьерного роста:
Перейти на руководящую должность, например, тимлида.
Заняться техническим руководством, например, стать СТО или архитектором.
Те, кто выбрал первый путь, неожиданно могут понять, что управление на самом деле это:
Постоянно проводить собеседования и нанимать разработчиков, чтобы компенсировать естественную текучесть кадров в IT.
Отвечать за действия разработчиков.
Работать с постоянно недовольными разработчиками, которые требуют больше прав.
Сидеть на бесконечных бесполезных совещаниях.
Решать много административных задач.
Больше не писать код, и, следовательно, чувствовать, что технические навыки атрофируются.
Когда тимлид, наконец, поймет, что с него хватит жизни менеджера, он будет искать возможность вернуться в роль программиста. Кажется, если учитывать, что лучшие тимлиды также занимаются программированием, это хорошее стремление. Однако, чаще всего время, проведенное вне программирования, отразилось на их навыках так, что они не могут возобновить свой прежний карьерный путь.
Проблема возникает, когда команда разработчиков узнает о желании тимлида.
Они часто приходят к выводу, что:
их тимлид потерпел неудачу в новой роли, когда отказался быть разработчиком, потому что это слишком сложно;
и теперь ему не хватает квалификации, чтобы вернуться к программированию;
но он хочет это сделать, сохраняя свои управленческие полномочия и вознаграждение.
Проще говоря, он теперь не тимлид, а просто некомпетентный разработчик, с обязанностями тимлида.
Решение
Если тимлид сможет быстро наверстать упущенное и прокачать навыки разработчика, недостаток компетентности больше не будет проблемой. Это возможно при условии, что технологии не слишком далеко ушли вперед с того времени, когда он в последний раз работал программистом. При этом если его убедить остаться, то он станет лучше и как тимлид — ведь теперь он подкован и технически, и как менеджер.
К сожалению, если тимлид слишком долго ждал, чтобы повернуть свою «карьерную реку» вспять, ему придется начать фактически с нуля. Большинство компаний не поддержат такое переобучение, и он потеряет свою зарплату тимлида. Будет неловко для всех: четкой причины для увольнения нет, но при этом нет стимула, чтобы тимлид хотел уйти.
Единственный вариант решения — поставить ультиматум.
Тимлид продолжает выполнять свои обязанности, рискуя быть уволенными за невыполнение своей работы.
В свободное от работы время приобретает необходимые технические навыки, чтобы стать разработчиком. Если получится — компания рассмотрит его кандидатуру в рамках открытых вакансий.
В первом случае у нас появляется несчастный и непродуктивный сотрудник. Во втором — тимлид, но чуть счастливее. Но реальность такова, что мало организаций поддержат сотрудника, взявшего на себя меньшую ответственность, если это также не связано с уменьшением компенсации.
Какие из этих категорий тимлидов вам встречались? Есть ли еще виды, которые вы хотите добавить в «картотеку»? Пишите в комментариях.
