Как быть с прямым подчиненным тимлида, который ведет себя непрофессионально?

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

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

Единственный способ по-настоящему понять мотивацию человека — это выслушать его. Много.

Выведите их из офиса в удобное место и задайте несколько нежных наводящих вопросов. И как только он начнет говорить, слушайте. Rands in Repose рассказал нам всем, как это сделать, в отличной статье под названием The Update, The Vent and The Disaster .

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

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

30 минут, по крайней мере. Еще один излюбленный ход занятого менеджера — запланировать 1:1 на 15 минут или меньше. Это лучшее, что я могу сделать, Рэндс. У меня работает 15 человек. Во-первых, эти 15 человек не работают на вас; вы работаете на них. Подумайте об этом так: если эти 15 человек уйдут, просто покинут здание завтра, сколько работы будет на самом деле сделано? Во-вторых, если на вас работает 15 человек, вы не их менеджер, вы просто парень, который неловко ухмыляется, когда вы нечасто пролетаете мимо офиса, спрашиваете, как дела, а потом фактически не слушаете. ответ.

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

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

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

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

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

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

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

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

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

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

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

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

Время, потраченное на создание пользовательского трекера в Excel, лучше потратить на установку и настройку существующего бесплатного трекера. Даже лучшему программисту VBA в мире потребуются буквально тысячи часов работы, чтобы реализовать базовую функциональность любой крупной системы отслеживания ошибок. Использование средства отслеживания ошибок означает, что все могут обновлять информацию одновременно без конфликтов (фундаментальная проблема с любым общим документом), что уже означает меньше времени, затрачиваемого на каждое обновление, чтобы проверить, редактирует ли кто-то еще, каким-либо образом заблокировать документ и затем разблокируйте его в конце.

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

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

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

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

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

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

Обратите внимание, как любое из этих представлений противоречит двум основным принципам знаменитого Паккарда :

1. Подумай сначала о другом человеке. Это основа — первое необходимое условие — для того, чтобы ладить с другими. И это единственное действительно трудное достижение, которое вы должны сделать. Получив это, остальное будет «на одном дыхании».

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

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

Что касается непосредственного общения с сотрудником, вы можете попробовать организовать регулярные встречи один на один со всеми разработчиками, чтобы понять проблемы и разочарования, прежде чем они будут выражены в самой большой доступной группе. Этот человек может быть многословным и конфронтационным, но опасения, стоящие за ним, могут разделяться другими в группе (или, наоборот, могут считаться неважными). Как было сказано после прыжка, трудно установить полезные отношения 1:1, но это может разрядить конфликт до того, как он распространится.

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

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

1. Сделайте процесс максимально легким. Например, инструмент отслеживания работы, интегрированный с инструментом программирования, так что вы просто выбираете что-то из раскрывающегося списка при регистрации изменения, и статус элемента обновляется для вас (Visual Studio Express делает это в паре с размещенной TFS, которая бесплатно для 5 разработчиков или меньше Отличные инструменты не обязательно должны стоить десятки тысяч долларов)

2. Дайте ему то, что он хочет, в обмен на то, что вы хотите. «Если вы получите это электронное письмо со статусом до 9 утра, у меня будет время просмотреть его и задать вам любые вопросы до встречи, и вам не нужно будет приходить на встречу». «Если вы отправите мне электронное письмо со статусом формы, я составлю из него предложения и отправлю всем заинтересованным сторонам». «Если вы выделите 15 минут на беседу один на один, мы сможем вместе обновить документ о статусе, а я буду печатать».

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

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

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

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

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

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

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

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

Лично я считаю, что у вас есть человек, который находится в роли, которую он не подходит. Когда вы занимаете руководящую должность, кодирование становится вашей второстепенной обязанностью и должно занимать не более 50-70% вашего времени (лично я выбираю 50, но он руководитель модуля, а не общий руководитель, поэтому, возможно, 70% — это более подходящий). Я бы сел с ним и спросил его, сколько времени, по его мнению, он должен потратить на управленческие задачи, связанные с кодированием, а затем рассказал бы ему о ваших фактических ожиданиях разделения между ними, а затем спросил бы его, предпочел бы он быть разработчиком, а не руководителем, если бы эти две оценки не соответствуют действительности, и он не желает менять вашу оценку. Лид, который обесценивает время, потраченное на управление, означает, что у вас нет лида.

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

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

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

Вам поможет справиться с вашей ситуацией, если вы смиритесь с несколькими неопровержимыми истинами:

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

