Поздравляю — вы новый менеджер! Нет, честно, от всей души. Слышите сарказм в голосе? Ну извините, я пытался как мог, но конечно, вместе с волнением есть доля сомнений и грусти. Наверное, вам придётся пройти через всё то, через что прошёл я и многие другие. Вы много лет работали инженером-программистом (или вставьте тут другую профессию), хорошо себя проявили, заслужили титул «сеньора» и вас считали неформальным лидером в коллективе. Вероятно, до настоящего момента были тимлидом. Возможно, какое-то время даже сопротивлялись этому «повышению», не хотели уходить из программирования, терять навыки. Но на самом деле боялись, что не справитесь. Наконец, каким-то образом вас уговорили рискнуть — и вот вы здесь. От ведущего инженера к начинающему менеджеру.
Как преуспеть в новой роли? Как опять пройти через все ступени и достичь такого уровня результатов и доверия, которого все ожидают, особенно вы сами? Сотни книг и тысячи блогов пытаются найти эти ответы, так что не буду притворяться, что у меня есть секрет успеха. Но я знаю несколько способов, которые совершенно точно гарантируют вам провал.
1. Продолжать программировать
Наверняка поднимется буря в комментариях. Ваша компания может ожидать, что менеджеры отчасти продолжат программировать, работая в двух ипостасях. Мой опыт и, кажется, опыт многих других говорит, что обычно это путь в никуда. Невозможно усидеть на двух стульях и уделить достаточное внимание каждой из двух работ, поэтому вы потерпите неудачу в обеих. Если с компанией повезло, то вас заставят чуть ли не подписать отказ от программирования.
Окей, даже если от вас отчасти ожидают написания кода, это точно теперь не основная задача. Речь о том, что ваши попытки программировать говорят о неуверенности, что делать в своей новой роли. Поэтому вы обращаетесь к работе, которая привычна и удобна. Это может принести краткосрочную пользу в некоторых проектах и дать вам чувство комфорта, но я гарантирую, что вы уходите от своих основных целей. Вы вредите долгосрочному результату команды и также не растёте в новой профессии.
Вряд ли кто-то захочет взять и отказаться от ценного и с трудом заработанного технического опыта. В этой статье приведены некоторые хорошие варианты для менеджеров, которые хотят сохранить практику программирования.
2. Сосредоточить внимание только на работе, а не на людях
У менеджера две важные обязанности: развивать команду и приносить пользу бизнесу. И я бы сказал, что следует расставить приоритеты именно в таком порядке. Первое усиливает второе.
Типичная картина эффективной работы — завершение проектов, выпуск функций, исправление ошибок и т. д. И если вам удалось избежать ловушки «ведущего программиста» и избежать ежедневного программирования, то вы как-то пытаетесь удовлетворить привычную потребность в ежедневном выполнении задач, чтобы получить это чувство полезности. Это часто приводит к ситуации, когда человек выступает в качестве менеджера проекта или надсмотрщика: назначает тикеты, отслеживает метрики, запрашивает обновления статуса, обсуждает архитектуру, ведёт историю и так далее. Короче говоря, сосредоточен на работе. Вы каждый день ставите галочки по списку и чувствуете, что дело продвигается.
Так и есть. Но это лишь половина работы. Лёгкая половина. Потому что другая половина труднее, она непохожа на то, чем вы занимались раньше и, вероятно, именно здесь вам сильнее всего не хватает опыта. Это рост вашей команды. Помогать людям расти не только технически, но и в продуктивности. Искать способы улучшить взаимодействие. Разговаривать один на один, слушать, обучать. Оказывается, эти «лёгкие» занятия — трудная часть. И если вы игнорируете её, то блокируете бóльшую часть производительности. Вы добьётесь результата, но он будет далёк от максимального потенциала команды. Вы покажете рост эффективности, но не истинный прогресс. Вы никогда серьёзно не поднимете планку — и не будете знать, почему.
Эффективность команды начинается с самих сотрудников, а не с их работы.
3. Оценивать своё ценность по производительности
В прошлом вам как отдельному работнику было легко оценить производительность работы: «сегодня я реализовал две функции», «исправил этот сумасшедший баг», «все тесты пройдены». Это ощутимые единицы работы, привязанные к результатам группы. И в коммитах указано ваше имя. Легко увидеть работу конкретного сотрудника и оценить его по тому, насколько его результат приближает команду к своим целям.
Но теперь большая часть вашего влияния — в эффектах второго порядка. Их сложнее соотнести с работой команды. Путаницы добавляет то, что ваша работа больше не формализована в виде чёткого списка. Вы даже не всегда уверены, что делаете какую-то «работу».
Поэтому как новый менеджер вы обычно хватаете несколько конкретных задач — и делаете их, чтобы добиться чувства завершённости, пользы. При этом, вероятно, завышая фактическую важность этих задач. Презентации, бюджеты, отчёты о состоянии, артефакты Скрама — это можно посчитать, но это не работа. По сути, ваша работа определяется достижениями команды. Их достижения — вот главная цель. В конечном счёте ваша ценность измеряется их успехом. Сосредоточьтесь на команде и на том, что им необходимо для успешной работы.
4. Не говорить о своих ожиданиях
Вы для себя чётко сформулировали, чего ждёте от команды? От каждого человека? Вы им рассказали?
Для нас вполне естественно думать, что разум другого человека работает так же, как наш. Что у нас одинаковая дисциплина, мотивация и логика. И это ведёт ко многим предположениям. Если мы с вами смотрим на один и тот же набор заданий с одинаковыми спецификациями, то естественно должны прийти к одинаковым выводам, как и когда эта работа будет выполнена. Ну-ну. Так мы раздаём задания с некоторым количеством информации, но с неустановленными и предполагаемыми ожиданиями. И вы знаете, что происходит в таких случаях.
При назначении задачи убедитесь, что согласовали предположения и ожидания.
«Только не забудь задокументировать свои выводы, а затем рассмотреть их с командой, прежде чем писать какой-то код»
«Данная история блокирует QA, поэтому это ваш главный приоритет. Я предполагаю, что вам нужно 30 минут, чтобы приостановить текущую работу. Если историю нельзя сделать до конца дня, дайте знать как можно скорее»
Гораздо сложнее сформулировать подсознательные ожидания — те, которых вы не сознаёте до тех пор, пока они не нарушаются. Это ваша личная модель принятия решений, как бы вы это сделали. Вы просто предполагаете, что так всё и будет. Но конечно, вы их не сформулировали, а когда результат не соответствует — вы испытаете разочарование в других. Это очень демотивирует и деморализует команду. Если у вас имеются ожидания относительно их работы, лучше сообщить об этом. Нельзя заставлять гадать. И если вы не уверены в своих ожиданиях, то потратьте время — разберитесь в себе и поймите их. Это ваша работа, ваша ответственность перед командой и, вероятно, таковы ожидания вашего начальника.
5. Отказаться из обязательств
Вы новый менеджер и хотите произвести впечатление на босса. «Конечно, мы можем это сделать», да, да, да. Давать обещания, которые команда не сможет выполнить. Я уверен, что большинство из нас были на другой стороне. Вам дают нереальные сроки и поставлены задачи, на которые вы никогда не соглашались. Что вы подумаете о своём боссе? Конечно, команда может сплотиться и выдать невозможное, но я уверен, что история не закончится на этом. Ваш босс теперь выглядит великолепно — и просто продолжит давать такие же обещания. Довольно скоро у команды заканчивается терпение, люди начали увольняться, переходить в другие команды или вообще покидать компанию.
Тяжело пойти против течения, но вы обязаны это прекратить. Нужно защитить команду. Как это сделать? Для начала, не будьте героем. Не отвечайте сразу «да» на любую просьбу начальника, клиентов или деловых партнеров. Выиграйте немного времени и вовлеките команду в принятие обязательств. Насколько это возможно, покажите сотрудникам общую картину. Почему это важно для компании? Как повлияет на клиентов? Что на самом деле от нас просят? И самое главное, вовлечь команду в решение: «Учитывая всю информацию, как вы думаете, что мы можем сделать?»
Иногда у вас не останется выбора, кроме как принимать и отдавать приказы, но гораздо лучше, если команда вовлечена в обсуждение.
6. Спутать командование с руководством
Стать на стул и раздавать приказы — это не лидерство. Часто бывает, что менеджер координирует работу и раздаёт задания. Но не путайте это с лидерством. Усиленная раздача команд часто является симптомом того, что мы называем микроменеджментом — это приводит к тому, что команды теряют способность работать автономно. Сотрудники ждут, что все решения исходят от вас. И в итоге вы станете узким местом для команды. Вы создали неэффективную группу, которая просто совершает привычные движения, ожидает следующей задачи и бездумно её выполняет.
Лидер вдохновляет, а не командует. Он рисует картину цели и устанавливает направление, а не даёт указания. Он прививает общее чувство цели и смысла. Обеспечивает достаточный контекст через миссию, стратегию и задачи, чтобы люди принимали правильные решения.
7. Избегать жёстких разговоров
Если вам удалось избежать большинства этих ошибок, у меня есть для вас личный вызов. Это то, что отличает тимлида от обычного менеджера, ученика от учителя, новичка от профи.
В бытность разработчиком вы наверняка вели горячие дискуссии о проекте, дизайне, выборе технологий, методах программирования и тому подобном. Но реальные проблемы людей, личные конфликты и жалобы? Ну, обычно этим занимается босс, если вообще кому-то есть дело. Угадай, что? Теперь ты босс, и всё это летит к тебе. Один из сотрудников втягивает вас в проблему или кто-то посторонний хочет решить какой-то инцидент. Но чаще всего вы лично видите проблему с некоторыми действиями и поведением. Они не соответствуют вашим ценностям или ценностям команды — и вам действительно нужно этим заняться. Вы напрягаетесь, а ум начинает придумывать всевозможные оправдания и причины, чтобы этого избежать. Но именно в этот самый момент проверяется ваша храбрость и профессиональные качества. Самый важный момент. Это оптимальная возможность для вас произвести реальные изменения в организации. Именно в такие моменты вы помогаете людям подняться на новый уровень (включая себя). Позитивное отношение к таким ситуациям — секрет построения высокоэффективной команды.
Как же не бояться жёстких разговоров и решать проблемы лицом к лицу? Надо перестать их ибегать. Как и многие другие навыки, единственный способ научиться — практика. В каком-то смысле вы тут кодируете в продакшне. Но есть способы подготовиться и определённая тактика, повышающая ваши шансы на хороший исход. В интернете много советов, поэтому ищите — и выберите какую-нибудь технику на пробу. Возможно, стоить начать с книги «Важнейшие разговоры».
Вот некоторые основы:
- Постарайтесь решить проблему как можно скорее. Чем дольше тянуть, тем сложнее разговор.
- Будьте конкретны и приводите примеры. Это ещё одна причина быстро поднять проблему, пока информация свежа в голове.
- Подготовьтесь. Подумайте, как начать разговор, и самое главное — что вы хотите получить от этого разговора. Каков основной посыл и каков желаемый результат? Подумайте о возможных реакциях, вопросах и ответах человека, и подумайте, как ответить.
- Разговор должен быть сосредоточен на поведении или действиях, а не на самом человеке. Вместо фразы «вы неуважительны» попробуйте «когда вы делаете X, это выглядит неуважительно». Хорошая идея — сосредоточиться на последствиях их действий. Влияние на других или негативные и неочевидные последствия для самого человека.
- Выберите подходящее время и место. Перехватить человека в коридоре может быть прекрасно для быстрой обратной связи, особенно в подкрепление прошлого разговора. Но если ожидается долгий и жёсткий разговор, то убедитесь, что для него есть приватное место и достаточно времени. Самое худшее — запланировать какой-то небольшой временной интервал, а затем прерваться, оставив разговор незаконченным.
- Конечно, лучший план — его отсутствие. Не доводите ситуацию до сложных столкновений, а решайте проблемы с самого начала, до эскалации. Регулярные и эффективные собеседования с сотрудниками — прекрасная возможность обсудить проблемы, пока они еще малы или вообще не существуют.
Когда я в первый раз готовился к такому разговору, было очень страшно, я мучился несколько дней. Но всё прошло гораздо легче, чем в той апокалиптической картине, которую нарисовало моё воображение. Тот разговор действительно помог и сильно упростил дальнейшее общение. Так что преодолейте страх — всё будет не так плохо, как вы думаете, а результаты того стоят. Ваша команда заслуживает этого, и вы сами себе скажете спасибо.
8. Перестать совершенствовать своё мастерство
Помните годы, потраченные на изучение новейших технологий, инструментов, языков, фреймворков в стремлении стать великим инженером? Роль менеджера тут ничего не меняет. Менеджмент — это навык, искусство, практика. Это способность, которую вы приобретаете с течением времени. Она требует тех же усилий и преданности к обучению, как у инженера.
Я обнаружил, что в менеджменте работают многие из тех же успешных методов, которые я использовал будучи программистом. Блоги, книги, конференции и социальные сети. На каждую статью об управлении контейнеров в Kubernetes есть статья о масштабировании команды по методологии Lean. На каждую книгу об изучении Golang есть книга о стратегиях эффективных переговоров. И на каждую лекцию на конференции о мониторинге микросервисов есть изложение лучших практик для изучения команды с использованием метрик и показателей.
Ладно, я преувеличил. На самом деле соотношение ресурсов о технологиях и менеджменте скорее 100:1.
Есть плохие менеджеры и есть отличные менеджеры. Новички и эксперты. Как и в программировании, существует природный дар, но главный и решающий фактор — это непрерывная жажда учиться и повышать свой уровень мастерства.
Когда я перешёл из разработчиков в менеджеры, то испытал подавленность, но и бодрящее чувство. Всё начать заново и столько изучить… но ведь так много я узнаю. Я могу определить свою личность с совершенно новой стороны.
Мне предстоит долгий путь. Когда я пройду его, то может и напишу о том, как добиться успеха. А пока я концентрируюсь на том, чтобы просто не потерпеть неудачу.
Автор: m1rko
