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

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

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

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

Оправданы ли эти опасения? Как я могу уменьшить разочарование, которое потенциально могут испытывать некоторые члены моей команды?

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

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

@snowlockk У одного из них должна была быть работа (это был первоначальный план). Другой, которого я знаю, говорил о надежде на роль в кулере с водой. Они не знают, что это было назначено мне.
Что касается «моих технических навыков в лучшем случае не хватает», разве это не определение менеджера? Серьезно, выполняйте свои управленческие задачи хорошо.
@jamesqf Лучше перефразировать это так: «моей уверенности в своих технических навыках в лучшем случае не хватает»
@ USER_8675309 - это не сильно меняет смысл. Большинством технических специалистов управляют нетехнические люди. То, что вы начинали на технической должности, не означает, что вас не будут уважать как менеджера. В самом деле, единственный способ потерять уважение — это щеголять своими «техническими знаниями» и ошибаться. AKA «Мы должны сделать это так», когда вы лично верите в это только из-за отсутствия у вас технических навыков. Если вы не знаете, просто доверьтесь тому, кто знает. Это не только нормально, но и является хорошей практикой.
несколько связано: принцип Дилберта
Кто может, тот делает . Кто не может, тот ведет .
Так почему вы выставили счет на 150%?
Ты лидер, а не командир. Вы здесь не для того, чтобы решать технические вопросы и рассказывать людям, как выполнять их работу — ваши собственные технические знания могут быть как помехой, так и полезной. Просто делайте свою работу и не пользуйтесь своим авторитетом, чтобы выставлять напоказ свои технические навыки (которых вам, по общему признанию, не хватает). В самом деле, сам факт того, что альтернативный лидер был значительно лучше вас в технической роли, вероятно, способствовал тому, что вас выбрали в качестве лидера — нет смысла тратить отличного технического сотрудника на роль менеджера, если только он не является также и лучшим менеджером.
Дайте им то, что им нужно для эффективного выполнения работы, и напомните им, что вы доверяете их мнению.
Думаете, армейского снайпера волнует, что командир его роты не может стрелять так же хорошо, как он? Или танкиста волнует, что генерал не умеет управлять танком так же хорошо, как он? Нет. Им нужны лидеры, которые умеют быть лидерами. Сделай это. Прочитайте несколько книг по лидерству и преуспейте в этом.
@jamesqf В техническом мире гораздо чаще менеджерам не хватает управленческих навыков, поскольку их часто поспешно продвигают из рядов разработчиков без какой-либо подготовки.
@Laconic Droid: Верно, вот почему (если вам повезет) секретарь отдела завершает работу :-)
Чтобы избежать путаницы, вы можете разделить свою роль между ролью «супервайзера» (т. е. «босса») и «руководителя группы» (т. е. старшего члена команды, который предлагает руководство и руководство для других членов команды). ). Нередко один человек занимает обе роли, но большинство ИТ-специалистов легко понимают разницу между обязанностями, связанными с каждой из них.
Будь лучшим мясным щитом, которым ты можешь быть.
"Все они были бы хорошим выбором для руководящей должности, которую я занимаю" - но ни один из них не был выбран - вы были.
У меня есть привычка всегда нанимать людей умнее меня. Без шуток.
Руководитель технического проекта должен быть лучшим в задействованных технологиях. Напротив, руководитель проекта не обязательно должен обладать высокой квалификацией в проектных технологиях, но должен обладать навыками управления. Навыки «лидерство» должны быть частью обоих, но эти две позиции не имеют одинакового описания. Административные задачи (по определению) больше относятся к роли менеджера проекта. Не так важно, какой ярлык соответствует реальной роли, важно, чтобы внутри команды было очень ясно, какова ваша роль.

Ответы (12)

Как разработчик я ненавижу следующие вещи:

  1. Запрос программного обеспечения / ресурсов занимает вечность и требует множества форм и т. д.
  2. Глупые требования, которые противоречат другим функциям или технически невозможны из-за существующей функциональности.
  3. Устанавливаются необоснованные и произвольные/взятые из воздуха сроки.
  4. Не зная приоритета моей работы.

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

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

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

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

Да, выступите в роли экспедитора, и ваша команда полюбит вас. +1
+1 от меня тоже. Мой любимый начальник вообще ничего не знал о написании кода, но он был моим защитником. Я знал, что он всегда поддерживает меня и будет буфером между мной и клиентом или руководством. Я бы не променял это ни на какое техническое совершенство.
+1 Решение таких проблем является частью ответственности, например, Скрам-мастера, который выполняет роль лидера-слуги. Дело не в том, чтобы обладать лучшими техническими навыками и опытом, а в том, чтобы убрать препятствия с пути, чтобы действительно хорошие разработчики могли эффективно выполнять свою работу. Сделайте это для них, и вы будете иметь их уважение.
Бонусные баллы: иногда может быть контрпродуктивно, когда лучший разработчик выполняет «задачи управления» — они тратят время на управление, которое они могли бы использовать для написания большего/лучшего кода. В идеале вы хотите, чтобы «менеджер» был наименее хорошим разработчиком, который может эффективно управлять.
+1, Забавно, что всегда дело не в том, кто вы, а в том, что лучше всего вы можете сделать в ситуации, с которой столкнулись. Мы поглощены мыслями о том, кто мы есть, вместо того, чтобы противостоять ситуации с тем, что мы можем дать.
«Вас выбирают для выполнения «управленческих задач» не потому, что вы лучший разработчик». +1. Набор навыков хорошего менеджера отличается от хорошего разработчика. Будь хорошим менеджером, и им будет наплевать на твои технические навыки.
+1 за приоритеты и сроки. Поскольку мне нужно было объяснять больше раз, чем следовало бы, если все имеет «немедленный» приоритет, то весь список приоритетов может пойти насмарку. Я ожидаю, что мой менеджер будет знать достаточно, чтобы установить приоритеты и изменить их. Кроме того, если мой руководитель спросит меня, сколько времени займет задача X? А я отвечаю: «Если мне разрешат только это, то через 5 дней», то я ожидаю, что срок будет установлен не раньше, чем через 5 дней, а остальные задачи перенесены. Кроме того, как ОП-разработчик, вероятно, знает, что выполнение 2 задач друг за другом намного быстрее, чем постоянное переключение...
5. Не делайте глупостей, например, не давайте разработчикам доступ администратора к их собственным машинам. (Это почти подпадает под № 1, но не совсем.)
Боже мой номер 3...
5 (6?) . Не проверяйте людей, не входящих в вашу команду (менеджеров проектов, специалистов по маркетингу, продажам и т. д.), когда они приходят с жалобами, добавляют проекты, изменяют спецификации и т. д. проделанная работа заслужила мое восхищение и уважение.
Единственное, что я хотел бы добавить, это то, что иногда лучший менеджер — это тот, который наиболее эффективно переводит между разработчиками и клиентами. Лучшие программисты часто с трудом объясняют вещи так, чтобы их могли понять люди, не являющиеся разработчиками.

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

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

Вам даже не нужно быть компетентным, пока вы слушаете компетентных разработчиков и не утверждаете, что знаете лучше.
Да, +1 за сохранение щедрой дозы смирения
@ gnasher729 Здесь выгодно быть немного компетентным. Это позволяет вам отсеивать BS и принимать более разумные решения, которые более позитивно влияют на вашу команду. Простое слушание того, кто, кажется, знает, о чем говорит, но не может разумно фильтровать эту информацию, приведет к принятию неверных решений. Например, все разработчики, которые усердно работают над новейшими популярными/шумными технологиями, но на самом деле не задумываются о том, действительно ли они практичны в использовании и являются ли технология лучшей для этой задачи. Если вы ничего не знаете, вы совершите эту ошибку, а потом пожалеете.
@ gnasher729, полная некомпетентность будет проблемой. Разработчиков будет очень сложно понять. Это приводит (по крайней мере, из того, что я видел) технически некомпетентных менеджеров к чрезмерному планированию и чрезмерной документации. «Я этого не понимаю, но, по крайней мере, у меня это записано» — заблуждение. И это при условии, что у разработчиков самые лучшие намерения; они не могут, они могут считать менеджера некомпетентным и пытаться их оболгать.
@SnakeDoc + Akavail: ОП работает с людьми, у которых «намного больше талантов», чем у него, как с разработчиками. Ему компетенция нужна не как разработчику, а как менеджеру. Хороший менеджер обнаружит чушь, не будучи компетентным в разработке. И компетентные разработчики сделают все, чтобы поддержать кого-то, кто компетентен в качестве менеджера, который удерживает все то, что разработчики ненавидят.

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

Директор приходит и спрашивает время X коллеги, когда этот коллега уже на 100% занят другим проектом? Будьте рядом, чтобы поговорить с директором, объяснить приоритеты и не мешать коллеге.

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

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

Мой вам совет: не продавайте себя дешево.

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

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

Что касается «облегчения разочарования», не бойтесь признать, что у некоторых из них больше знаний, чем у вас, и всегда отдавайте должное. Если есть проблема, и [X] решает ее, похвалите его и признайте руководству/клиенту, что [X] спас положение. Однако не терпите никаких вызовов вашему лидерству. Конечно, вы не лучший разработчик, но вы лидер, и это не подлежит обсуждению.

Я согласен с этим, однако я думаю, что в нем отсутствуют некоторые вещи, которых следует избегать ОП. Лично, когда у меня есть кто-то выше меня, у которого есть какие-то фоновые технологии, но ему явно не хватает, мне очень не нравится, когда он пытается обойти некоторые вещи, которые я утверждаю (например, оценку), говоря вещи, которые либо неверны, либо недостаточно точны. Лучший менеджер проектов, который у меня когда-либо был, был на 100% не техническим специалистом. Он попросил нас дать оценку, он не стал ее обсуждать. TL; DR не пытайтесь выполнять какую-то техническую работу в качестве менеджера, позвольте нам заняться этим, доверьтесь нам и сосредоточьтесь на вашем лидерстве и управлении.
@walfrat - я никогда не предлагал ОП игнорировать технические советы. Мой собственный менеджер — бывший разработчик-самоучка, который потерял связь с технологиями, чтобы перейти на полный рабочий день. Он просит разъяснений, но поддержит мои решения, когда поймет, что не в себе. Однако, когда он принимает решение, я следую его примеру. Я могу возразить наедине, что это плохое решение, но он все равно босс.
+1 за первые две строки. Если у вас нет уверенности в себе, то и у других не будет. Это не означает, что вы должны игнорировать навыки своих разработчиков, но никогда не подразумевайте, что вы считаете себя неподходящим для этой работы или что они справятся с ней лучше.
Я не говорил, что ты предложил это. Я хотел сказать, что вы говорите то, что должен делать ОП, но я думаю, что в нем отсутствуют некоторые предложения о том, что ОП не должен делать в отношении типа профиля, которым он должен управлять.
Хороший совет. Было бы полезно также включить некоторую информацию о том, что вы считаете «вызовом вашему лидерству», о котором вы упомянули, и как решить его, не сжигая дом. Есть поговорка: «Если вам нужно сказать, что вы лидер, совершенно очевидно, что это не так».

Как вы думаете, футбольный тренер лучше бросает, чем звездный защитник?

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

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

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

Например, если кто-то умнее вас по «Теме X», то советуйтесь с ним по «Теме X» при принятии решения. Это показывает несколько вещей: (1) вы признаете их талант, (2) вы уважаете их талант, (3) вы хотите, чтобы команда была успешной, а не вы.

Пусть они ведут вас технически, а вы ведете их профессионально.

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

