Случай из жизни…
Приведу показательный пример из своей практики, который и стал «триггером», почему эта проблематика возникла.
Когда я пришел на работу в новую организацию, начал вникать в организацию процесса, некоторые дамы фертильного возраста начали уходить в декрет (может для того, чтобы не сократили, может совпадение). Поняв, в чем заключаются функции одной из таких сотрудниц, я решил, что 50% ее работы можно автоматизировать, а остальное попросту не делать.
В том же подразделении был и есть один опытный и «политически грамотный» сотрудник. Назовем его Сан Саныч, чтобы никто не догадался. Очень много разговоров о важности и сложности исполняемой им работы, но по факту как в кабинет не зайдешь – всегда в интернет-браузере.
Я ему решил поручить автоматизацию работы уходящей в декрет девушки. Он долго сопротивлялся, доказывал, что у него нет ни минуты свободного времени, хлопал дверью, но выгрузка интернет-трафика компьютера сделала его более договороспособным. В общем, он согласился.
Я ему делегировал задачу по разработке техзадания для айтишников на необходимые объекты учетной системы. Вкратце рассказал свое видение программного решения.
«Все понятно, я продумаю мелочи и ТЗ подготовлю, с программистами отработаю», – был его ответ.
Проходит неделя, мы собираемся с айтишниками, они показывают прототип решения. И оно выглядит кардинально не так, как я предполагал и излагал Сан Санычу. Тут я задаю вопрос, почему так?
«Я подумал, что вы в этом вопросе не глубоко разобрались, поэтому решил, что нужно сделать по-другому», – заключил Саныч.
Слово за слово. И я начал воспитательную работу, разъяснив свое видение уровня организации подразделения, компетенций некоторых сотрудников и дисциплины. Далее сам объяснил программистам, что я хочу и велел все переделать.
Проходит еще неделя. В конференц-зале те же, что и неделей ранее. Айтишники показывают измененную разработку, меня она устраивает. Саныч молчит.
Разработку устанавливают в эксплуатацию.
Проходит еще неделя, я звоню Сан Санычу, прошу срочно отчет по результатам месяца.
«Нужно пару дней, чтобы собрать», – отвечает он вкрадчиво.
«Может быть пару минут, чтобы кнопку нажать», – иронизирую я.
«Те отчеты, которые программисты написали, дают неправильные данные, я только вчера это обнаружил, поэтому быстро не получится».
Далее я выслушиваю от генерального «благие» слова про «мою» автоматизацию и так далее.
Занавес.
Что я сделал не так?
Чему меня научил опытный Сан Саныч? Какие я допустил ошибки при «жесткой» отмене решения подчиненного относительно порученного ему задания?
Ошибка первая – забрал на себя ответственность за результат делегированной ему задачи. Возникли негативные последствия, а предъявить что-то человеку я не могу. К тому же, если так делать постоянно, то подчиненный скорее всего привыкнет возвращать своих «обезьянок».
Ошибка вторая – это удар по репутации и экспертности Сан Саныча. Я устроил ему разнос на глазах у других коллег, у которых он пользовался авторитетом. А отмена решений происходит часто прилюдно и сопровождается негативной окраской. Он это запомнил и отомстил.
Ошибка третья – мне нужно было понимать, что я могу не обладать всей полнотой информации, когда считаю, что решение, которое я отменяю неправильное. Если я доверил и делегировал задачу или функцию человеку с определенными навыками и знаниями, то, скорее всего, он умеет и знает побольше моего. Так и произошло. Во-первых, я не разобрался в наличии результата по доработке системы в первом варианте, сделав отрицательный вывод только потому, что она работала не так, как я предполагал. А во-вторых, я не учел ряд моментов, получив в результате нерабочий продукт.
Три способа «мягкой» отмены решений подчиненных
Как же быть в таких ситуациях? Ведь порой мы понимаем, если согласимся с решением, то оно может создать угрозу или привести к убыткам.
Сначала отменять «мягко». «Мягкой» отменой я называю такую отмену решения, при которой подчиненный сам его пересматривает и отвечает за него.
Размышляя и практикуя, я выработал три способа «мягкой» отмены решений.
Способ 1: мы уверены, что решение неправильное
Такая уверенность может строиться на чем угодно. Например, документация, информация, опыт и т. д. В этом случае достаточно сказать сотруднику, чтобы он еще раз перепроверил свои выводы, посмотрел там-то, поговорил с тем-то, почитал то-то. В большинстве случаев это срабатывает, если перед нами не идиот. Если мы делегировали работу идиоту, то вопрос применения способов «мягкой» отмены отпадает.
Способ 2: мы не согласны с решением, но есть сомнения, что сами правы
Самое лучшее, что можно в такой ситуации сделать, это задавать вопросы, уточняющие, разъясняющие и описывающие, почему человек принял такое решение. Получаем все вводные и определяемся как бы мы поступили. Если что-то не учтено, спрашиваем, учел ли это сотрудник. В результате либо мы соглашаемся, либо смотри пункт номер один.
Способ 3: мы не знаем правильное решение или нет, но что-то боязно
Такая ситуация может сложиться, если мы не погружены в тему или не хотим погружаться, а также, если после использования предыдущего способа, получили ответы на вопросы, но представленные аргументы нас полностью не убедили.
Я даю возможность ошибиться. Лучше всего выделить небольшой «полигончик» для эксперимента, чтобы потери в случае ошибочного решения были незначительными. Опять-таки, если тема провалится и сотрудник не идиот, то он сам от такого решения откажется.
Если человек устойчиво принимает неверные решения по делегированному кругу вопросов, значит, он не на своем месте. Вариант в таком случае «полумягкий» – передать задачу другому исполнителю.
Что важнее: результат или способ его достижения
Хотелось бы обратить внимание еще на один важный аспект. Достаточно часто я встречаюсь с людьми другого образа мыслей и стилей работы. Какая проблема? Их решения эффективные, но они отличаются от вашего представления. В итоге задача выполняется, но по-другому. У меня это вызывает дискомфорт. Возможно от того, что я не могу контролировать ход выполнения работы, во-вторых, не понимаю, как может получиться результат.
И получается так, с одной стороны, человек показывает результат, а с другой, не достигает его тем способом, который представляете себе вы. Казалось бы, забирать задачи у такого человека нелогично, он же справляется. Универсального ответа здесь нет. Либо смириться, либо поменять без потери эффективности решений, конечно же. Я стараюсь нанимать людей, близких по стилю. Для меня важен комфорт и понимание.
Чем все закончилось
Возвращаясь к истории, с которой я начал, как она закончилась, и как я должен был бы поступить?
Сан Саныч в итоге благополучно «слился» с этой темы, я поручил ее более загруженному подчиненному, он выявил недочеты в программе, айтишники их устранили за день, и все заработало как надо.
То есть моя схема была правильная. Но, с учетом всех обстоятельств и наличия альтернативного мнения более опытного сотрудника, я должен был воспользоваться вторым способом.
Скорее всего, если бы я попросил изложить мне логику иного решения, Сан Саныч бы мне все раскидал, и, возможно, оно тоже достигало поставленных целей. Либо он утонул бы в неправильных суждениях, и сам бы это понял. А далее, либо я был уверен в его схеме, либо он пошел бы исправлять свои ошибки. Но, вряд ли «слился» бы.
Сейчас меня перевели в другое подразделение. А с Санычем мучается новый руководитель, которому я не спешу раскрывать свои секреты делегирования.
Читайте также:
Александр, а как быть с ситуацией когда вы вообще не понимаете как решать вопрос? Но краем мозга понимаете, что то что делает Ваш подчиненный - не туда. А еще обычно цейтнот, надо было все еще вчера? Вы отменяете (приостанавливаете) решение сотрудника, если не сомневаетесь в его компетенции? Если да, то как? Даете возможность ошибиться?
Хоть вопрос и к Александру, отвечу за него или вместе с ним. Да. Даю возможность, но не ошибиться, а реализоваться ситуации. Тем более, как вы говорите, вы сами не знаете, как нужно. Вы делегировали задачу, дайте возможность сотруднику проявить себя. Тем более, речь идет, как я понял, о "старожиле".
Все эти цейтноты, и "надо было вчера" - это все существует только в головах менеджеров - отвлекающий фактор, к реальности не имеющий никакого отношения. Те люди, которые создают прибыль вашей компании, даже не подозревают о вашем существовании и что бы вы не решили, на них это никак не повлияет. Вот, например, "Саныч", судя по всему, это прекрасно знает.
Там, где " передний край" разработок, там и вопросы ставятся и решаются по другому. И, кстати, "Саныча" вы там тоже не встретите.
По крайней мере, мне сейчас так видится эта ситуация. Со всем уважением.
Боюсь, он свое насиженное место никому не отдаст)
Да, это правда. Давно и свою работу знает хорошо. И справляется с ней быстро. Некоторые другие,возможно, отпахивали в поте лица на его участке.
Мне кажется "Санычи" есть везде. Всегда кто-то пашет больше, а кто-то меньше. Не всегда руководитель это может заметить.
Но с другой стороны, Антон (я тоже не сильно далек от разработки ПО), такая ситуация. У Вас наверняка в команде есть сильные и опытные прогеры (назовем их зубрами), а есть молодняк и прочие (падаваны). Между ними большая разница как по эффективности, так и в зарплате. Согласитесь, что если зубр будет работать по 4-5 часов в день (а тяжелой мозговой работы больше выгрести сложно), то этот результат будет в 10 раз ценнее (и дороже), чем интенсивный 8ми часовой труд падавана. И Вы вряд ли уволите зубра. Иначе останетесь с одними падаванами.
В умственной работе в отличие от физической, основным критерием является эффективность, а не напряженность.
Ну вот - я же говорю, что он чей-то протеже, раз компания не способна его уволить
Блокбастер "Дожить до пенсионного возраста".В главной роли - Саныч.
Наверное, сильно не ошибусь, если скажу что напряженность работы не падает с квалификацией. Я бы даже сказал, скорее наоборот.
Эффективность, в данном случае - мультипликатор.
Так вот и уволить же не за что)
За безделье у вас не увольняют?
А где увольняют?
Насколько я знаю, ни в одном трудовом законодательстве нет такой статьи. А свои все должностные он выполняет.