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

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

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

И вот, хотя он мог немного помочь, я услышал во время перерыва на кофе от более младшего коллеги, что он думал, что «я был лучше этого; если я попрошу о помощи, это не покажет большого мастерства». По сути, моя просьба о помощи была воспринята этим младшим как проявление слабости.

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

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

Как бы вы попросили о помощи в сложившейся ситуации, не теряя доверия?

«моя просьба о помощи была воспринята этим младшим как проявление слабости». Он младший и все еще достаточно наивен, чтобы думать, что те, кто выше его, должны иметь все знания всех, кто ниже их. Его заявление больше говорит о нем, чем о вас.
Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Почему вы используете термин "младший" вместо "дебил"? Не должно ли это быть "расценено дебилом как проявление слабости"? Серьезно, большинство коллег просто подумали, что придурок действительно поверхностный парень, если он думает о том, что сказал им. Вы тоже должны игнорировать это поведение, пока он не вырастет :)
Различие между слабостью и уязвимостью может привести к некоторым свежим взглядам. Это напомнило мне об этом выступлении на TED ted.com/talks/brene_brown_on_vulnerability , хотя и не имеющем отношения к ИТ и организациям .
Такое конкурентное место не было бы чем-то, что я хотел бы испытать на работе.
@SteveSmith Хотя я согласен, я считаю это чрезмерно милосердным по отношению к младшему разработчику. Вера в то, что у старейшины должны быть все ответы на любую заданную тему, должна быть тем, от чего большинству взрослых следует отказаться до окончания средней школы. Это свидетельствует об отсутствии зрелости, и если это по-прежнему влияет на рабочие отношения в команде, с этим следует бороться.
Нужно обратиться за помощью на Stack Exchange? Стыдно! ;)
Чтобы прояснить этот вопрос, вы спрашиваете о темах, которые человек в вашем положении, как правило, должен понимать?
Каждый раз, когда вы просите о помощи, вы чему-то учитесь, а это значит, что это сделает вас лучше в старших классах. Быть старшим не означает, что вы все знаете, это означает, что вы знаете, как опереться, как себя вести, а также, как/когда и к кому следует обращаться за помощью.
По его устному мнению совершенно очевидно, что этот "джуниор" на самом деле "новичок".
Как будто ты мог убить этого клоуна самостоятельно
Все хорошие ответы, полезные в этом, спасибо. Я должен упомянуть, что мне нравится младший, о котором я говорю. Наверное, мне нужно работать над тем, чтобы принимать критику. Кроме того, команда хорошая, некоторые просто играют в политику и «вы видели, какой я классный» до такой степени, что просьба о помощи подпитывает их позицию. Но это исключения, а не общее правило, к счастью.
Я придерживаюсь мнения, что руководитель группы не обязательно должен быть лучшим и наиболее технически подкованным членом команды. Если лучший разработчик продвигается вверх по иерархии, то у нас есть директор Питера, который утверждает, что чем выше разработчик поднимается по лестнице, тем более бесполезным он становится. Я работал во многих командах, где тимлид знает достаточно, чтобы руководить командой и выполнять все дополнительные задачи, требуемые от тимлида, в то время как это передается эксперту в команде, который на 100% сосредоточен на чистой разработке. Что-то, что какой-нибудь умный младший никогда не узнает...!
Задавать вопросы — это признак уверенности. Как старший разработчик, я не знаю, как делать много простых вещей. Мое эго не уязвлено вопросами, потому что незнание одной вещи не означает, что я не подхожу для своей работы. И чем больше я узнаю, тем больше я понимаю, как многого я не знаю. По моему опыту, люди, которые не задают вопросов, опасаются, что их невежество покажется. Опытные люди не стесняются говорить, когда чего-то не знают, потому что они уверены в том, что знают .
Я архитектор и постоянно обращаюсь за помощью ко всем кодерам. Они умные люди и могут иметь хорошие идеи. Почему бы мне не использовать эти IQ?
Почему бы вам не спросить в stackoverflow? Идеально подходит для обучения, когда никто не знает, что вы слабы (и все остальные тоже слабы).
Полуироничный мета-пост @Zibbobz
определение роли; «Младший»: Думайте, что они все знают, никогда не просите о помощи, так как они думают, что это показывает, что они не знают. «Старший»: Знайте, что они не знают всего, всегда обращайтесь за помощью, как только они чего-то не знают, потому что они достаточно опытны, чтобы знать, что именно так вы делитесь знаниями.
Все ответы были положительными и полезными; Я наткнулся на следующую ссылку, которая очень красноречиво описывает, что могут спровоцировать все эти безобидные реакции: medium.com/@jasmineyctsai/… ; но да, я думаю, что ответ заключается в уважении и зрелости с обеих сторон.

