Хабрахабр

[Перевод] 8 простых шагов к провалу начинающего менеджера по разработке

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

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

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

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

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

У менеджера две важные обязанности: развивать команду и приносить пользу бизнесу. И я бы сказал, что следует расставить приоритеты именно в таком порядке. Первое усиливает второе.

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

Но это лишь половина работы. Так и есть. Потому что другая половина труднее, она непохожа на то, чем вы занимались раньше и, вероятно, именно здесь вам сильнее всего не хватает опыта. Лёгкая половина. Помогать людям расти не только технически, но и в продуктивности. Это рост вашей команды. Разговаривать один на один, слушать, обучать. Искать способы улучшить взаимодействие. И если вы игнорируете её, то блокируете бóльшую часть производительности. Оказывается, эти «лёгкие» занятия — трудная часть. Вы покажете рост эффективности, но не истинный прогресс. Вы добьётесь результата, но он будет далёк от максимального потенциала команды. Вы никогда серьёзно не поднимете планку — и не будете знать, почему.

Эффективность команды начинается с самих сотрудников, а не с их работы.

В прошлом вам как отдельному работнику было легко оценить производительность работы: «сегодня я реализовал две функции», «исправил этот сумасшедший баг», «все тесты пройдены». Это ощутимые единицы работы, привязанные к результатам группы. И в коммитах указано ваше имя. Легко увидеть работу конкретного сотрудника и оценить его по тому, насколько его результат приближает команду к своим целям.

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

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

Вы для себя чётко сформулировали, чего ждёте от команды? От каждого человека? Вы им рассказали?

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

При назначении задачи убедитесь, что согласовали предположения и ожидания.

«Только не забудь задокументировать свои выводы, а затем рассмотреть их с командой, прежде чем писать какой-то код»

Я предполагаю, что вам нужно 30 минут, чтобы приостановить текущую работу. «Данная история блокирует QA, поэтому это ваш главный приоритет. Если историю нельзя сделать до конца дня, дайте знать как можно скорее»

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

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

Нужно защитить команду. Тяжело пойти против течения, но вы обязаны это прекратить. Для начала, не будьте героем. Как это сделать? Выиграйте немного времени и вовлеките команду в принятие обязательств. Не отвечайте сразу «да» на любую просьбу начальника, клиентов или деловых партнеров. Почему это важно для компании? Насколько это возможно, покажите сотрудникам общую картину. Что на самом деле от нас просят? Как повлияет на клиентов? И самое главное, вовлечь команду в решение: «Учитывая всю информацию, как вы думаете, что мы можем сделать?»

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

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

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

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

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

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

Вот некоторые основы:

  • Постарайтесь решить проблему как можно скорее. Чем дольше тянуть, тем сложнее разговор.
  • Будьте конкретны и приводите примеры. Это ещё одна причина быстро поднять проблему, пока информация свежа в голове.
  • Подготовьтесь. Подумайте, как начать разговор, и самое главное — что вы хотите получить от этого разговора. Каков основной посыл и каков желаемый результат? Подумайте о возможных реакциях, вопросах и ответах человека, и подумайте, как ответить.
  • Разговор должен быть сосредоточен на поведении или действиях, а не на самом человеке. Вместо фразы «вы неуважительны» попробуйте «когда вы делаете X, это выглядит неуважительно». Хорошая идея — сосредоточиться на последствиях их действий. Влияние на других или негативные и неочевидные последствия для самого человека.
  • Выберите подходящее время и место. Перехватить человека в коридоре может быть прекрасно для быстрой обратной связи, особенно в подкрепление прошлого разговора. Но если ожидается долгий и жёсткий разговор, то убедитесь, что для него есть приватное место и достаточно времени. Самое худшее — запланировать какой-то небольшой временной интервал, а затем прерваться, оставив разговор незаконченным.
  • Конечно, лучший план — его отсутствие. Не доводите ситуацию до сложных столкновений, а решайте проблемы с самого начала, до эскалации. Регулярные и эффективные собеседования с сотрудниками — прекрасная возможность обсудить проблемы, пока они еще малы или вообще не существуют.

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

Блоги, книги, конференции и социальные сети. Я обнаружил, что в менеджменте работают многие из тех же успешных методов, которые я использовал будучи программистом. На каждую книгу об изучении Golang есть книга о стратегиях эффективных переговоров. На каждую статью об управлении контейнеров в Kubernetes есть статья о масштабировании команды по методологии Lean. И на каждую лекцию на конференции о мониторинге микросервисов есть изложение лучших практик для изучения команды с использованием метрик и показателей.

На самом деле соотношение ресурсов о технологиях и менеджменте скорее 100:1. Ладно, я преувеличил.

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

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

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

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть