Технический менеджер, ведущий / главный инженер, архитектор программного обеспечения… все эти роли требуют определенного мышления.
Большинство инженеров-программистов достигают определенной точки в своей карьере. Момент, когда они думают выйти за рамки роли отдельного участника и взять на себя роль лидера.
Часто это подразумевает переключение именно на роль «Технического менеджера». Однако даже продвижение по техническому пути - скажем, от «старшего инженера-программиста» до «архитектора программного обеспечения» или «главного / штатного инженера-программиста» подразумевает принятие на себя руководящей роли. Действительно, во многих организациях роли инженерного менеджмента сильно пересекаются с более техническими ролями.
При оценке вашей пригодности для перехода к руководящей роли вашим первым мерилом могут быть ваши технические навыки. Большинство инженеров полагают, что им необходимо продемонстрировать высокий уровень инженерных знаний, будь то глубокое понимание алгоритмов, владение одним или несколькими языками программирования, опыт работы с AWS, понимание распределенных систем или что-либо еще.
Безусловно, предварительным условием является наличие технических способностей. Трудно руководить командой инженеров, если вы не достигли определенного уровня технической компетенции. Но инженерное мастерство, как говорится, ставка стола. Чтобы по-настоящему добиться успеха в качестве лидера, вам необходимо продемонстрировать ряд нетехнических качеств, например:
- Желание помочь другим инженерам расти в карьере
- Гордость за работу и успехи своей команды
- Уверенность в себе и своих решениях
- Признание того, что вы здесь, чтобы помогать другим людям решать проблемы.
- Желание сосредоточиться на меньших технических проблемах
Более того, вам нужно будет продемонстрировать их сейчас -, прежде чем вы сможете надеяться подняться до руководящей роли.
Хорошая новость заключается в том, что мы склонны приобретать эти качества со временем, по мере того как наш опыт и уверенность в себе растут, и мы работаем со все большим количеством людей. Более того, мы можем активно работать над приобретением и укреплением тех качеств, в которых мы слабы. Так что, даже если вы не обладаете многими из них сейчас, если вы непреклонны в этом, вы все равно можете работать, чтобы подготовиться к будущему успеху в руководстве.
Давайте исследуем эти черты.
Вы говорите «мы» гораздо чаще, чем «я»
Ваша команда только что завершила проект. Вы сами проделали большую часть работы над проектом. Вы придумали дизайн и сделали большую часть программирования. Вы также развернули готовый проект (но не раньше, чем обнаружите и исправите пару проблем). Конечно, другие инженеры в команде помогли, но давайте посмотрим правде в глаза: вы в значительной степени направляли их на всем пути.
Что вы скажете, когда кто-то за пределами вашей команды спросит вас о проекте?
- Вы говорите: «Позвольте мне рассказать вам о том, что я сделал»?
- Или вы скажете: «Позвольте мне рассказать вам о том, что мы сделали…»?
Ваш естественный инстинкт может потребовать уважения к себе. В конце концов, вы сделали основную работу, верно? Именно ваш дизайн, ваше инженерное мастерство сделали проект успешным. Так почему бы не заявить о себе?
Это кажется разумным. Но это то, что делают отдельные участники, а не лидеры.
ИС предназначены для выполнения своих собственных задач, часто работая изолированно. Однако лидеры должны руководить командами и делать их успешными. Когда вы продвигаете себя и свои достижения, вы можете звучать как индивидуальный участник рок-звезды, но вы не ведете себя как лидер.
Более того, лидеры несут ответственность за рост команд и членов этих команд. Если команда, которую вы возглавляете, добивается успеха только благодаря вашим техническим навыкам и работе, то как руководитель вы потерпели неудачу.
Как переключиться с «я» на «мы»
Поначалу может быть неудобно отдавать должное всем остальным в вашей команде. По мере того как молодые инженеры пытаются добиться успеха, требование индивидуальной заслуги становится своего рода навыком выживания. И этот менталитет может укорениться в нас по мере того, как мы получаем все больше и больше опыта.
Итак, первое, что вы можете сделать, - это осознавать, когда вы продвигаете себя, и перейти к продвижению команды. Буквально, если вы слышите, что используете «я» или «меня», чтобы присвоить себе должное, остановите себя и используйте вместо этого «мы» или «нас». Это будет странно, как если бы вы сгибали ранее неиспользованные мышцы. Но, как и тренировка запущенной мышцы, чем больше вы ее будете делать, тем больше будет ощущаться она естественнее.
Следующее, что вы можете сделать, это то, что я называю сдвигом кредита вправо. Возьмите следующую диаграмму.
- «Я» представляет собой меня.
- «Алиса» представляет члена команды, с которой я работаю.
- «Мы» представляет нас обоих, работающих вместе.
Когда я описываю работу, которую мы проделали, я считаю, кто сделал основную работу. Возьмем пример в начале этого раздела, где я проделал большую часть тяжелой работы над проектом. На мой взгляд, всю работу выполнял я. Тем не менее, я выдвигаю кредит один раз вправо и описываю его другим как работу, которую проделали «мы».
Если вместо этого это было действительно совместное усилие между нами двумя, то я хвалю работу, проделанную «Алисой».
Наконец, вам нужно расширить свое представление о том, чем гордиться. Как младшие / старшие инженеры, мы гордимся хорошо разработанным программным обеспечением, которое мы производим. Помощь другим инженерам в их работе - необходимая, но отвлекающая часть нашей работы. Чтобы быть настоящим инженером-лидером, вам нужно принять тот факт, что помощь другим инженерам - это, по сути, ваша работа. Если младшие инженеры в вашей команде растут и получают признание, значит, вы хорошо делаете свою работу.
Вы счастливы, когда младшие инженеры решают проблемы
Наша работа как старших инженеров - решать сложные технические проблемы. Так что мы должны быть уверены, что их берут на себя мы. В конце концов, если младший инженер в нашей команде должен был начать решать проблемы, что это говорит о нас? Это не выглядело бы так, как будто мы выполняли свою работу, и, честно говоря, это было бы немного опасно.
Верно?
Если вам это кажется правдой, то это совершенно естественная реакция. Однако это также означает, что вы не совсем готовы к роли лидера. Это наглядная демонстрация того, что вам не хватает двух жизненно важных качеств:
- Уверенность в собственных силах.
- Понимание того, что ваша работа - помогать молодым инженерам расти.
Как быть счастливым, когда младшие инженеры решают задачи
Это мышление может оказаться трудным для сознательного принятия, поскольку во многом это связано с ростом вашей собственной уверенности. Однако я обнаружил, что лучший способ укрепить уверенность - это просто опыт.
Итак, для начала поговорите со своим менеджером. И убедитесь, что в вашем официальном описании должности есть что-то вроде «наставничество младших инженеров». Таким образом, вы можете быть уверены, что вас оценит - хотя бы частично - по тому, насколько хорошо работают младшие инженеры в вашей команде.
Затем определите сложную проблему для младших инженеров в вашей команде и поручите ее им. Обязательно проверяйте их часто, предлагая рекомендации, где это необходимо. Но по возможности пусть решает проблему инженер.
И как только они это сделают, не забудьте рассказать об этом остальным в вашей команде. Независимо от того, насколько вы им помогли, не создавайте иллюзий, будто вы и инженер решили проблему. Скорее сдвиньте кредит вправо и отдайте все другому инженеру (ам).
Затем осмотритесь и посмотрите, что происходит. Вы не потеряете работу. Тебя не понизят. Никто не подумает, что ты слабый инженер. Фактически, вы начнете выглядеть лидером.
Вы перестали высмеивать чужой код
Мы все это сделали. Получил устаревшую кодовую базу, просмотрел код и предложил оценку всего, что предыдущий инженер сделал неправильно.
«Эти пять строк можно было бы объединить в одну».
«Почему здесь передается этот параметр? Это безумие! »
«Пулы потоков должны использоваться не так. Эти парни не знали, что делают! »
Ладно, если честно, возможно, ты никогда не делал этого вслух. Но признай это; вы, вероятно, сделали это молча, в собственном уме. И почему бы нет? Это не только увлекательное занятие, но и хороший способ продемонстрировать свои превосходные технические навыки и стандарты кодирования - себе или другим инженерам в пределах слышимости. Верно?
Ну, может быть. Но более того, он демонстрирует еще несколько важных вещей о вас:
- Вам не хватает сочувствия. Может быть, увлекательно заниматься чужой работой, но это свидетельствует о серьезном отсутствии сострадания к бедному инженеру, чью работу вы занимаетесь. Возможно, они действительно не знали, что делали. Также могло случиться так, что они были в огромной цейтноте и были вынуждены срезать углы. Или что им пришлось пойти на другой компромисс при написании кода. Если бы вас там не было, вы не знали бы.
- Вам не хватает уверенности в своей работе. Мы знаем это с детства: люди обычно высмеивают других, чтобы скрыть свою неуверенность. Уверенным в себе людям не нужно высмеивать других. Конечно, указание на недостатки других людей может показать другим то, что вы знаете, но это также ясно показывает, что вам не комфортно со своими собственными навыками.
- Вам не хватает самосознания. Спросите любого опытного, знающего себя инженера-программиста, и он скажет вам, что обычно оглядывается на свой собственный код и передергивается. Написание программного обеспечения - это путь к самосовершенствованию на всю жизнь. Это означает, что в целом код, который мы написали в прошлый раз, будет более низкого качества, чем код, который мы пишем в этот раз. Если вы думаете, что никогда не писали недостойного кода, что ж, вы просто не честны с собой.
Чтобы было ясно, мы не говорим о конструктивной критике кодекса наших коллег. Предложить другому инженеру, как лучше решить проблему или как их текущий подход может вызвать неожиданные проблемы - и делать это уважительно - - это важно сделать (в конце концов, это и есть проверка кода Мы говорим о потакании своим желаниям насмешкам, которые не служат никакой другой цели, кроме как заставить себя выглядеть лучше, заставляя других выглядеть хуже.
Как перестать высмеивать код других инженеров
Может быть трудно просто решить избавиться от этой вредной привычки. Даже если вы можете перестать открывать рот каждый раз, когда чувствуете желание посмеяться над чужим кодом, это желание все равно может присутствовать.
Вместо этого попробуйте это. Когда вы просматриваете кодовую базу, которая кажется вам достойной насмешек, остановитесь. А затем попытайтесь выяснить, почему инженер сделал то, что они сделали. Представьте, что вы написали этот код, и объясните причины, по которым вы могли это сделать. И кто знает ... может, ты действительно чему-нибудь научишься.
Вы ставите во главу угла помощь другим, а не выполнение собственных задач
Ты занят. У вас много работы ... так много, что вам повезет, если вы сделаете половину из нее вовремя. А потом другой инженер просит вас о помощи. Им понадобится уйма вашего времени, чтобы понять, как решить проблему. Что вы делаете?
Может быть, ты скажешь этому инженеру подождать. Что ты слишком занят, чтобы им помочь. У тебя свои дела. И это нормально. Возможно, вам как индивидуальному участнику лучше сосредоточиться на выполнении собственных задач.
Но если вы настоящий руководитель инженерной мысли, вы бросите то, что делаете, и поможете другому инженеру. Потому что это жизненно важная часть лидерства: помогать другим в достижении того, что им нужно делать, и ставить их потребности выше ваших собственных.
Много десятилетий назад Роберт К. Гринлиф придумал термин лидерство слуг. По сути, лидерство в виде слуг утверждает, что лучшие лидеры начинают с стремления быть слугами, стремясь помочь другим в достижении своих целей. Эта концепция снова и снова повторяется в компаниях повсюду.
На самом деле, вспомните некоторых из лучших инженеров, с которыми вы когда-либо работали. Это могут быть ваши менеджеры, руководители высшего звена или вице-президенты в вашей группе, либо старшие / штатные инженеры и архитекторы. На ум приходят те, у кого никогда не было времени работать с вами, помогать и направлять вас? Или это те немногие, кто всегда оставлял для вас место в своем графике, кто работал с вами и следил за тем, чтобы вы учились и росли?
Как начать расставлять приоритеты для других
Это может показаться оксюмороном - чтобы добиться успеха самому, вам нужно помогать другим выполнять их работу, а не делать свою собственную. На самом деле это не так. Любые конкретные задачи или результаты, которые у вас есть - документация, которую нужно написать, технические проекты, которые нужно завершить, даже отчеты о производительности, которые нужно сдать, - вторичны по отношению к вашей ответственности по оказанию помощи вашим инженерам.
Это означает, что - как мы обсуждали ранее в разделе «Вы счастливы, когда младшие инженеры решают проблемы» - вам необходимо убедиться, что в официальном описании должности и личных целях особое внимание уделяется наставничеству и помогая другим. Если сейчас это не так, поговорите со своим менеджером. Скорее всего, он будет счастлив сделать это частью ваших должностных обязанностей.
Вы можете позволить другим людям делать интересную работу по кодированию
Большинство инженеров считают, что как только они пойдут по пути управления, они больше не будут писать код. Это не обязательно. Множество технических менеджеров и директоров все еще пишут код в течение дня (см. Пончиковая дыра в работе инженерного менеджмента). Но в целом, чем выше мы занимаемся инженерным менеджментом, тем меньше практической технической работы мы выполняем.
И это верно не только для руководителей. Такие роли, как ведущий / главный инженер или архитектор программного обеспечения, также означают меньше практической работы и гораздо больше обязанностей, не связанных с кодированием, например:
- технический дизайн
- планирование
- управление проектом
- наставничество
- обзоры кода
Когда вы возьмете на себя эти роли, вы обнаружите, что перекладываете интересную и содержательную работу по программированию на более молодых инженеров в вашей команде.
Как стать нормальным, отказавшись от интересной работы по кодированию
Это единственная черта, которую мы обсудим, которую вы не можете решить самостоятельно. Если вы действительно хотите продолжать заниматься интересным программированием на регулярной основе, то вы просто не готовы к руководящей роли. По крайней мере, пока.
Но время и опыт могут это изменить. Вы можете обнаружить, что написание программного обеспечения изо дня в день - независимо от того, насколько оно интересно или сложно - начинает устареть. Вы можете начать интересоваться более серьезными проблемами. Или вы можете понять, что ваши лучшие дни на работе были те, когда вы разговаривали и сотрудничали с другими инженерами и людьми из других отделов.
В этот момент вы действительно можете быть готовы к роли лидера.
Вам нравится двусмысленность, и вы принимаете на себя ответственность
На протяжении многих лет мне приходилось работать с рядом талантливых инженеров младшего звена. О многих из них я не беспокоился. Я чувствовал, что у них будет сильная карьерная траектория и перед ними будет широкий карьерный путь.
Но было несколько сильных, потрясающих инженеров, о которых я действительно беспокоился. Одна, в частности, «Эмбер», вызывала уважение и уважение большинства ее коллег. Ее навыки программирования были на высшем уровне, а ее понимание шаблонов проектирования и передовых методов было сверхъестественным. Она была приверженцем качества кода и соблюдения стандартов нашей компании. И она часто бралась за сложные проблемы, с которыми сталкивались другие инженеры, и быстро помогала их решать.
Но каждый раз, когда я предлагал Эмбер возможность - скажем, возглавить проект, - она отказывалась.
Сначала я был в недоумении. Но вскоре я понял, что Эмбер смертельно боялась неопределенности. Стало ясно, что причина, по которой она так часто вызывалась для помощи в решении других проблем инженеров, заключалась в том, что она не брала на себя никаких рисков или ответственности сама. Если ей это удастся, она получит признание. Если бы она потерпела неудачу, что ж, она бы попыталась, но, в конце концов, это была чужая проблема.
Как бы ни была сильна Эмбер как инженер, было трудно представить, как она продвигается к какой-либо руководящей должности в инженерии. Это потому, что двусмысленность и ответственность - два важных аспекта лидерства.
Последнее, ответственность, вероятно, более понятно. По мере того, как вы становитесь лидером, вы обнаружите, что отвечаете за все больше и больше. Вас будут судить по успехам и неудачам целых проектов. Более того, эти успехи и неудачи не будут находиться под вашим непосредственным контролем. Одной ночи напролет для завершения задач по кодированию недостаточно. Вместо этого ваши успехи и неудачи будут зависеть от того, насколько хорошо работает ваша команда в целом.
Первое, двусмысленность, заслуживает небольшого обсуждения. Мы, младшие инженеры, привыкли, что нам нужно выполнить конкретную задачу. К тому времени, когда он попадает в нашу очередь JIRA, кто-то выше нас уже понял, что нужно делать. Наша задача - просто следовать инструкциям.
По мере того как мы все больше и больше занимаем руководящие должности, мы будем сталкиваться со все большей двусмысленностью и неуверенностью в том, что нам нужно делать. Часто мы просто сталкиваемся с проблемой, которую необходимо решить. Как это исправить - или даже если это можно исправить в первую очередь - нам будет совершенно неизвестно.
Тем не менее, мы будем нести ответственность за его решение.
Это очень большой риск. Но на руководящей должности от вас ожидается, что вы будете ее регулярно выполнять. Если вы не можете справиться с двусмысленностью, неопределенностью и риском, который они представляют, то вы, вероятно, не готовы к лидерству.
Как смириться с риском и ответственностью
К счастью, вполне возможно привыкнуть к неоднозначным обязанностям. Как и во многих других случаях в жизни, это приходит с опытом.
Вспомните, когда вы были моложе. Еще, скажем, в начальной школе. Представьте, что тогда вам сказали, что вам нужно написать курсовую работу. Что-то объемом не менее шести страниц, хорошо проработанное и снабженное библиографией. Вы бы испугались!
А теперь перенесемся в сегодняшний день. Мысль о том, чтобы написать что-то подобное сейчас, была бы гораздо менее пугающей, чем казалось тогда.
Почему? Потому что вы приобрели опыт и обрели перспективу. С тех пор вы, вероятно, написали много таких посланий и уверены, что сможете сделать это снова.
То же самое и с управлением рисками, ответственностью и разработкой программного обеспечения. Поначалу идея взять на себя ответственность за рискованные, непонятные проекты пугает. Но после первого все становится менее страшным. Что еще более важно, в первый раз, когда ваш неоднозначный проект идет не так хорошо - и все же ни мир, ни ваша работа не приходят к концу - риск внезапно кажется намного легче.
Так что постарайтесь получить некоторый опыт работы с проектами такого типа. Не забывайте о проблемах, не имеющих заранее определенных решений. Например:
- Вашей компании необходимо обновить версию своего основного языка программирования для всех своих сервисов, приложений и внутренних библиотек… без возникновения производственных проблем.
- У ряда микросервисов периодически заканчивались соединения с базой данных, и они зависали.
- Инженерной организации необходимо снизить затраты на определенную сумму.
Если вы действительно испытываете опасения, вам не нужно брать на себя полную ответственность за проект; вместо этого вы можете искать кого-то, кого ведет другой. Но не забудьте активно работать с проектом, чтобы найти решение.
После этого - независимо от того, имел ли проект оглушительный успех или не очень - у вас будет этот опыт за плечами. И вам будет удобнее работать со следующим неоднозначным проектом, который появится на вашем пути.
Вы хорошо работаете с людьми, которые умнее вас
Некоторые инженеры - «рок-звезды», мастера программного обеспечения, разбирающиеся во всем техническом. Они владеют языками, которые использует ваша организация, и знают тонкости работы со всеми фреймворками. Они хорошо разбираются в передовых методах (и очень много говорят о них). Они приверженцы качества кода.
И это немного затруднительно. Потому что, как мы учимся, для того, чтобы быть сильным инженером-лидером, нужно гораздо больше, чем просто сильные технические навыки. Но будучи инженером-рок-звездой, не всегда остается возможность преуспеть в чем-то еще.
Так что у этих рок-звезд может не хватать лидерских качеств, чтобы руководить инженерными командами. Но они вроде все знают с технической точки зрения. И в целом они более чем готовы поделиться своим мнением о том, как все должно быть сделано.
Насколько хорошо вы работаете с такими инженерами? Это не всегда легко. Работа с кем-то, кто, кажется, знает больше, чем вы, может унизить и расстроить.
И если вы не можете хорошо с ними работать, насколько хорошо вы сможете ими руководить?
Вы можете полагаться на их мнение
Во-первых, как их руководитель или технический руководитель, вы часто будете полагаться на их мнение, чтобы направлять проекты вашей команды. Вы из тех людей, которые могут спросить их мысли о том, как что-то делать? Можете ли вы прислушаться к их нежелательным советам?
Или ваше собственное эго - или неуверенность - помешают вам сделать это? В конце концов, будучи инженером любого рода, вы не можете постоянно конфликтовать с членами своей команды.
Вы можете противостоять им
В то же время вам иногда нужно конфликтовать с ними. Технические мастера часто сосредотачиваются на одном: на лучшем техническом решении. Однако вам нужно будет принять во внимание все: да, хорошие технические решения, но также такие вещи, как:
- сроки
- организационные приоритеты
- расходы
- доступные ресурсы
А иногда, каким бы гениальным ни был член вашей команды, их подход может оказаться неприемлемым в долгосрочной перспективе.
Вам удобно отталкиваться? Часто эти инженеры открыто высказывают свое мнение и будут настаивать на своем мнении еще долго после того, как вы подумаете, что разговор закончился. Сможете ли вы придерживаться своего мнения и продолжить работу над проектом?
Вы можете сказать, когда делать одно, а когда - другое
Иногда вам придется полагаться на своих блестящих, упрямых инженеров; иногда вам нужно противостоять им. Часть вашей работы будет заключаться в том, чтобы определить, когда делать первое, а когда - второе. Достаточно ли у вас опыта и уверенности, чтобы отличить?
Как работать с людьми умнее вас
Если вам трудно работать с инженерами-рок-звездами, сначала попытайтесь определить, почему. Например:
- Это ваше собственное эго? Считаете ли вы, что в целом знаете лучше всех?
- Это ваше чувство незащищенности? Вы чувствуете себя более слабым, работая с сильным инженером?
- Это неуверенность? Возможно, вы обычно придумываете разумные решения, но вам неудобно их продвигать.
В любом случае волшебной пули нет. Всегда будет сложно работать с сильными инженерами с сильным характером и уметь сочетать почтение с их умопомрачением. Как и в случае со многими описанными здесь навыками, это приходит с опытом.
Вы не ждете, пока другие люди сделают что-то за вас
Во всех организациях, кроме самых маленьких, вы часто полагаетесь на других в достижении цели. Вы можете полагаться на сетевых инженеров в предоставлении ресурса. Вы можете получить рекомендации от своей службы безопасности. Или вам может понадобиться текст от маркетинговой команды.
Как младший инженер вы склонны обращаться с просьбой к кому-то еще, а затем предполагать, что ответственность полностью ложится на них. Мяч - как говорится в метафоре - на их стороне. Ничего из того, что ты можешь сделать, правда?
Итак, вы ждете. И вы приходите на ежедневную стендап и сообщаете о своем статусе:
- «Я переключился на исправление некоторых модульных тестов, потому что жду маркетинговую копию».
Или хуже:
- «Вчера я ничего не мог сделать, потому что все еще жду маркетингового текста».
И это ведь не твоя вина? Вы ждете кого-то другого, а он не сделал то, что ему нужно.
Кроме того, независимо от того, где находится метафорический мяч, вы не делаете свою работу.
Более того, вы можете подумать, что ваш менеджер или главный инженер, услышав ваш отчет о состоянии дел, не испытывает к вам ничего, кроме сочувствия. «Бедный инженер; все, что он / она хочет сделать, это написать код, но какой-то придурок из другого отдела сдерживает их! » Верно?
Что ж, открою тебе секрет. То, что, вероятно, чувствует ваш руководитель или руководитель, скорее всего, больше похоже на раздражение, а не на маркетолога. «Почему?» они, вероятно, думают про себя, «может ли этот инженер не просто разблокировать себя?»
Речь идет о владении
Итак, по мере того, как ожидание затягивается, ваш менеджер или руководитель вмешивается, чтобы убедиться, что вы получили то, что вам нужно. Возможно, они обращаются напрямую к команде или человеку, которому необходимо выполнить задачу. Или, в зависимости от поставленной задачи, может быть, они просто выполняют ее сами.
Потому что, конечно же, лидер делает это.
А что, если вместо этого вы убедитесь, что получили то, что вам нужно? Вместо того, чтобы сидеть сложа руки, найдите специалиста по маркетингу, у которого есть нужная вам копия, и поговорите с ним напрямую. Или посетите сетевую инженерию, чтобы узнать имя человека, который может предоставить необходимый вам ресурс.
Когда вам поручают задачу, обычно ожидается, что она вам принадлежит. Это означает, что вы доводите до конца каждый аспект задачи - программирование или нет.
Как сделать все самостоятельно
В следующий раз, когда вы окажетесь заблокированными, не поддавайтесь желанию просто подождать, пока вас не разблокируют. Напомните себе, что пока вы инженер-программист, ваша работа включает в себя больше, чем просто написание программного обеспечения. И спросите себя: что я могу сделать, чтобы заранее разблокировать себя?
Иногда ответ будет заключаться в том, что вы можете выполнить задание самостоятельно. Если вы ждете, что сетевой инженер предоставит вам ресурс, можете ли вы вместо этого предоставить его самостоятельно?
В других случаях вы действительно будете полагаться на кого-то другого. В таких случаях не бросайте и не забывайте свой запрос. Следовать за. Спросите другого человека, когда он сможет предоставить вам то, что вам нужно, и убедитесь, что он знает ваш график. Если они не могут довести дело до конца, вы можете привлечь кого-нибудь с большим авторитетом, например вашего менеджера или руководителя группы. Но заранее привлекайте их для поддержки; не ждите, пока они решат вашу проблему за вас.
Вы начинаете жесткие разговоры
Мы установили, что, будучи лидером в области инженерии, вы будете проводить большую часть своего времени за нетехнической работой. Большая часть вашей работы связана с общением с другими людьми.
В результате наиболее успешным лидерам нравится этот аспект своей работы. Знакомство с новыми людьми, наставничество младших инженеров, продвижение идей и обсуждение приоритетов… все это может быть интересно, весело и полезно.
Однако, как и в любом другом деле, работа с людьми также может быть сложной. Часто бывает трудно вести разговор.
Например, вам может потребоваться поговорить с тем инженером в вашей команде, который придумал блестящую идею для написания программы. Они написали POC, убеждены, что их программа - это именно то, что нужно организации, и готовы приступить к работе. И вам нужно будет усадить их и сказать, что вы не можете финансировать их проект. Вместо этого они присоединятся к месячным усилиям по очистке чужой кодовой базы.
Или ваша команда инженеров может не согласиться с тем или иным подходом администраторов баз данных. Каким бы спорным и спорным ни был разговор, как бы вы его ни боялись, вам нужно объединить обе стороны, чтобы договориться о рабочем решении.
Или у вас может быть член вашей команды, который, откровенно говоря, создает проблему. Возможно, качество их работы влияет на общее качество и продуктивность команды. Возможно, они создают проблемы для другого сотрудника. Как их руководитель, вы будете ответственны за планирование встречи с ними и начало этого сложного разговора.
Как младшие инженеры, мы часто можем позволить себе роскошь бездействовать в этих разговорах. Как руководитель инженерного отдела, мы этого не делаем. Более того, нам не нужно только участвовать в этих разговорах; мы должны быть теми, кто принимает это и активно их инициирует.
Как завязать тяжелые разговоры
Умение заводить сложные разговоры - это сложный навык. Однако есть несколько вещей, которые могут помочь.
Думайте об этом как о BAND-AID®
Большинство из нас усвоили старую пословицу о том, что лучше просто оторвать BAND-AID®, а не медленно отдирать его. Таким образом, возникает кратковременная боль, но затем боль быстро утихает.
Так обстоит дело и с началом трудного разговора. Самое сложное - просто начать разговор. Как только вы затронули эту тему, разговор, как правило, становится намного проще. Помните об этом, чтобы набраться смелости и начать разговор.
Кроме того, используйте эту аналогию как руководство для того, как начать разговор. Не приукрашивайте вещи слишком много и не тратьте время на то, чтобы перейти к делу. Четко сформулируйте проблему заранее. Как можно скорее преодолейте это первоначальное препятствие, чтобы сосредоточиться на остальной части разговора.
В первом примере, который мы рассмотрели в этом разделе, у нас может возникнуть соблазн начать разговор с нашим нетерпеливым инженером следующим образом:
«Мне очень нравится предложение по заявке, которую вы представили. Как показал ваш POC, я думаю, это действительно может помочь компании. Так думали и многие другие. Есть шанс, что вы не сможете над этим поработать. Я не уверен, но я скоро вернусь к вам ... »
Вместо этого постарайтесь начать так:
«К сожалению, я не смогу профинансировать ваш проект в этом квартале».
Это однозначно сразу же меняет смысл. И вы, и инженер сразу же избавляетесь от самого болезненного момента. После этого вы можете обсудить более тонкие детали проблемы: признание работы, которую проделал инженер, почему работа по очистке кода является более приоритетной, есть ли шанс, что проект можно будет пересмотреть позже и т. Д. .
Практикуйтесь дома
Многие из этих навыков актуальны не только в профессиональной, но и в личной жизни. Время от времени нам приходится обсуждать сложные темы с друзьями и семьей. То, что мы действительно поднимаем темы и инициируем такие разговоры в одной обстановке, может дать нам уверенность в том, что мы сможем сделать это в другой обстановке.
Некоторое время назад моей семье пришлось нелегко поговорить с одним членом семьи. В частности, старший член моей семьи дошел до того, что, как мы все считали, он больше не мог безопасно водить машину, и нам пришлось убедить его передать ключи от машины.
Как младший член семьи, я обычно не вел такие разговоры; как правило, я просто выражаю поддержку. Однако на этот раз все было иначе. Однажды моя семья встретилась, и вскоре воцарилось неловкое молчание. Оглядевшись, я мог сказать, что почти все в комнате думали о том же: «Кто начнет этот разговор?»
Я решил, что это буду я.
Разговор прошел, как и следовало ожидать. Ключи были переданы без особых споров, и вскоре мы пошли на более ранний обед. Но этот момент по-прежнему остается для меня поворотным моментом, который вселил в меня уверенность в том, что я могу инициировать и вести такие разговоры как в личной, так и в профессиональной жизни.