Ответы (10)

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

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

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

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

Лично я считаю обращение за помощью признаком зрелости .
Я заметил одну вещь в нашей маленькой компании, занимающейся ИТ / кодированием. Просить о помощи — это нормально... если вы прилагаете минимум усилий, чтобы попытаться решить проблему самостоятельно. Если что-то не работает/не компилируется и кто-то моментально перебегает к старшему разработчику... то мы не одобряем такое поведение. Но если вы погуглили проблему и / или это более широкий вопрос с подвохом по «архитектуре»? Тогда конечно, спрашивайте! Это почти как на StackOverflow!
Как сказал @Shaamaan, приложите некоторые усилия, чтобы понять это самостоятельно, а затем спросите. Хуже, чем «тратить часы или дни на выяснение чего-либо», я видел, как люди, которые боялись спросить, поступали неправильно , иногда с катастрофическими результатами. Таким образом, всегда лучше спросить, если вы не можете найти ответ самостоятельно; и никто не знает всех ответов.
но если это босс, а не младший разработчик, который создает плохие флюиды, у вас могут быть проблемы
Этот ответ, кажется, начинается с предположения, что критика младшего разработчика недействительна. Как было установлено это положение?
@Nat Если события описаны в OP (и я еще не видел ничего, что заставило бы меня в этом усомниться), то я считаю, что критика Джуниора недействительна по причинам, которые я изложил в своем ответе . Есть обстоятельства , при которых такая критика может быть обоснованной, и я также предупредил об одном таком обстоятельстве в ответе.
"Фред: Почему этот богатый человек экономит и экономит?" "Боб: Как ты думаешь, как он разбогател?"
Я нахожу ваше предложение о том, чтобы «признать тот факт, что я прошу о помощи, и отложить в сторону эго», как то, над чем мне нужно работать. Все дело в том, как мы справляемся с этим. Я работаю над этим точно. Спасибо за комментарий.
У меня есть яркий пример этого здесь, на моем рабочем месте, @Cantalope. Технически я «низкий человек на тотемном столбе» на этом рабочем месте, но у меня больше знаний о Linux, чем у остальной ИТ-команды вместе взятой. И хотя я все еще младший парень в команде (хотя я много лет работаю там неполный рабочий день), старшие ИТ-специалисты всегда просят меня помочь с Linux. Они просят меня о помощи; Я делаю то же самое. Это цикл зрелости и сотрудничества на рабочем месте, независимо от того, являетесь ли вы техническим директором или самым низшим разработчиком на лестнице, чтобы задавать вопросы своим коллегам, если вы чего-то не знаете.
... так что отбросьте эго и не бойтесь просить о помощи, даже будучи старшим айтишником. (Даже сисадмину иногда приходится просить о помощи, и он один из лучших людей в ИТ-команде, хех)
Я обнаружил, что в ИТ (и, возможно, во многих других областях) чем больше я узнаю, тем больше я понимаю, что не знаю!

Этот младший разработчик имеет ошибочное представление о том, что должен делать старший разработчик.

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

Ссылаться на опыт другого члена — это приобретаемый навык и часть менталитета «большой картины», которого явно нет у этого младшего, и поэтому вы старший, а он нет.

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

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

Как только это будет сделано, и вы на 100% уверены, что никто не обижается, признайте, что джуниор ДОЛЖЕН научиться этому, чтобы вырасти до старшего разработчика. Любой пожилой человек, который думает, что просить о помощи является «слабостью», естественным образом создаст очень токсичную среду.

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

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

