Какие черты общего у лучших менеджеров, с которыми вы работали? [закрыто]

Я слушал подкаст Скотта Хансельмана и Роба Конери «Жизнь этого разработчика» .

В последнем эпизоде ​​они обсуждают черты личности:

1.0.4 - Быть Злым.

Что заставляет людей значить в нашей отрасли? Как насчет агрессивного? Уверенный? Какая разница? Вы бы предпочли сержанта для босса или мастера дзен? Разговариваем с Сирой Ричардсон и Джайлсом Боукеттом.

Это заставило меня задуматься, какие черты были у лучших менеджеров, на которых вы работали?

РЕДАКТИРОВАТЬ: Просто чтобы уточнить, так как было несколько близких голосов, меня интересует, есть ли черты, общие для менеджеров разработчиков, которые не обязательно те черты, которые требуются менеджеру какой-то другой профессии.

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

По моему опыту, это было сочетание следующего:

1. Измеряет по результатам / выходу, а не по входу.
2. Мотивирующий, вдохновляющий лидер, которого вы можете уважать и уважать.
3. Чувствителен к потребностям членов команды - поддержка / обучение / карьера и т. Д.
4. Быстро разрешает конфликт, рассеивает сложные ситуации.
5. Понимает вашу работу - они могут действительно выполнять вашу работу, но наняли вас для этого.
6. Обрабатывает / фильтрует то, что не важно или ухудшает производительность команды.

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

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

Период.

Желание слушать людей, которые работают на них.

У меня были очень технически склонные менеджеры, и у меня были некоторые, кто даже не знал о многозадачности («Ух ты! Где ты научился этому трюку Alt-Tab?»), Но дело в том, что все Мне действительно нравилось работать, потому что у них общего было то, что они знали, что они не знают всего, и были готовы выслушать, когда те из нас, кто фактически выполняет работу, которой они должны были управлять, представляли идеи, проблемы или предложения об этой работе.

Он / он защищает свою команду и принимает на себя ответственность

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

Они управляют на основе целей, а не времени, и в первую очередь заинтересованы в достижении этих целей

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

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

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

Признание того, что меня нанимают и платят за принятие решений.

Они поддерживают тебя, когда ты говоришь НЕТ

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

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

Тот, кто просто позволяет мне делать свою работу.

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

Признание того, что меня нанимают и платят за принятие решений.

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

(Глубокий) Умение сочувствия .

Я должен пойти на это с точки зрения худших боссов, на которых я работал - у хорошего НЕ было бы этих качеств:

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

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

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

Нанеси удар своим людям. Он получает кредит, мы получаем вину. AND не поддерживает нас в цепочке команд, когда он должен.

Не разбирается в процессе разработки программного обеспечения и даже не хочет учиться достаточно, чтобы знать, что мы используем C # (или другой язык по вашему выбору). Считает, что все может быть сделано за короткий промежуток времени, и что простое изменение снаружи страницы User_interface означает, что это не займет много времени для реализации. Тот человек, который сидит на перемене до дня, предшествующего крайнему сроку, а затем говорит: «О, кстати, нам нужно сделать ...», и все, что он просит, - это то, что меняет фундаментальную архитектуру.

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

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

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

Кредит, когда кредит должен и достаточно знаний, чтобы иметь возможность назначить его

Я бы добавил, что слушает хорошо, но вместо этого проголосовал.

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

Они доверяют своим людям выполнять свою работу и не пытаются «пасти кошек».

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

Тот, кто хорошо слушает

а также

Кто-то, кто действительно хочет говорить со мной, по крайней мере, еженедельно

У меня были хорошие менеджеры и плохие. Вот некоторые черты, которые я заметил у плохих менеджеров:

Убирайся с дороги, чтобы ты мог выполнять свою работу

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

Микро управляет неправильными деталями

Менеджер такого типа не сможет прикрепить подпись к вашему письму, игнорируя при этом дополнительную работу, проделанную вами до этого письма.

Не заинтересован в процессе разработки

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

Думает, что он там для меня, чтобы сообщить

Такого рода менеджер получает от людей все, что ему сообщают.

Неправильно распределяет время

В течение месяца, отведенного на разработку проекта от начала до конца, этот менеджер будет выделять 3/4 месяца команде по проектированию и разработке требований, чтобы сгенерировать 1000 документов в слово и ожидать, что команда разработчиков выполнит все это за неделю. Он также будет повторять требования до тех пор, пока они не станут «идеальными», добавляя большое количество деталей, пока документ не станет непригодным для использования. Но потом, в процессе разработки, вы обнаружите ошибки в документации по проектированию и требованиям и поймете, что попытка написать идеальный документ была ошибкой.

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

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

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

Борется за меня. Я не должен был заниматься этим с ИТ. Дает мне инструменты, которые мне нужны. Сообщает политику компании вниз. Принимает решения, когда об этом просят, и остается, когда нет.

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

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

Две вещи:

1) Является (или совсем недавно) разработчиком сам.
2) Управляет как вверх, так и вниз .

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

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

Короче говоря, наличие черты (1) дает вам менеджера, который понимает, что вам нужно для выполнения своей работы, а наличие черты (2) дает вам менеджера, который обеспечит то, что вам нужно.

« Разговор Джоэла Спольски в Йельском университете» (и соответствующая статья « Командуй и властвуй и стадо кокосовых орехов ») очень лаконичен:

Говоря о (плохом) управлении в Юноне:

«Предполагалось, что менеджеры существуют, чтобы говорить людям, что делать».

Говоря о (в целом хорошем) управлении в Microsoft:

«Менеджеры существуют, чтобы убрать мебель с пути, чтобы настоящий талант мог сделать блестящую работу».

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

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

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

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

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

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

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

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

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

Я работал в нескольких местах, где управление было явно нетехническим. У моего нынешнего работодателя есть политика, согласно которой менеджер, принимающий техническое решение, является основанием для увольнения. (Это не какая-то маленькая компания, о которой вы никогда не слышали, примерно треть из вас использует наш продукт). Отчасти в результате этой политики, по крайней мере, на мой взгляд, менеджеры здесь намного «сильнее», чем у других работодателей. Поскольку они не участвуют в принятии технических решений, руководство не принимает постоянную последовательность «слегка или очень неправильных» технических решений, и они принимают только крупные решения «на уровне продуктов».

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

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