Вы понимаете, что не все знают, кто такие Билл Беличик и Том Брэди. Спортивные аналогии редко бывают полезными.
@adelphus Сам ответ делает очевидным, что Том Брэди - квотербек. Моей первой догадкой было то, что Билл Беличик — тренер, и двухсекундный поиск в Google подтвердил это. Если вас это беспокоит, превратите имена в ссылки на Википедию или что-то в этом роде.

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

Но вам платят не за то, что вы пишете код, вам платят за то, чтобы вы управляли написанием кода другими людьми. Итак... может быть, это поможет: думайте о себе не как о «лидере» в смысле капитана команды, а как о вспомогательном персонале для них. Будьте той ширмой между высшим руководством и вашими ребятами: если у кого-то наверху есть проблемы с работой вашей команды или если им нужно выполнить определенную работу за Х времени, убедитесь, что вы , а не один из разработчиков, получаете это. info (а затем зарегистрируйте проблему и определите ее приоритет). Если у вас нет степени бакалавра, действуйте как один. Говоря как разработчик, если мне придется поговорить с не-разработчиками, я это сделаю, но я знаю, что очень, очень ценю, когда кто-то стоит между мной и толпой.

Еще одна вещь, которая, как мне кажется, действительно работает и которую многие разработчики не обязательно делают самостоятельно, — это много-много общения. Вы работаете в Agile/Scrum? Если нет, я бы сильно задумался. Даже если вы делаете чистый Waterfall, потому что ваша компания диктует вам это, нет никаких причин не добавлять некоторые аспекты Agile/Scrum, такие как ежедневная стоянка или оценка рабочей нагрузки по «спринту» в баллах. Если кто-то борется с задачей, пригласите более старшего разработчика, чтобы поговорить с ним о том, как справиться с этим, и постарайтесь воспитать отношение «мы добьемся успеха и потерпим неудачу как команда», чтобы люди, которые могут отстать, могли понять с помощью тех, кто впереди.

Наконец, вы отвечаете за системы, такие вещи, как кодовая база, процесс регистрации, тестирование и т. д. Как программист с СДВГ, я. временами очень, очень неорганизованный, и b. Я далеко, далеко, далеко не единственный человек, работающий в этой профессии, с таким заболеванием. Я лично получаю большую пользу от наличия команды управления/поддержки, желающей и способной обеспечить структуру. Чем меньше мне приходится думать об этом, тем больше я могу сосредоточиться на написании кода — о, смотрите! Птица!

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

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

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

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

У меня к тебе вопрос. Почему ты получил эту работу, а не других парней? Что оправдывает ваше время, которое оплачивается на 150% по сравнению с другими людьми? Если вы не знаете ответов, вам нужно разобраться.

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

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

@antipattern Мне нужно кое-что узнать из того, что вы спрашиваете. Я вижу пиявок в менеджменте, но как программист может быть пиявкой?
Возможно, пиявка — неудачная формулировка. Я имел в виду того парня, который работает очень быстро и всегда «заканчивает» вовремя. Если менеджер не способен оценить качество работы, возможно, этот парень просто работал над основным кодом и оставил там массу ошибок/необработанных мелких случаев. Частью работы менеджеров является обеспечение не только реализации , но и того, что эта реализация работает так, как рекламируется . Это прояснило для вас?

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

Подруга рассказала мне о чем-то подобном, произошедшем в ее компании. Разработчики были счастливы, что кто-то взял на себя административную работу, которую они презирали. Они видели в человеке не начальника, а коллегу, который отвечал за проведение схватки и составление отчетов в Power Point для руководства и т. д., и в их отношениях ничего не изменилось. Пока каким-то образом не просочилась информация о деньгах, и вдруг появилось много обиды на человека, занимающего должность «менеджера».

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

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

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

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

Поскольку большинство ответов довольно длинные, я хотел бы добавить простой.

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

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

Я бы сказал, расслабься.

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

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

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

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

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

Как возглавить группу разработчиков, у которых гораздо больше таланта, чем у вас
СпросиСетьПолитика конфиденциальности1y, 0v