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

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

  • Соло: мне нравится работать в одиночку над моими сторонними проектами, так как я люблю не спеша экспериментировать, узнавать новое и делать ошибки. Нет никакого давления, чтобы доставить. Я работаю в своем темпе. Я выбираю технологию и язык программирования и т. д. Это хорошо для ночной разработки с фоновой музыкой или сериалами.
  • Команды среднего размера. Я бы сказал, что в командах среднего размера от 2 до 4 человек. Обычно в командах среднего размера у каждого есть несколько ролей. Я работал в проектах, где был бэкендщиком и мобильным разработчиком одновременно. Мне нравится эффективность и подача в таких командах, потому что я чувствую себя в отряде спецназа.
  • Большие команды: скорость здесь высока. Задачи имеют много зависимостей. Другие члены команды ждут, когда вы их доставите, чтобы они могли начать, и это очень напрягает. Но позвольте мне сказать вам кое-что: мне нравится этот стресс, поскольку он делает меня способным создавать истории высокого качества. В больших командах долгие часы технических/деловых дискуссий дают мне возможность учиться у других и делиться с ними своим мнением. Так что я многому учусь за очень короткое время, работая в таких командах.

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

  • Наслаждайтесь двусмысленностью. Количество неоднозначных проблем значительно возрастет, когда члены команды начнут делиться ими с вами. У этих проблем нет решений с серебряной пулей. На данный момент есть только лучший ответ. Решение этих проблем в этом случае требует выявления компромиссов и их балансировки, что означает дополнительное обсуждение с командой. Проблемы обычно исходят от одного разработчика, но я обычно предпочитаю приглашать других присоединиться к нам в этих обсуждениях только для того, чтобы поделиться с ними знаниями и поразмышлять вслух.
  • Вы узнаете, как создать самоуправляемую команду. Быть успешным лидером означает создать организацию, способную самостоятельно решить сложную проблему. Это скорее навык управления персоналом, чем технический мастер.
  • Вы научитесь делегировать полномочия.Делегирование — это один из тех навыков, которыми вам необходимо овладеть, чтобы создать самоуправляемую команду. Учиться трудно. Я наделал столько ошибок: делегировал кому-то, у кого полно задач, делегировал себе, где другим нечего делать. Подумайте о делегировании, когда вы делитесь своей тарелкой с другими. Излишняя щедрость перегружает команду, увеличивает стресс, и команда не будет продуктивной. Держите задачи для себя, вы станете единой точкой отказа, напрягая себя, и не будет самоуправляемой команды, как никто другой обучение. Вы должны подумать об этом, так как эта тарелка для всех. У вас есть часть этого, другие члены команды "заслуживают", чтобы получить часть этого, потому что они лидеры и они «заслуживают» учиться и расти.
  • Вы узнаете, как защитить свою команду. Иногда вы будете ввязываться в политику организации, что может повредить гармонии в команде. Ваша задача защитить их от любых ударов.

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