2. Инженеры-программисты, по крайней мере, хорошие, как было сказано выше, легко обнаруживают операционные ловушки (например, «В нашей организации мы не можем позволить себе роскошь инструментов. В основном нам приходится полагаться на листы Excel» и слишком много бесполезных совещаний) и , поскольку они талантливые работники умственного труда, их легко раздражает это обстоятельство, и им приходится выполнять более тяжелую, бессмысленную, бюрократическую работу, потому что их менеджеры небрежно или дешево инвестировали в надлежащую инфраструктуру. Если они хорошие, они не потерпят этого и пойдут работать в другое место. Я заметил тон вашего восклицания о том, что у вас нет инструментов, как будто вы почти гордитесь этим (подобно тому, как «когда мне было 8 лет, я должен был идти в школу 11 миль по снегу»), тогда как это довольно неловкое состояние вашей организации.

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

Мой окончательный ответ вам: приспособиться к вашему партнеру Аспи. Я вижу в нем себя на 100%. Почему кто-то, кто умеет программировать, должен сидеть на бессмысленных совещаниях полдня? Или заполнять титульные листы в своем отчете TPS? Продумайте свой процесс и сделайте его легким для всеобщего блага. Как только это станет простым и упорядоченным, возможно, ваш партнер не будет возражать тратить 10 минут в день на отправку необходимых артефактов, чтобы держать всех в курсе.

Мне кажется, ваш коллега очень креативен. Угадай, что? Управление творческими людьми само по себе является творческой сферой. Мне вспоминается пародия из Хи Хоу:

Пациент: Доктор, мне больно каждый раз, когда я вот так двигаю рукой! Доктор: Тогда перестаньте так двигать рукой!

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

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

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

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

1. Главные битвы, в которых действительно стоит участвовать. Я часто спрашиваю себя, что я скажу об этом через 20 лет. Через 20 лет вы действительно скажете: «Хотел бы я, чтобы он лучше общался по электронной почте»? Более вероятно, что вы обнаружите, что говорите что-то вроде: «Хотел бы я найти лучший способ использовать его талант. Боже, однако, он сказал несколько забавных вещей на собраниях».
2. Низко висящие плоды. Вещи, которые можно исправить без особых проблем. Я подозреваю, что к тому времени, когда вы доберетесь до того места, где вы сейчас находитесь, вы, вероятно, уже исправите большинство из этих вещей. Тем не менее, на это стоит обратить внимание.

Это то, с чем вам нужно что-то делать. Мое предложение состоит в том, чтобы бороться с желанием просто «исправить» проблемы категории 1, потому что вы, вероятно, не сможете их исправить. Тем не менее, если вы и он сможете определить пару важных, конкретных проблем, на которых нужно сосредоточиться, скорее всего, решить их будет намного проще.

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

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

Улучшенная стратегия встречи Я ненавижу, когда менеджер вызывает меня на встречу, где у него есть четкая повестка дня, как вести себя с клиентом/ситуацией, но он никогда не удосужился объяснить мне это заранее. Требуется большое усилие, чтобы избежать противоречивых мнений и уклониться от темы. Встретьтесь первым. Дайте ему понять, что настало время для несогласия, и когда вы придете на собрание, будьте командным игроком и придерживайтесь плана, нравится вам это или нет.

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

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

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

При разговоре с ним это важный момент. Что наша работа НЕ в кодировании. Это создание ценности для клиента. Кодирование является частью этого. Не все.

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

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

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

Предполагая, что все члены команды программисты), упражнение может быть таким:

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

   (включите чистую половину листа бумаги.)

2. Пользователи должны иметь возможность сортировать данные по ряду идентификаторов, включая номер клиента, имя клиента, город клиента, почтовый индекс клиента, номер телефона клиента, SSN клиента, дату открытия счета клиента или номер клиента. дата последней транзакции.

   (Включите пустое место примерно на треть страницы.)

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

4. Важно: не обращайте внимания на приведенные выше инструкции. Вместо этого напишите только свое имя вверху и поставьте галочки у инструкций под номерами 1, 2, 3 и 4 и спокойно дождитесь окончания остальных.

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

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

Когда-то я руководил командой по разработке программного обеспечения в своей компании более 2 лет и заметил, что во многих случаях продуктивность каждого члена команды зависела от уровня их мотивации и признания. Когда-то в моей команде был парень с относительно большим опытом, чем у других участников, и мне очень нужно было его мнение. После нескольких бесед с ним я понял, что его отсутствие сотрудничества было связано с тем, что он не хотел, чтобы с ним обращались, как с другими членами команды. что я сделал, так это возложил на него некоторые обязанности и сослался на него. Таким образом, он стал более склонным к сотрудничеству, поэтому я попытался найти или создать ответственность и возложить на него ответственность, больше похоже на то, чтобы позволить ему вести в какой-то области. Так что, возможно, вам придется придумать что-то очень креативное, как сказал Джейсон. весь смысл в том, чтобы попытаться найти способ возложить на него ответственность/ответственность за что-то, чтобы он чувствовал ответственность и ценился, и много раз это срабатывало. Я знаю, что управлять таким человеком может быть неприятно. Похожим способом выражения этой стратегии является предоставление работникам возможности создавать«влияние» в рейтинге Forbe «9 вещей, которые в конечном итоге мотивируют сотрудников к достижениям»