Как узнать, когда вашему стартапу нужны инженеры-менеджеры
Понять, как развиваются стартапы, зачем нужны менеджеры и как понять, нужно ли вам нанимать технического менеджера.
Большинство технических руководителей, которые работали на начальной стадии стартапа, сталкивались с этим вопросом: «Нужен ли мне технический менеджер?»
Это трудное решение. Большинство стартапов на ранних стадиях не имеют денег. Каждый доллар, который они тратят на «дорогого» менеджера, - это на один доллар меньше, которое они могут потратить на непосредственного участника кодовой базы.
Более того, наем неправильного менеджера может нанести невероятный ущерб культуре и организации. Техническим лидерам, впервые занимающим руководящие должности, приходится вдвойне плохо - им также приходится бороться с тем фактом, что они никогда раньше не нанимали менеджера, что увеличивает их вероятность нанять плохого менеджера.
Столкнувшись с такой неопределенностью, многие технологические лидеры стартапов откладывают решение, прибегая к тому, что они знают лучше всего: индивидуальному вкладу.
Иногда позже уже слишком поздно
Да, слишком ранний наем руководства может стать ненужной статьей расходов в компании с ограниченными деньгами. Однако есть и обратная сторона медали: слишком поздно нанятый персонал может дорого обойтись компании. Проблемы, связанные с культурой, технологиями и процессами, со временем усугубляются, и даже лучшие мировые менеджеры не могут исправить ущерб в мгновение ока. Время невероятно важно.
Как вы определяете, когда вам нужен уровень инженерного менеджмента?
Я собираюсь испортить финал пораньше - запись в блоге в Интернете не скажет вам, когда вашей компании нужны менеджеры.
Это весьма косвенное решение, которое могут принять только сотрудники компании. Лучшее, что может сделать онлайн-статья, - это вооружить вас знаниями - пониманием фундаментального «Почему?», стоящего за менеджерами, чтобы вы были лучше информированы, чтобы определить «Когда? ».
Понимание эволюции инженерной организации
Чтобы понять, зачем вообще нужен технический менеджер, важно понимать жизненный цикл инженерной организации в рамках стартапа, который может длиться годами.
Начала
Стартапы обычно начинают жизнь с одного-единственного разработчика или подрядчика. На данный момент это даже нельзя было назвать командой. Этот первоначальный разработчик либо подчиняется непосредственно основателю, либо сам является техническим учредителем.
Вывод продукта на рынок
По мере того, как компания продает свое видение и то, что они создали, им необходимо увеличить скорость разработки, чтобы создать все, что требует рынок. Они достигают точки, когда подрядчиков становится недостаточно или они становятся слишком дорогими.
Чтобы удовлетворить новые требования к команде разработчиков, стратегия найма смещается, и внимание начинает уделяться созданию внутренней команды. Стартап в конечном итоге достигнет точки, когда 6–8 инженеров в одной команде будут работать над одним и тем же продуктом.
В такой большой команде основатель больше не может напрямую управлять этими инженерами, если они вообще когда-либо были. Они слишком заняты заключением сделок, выяснением финансов, бизнес-планов и всего того, чем занимаются деловые люди, что инженеры часто принимают как должное.
Вместо этого ответственность за быстрое выполнение команды ложится на первоначального разработчика или самого старшего разработчика. Этот разработчик, приобретя обширный объем знаний в предметной области за несколько лет, стал де-факто главой инженерного отдела, отвечающим за всех других привлеченных инженеров.
Их титулы различаются в зависимости от компании - одни компании используют директора по разработке, другие - технического директора, третьи - ведущего инженера-программиста. Технически не так важны, как тот факт, что они являются техническим руководителем организации.
Бремя успеха
По мере того, как компания растет и набирает обороты на рынке, требования к технологиям возрастают. Межфункциональное сотрудничество становится все более и более ключевым компонентом работы. Работа с заинтересованными сторонами бизнеса, потенциальными клиентами, регулирующими органами - все это при одновременном поддержании команды разработчиков продукта - это много работы и много общения.
В какой-то момент главу инженерного отдела доходит, что их время больше не их время. Об этом свидетельствует простой взгляд на их календарь:
В какой-то момент их время перешло от кодирования 24/7 к 24/7 встречам. Трудно точно определить, когда это было, но, вероятно, именно тогда организационная диаграмма стала выглядеть так:
Чем больше людей, тем больше общение. Проекты становятся более сложными, с большим количеством движущихся частей. Потребности бизнеса растут по мере ускорения роста компании. Руководство желает, чтобы руководитель отдела разработки сосредоточился на самом важном. При таком большом количестве людей руководитель отдела разработки едва ли может сосредоточиться на чем-либо.
Привлечение старших талантов
Если в организации на данный момент нет старших инженеров, они часто привлекают их, мотивируя это тем, что старшим инженерам требуется меньше менеджмента и они могут помочь взять на себя некоторые из этих обязанностей.
Это по совпадению правильное объяснение. По мере того как эти старшие инженеры становятся надежными исполнителями, руководитель инженерного отдела может начать делегировать им ответственность за выполнение определенных проектов или потоков работы.
Разделение на команды
Во многих случаях руководитель отдела разработки неявно знает, когда они достигают своих пределов.
Они часто пытаются сэкономить больше собственного времени, синхронизируя только со старшим инженером, которому они поручили отвечать за проект или рабочий процесс, избегая необходимости синхронизации с каждым отдельным инженером, который является частью того же проекта.
В этом есть смысл - часть стимула для делегирования заключается в том, что руководитель инженерного отдела тратит меньше времени на определенные вещи, включая надзор за проектами и людьми, и эта деятельность сокращает количество каналов связи, которые необходимо синхронизировать руководителю инженерного отдела.
Хотя формальные подчинения не меняются, организационная структура инженерного отдела начинает неявно выглядеть, как показано ниже:
Формализация раскола
В конце концов, раскол оформляется. Как я писал в другом посте, существует множество способов разделить команды, с плюсами и минусами каждой структуры. Существуют также скрытые опасности того, что квалифицированные ИС внезапно перейдут на руководящие должности без надлежащей подготовки, и методы, с помощью которых можно справиться с недостатками.
В любом случае, конечный результат таков: есть разные команды и за них отвечают разные люди:
Вещи в рамках этой структуры становятся намного более управляемыми для руководителя отдела разработки, и организации могут пройти долгий путь с помощью этого подхода.
Почему это работает?
В этом сценарии задействованы некоторые основы организационных структур, которые нам необходимо понять.
По мере роста организации становится все труднее обеспечить синхронизацию всех. Это связано с тем, что требования к каналу связи экспоненциально масштабируются с размером организации.
Скажем, на ранних стадиях стартапа - когда всего три человека - этим трем людям легко разговаривать друг с другом. Есть только три пути общения для достижения общего сознания и согласования. Каждый может общаться со всеми.
Но если организация станет больше? Это другая история.
Что у нас здесь, так это неспособность общаться
По мере увеличения количества людей количество связей между ними резко возрастает. Стратегия синхронизации, которая раньше поддерживала синхронизацию 5 или 10 человек, внезапно перестает работать в 15. Проблема усугубляется по мере роста организации:
- 9 человек? 36 подключений.
- 15 человек? 105 подключений.
- 50 человек? 1225 подключений.
- 100 человек? 4950 подключений.
Невозможно поддерживать синхронизацию такого количества людей на одной и той же странице, используя стратегию, предполагающую прямое общение 1: 1.
Это большая причина, по которой существуют организационные структуры: создание потока коммуникации, которым можно эффективно управлять. Переход к модели, в которой коммуникация между отдельными людьми создает порядок.
Однако есть некоторые незначительные недостатки. Поскольку каждый отдельный член сейчас не имеет доступа к полному сознанию организации, она имеет тенденцию создавать разрозненные структуры. Эти разрозненные хранилища легко могут быть несовместимы с более крупной организацией.
Эти недостатки устраняются за счет сосредоточения внимания на эффективном согласовании, порождаемом - как вы уже догадались - эффективными управленческими действиями. Такая управленческая деятельность обеспечивает потоки информации туда, где она необходима, и отдельные разрозненные хранилища направляют свои усилия в направлении, которое согласуется с остальной частью организации.
Почему руководитель отдела разработки не может этого сделать?
Мне часто задают вопрос: почему руководитель отдела разработки не может просто управлять людьми?
Они могли бы, если бы у них был набор навыков (а у многих их нет), но это только отсрочивает неизбежное. У них слишком много других требований к своему времени, чтобы они могли эффективно выполнять все, что от них требуется в растущей организации.
Компании осознают это и в большинстве случаев разделяют обязанности руководителя отдела разработки.
Разделение ролей руководителя отдела разработки
На данный момент руководитель отдела разработки имеет (или не имеет) определенные навыки.
Если мы воспользуемся упрощенной 4-квадрантной моделью набора навыков технического директора, мы получим следующее:
- Управление персоналом
- Управление исполнением
- Кодирование и технологии
- Управление и стратегия
Немногие, если вообще есть, люди сильны во ВСЕХ этих областях. У большинства руководителей инженерного отдела есть одна или две из этих областей, в которых они преуспевают, и разные уровни производительности и интереса к другим.
Имея кого-то, кто преуспевает в тех областях, в которых руководитель отдела разработки приемлем только, организации могут гарантировать, что ключевые аспекты своей роли получат должное внимание. Это позволяет руководителю отдела разработки сосредоточиться на своих сильных сторонах, а организация в целом становится сильнее.
Иногда эту пилюлю сложно проглотить, и некоторые технические лидеры выступают против идеи отказаться от своего авторитета и власти. Они цепляются за все эти области независимо от своих навыков, ослабляя организацию в пользу своего эго.
Однако эффективные лидеры осознают важность использования своих сильных сторон и приветствуют способность сосредоточиться, которая приходит с разделением их ролей.
Где распределяются обязанности?
Это сильно зависит от контекста и действительно зависит от вовлеченных людей и организации.
Руководитель отдела разработки, отвечающий за управление людьми и исполнение, вероятно, захочет выполнять роль, близкую к повседневной, и передавать стратегию и управление новому техническому директору. В подобных случаях руководитель отдела проектирования становится вице-президентом по проектированию.
Руководитель отдела разработки, который хочет больше сосредоточиться на кодировании, технологиях и аспектах инфраструктуры, по сути, может взять на себя роль главного технолога. В подобных случаях они часто остаются техническим директором, ориентированным на IC, а управление исполнением переходит к новому вице-президенту по проектированию.
Возможно, руководитель инженерного отдела хочет быть более ориентированным на внешний мир / управление / стратегию. В этом случае они остаются директивным / стратегическим техническим директором, а управление исполнением переходит к вице-президенту по инжинирингу.
Организация должна работать со своим руководителем инженерного отдела, чтобы найти их сильные стороны и убедиться, что распределение ролей соответствует их интересам.
Что будет, если начальник отдела разработки вообще не готов?
Конечно, всегда есть последний вариант: у руководителя отдела разработки просто нет навыков, необходимых для перехода компании на следующий уровень.
Это может произойти по множеству причин.
Некоторые инженеры начинают свою карьеру в стартапе и развиваются вместе с ним. На ранних этапах, когда строительство является приоритетом, они могут эффективно выполнять свою роль, но на более поздних этапах требования к навыкам значительно отличаются, к которым они могут быть не готовы.
Некоторых просто не интересуют фактические обязанности, которые связаны с ролью, когда организация становится больше, и это было не совсем то, чего они ожидали.
Организационные требования меняются по мере того, как стартап переходит от этапа к этапу, и для разных этапов требуются разные навыки. Хотя многие так и поступают, не все приспосабливаются к этим изменениям и сохраняют свои навыки актуальными. Это не всегда интересно всем, и у людей могут быть предпочтения в отношении конкретных этапов запуска.
Решение здесь простое: либо они берут на себя более низкую роль в организации, более соответствующую их навыкам, чтобы они могли продолжать вносить максимальный вклад, либо они расходятся с компанией.
Менеджер менеджеров
Конечно, я полагаю, что вам повезло, и у вас есть фантастический технический руководитель.
Каким бы ни было разделение ролей, вице-президент по инжинирингу в конечном итоге берет на себя управление командами разработчиков, управляя менеджерами, которые управляют командами. Иногда они отчитываются перед техническим директором, иногда - перед генеральным директором.
Уровень управления установлен, и по мере роста команды он со временем расширяется, включая новых менеджеров. В более крупных организациях должность технического директора часто возвращается в ограниченной, неорганизационной сфере, управляя менеджерами, входящими в определенную рабочую группу или отдел.
Что вам нужно спросить себя?
Итак, теперь, когда мы изучили эволюцию этого гипотетического стартапа, мы подошли к настоящему вопросу: как узнать, когда пришло время получить уровень управления для ВАШЕГО стартапа?
По правде говоря, онлайн-статья в блоге не может вам сказать об этом. Это зависит от контекста. Однако, задав себе следующие вопросы, вы научитесь понимать, что именно нужно искать:
Ценит ли ваша организационная культура менеджмент?
Некоторые стартап-культуры очень сильно ориентированы на IC (индивидуальный вкладчик). Стартапы на ранней стадии выживают благодаря готовности их участников делать все, что нужно, носить как можно больше шляп, трудиться и торопиться, чтобы добиться цели.
В этих организациях представление о том, что кто-то сидит без дела и ничего не делает сам, является проклятием для идеи героического участника. Конечно, это ошибочное мнение, но я обнаружил, что оно превалирует во многих стартапах на ранних стадиях.
Если ваша организация не ценит менеджеров, это возлагает на них ожидания отдельного сотрудника и снижает признание управленческих аспектов роли, а это рецепт неудачи.
Что вы будете делать, если ваша культура не ценит менеджеров?
Если в вашей культуре менеджеры не ценятся, возможно, она:
- Были плохие примеры менеджеров
- На самом деле не знаю, в чем ценность менеджера
У менеджеров есть причина, и их действия могут внести значительный вклад даже в культуру, ориентированную на исполнение: координация, перекачка информации, согласование - все это действия, которые уменьшают трение при исполнении во всей команде.
Менеджеры также могут обеспечить навыки и карьерный рост, уделяя особое внимание обучению и росту. Это помогает в исполнении, а также удержании сотрудников.
Наконец, менеджеры могут помочь обеспечить эмпиризм и улучшить процессы в долгосрочной перспективе за счет сбора показателей и действий по оптимизации на их основе. Сосредоточение внимания на улучшении может помочь устранить неэффективность и неэффективное поведение - вещи, на которых сложно сосредоточиться, если вы также заняты попытками внести свое участие в следующий проект.
Управленческая деятельность (выполненная хорошо) действует как множитель силы, что приводит к ужасному деловому слову синергия, когда сумма частей вместе становится больше, чем то, чем они могли бы быть по отдельности.
Наконец, помните: Google однажды попытался избавиться от всех своих менеджеров. Все прошло очень плохо.
Ваш руководитель инженерного отдела перегружен?
Термин "перегружен" может быть перегруженным, поэтому давайте уточним, что он означает.
Ваш руководитель отдела разработки…
- … Тратить больше времени на то, что им не нравится, чем на то, что им нравится и в чем они преуспевают?
- ... кажется, весь день на собраниях, и им нужно написать огромное количество кода?
- … Казаться напряженным, взволнованным, демотивированным, истощенным, подавленным, безнадежным?
- … Продолжайте просить бюджет для найма старших инженеров в надежде, что они освободят время?
Если ответ «да», вам следует изучить это подробнее.
Часто ли проекты не достигают целевых показателей выпуска?
Проекты, которые постоянно откладываются, указывают на некоторую форму процесса, качества или проблемы с людьми. Тот факт, что они случаются часто, означает, что чего-то не хватает, будь то лучшая координация, ясность целей или время для учета технического долга.
Менеджеры могут глубоко погрузиться в эти проблемы и помочь в реализации проектов.
У вас много ошибок?
Вот секрет: в хорошо спроектированных проектах ошибки должны появляться МЕНЬШЕ со временем, не чаще. Если ошибки возникают все чаще и чаще, это может указывать на серьезные проблемы с качеством, вызванные техническим долгом, нереалистичными сроками, отсутствием навыков или стремлением к снижению стандартов качества.
Легко отклонить увеличивающееся количество ошибок, поскольку «проект становится более сложным» или «мы движемся быстро и ломаем вещи», но суть в том, что если у вас есть возможность «двигаться быстро и ничего не ломать» , то «двигаться быстро и ломать вещи» безответственно.
Чувствуют ли инженеры рассинхронизацию, недостаток ясности или несогласованность?
Одно из ключевых направлений деятельности по управлению и лидерству - внести ясность в команду. Хорошие менеджеры могут действовать как информационные насосы, обеспечивая людей информацией, необходимой им для принятия эффективных решений, соответствующих целям компании. Они действуют как генераторы выравнивания, которые удерживают всех в команде в одном направлении.
Если ваша команда не понимает, что происходит, или не понимает целей или текущей ситуации, это признак того, что они не получают нужной информации.
Это могут помочь опросы сотрудников, а также инструменты 1: 1 и другие инструменты.
Инженеры жалуются на отсутствие навыков или карьерного роста?
Хороший менеджер может творить чудеса с карьерным ростом инженера.
У них есть время, чтобы предоставить инженеру ресурсы, направление, наставничество, обучение и возможности для роста и совершенствования инженера. Они могут работать 1: 1 с инженером, чтобы разработать индивидуальный план роста, который поможет им гораздо быстрее, чем они сами.
Это мощный инструмент удержания и повышения квалификации в долгосрочной перспективе. Однако это требует сосредоточения и внимания, и часто это первое, что упускается из виду, когда сроки начинают срываться.
Без специального уровня управления, чтобы удовлетворить эту потребность, зачастую бывает нелегко.
Вы не имеете представления о технических характеристиках или тенденциях?
Agile-аисты часто осуждают использование метрик для измерения производительности команды разработчиков, вместо этого предпочитая указывать на «работающее программное обеспечение» как на главный показатель прогресса и успеха.
В эпоху, когда каждый и его собака могут создавать рабочие программы, действительно ли это хороший стандарт для использования?
Хотя я согласен с тем, что такие метрики, как Story Points и Velocity, использовались неверно информированными руководителями бизнеса, правильное использование метрик может быть мощным сигналом, указывающим на проблемы процесса или рост возможностей инженера с течением времени.
Такие показатели, как время цикла, частота сбоев при изменении, частота развертывания, могут помочь понять, становится ли ваша команда лучше или хуже в долгосрочной перспективе, и вы можете нацелить улучшения, чтобы сосредоточиться на областях, которые от них выиграют больше всего.
Чувствуют ли инженеры себя бессильными?
Вы можете сказать, когда входите в команду уполномоченных инженеров. С того момента, как вы начинаете работать с ними, вы чувствуете этот шум работы и это желание преуспеть и улучшить все.
Вы также можете сказать, что находитесь в бесправной команде инженеров. Они не общаются. Они не проявляют инициативу. Они делают только то, что им говорят - ни больше, ни меньше. Им не нравится работа.
Эффективное инженерное управление может оживить команду и помочь вдохновить и расширить возможности. Я видел десятикратное повышение эффективности разработки в командах, которые были переданы эффективному руководителю после того, как томились под руководством плохого менеджера или вообще не работали.
Найм менеджера - непростое решение, но оно имеет решающее значение для стартапа. По мере того, как стартапы растут и развиваются, бремя сотрудничества становится слишком большим, чтобы его не мог нести только руководитель отдела разработки.
Эффективный уровень управления часто становится необходимостью для обеспечения того, чтобы организация продолжала добиваться успеха и выходила на новый уровень.
Джозеф Гефро - технический руководитель из Сиэтла, штат Вашингтон. В его прошлом опыт работы старшим техническим директором в Snap! Рейз и технический директор компании Jumpsuit Commerce.
