Менеджмент. Действительно Ли Иерархия Имеет Значение Для Общения В Небольшой Команде Разработчиков Программного Обеспечения?

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

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

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

#менеджмент #иерархия

Я лично считаю, что пропуск уровней в такой маленькой команде не принесет никакого вреда.

Во-первых, 20 человек не маленький.

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

), почему они не закончили с XYZ, а не работают над его выполнением.

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

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

Еще одна проблема, с которой я столкнулся, — это когда менеджеры проектов пытаются давать инструкции. «Эй, почему бы тебе не поработать над ошибкой F?». Руководитель группы, вероятно, уже дал инженеру указания, над чем ему работать. Изменение этого правила означает, что инженер (и, как следствие, и вы сами) обречены на неудачу. Теперь инженеру необходимо решить, какому из двух приказов следовать. Некоторые попытаются сделать и то, и другое, что приведет к неудаче. Некоторые просто закроются и не сделают ни того, ни другого, что приведет к провалу. Некоторые будут следовать за лидером команды, вредя отношениям с вами. Некоторые последуют за вами, навредив отношениям с руководителем команды и, возможно, разрушив хорошо скоординированный план. А некоторые просто созовут собрание, чтобы вы и лидер могли сражаться насмерть (или иным образом разрешить ваши разногласия). Так что нет, я не думаю, что в большинстве сред менеджерам проектов полезно обходить руководителей групп, но это не вопрос иерархии. Это скорее вопрос координации. Если вы оставите руководителя группы вне процесса, он не сможет выполнять свою работу, а отдельные инженеры не смогут сосредоточиться на выполнении задач. их

участие в техническом уровне детализации, которое есть у руководителя и разработчиков.

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

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

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

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

• ^{Они также объяснили, что такое прыгая по уровням предполагается только для общения - то есть, если ты начальник, ты все равно не указывай подчиненному своего подчиненного, что делать. Вместо этого вы просто учитесь тому, как более эффективно управлять своими «прямыми подчиненными», которые, в свою очередь, передают их дальше по управленческой лестнице.}

Интересный, хотя, может быть, и несколько крайний пример такого подхода был изложен в интервью Эрик Шмидт к Гарвардский бизнес-обзор о его предприятие в качестве генерального директора Novell:

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

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

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

_{Большая часть вышеперечисленного была «извлечена» из этот ответ где он был опубликован как слабо связанное дополнение.}

У меня есть команда из 20 человек, поэтому я могу обсуждать только с тремя

их ведет. Я лично считаю, что пропуск уровней в таком маленьком

Команда из 20 человек совсем не маленькая. Небольшая команда, наверное, 5 человек. Скорее всего 3 человека. Но команда из 20 человек требует управления и структуры.

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

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

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

Нанесет ли это вред вам и другим членам вашей компании? Вероятно. Если они настаивают на «цепочке подчинения», то они, скорее всего, прямо или косвенно накажут тех, кто этого не делает. Я работал в крупной химической компании, в которой была очень «командная цепочка», и с тех пор я строго избегал подобных сред. Это не имеет ничего общего с размером - я работал на более крупных предприятиях, где вы можете поговорить с людьми, у менеджеров либо нет офисов и они сидят с персоналом, либо действует политика открытых дверей и т. д., и я видел 100 человек ходит по магазинам, где менеджер "ревностно охраняет своих людей" (конечно, на стартапе 10 это сделать сложно).

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

Конечно, если это дублирование усилий («Я хочу статуса, но должен был прийти на стендап»), то вместо этого им скажут прийти на это. И они в любом случае склонны разговаривать с лидами, поскольку лиды обычно имеют более полное представление о том, что происходит, и будут искать отдельных разработчиков только тогда, когда знают, что этот человек конкретно глубоко погружен в то, что их беспокоит. .

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