• Кейс “Какой же ты руководитель, если код не пишешь?”

    Posted on September 3rd, 2010 Александр Орлов 40 comments

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

    Кейс “Какой же ты руководитель, если код не пишешь?”

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

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

    И вот прошло 4 года.

    В команде уже 12 человек. Среди них один менеджер и один team lead. Пришло время делить команду.Выбирая, кого же сделать вторым team lead-ом, и здешние руководители, и менеджеры со стороны заказчика, с которыми я довольно тесно работал все эти годы, остановились на мне.

    Получил под опеку трех сотрудников: двое – разработчики среднего уровня, один – старший (и по уровню и по годам), Слава.Я взялся за дело с большим энтузиазмом, судя по первым отзывам, недовольных не было. На выполнение первой задачи нам отвели 3-4 месяца, учтя необходимость для всех привыкнуть к плотной работе друг с другом, а мне научиться сочетать новые менеджерские обязанности с обязанностями разработчика.

    Через месяц со стороны заказчика поступила заявка на мое участие в Proof of Concept проекте с командировкой в США на два месяца. Т.е. на это время для команды я становился только руководителем и участвовать в разработке не имел возможности. Мне прямо сказали – “там ты будешь только руководить, разработкой заниматься будешь только здесь.”

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

    Одним утром, придя на работу, я получил письмо от одного из ребят с просьбой объяснить что-то по дизайну разрабатываемого модуля. Прикинул, что успею разобраться и помочь, потратил около часа на выяснение деталей и дал подробный ответ. В ответном письме мне сообщили, что Слава уже все объяснил. Дело в том, что он был включен в “СС” и, как и я, поспешил ответить на поставленный мне вопрос, но я был исключен из переписки.

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

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

    За этим последовали серьезные разговоры с ним и с моей стороны, и со стороны обоих руководителей.Мне он сказал – “Не можешь писать в рабочее время, пиши по ночам. Я не считаю тебя своим руководителем.”
    Похоже было, что только объяснение непривлекательности этого поступка заставило его слегка остыть.В итоге, руководство моей командой взял на себя наш менеджер проекта, я на 100% ушел в РОС проект до его завершения, но команду назад так и не получил.

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

    А вопросы вот какие – Что нужно делать, чтобы не попадать в подобные ситуации? В чем были мои ошибки? Как быть, если все же подобное случается?

    P.S. Хочешь разобрать свой кейс? Присылай его на info@happy-pm.com !

     

    40 responses to “Кейс “Какой же ты руководитель, если код не пишешь?””

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

    2. Автор кейса to linker:
      “Собрать-пообщаться-объяснить”
      Что-то подобное и было сделано. Все были проинформированы, часть обязанностей легла на Славу. Однако многие вопросы проходили через меня, знающего дизайн в деталях, с “СС” на Славу, который все же занимался больше разработкой, а не руководством.
      “Расставаться?”
      На тот момент у меня не было таких полномочий. Да и не отпустили бы его так легко, как специалист, он очень хорош.

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

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

    5. ”Я этого делать не собираюсь. Не считаю тебя team lead-ом, т.к. человек на такой позиции должен писать хоть строчку кода в день, а ты не пишешь ничего.”
      Ну и ответить на такое письмо в том-же духе: “Ты – быдлокодер, сиди и пырься в код! А вопросы дизайна прошу всех решать исключительно со мной.” :)

    6. To starina_bz:
      Такой ответ, в случае если сотрудник иммет меньший вес в компании, чем его руководитель, только подтолкнет его к уходу. А это, думаю, крайний способ решения подобных ситуаций.

    7. На это я получил ответ от Славы с “СС” на всю команду, наше и заказчика руководство, которого я никак не ожидал.”Я этого делать не собираюсь. Не считаю тебя team lead-ом, т.к. человек на такой позиции должен писать хоть строчку кода в день, а ты не пишешь ничего.”

      Человек выносит сор за рамки команды, как с ним еще поступить можно, если после всех объяснений он не понимает?

    8. Register For This Site

      > Что нужно делать, чтобы не попадать в подобные ситуации?

      Как мне представляется, здесь затруднительно что-то сделать заранее. То есть конечно, было бы здорово “подсыпать” заранее “соломки” в нужном месте и не подскользнуться.

      Здесь если и мог кто-то что-то сделать (и должен был) – так это тот, кто “пообещал руководящую позицию в перспективе”. За такие обещания необходимо отвечать (то есть буквально “отвечать за базар”). Возможно, тот кто пообещал, обещает это всем и не помнит, кому и чего он обещал. В обоих случаях – забыл этот “кто-то” или “забил” – выглядит не очень красиво.

      > В чем были мои ошибки?

      На мой взгляд, ошибок не было.

      > Как быть, если все же подобное случается?

      Разруливать по факту, как собственно и было сделано в описанном случае.

    9. Ну, а если серьёзно, то о том, что “ему пообещали руководящую позицию в перспективе” надо было узнавать раньше, а не потом, когда уже всё потеряно и конфликт на основе пересекающихся амбиций двух человек уже произошёл (это в тему о нобходимости проведения встреч один-на-один ;) ).
      Из кейса не совсем понятно, чем руководствовался автор, когда послал письмо всей команде с требованием не исключать его из переписки?
      Если автор просто хотел быть в курсе происходящего на проекте и хотел принимать удалённое участие в решениях, касательно дизайна модуля, то надо было так и объяснить это Славе приватным письмом, а не выносить сразу-же приказное решение для всей команды (если “т.к. я – team lead и о наших успехах спрашивают и будут спрашивать именно меня” – это дословная цитата из письма, то не только Слава и два остальных разработчика должны задуматься о перспективах под руководством такого тимлида).
      Если-же, автор хотел управлять командой в стиле “Ни одна тупая скотина не может закоммитить код в хранилище пока лично я его не проревьюил!”, то он поступил абсолютно правильно :) Со Славой вместе им всё равно не сработаться.
      А теперь, внимание правильный ответ :)
      На время поездки в Америку административное управление командой надо было поручить менеджеру, при техническом лидерстве со стороны Славы + совещательном /согласовательном участии в вопросах проекта, дизайна и пр. со стороны автора. Иначе и в POC-проекте автор работаьь не сможет в полную силу и оставшихся здесь будет только тормозить.

    10. Register For This Site

      2starina_bz: такой ответ (который является хамским) покажет несостоятельность топикстартера как руководителя команды. Что вряд ли входит в его планы ;)

    11. Register For This Site

      2 linker September 3rd, 2010 at 12:54

      > Человек выносит сор за рамки команды, как с ним еще поступить можно, если после всех объяснений он не понимает?

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

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

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

    12. 2 starina_bz:
      “Из кейса не совсем понятно, чем руководствовался автор, когда послал письмо всей команде с требованием не исключать его из переписки?”
      Это была вполне обоснованная просьба. Т.к. руководство командой и отчет о достигнутых результатах для меня никто не отменял. Т.е. каждое мое утро начиналось с этого вопроса.
      Я не сторонник приказного порядка и тона в работе с людьми, хоть иногда это и необходимо.
      С предложенным решением от части согласен, только причин для торможения команды не вижу. Какой бы подход в руководстве ни был выбран, время на обновление статуса тратится всегда.

    13. 2Alx: “Это была вполне обоснованная просьба. Т.к. руководство командой и отчет о достигнутых результатах для меня никто не отменял”
      Тогда так и надо было озвучить свои ожидания команде и контролировать результат. Утрируя: “каждое утро в 9:00 у меня в почте должно быть письмо со статус-репортом, какие результаты достигнуты, какие модули разработаны, сколько SLOC-ов закоммичено и т.д.” (ну или как вы там результат измеряете?).
      А в описанном кейсе, как мне показалось, ты свалился в банальный микроменеджмент, что и не понравилось Славе (хотя его реакция была совсем неадекватной ИМХО). Если ещё учитывать низкую эффективность коммуникаций по почте между двумя разными континентами с разными часовыми поясами, то согласование каждого архитектурного пука с тобой, занятым при этом на POC и будет самой главной преградой на пути эффективной работы команды.

    14. 2 starina_bz:
      Согласен.
      Хоть я и не могу сейчас восстановить дословно текст письма, но сходство с предложенным было.
      Как раз в микроменеджмент старался и не свалиться, и так работы хватало на РОС. Как уже говорил, очень многое перевесил на Славу. Но вопросы ко мне продолжали поступать.
      Как и написано в самом кейсе “отвечал на любые вопросы, либо находил и просил помочь того, кто мог ответить”. Можно сказать, в основном консультировал при необходимости и принимал отчеты о результатах, чтобы сам мог отчитаться. Ни о каких согласованиях речь не шла вообще.

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

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

    15. Полностью согласен с выводом, что с самого начала нужно было более четко сформулировать и донести до всех членов команды расстановку сил, ответственностей и приоритетов, так же определить принципы коммуникации.
      Однако помогло бы ли это избежать ответа “Ты не пишешь ничего ни днем ни ночью, значит ты и не тимлид”?

    16. 2 Alx
      Тогда самая главная проблема, что вы со Славой так и не договорились о том, кто какие вопросы решает (хотя то, что Слава при ответе на письмо не поставил тебя в СС, характеризует его далеко не с самой лучшей стороны).
      Я, конечно, понимаю, что ты можешь “отвечать на любые вопросы, либо находить и просить помочь того, кто мог ответить”, но при этом не надо забывать синхронизировать свои усилия с другими членами команды ;)
      В GTD есть замечательный совет насчёт обработки почты -каждое поступающее задание можно:
      а) выполнить незамедлительно (если оно не занимает более 2-ух минут)
      б) поставить в одну из очередей
      в) делегировать.
      Судя по кейсу написание ответа заняло у тебя приличное время. В твоём случае надо было либо сразу делегировать ответ Славе (ты-ж тимлид ;) ), либо тут-же уточнить, кто из вас будет разбираться с этим вопросом (типа, “Слава, я могу ответиь на этот вопрос, но через полдня. Если можешь раньше – ответь ты.”)
      А вообще переписка в почте – не самый лучший выбор для вашего случая. Юзайте общий чат в скайпе :)

      “Однако помогло бы ли это избежать ответа “Ты не пишешь ничего ни днем ни ночью, значит ты и не тимлид”?”
      Да это вообще детский сад какой-то, не обращай внимания :) Слава просто нашёл первый попавшийся повод.

      P.S. Ну и немного оффтоп, только косвенно относящийся к кейсу: оставлять тебя, сидящего на другом континенте, проксей между командой и менеджером или заказчиком (“контроль прогресса, отчетность, корректировка действий в соответствии с приоритетами”) на проекте длящимся 3-4 месяца, из которых ты 2 месяца находишься вдали от команды, стоило только в том случае, если к тебе имеется какое персональное доверие менеджера/заказчика и ни кого другого в этой роли они не приемлят.

    17. 2 starina_bz:
      Это ж из моего раннего опыта :) Этой истории уже года три исполнилось :)
      Вот и получилось – ко мне пришло письмо, адресованное мне, и разобраться с ним я считаю своей прямейшей, важнейшей и первоочередной обязанностью.. был мал и глуп :)

      Оффтопом на оффтоп – спасибо:)

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

    18. Лично на мой взгляд в сложившейся ситуации лучше было посмотреть диф в сорсконтроле чем устраивать дрязги. По своему Слава был прав, ждать ответа от человека с 8-10 часовой разницей по времени немного глупо. На мой взгляд на время поездки ф-ии тимлида должны были быть полностью переданы Славе со всеми полномочиями и ответственностью(!).
      А на счет копии в CC то лучше для команды сделать отдельный DL и стараться чтобы вся информация постилась именно туда. Это психологически облегчает ф-ии отчетности и позволяет всем заинтересованным лицам быть в курсе.

    19. Неправильно построена система общения в команде.

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

    20. Тут надо было сделать несколько шагов:
      1. Назначить Славу формальным тим лидом на период Вашего отсутствия.
      2. Вы должны были быть на пересечении комуникационных покотов в команде
      3. Митинги со Славой каждий день или немного реже
      4. Обяснить Славе его неправоту нужно было в приват, а не на всю команду (хвалить – публично, воспитывать – лично)
      5. После писма Славы набо было попрощатся

    21. Основы менеджмента. Врагов (антилидеров) надо ликвидировать. Любыми способами. Иначе получается результат из кейса. Необходимо было отстранить Славу от выполнения работы, перевести в рядовые разработчики или убрать в сторону, на индивидуальную работу, депремировать, публично дискредитировать в глазах команды (“наказан за неспортивное поведение”). Предвосхищая возражения, напоминаю, что устанавливать и поддерживать правила работы (в т.ч., карать за неисполнение) – основная задача РП на любом проекте.

    22. Register For This Site

      2 covrom September 5th, 2010 at 09:29

      > устанавливать и поддерживать правила работы (в т.ч., карать за неисполнение) – основная задача РП на любом проекте.

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

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

    23. Как всегда, проблема в менеджере :)

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

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

      Таким образом, можно посоветовать нашему герою вначале решить, кем он себя видит и двигаться в ту сторону. Если невозможно объявить всем о своем выборе right now, то можно, для начала, хотя бы не принимать близко к сердцу обвинения в некомпетентности в той области, от которой он отказался. И медленно, но неуклонно отпихивать от себя обязанности, которые не ведут его к выбранной цели. Если цена за выбор направления “разработчик” – интересная командировка в США, то надо заплатить эту цену.

    24. Не очень понятна расстановка сил в этом кейсе. Team lead в данной организации, судя по всему, не является прямым начальником команды (я делаю этот вывод по фразе «со стороны обоих руководителей»). В таком раскладе менеджер лишается формального кнута (а также части авторитета), и для решения конфликтных ситуация должен иметь серьезную поддержку со стороны своего руководства, а также руководителей людей, вовлеченных в проект. В нашем случае с поддержкой явно было туго, и «нарушителя спокойствия» сначала не поставили на место за откровенно хамское отношение, а потом и самого team lead’а отодвинули от руководства проектом. Вывод – тылы нужно прикрывать заранее, а не когда конфликт уже разразился.

      Вторая ошибка тимлида – покинуть команду на два месяца ради POC. Мотивация понятна – командировка в Штаты, интересный перспективный проект, fun, experience. Но… менеджер должен руководить, а ездить в командировки – программисты, с этим нужно смириться с самого начала, когда тебя повышают.

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

    25. Не согласен с определением Славы как «смутьяна» (или “Project Killer-a”, если говорить научно :)
      В проекте ВСЕГДА есть только один руководитель. Он может быть реальным, а может быть и всего лишь официальным, по бумажкам, а реально руководит проектом другой человек. Если реальный и официальный руководители проекта – разные люди, существует почти полная гарантия того, что проект провалится. Из-за описанных в кейсе эксцессов. Хорошо, что дело закончилось именно так, как описано в кейсе. А если бы «официальный» менеджер не махнул рукой, сказав нечто вроде «Бог тебе судья», а стал бы качать права? Проиграйте этот сценарий и подумайте, что получится.

      Слава поступил достаточно честно и пошел на риск, на мой взгляд, не из-за желания занять подвернувшееся теплое место, а из-за искреннего беспокойства за судьбу проекта, потому что увидел, что замедленное реагирование на запросы сваливает проект в штопор. Хотя форма, в которой он это сделал…мда.

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

    26. Как Вам такой ответ по мейлу после обвинения в «ни строчки кода»:

      Да, Слава, ты прав. Я не пишу ни строчки кода для нашего проекта ни днем, и не готов заставить себя делать это и ночью. Я и сам не считаю себя тим-лидом. Я вынужден писать код на проекте заказчика и отчитываться по нашему проекту, в который я не добавил и строчки кода.
      Я уверен, что ты был бы лучшим тим лидом, ведь ты знаешь техническую сторону проекта лучше меня и всегда можешь объяснить самый сложный участок кода простым и доступным языком так, как это делают профессионалы.
      Заказчики уже привыкли к моим отчетам, на которые сейчас у меня не хватает времени в связи с моей загруженностью на другом проекте. Именно поэтому я и попросил тебя о составлении ежедневного отчета. Именно потому, что ты не только пишешь код, но и ориентируешься в проекте так, как никто другой. Сегодня ты отчитываешься передо мной, а в ближайшем будущем – напрямую перед заказчиком.
      Хотя, если такие ежедневные отчеты тебе в тягость, то я могу делать их и сам, как делал и раньше.

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

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

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

    28. Коллеги, заранее прошу прощения за то, что, возможно, прочитал не все предшествующие комментарии.

      Мне кажется, вопрос сводится к следующему. Руководитель должен иметь заместителя. При чем этот заместитель должен быть способен заменить руководителя на 90-95 процентов, а по оставшимся 5-10% делать следующее:
      – консультироваться с руководителем
      – консультироваться с высшим руководством

      Для заместителя заранее долджны быть определены эти проценты (т.е. его полномочия). В данном случае – перед поездкой.

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

      Если всё организовано правильно, то “рядовые сотрудники” вообще не должны беспокоить руководителя в командировке. Это должден делать только заместитель и высшее руководство.

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

      Конечно, полноценным заместителем может стать только человек, которому доверяет сам руководитель. Это к вопросу о том, как не попадать в такие ситуации. Насколько я понимаю, у автора кейса просто не было достаточно времени ни на то, чтобы выявить потенциальный конфликт, ни на то, чтобы воспитать заместителя.

    29. 2dz
      Прошу прощения, но исходя из вашего варианта оправдательного письма, кажется, что вы именно тот нарушитель спокойствия, который обвинил тим-лида, что тот не пишет код:)

      Фраза “Я и сам не считаю себя тим-лидом.” – вообще блеск.

    30. 2Diana

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

      ЗЫ: Как вы думаете, сколько раз слава бы перечитал это письмо, и что он бы подумал?

    31. 2 dz,

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

      Славу нужно поставить на место. Это поведение – хамство и провокация. Или выглядит, как хамство и провокация. Не думаю, что тут можно игнорировать или ждать, пока само пройдет. Пресечь такое поведение, посмотреть из-за чего, объяснить, почему так нельзя, посмотреть, как дальше пойдет комуникация. Возможно, и получится вырулить Славу, а нет – ну что ж, нужно расставаться. Иначе он будет занимать очень много энергии.

    32. А вообще,

      молодая команда + молодой менеджер + расстояние между ними = неизбежные проблемы.

      Из них сама большая – не поговорить лично в курилке.

    33. 2 Diana,

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

      А как бы вы пресекли поведение Славы в данном кейсе? Мне этот вариант очень интересен.

    34. [...] кейс “Какой же ты руководитель, если код не пишешь?” вызвал бурные обсуждения – 32 комментария. Это вам не [...]

    35. Я опущу, что нужно работать заранее с командой и т.д. и т.п. Итак, если все-таки случилось? Например, можно ответить письмом на всех, кто был в адресатах письма Славы:
      ——————-

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

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

      С уважением, …

    36. Спасибо. Такой вариант ответа действительно хорош. Я уверен, что будущий вариант решения кейса от Александра Орлова будет не многим отличатся от Вашего.

    37. 2 Diana Timoshenko

      Респект, хорошие слова.

      2 dz

      Я сегодня опубликовал свой разбор: http://www.happy-pm.com/blog/?p=5795

    38. [...] На суд читателей выставляется новый кейс от автора кейса “Какой же ты руководитель, если код не пишешь?”: [...]

    39. [...] кейс постоянного читателя Happy-PM.com, автора кейсов “Какой же ты руководитель, если код не пишешь?” и “Лидер сам по себе”. Ситуация настолько же [...]

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

      Ошибка была следующая…
      “Получил под опеку трех сотрудников”.
      Никогда не формируй команду из тех, кого дали! Избирательно, избирательно…
      Ты подложил мину себе под стул.

      Это было с одной стороны.

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

      Помнится мне, первый мой опыт.. один гавнюк меня подсидел, так вот, в бизнесе человек человеку волк, и это к сожалению норма. При неправильно выстроенной конфигурации команды, стоит хоть немного дать слабину, как тут же жди подставы.
      Иногда можно выявлять таким образом bugs в системе. Кто хочет – тот поймет, о чем я =)

    Leave a reply

    You must be logged in to post a comment.