Применение лучших практик технического лидерства в управлении людьми

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

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

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

  • отзывы (расширение возможностей вашей команды),
  • структура (архитектура как кода, так и операций команды) и
  • направление (куда движется ваша команда и как она собирается туда добраться).

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

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

Если вам понравился этот пост, пожалуйста, 👏 , подпишитесь или следуйте за мной в среде или LinkedIn, чтобы сообщить мне, что я на правильном пути!

Структура: обратная связь, структура и направление

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

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

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

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

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

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

Обратная связь

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

Отзывы о результатах работы и выполнении работ

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

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

Хороший способ еще больше разбить обратную связь — подумать об этом с точки зрения времени, как показано в таблице ниже.

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

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

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

Отзывы о влиянии на бизнес

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

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

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

  1. максимизировать создаваемую ценность и
  2. свести к минимуму дельту между общей компенсацией и конкурентоспособной заработной платой.

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

Состав

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

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

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

API для команд

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

  • Простота. Взаимодействие с вашей командой не должно быть сложным.
  • Хорошо задокументировано. Четко определенные входные/выходные данные позволяют внешним командам предоставлять правильные входные данные для получения желаемых результатов.
  • Ограничение скорости. Ваша команда не может выполнять бесконечную работу, так как же вы сообщаете об ограничениях производительности?
  • Стабильный. Будьте избирательны при обновлении внешних процессов. Надежность важнее скорости.
  • Собирайте отзывы потребителей. Дайте людям возможность запрашивать новые или измененные функции.

На практике API — это то, как ваша команда

  • отвечает на запросы о новых функциях,
  • поддерживает существующий функционал,
  • осуществляет планирование мощностей и
  • взаимодействует с зависимыми командами (дизайн, QA и т.д.).

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

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

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

Архитектуры для команд

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

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

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

Следуйте существующим шаблонам проектирования

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

Вариант A: Каждый в команде отвечает за ответы на запросы в службу поддержки.

Вариант B: Один человек (по очереди) отвечает за запросы в службу поддержки.

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

Направление

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

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

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

Направление команды можно разделить на три части, как указано ниже.

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

Мне нравится думать о направлении как о походной метафоре, поэтому давайте воспользуемся «Властелином колец».

В видении Гэндальф говорил сообществу, что они собираются уничтожить единственное кольцо на Горе Рока. Это видение было ясным, измеримым и убедительным. За исключением всего остального, Фродо знал, какова его цель, хотя он и не «знал пути».

В дорожной карте Гэндальф потерпел неудачу как лидер. Хорошая дорожная карта включает в себя этапы, ведущие к реализации видения. Он должен включать альтернативные пути и варианты, которые команда может выбрать в зависимости от того, что принесет будущее. Возможно, если бы Гэндальф сделал это, Фродо не пошел бы по опасному и трудоемкому пути через логово Шелоб, а вместо этого просто улетел бы в Мордор с гигантскими орлами.

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

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

Заворачивать

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

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

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

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

Заинтересованы в других темах лидерства? Напишите мне через LinkedIn. Спасибо Keegan за редактирование.