Вдобавок к этому чрезвычайно распространен прием на работу младших сотрудников, обладающих очень специфическими знаниями (например, передовыми технологиями), которых не хватает старшим. Вот почему вы наняли их в первую очередь.
Я не старший, но я не согласен с тем, что он должен идти и спорить с младшим по этому поводу. особенно не в части "Я слышал, как ты говорил...". Небольшая болтовня во время перерыва на кофе должна оставаться таковой. Я бы, наверное, возвысился над обсуждением и проигнорировал бы его. Я бы перестал игнорировать это, если бы джуниор подошел ко мне и сказал мне это прямо. Тогда это было бы неуважением со стороны младшего, и он заслуживал бы выговора за это.
@user32882 user32882 Особенно в качестве старшего / лидера ОП несет определенную ответственность за культуру работы в команде и должен следить за тем, чтобы младший не распространял это странное отношение «никогда не просить о помощи» (например, другим младшим). Как пишет Нельсон: это может создать токсичную среду, а лидеры несут ответственность за среду, в которой приходится работать их команде.
В данном случае джуниор, вероятно, повлиял на другого джуниора, и теперь у нас есть два человека, которые не будут просить о помощи. Такое отношение очень разрушительно. Чтобы справиться с этим, требуются огромные навыки, и поэтому ОП является старшим. Он просит помощи.
Слишком часто люди часами бьются над проблемой, потому что не могут заставить себя попросить кого-то, кто может помочь им решить ее за 5 минут... и это сводится к нежеланию показывать слабость.
Я думаю, что очень важным моментом в разговоре об этом с младшим является объяснение ему, почему просить о помощи — это хорошо, он, похоже, этого не понимает.
Во многих темах я читал утверждения о том, что старших разработчиков нанимают за гораздо более высокую плату, потому что они являются экспертами; их работа лучше, быстрее и опытнее, так что, когда вам действительно нужно, чтобы работа была сделана хорошо, лучше выложить дополнительные деньги старшим разработчикам. Этот ответ, кажется, идет в совершенно другом направлении, утверждая, что старшие разработчики не обязательно более опытны, чем младшие, а скорее способны действовать в управленческой роли. Не могли бы вы уточнить эту позицию, особенно в отношении того, что следует ожидать от старших разработчиков?
@Nat, они не разбираются исключительно в технических знаниях. Знания старшего также заключаются в том, насколько успешны успешные проекты, а это требует гораздо большего, чем технические навыки. Этот ответ связан с ложным представлением о том, что старший разработчик является вершиной технических знаний. Он может быть, но он не поэтому старший.
@Nelson У меня сложилось впечатление, что квалификатор «Старший» должен был подчеркнуть отточенный опыт работы на должности, на которой сотрудник является старшим; и хотя быть старшим часто связано с некоторыми обязательствами по управлению младшими, старшие сотрудники по-прежнему в основном выполняют ту же работу, в отличие от менеджеров. Если бы мое впечатление было верным, то у Старшего были бы законные основания для беспокойства, если бы он постоянно проигрывал Младшему, в то время как Менеджер был бы свободен от таких опасений по причинам, которые вы описали выше. Отличается ли ваш опыт работы с должностями?
Будет трудно даже обсуждать сами названия, потому что они одновременно полны смысла и бессмысленны. Это не то, что действительно может поместиться в комментарии.
Я думаю, это зависит от того, насколько конкретна роль. Если компания работает с несколькими различными технологическими стеками, то старшему разработчику, безусловно, не обязательно быть техническим экспертом во всех из них. Однако, если, например, я работаю старшим разработчиком C#, и мне нужно обратиться за помощью к младшему разработчику C#, потому что мой код не компилируется, то я не думаю, что смогу действительно оправдать свою роль в этой роли. Старший разработчик отличается от обычного менеджера тем, что он должен быть очень технически подкован и, безусловно, должен знать больше о своей конкретной области, чем джуниор.

Слабость подрывает товарища по команде, который просит о помощи.

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

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

Если бы вы работали со мной или для меня, я был бы рад, что вы просите о помощи. Это ПОВЫШИЛО бы мое доверие к вам, потому что я знаю, что вы не станете тем, кто пойдет и сделает что-то наполовину, испортит все, а затем попытается обвинить кого-то еще.

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

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

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

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

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

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

Просить о помощи — это не слабость. Этот младший не знает, о чем говорит (наверное, поэтому он младший). Хороший старший техник знает то, что он знает, но, что более важно, он знает то, чего не знает.

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

"он знает то, чего он не знает" Это, так много этого. Самые компетентные люди — это те, кто осознает свои ограничения и стремится выйти за их пределы.

Я вижу это так: ваш младший коллега уже негативно смотрит на просьбу о помощи.

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

«Первый шаг к мудрости — это признать, что ты не знаешь». Или что-то подобное.
вот почему существует охота на бекасов ( en.wikipedia.org/wiki/Snipe_hunt ).
+1 за цитирование Сократа, и кто посмеет сказать, что Сократ был неправ? :-)

У вас проблема не в том направлении.

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

Если есть кто-то, кто работает с ними в определенной роли наставника, поговорите с этим наставником об этой проблеме.

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

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

Командная работа это все об этом, КОМАНДА !

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

Это не ситуация «моя больше твоей»; гораздо больше темы "каждый день - школьный день"!

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

Вот чем на самом деле занимаются лидеры (конечно, при создании кода для завершения проекта).

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

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

@MisterPerfect Мне не нравится, что вы изменили смысл моего поста: 1) «каждый сам за себя» имеет совершенно другое значение, чем «мой больше, чем твой» 2) «мой больше твоего» не является сексуальной отсылкой! «У меня больше, чем у тебя» намекает на бессмысленную конкуренцию, тогда как «каждый сам за себя» подразумевает эгоизм. Совершенно разные вещи.

TL;DR

  • если речь идет о продвижении по службе, подумайте о том, чтобы понаблюдать за собой, чтобы выяснить, оправдано ваше беспокойство или нет. Сравните с другими людьми, которые могут быть вашими соперниками в этой работе. (теперь с разделом EDIT после комментария @Cantalope)

  • если речь идет о репутации, взвесьте, просите ли вы других о помощи, и они просят вас, чтобы понять, стоит ли вам беспокоиться

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

  • если речь идет именно об этом младшем, посмотрите другие ответы, я полностью их поддерживаю. Особенно хорошие идеи: @Jon Hanna (шепчет наставнику младших), @SaggingRufus (младшие иногда могут помогать старшим) @motosubatsu (почему младшие так думают)...

Полный ответ

Младший парень в стороне (другие ответы широко охватывают его), вопрос:

Как бы вы попросили о помощи в сложившейся ситуации, не теряя доверия?

  1. Какова ситуация?
  2. Потеря авторитета... в чьих глазах?

Начнем с простого вопроса:

Это про продвижение?

Вы упомянули беспощадное продвижение по службе сразу после этого отрывка:

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

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

Как бы вы попросили о помощи в сложившейся ситуации, не теряя доверия?

  1. Я бы следил за тем, КАК ЧАСТО я это делаю. На всякий случай. За человека, которого вы спрашиваете (иногда это имеет значение). Вы также можете посмотреть, как часто вы делаете это по сравнению с другими. И - если есть существенная разница - почему.
  2. Сначала я искал/исследовал/испытывал свои собственные идеи в течение 20 минут (или немного больше, если проблема была крупнее).
  3. Я бы правильно сформулировал свой вопрос, чтобы другие знали, что я сделал все, что в моих силах.
  4. Я бы спросил на SO иногда, а не в офисе.
  5. Я бы попробовал прийти с простыми правилами для себя: когда (НЕ) спрашивать.

я спрашиваю

  • когда время имеет решающее значение,
  • если я смогу выиграть значительно больше времени по сравнению с тем, сколько потеряет другой парень (ответ и переключение контекста),
  • когда я потратил слишком много времени на это без эффекта. Сколько времени для меня слишком много, зависит от размера/веса проблемы.

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

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

Конкуренция в ИТ

EDITed после комментария @Cantalope:

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

  1. Если вы хотите быть на вершине, будьте либо первопроходцем, либо последним парнем в этой технологии - и то, и другое дает отличные деньги и стабильность (в некоторой степени).
  2. Конкуренция несколько сильная. Тем не менее, вы можете легко измерить качество компании по тому факту, как часто навыки попирают политику, и наоборот. Все мы люди, поэтому полагаться на то, «насколько приятными кажутся другие люди», заложено в нашей природе, но во многих ИТ-компаниях это приносит пользу. Такой эксперт, как вы, будет преуспевать в тех, кто ценит навыки — вот где вы хотите быть. Конечно... ВАШИ навыки.
  3. Итак, рассмотрим вашу основную область знаний. Соответствует ли это тому, что нужно вашему боссу? Потому что он обычно продвигает то, что ему нужно. Не имеет значения (обычно!) насколько вы хороши в C#, если вам очень нужны специалисты по Java для нового самого важного проекта из всех.
  4. Ощущение нахождения вне зоны комфорта достается всем, думаю, не только вам. Думайте позитивно, технологии похожи, и со временем становится все проще. Это никогда не закончится, это специфика работы, я уверен, вы знаете. Верь в себя.

Итак, суть продвижения:

  1. Не волнуйся. Доверьтесь своим навыкам. Если ваша компания ценит политику и самопродажу больше, чем навыки, подумайте о переезде. Если нет людей, с которыми вам нравится работать, обычно это хороший повод задержаться еще немного.
  2. Обогатите их, если вы этого хотите или нуждаетесь (возможно, новый язык или фреймворк, чтобы получить повышение или перейти в другую многообещающую компанию?)
  3. Оцените своего начальника, на кого он повышал в прошлом. Самопродавцы? Красноречивые болтуны? Сапоголизы? Усердно работающие? Технические волшебники? Гуру X-технологий? Затем переоцените свои шансы.

Готова ли команда признать «я не знаю»?

Теперь другая часть вашего комментария:

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

  1. Давайте проверим, если они делают то
  2. Если они НЕ делают, вы хотите изменить это или вы хотите переехать?
  3. Если вы хотите изменить это, я бы рекомендовал изменить их восприятие (спасибо @BrianD за идею).

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

«Как вы думаете, такие люди, как X или Y, признают, что у них есть проблема, или они не знают ответа? Недавно мне было интересно, как мы, как команда, стоим на not knowing».

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

Изменение их восприятия должно начаться с того, чтобы поставить на один уровень «обращаться за помощью» и «получать их вклад». Первый подразумевает, что вы слабее (для некоторых!), второй (обычно!) подразумевает, что ОНИ ДОСТАТОЧНО ХОРОШИ, чтобы их спросили. Я обычно использую оба, поэтому всем вокруг ясно, что я считаю их одинаковыми. Через какое-то время, если я попрошу кого-нибудь о помощи в X, все узнают, что у парня с X все в порядке.

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

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

Это из-за репутации?

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

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

Вы исключили заржавевшие (хотя и базовые) навыки? Может быть, это был простой вопрос?

Недавно очень зрелый джуниор (пожилой парень, сменил профессию, очень глубоко учится) рассказал мне о сениорах на своем новом рабочем месте. Несмотря на то, что выходит Java 9, а Java 8 существует уже много лет, они никогда не удосужились взглянуть на нее и продолжают говорить, насколько это сложно. Когда он написал несколько вещей на Java 8, трое из них бросились к его экрану, чтобы посмотреть. Он замедлился, снова закодировал это, чтобы они увидели, как он это делает, предложил показать что-нибудь об этом, если они захотят, и вообще никогда не поднимал шума, но он сказал мне, что это было несколько горько-сладкое чувство. Так что, судя по вашему рассказу, это не так... перепроверьте. Возможно, ваш вопрос в целом воспринимается как легкий материал? Я несколько раз спрашивал о вещах, которые было легко найти, и несколько минут с Google могли бы' Он ответил мне так же хорошо, как и мой несчастный коллега, которому пришлось провести со мной несколько минут. Позже я был очень смущен, когда обнаружил, как легко найти это в Google. Я думаю, это случается с лучшими из нас.

Не поймите меня неправильно . Никто не знает всего. Иметь заржавевшие навыки — это естественно. Но так воспринимается слабым - особенно теми, кто считает эти навыки обязательными.

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

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

Резюме

  1. Следите за собой. Установите простые правила, когда вы спросите, когда нет.
  2. Помните о приоритетах работы, когда спрашиваете или просите о помощи.
  3. Взвесьте, как часто вы просите / вас просят, сколько времени вы / другие тратите на помощь. Сравните это с вашими соперниками, если вы беспокоитесь о том, что они вас обойдут.
  4. Отдавайте должное проблемам, прежде чем просить решения/помощь.
  5. Формулируйте свои вопросы, чтобы другие знали это.
  6. Дважды проверьте, что это не простой вопрос, возможно, проверьте, сколько времени потребуется вашим коллегам, чтобы решить его.
  7. Не обращайте внимания на младшего, его комментарий может исходить от простого волнения, что у этого могущественного старшего, которого он посвятил, есть вещи, которых он не знает, и, возможно, с ними можно будет связаться вовремя.

Очень длинный ответ, извините за это.

Вот несколько хороших способов сформулировать запросы: «Что вы думаете об этом?» или «Есть ли у вас какие-либо предложения по этому поводу?» или даже «Я хотел бы получить ваше сотрудничество в этом». Я бы даже не использовал слово «помощь».
Мне очень нравится твой ответ. Я уверен, что вопрос был не в том, что у меня заржавели навыки, а в том, что я недавно открыл для себя новую рабочую среду, будучи экспертом в другой несколько месяцев назад. Думаю, я тоже не слишком часто спрашиваю, так что не беспокойтесь. Я действительно беспокоюсь о продвижении по службе, честно признаюсь, поскольку там много поваров, и чувство «не в своей основной области» может быть неприятно. У меня есть ощущение, что в ИТ конкуренция сильна, но я определенно хочу стать более открытым, независимо от комментариев. Я принимаю незнание. Я не уверен, что моя команда это сделает.
@Cantalope, отредактировал мой раздел «о продвижении», обратившись к этому. Я могу написать больше, но я думаю, что это должно быть отдельным ответом на новый вопрос, предлагающим вам здесь пищу для размышлений. ;-)

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

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

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

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

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

Обращение за помощью в ИТ на руководящей должности, сохраняя при этом авторитет
СпросиСетьПолитика конфиденциальности1y, 0v