Привет, меня зовут Вадим Карасев, я — руководитель группы разработки в команде KasperskyOS. Мои коллеги по «Лаборатории Касперского» недавно провели митап про карьерные ловушки тимлидов. Там в очередной раз подняли, на мой взгляд, достаточно острую проблему. Многие разработчики не хотят быть руководителями, потому что считают, что кодить будешь меньше, работа будет наполнена скучными управленческими обязанностями и все в таком духе. В итоге многие из тех, кто мог бы быть хорошим руководителем, не решаются даже попробовать.
На своем примере могу сказать, что это не так. Идти в руководство — логичный и захватывающий шаг.
В этой статье поговорим о стереотипе, будто переход из разработчика в руководители лишает человека интересных задач и карьерного развития. Разберу некоторые типовые ошибки начинающего (и не только) руководителя, приводящие к формированию этого впечатления. Постараюсь дать советы, на что смотреть, чтобы оценить ситуацию, и какие меры предпринять, чтобы жить стало «бодрее и веселее».
Свой опыт руководства я начал в компании, которая занималась программным обеспечением для анализа логистической поддержки. Из разработчика я сначала превратился в специалиста на все руки — взаимодействовал с заказчиком, разбирался с требованиями, а со временем начал организовывать полный цикл разработки в небольших командах по два-три человека.
На ступень неформального, а затем и формального руководителя я поднимался в нескольких компаниях. Работал с большими командами, в том числе распределенными между часовыми поясами и странами, а это накладывает определенные сложности, связанные с асинхронными коммуникациями и разным культурным кодом. Видел, как устроены процессы у коллег-руководителей. Проходил вместе с командой через различные внутрикорпоративные трансформации. И наконец, пришел в «Лабораторию Касперского» в статусе руководителя довольно крупной команды — 20 человек. И продолжаю расти вместе с командой. За год мы выросли более чем в два раза.
Путь получился длинный и интересный. И скука, о которой говорит стереотип, — скорее показатель того, что человек где-то ошибся, пытаясь выстроить свою работу как руководитель. Итак…
Классический пример, когда начинающий руководитель самостоятельно решает массу организационных вопросов, но продолжает заниматься техническими задачами в роли разработчика. Через некоторое время можно поймать себя на том, что ты сначала восемь часов помогаешь команде и занимаешься процессами, а потом еще восемь — разработкой. А ведь еще и поспать надо!
Конечно, до работы 16 часов в сутки редко доходит, но я специально утрировал. В такой ситуации становится ясно, что приоритеты расставлены неверно и надо перестраивать рабочие процессы — делегировать, выявлять проблемные места и исправлять их.
Как действовать в сложившейся ситуации — зависит от культуры компании, а также внутреннего устройства и размеров команды. Если с руководителем работает лишь пара человек, скорее всего вопросов о том, где взять время на написание кода, не возникнет. В командах из 10 или 100 сотрудников ответить на этот вопрос сложнее.
На мой взгляд, роль руководителя в некоторых аспектах напоминает системного администратора — со стороны кажется, что руководитель ничего не делает, но при этом все работает. Он уходит на месяц в отпуск, ему в это время никто не звонит, но все продолжает функционировать — все знают, к кому идти и кто может помочь ответить на вопрос.
Чтобы дело действительно обстояло таким образом, нужны правильно настроенные процессы, а это требует времени и сил. Когда с процессами все хорошо, можно найти время и на написание кода. Главное — желание. На своем пути я встречал специалистов, которые, помимо руководства командой в 50–100 человек, успевали еще и полноценные фичи в релиз выпускать без больших проблем и на конференциях выступать. С другой стороны, встречал и тех, кто с ростом команды до 10 человек переставал писать код совсем. Все зависит от личных предпочтений и личного выбора.
Сложность в том, что время на этот личный выбор освобождается не сразу. Переходя в статус менеджера, нужно себе честно признаться, что как минимум в «переходном» периоде кодить ты будешь меньше. Но это не навсегда. Вполне возможно в некотором объеме вернуться к разработке после того, как трансформация завершится.
Иные руководители могут сильно менять принятые в команде правила игры или вводить новые без оглядки на обратную реакцию. Особенно часто это бывает, когда новый лид приходит в уже сложившуюся команду. Стоит ли говорить, что подход «ломать через колено» может привести к проблемам?
Для команды любые изменения — стресс, поэтому действовать надо аккуратно. Все должно начинаться с рекогносцировки. Как я говорил выше, надо обратить внимание, на что уходит время команды.
У меня есть наглядный пример — мы сталкивались с этой ситуацией в «Лаборатории Касперского».
В нашей команде была синхронизационная встреча по понедельникам. К моменту моего прихода она стала занимать 2,5 часа вместо запланированного часа. На митинге присутствовало более 20 человек, и каждый хотел рассказать, чего хорошего он сделал за прошлую неделю, а с чем возникли проблемы. Несложно подсчитать, что 2,5 часа времени 20 человек — это больше человеко-недели (почти такой же мифической, как человеко-месяц). Это эквивалентно тому, что в команде становится на одного человека меньше.
Чтобы оптимизировать процесс, мы выделили ответственных по конкретным темам, которые проводили митинги на час с меньшим количеством людей, а потом приходили на общую синхронизационную встречу.
Изначально на этот общий митинг могли прийти все, кому интересно, но говорить могли только ответственные. И коллеги действительно слушали, задавали вопросы в чате. Со временем стало понятно, что проще разбирать вопросы на внутренних митингах. В итоге мы пришли к тому, что каждая подкоманда тратит около часа на внутренний митинг, а потом шесть человек тратят еще час на общую синхронизацию.
Это пример того, как мы плавно внедряли изменения, а также слушали и чувствовали обратную связь — старались, чтобы люди могли привыкнуть к новому порядку, и сразу оговаривали, что, если почувствуем нехватку коммуникации или что-то еще пойдет не так, вернемся к исходному варианту. И в процессе внедрения изменений у нас была понятная метрика — время, которое люди тратят на митинги. По итогам все ощутили на себе, что оно значительно сократилось, но просадки в производительности не произошло. Также не возникло проблем с коммуникациями.
Рекомендую придерживаться этой идеологии — мягкий подход, понятные метрики, открытый фидбэк и возможность сделать шаг назад. Никаких методологий ради методологий. Никакого «через колено». Внедрение фреймворков только с пониманием того, какую проблему решаем и что на выходе хотим получить. И нет разницы, новая команда перед вами или уже существующая. В новой, возможно, сопротивление изменениям будет меньше, но это не значит, что надо поменять сразу и все.
Вообще, это не всегда плохо — например, в консалтинге задачи часто стараются сводить «к предыдущей». Но это особый случай.
В управлении IT-проектами, с моей точки зрения, сложность управления проектом зависит от уровня зрелости процессов, самой команды и ее окружения. Одним из показателей, которые можно использовать для измерения, являются накладные расходы, management overhead (время, которое уходит на все, кроме непосредственно разработки, — договоренности, обсуждения, наем и т. п.). Даже огромный проект для руководителя может оказаться простым, если все хорошо работает, а его внимание нужно в отдельных крайних случаях.
Если вам не нравится, что проекты однотипные, нужны новые вызовы и возможности, можно поговорить о доступных вариантах со своим руководителем (хороший руководитель может и сам подвести к такой беседе). Лично я начал бы с попытки понять, откуда вообще появилась мысль, что стало скучно. Конечно, бывает так, что ты все настроил и процессы в проекте отлично работают и в результате тебе, как руководителю, нечем заняться. Но вполне вероятна и другая ситуация — когда человек теряет связь с реальностью. Ему кажется, что он молодец, все работает, а на самом деле команда (иногда вместе с проектом) катится в бездну.
Если все действительно хорошо работает, в контексте руководства есть несколько путей. Обозначим два из них.
Первый — это тиражирование, когда свои удачные практики переносятся в соседние команды или команды более высокого уровня.
Второй — другой проект, который может стать новым вызовом. Можно поговорить с руководителем и выбрать сферу, где вы будете наиболее полезны (но, уходя, не забыть оставить за собой всю документацию и человека, который подхватит команду).
Отчасти это зависит от компании и принятого в ней подхода, но менторинг, конечно, необходим. Это общеизвестная вещь — когда вы кого-то учите, вы прокачиваете собственные скиллы.
Когда только пришел в команду, мы с коллегами выстраивали не только технические процессы, но и коммуникации. Выделенные технологические лидеры учились подхватывать процессы работы с людьми (people management). И на этой стадии менторинг занимал процентов 70 моего времени, если не больше. Сейчас он занимает несколько меньшую долю.
Степень менторинга нужно чувствовать для каждого человека отдельно. Кому-то вопрос «как дела» покажется нормальной заинтересованностью положением дел, а кому-то — ненавистным микроменеджментом. Но в любом случае отличный способ узнать, хватает менторства или нет, да и в целом все ли идет хорошо, — разговаривать с людьми. Чтобы вовремя узнать о проблемах, в том числе о тех, которые вы и проблемами-то изначально не посчитали (а они на самом деле мешают работать). Плюс помогает давать фидбэк вовремя и честно.
Кстати, у нас в «Лаборатории Касперского» есть отдельное направление менторинга для самих руководителей. Помимо неформального общения с лидерами соседних отделов и теми, кто стоит на уровень выше, есть школа тимлидов, где в сжатом виде дается информация, которая будет полезна всем, кто претендует на управляющие должности. Мы стараемся, чтобы эту школу проходили все, кто уже руководит, а заодно и те, кому может быть интересен такой путь развития. Даже если потом эти люди не станут тимлидами, им это просто поможет лучше выстраивать коммуникации, работать с требованиями, зависимостями и сроками, понимать мотивацию свою и окружающих, а так же всесторонне развиваться.
Если говорить о конкретных советах для начинающих руководителей, то я рекомендую активно пользоваться календарем. Я заношу в Outlook все свои активности, включая «прочитать документ», «провести ревью кода» и т. п. Жестко бронирую слоты времени, когда их необходимо посвятить определенной работе, чтобы лишний раз не переключать контекст. В этот момент со мной не получится поговорить (за исключением каких-то действительно экстренных ситуаций, которые не могут ждать 30–60 минут).
В отношении команды стоит думать о capacity и планировании. Про это написана масса книг. Планы для двух-трех человек можно держать и на доске, понимая, где может быть отставание. А в команде из 50+ человек это невозможно. Необходимо более конкретное понимание, какие ресурсы доступны и что будет выталкиваться, если появляются незапланированные задачи. В идеале под них еще и буфер стоит оставлять.
А еще я уверен, что иметь один неидеальный процесс лучше, чем два-три очень классных. Чем больше подходов, тем сложнее с ними работать. Можно использовать любой удобный инструмент, но результат для обсуждения должен быть в таком виде, о каком изначально договорились.
Ходить на конференции полезно для вдохновения. Возможно, не каждый из докладов описывает что-то принципиально новое. Но там поднимаются темы, о которых вы могли раньше не думать, разбираются интересные паттерны. Впрочем, тут надо быть осторожным — классическая история, когда руководитель приезжает с конференции и начинает внедрять пять новых практик. Если возникнет такое желание, подумайте, какую проблему вы решаете и какими метриками будете контролировать качество решения.
На мой взгляд, на конференциях особенно полезны бизнес-игры, мастер-классы, воркшопы и неформальное общение. Обычно их не записывают, а там происходит интересное. Это интерактивные мероприятия, где больше общаешься с людьми, обсуждаешь или решаешь выдуманные или даже реальные кейсы.
А чтобы найти интересную тему для себя, стоит остановиться и разобраться, можно сделать 360-ревью, поговорить с руководителями и с коллегами по горизонтали, чтобы получить фидбэк и порефлексировать, в какую сторону стоит двигаться дальше.
Надеюсь, мой опыт поможет вам решиться на эксперимент с руководящей позицией или же вовремя вывернуть, если вы идете «не туда». И главное, если процессы в компании построены правильно, вы всегда сможете сделать шаг назад. За примерами далеко ходить не надо — у нас в команде был случай, когда сотрудник начал руководить, но понял, что ему это не нравится, и с общего согласия он вернулся на линейную позицию. Или, например, кейс участника митапа тимлидов, о котором я говорил в самом начале: Евгений Мацюк даже написал целую статью о том, как не попасть в карьерную ловушку тимлида.
К такому повороту событий должны быть готовы и команда, и сам начинающий руководитель, и его руководитель тоже. Если обсудить все на старте, последствия ошибки можно нивелировать как для команды, так и для сотрудника. И в целом это помогает создать среду, где люди не боятся пробовать и совершать ошибки.
На своем примере могу сказать, что это не так. Идти в руководство — логичный и захватывающий шаг.
В этой статье поговорим о стереотипе, будто переход из разработчика в руководители лишает человека интересных задач и карьерного развития. Разберу некоторые типовые ошибки начинающего (и не только) руководителя, приводящие к формированию этого впечатления. Постараюсь дать советы, на что смотреть, чтобы оценить ситуацию, и какие меры предпринять, чтобы жить стало «бодрее и веселее».
0b000. Немного о себе
Свой опыт руководства я начал в компании, которая занималась программным обеспечением для анализа логистической поддержки. Из разработчика я сначала превратился в специалиста на все руки — взаимодействовал с заказчиком, разбирался с требованиями, а со временем начал организовывать полный цикл разработки в небольших командах по два-три человека.
На ступень неформального, а затем и формального руководителя я поднимался в нескольких компаниях. Работал с большими командами, в том числе распределенными между часовыми поясами и странами, а это накладывает определенные сложности, связанные с асинхронными коммуникациями и разным культурным кодом. Видел, как устроены процессы у коллег-руководителей. Проходил вместе с командой через различные внутрикорпоративные трансформации. И наконец, пришел в «Лабораторию Касперского» в статусе руководителя довольно крупной команды — 20 человек. И продолжаю расти вместе с командой. За год мы выросли более чем в два раза.
Путь получился длинный и интересный. И скука, о которой говорит стереотип, — скорее показатель того, что человек где-то ошибся, пытаясь выстроить свою работу как руководитель. Итак…
0b001. Начинающий руководитель не перестраивает активности и их приоритеты или перестраивает их неправильно
Классический пример, когда начинающий руководитель самостоятельно решает массу организационных вопросов, но продолжает заниматься техническими задачами в роли разработчика. Через некоторое время можно поймать себя на том, что ты сначала восемь часов помогаешь команде и занимаешься процессами, а потом еще восемь — разработкой. А ведь еще и поспать надо!
Конечно, до работы 16 часов в сутки редко доходит, но я специально утрировал. В такой ситуации становится ясно, что приоритеты расставлены неверно и надо перестраивать рабочие процессы — делегировать, выявлять проблемные места и исправлять их.
Как действовать в сложившейся ситуации — зависит от культуры компании, а также внутреннего устройства и размеров команды. Если с руководителем работает лишь пара человек, скорее всего вопросов о том, где взять время на написание кода, не возникнет. В командах из 10 или 100 сотрудников ответить на этот вопрос сложнее.
На мой взгляд, роль руководителя в некоторых аспектах напоминает системного администратора — со стороны кажется, что руководитель ничего не делает, но при этом все работает. Он уходит на месяц в отпуск, ему в это время никто не звонит, но все продолжает функционировать — все знают, к кому идти и кто может помочь ответить на вопрос.
Чтобы дело действительно обстояло таким образом, нужны правильно настроенные процессы, а это требует времени и сил. Когда с процессами все хорошо, можно найти время и на написание кода. Главное — желание. На своем пути я встречал специалистов, которые, помимо руководства командой в 50–100 человек, успевали еще и полноценные фичи в релиз выпускать без больших проблем и на конференциях выступать. С другой стороны, встречал и тех, кто с ростом команды до 10 человек переставал писать код совсем. Все зависит от личных предпочтений и личного выбора.
Сложность в том, что время на этот личный выбор освобождается не сразу. Переходя в статус менеджера, нужно себе честно признаться, что как минимум в «переходном» периоде кодить ты будешь меньше. Но это не навсегда. Вполне возможно в некотором объеме вернуться к разработке после того, как трансформация завершится.
Иные руководители могут сильно менять принятые в команде правила игры или вводить новые без оглядки на обратную реакцию. Особенно часто это бывает, когда новый лид приходит в уже сложившуюся команду. Стоит ли говорить, что подход «ломать через колено» может привести к проблемам?
Для команды любые изменения — стресс, поэтому действовать надо аккуратно. Все должно начинаться с рекогносцировки. Как я говорил выше, надо обратить внимание, на что уходит время команды.
Личный совет
У меня есть наглядный пример — мы сталкивались с этой ситуацией в «Лаборатории Касперского».
В нашей команде была синхронизационная встреча по понедельникам. К моменту моего прихода она стала занимать 2,5 часа вместо запланированного часа. На митинге присутствовало более 20 человек, и каждый хотел рассказать, чего хорошего он сделал за прошлую неделю, а с чем возникли проблемы. Несложно подсчитать, что 2,5 часа времени 20 человек — это больше человеко-недели (почти такой же мифической, как человеко-месяц). Это эквивалентно тому, что в команде становится на одного человека меньше.
Чтобы оптимизировать процесс, мы выделили ответственных по конкретным темам, которые проводили митинги на час с меньшим количеством людей, а потом приходили на общую синхронизационную встречу.
Изначально на этот общий митинг могли прийти все, кому интересно, но говорить могли только ответственные. И коллеги действительно слушали, задавали вопросы в чате. Со временем стало понятно, что проще разбирать вопросы на внутренних митингах. В итоге мы пришли к тому, что каждая подкоманда тратит около часа на внутренний митинг, а потом шесть человек тратят еще час на общую синхронизацию.
Это пример того, как мы плавно внедряли изменения, а также слушали и чувствовали обратную связь — старались, чтобы люди могли привыкнуть к новому порядку, и сразу оговаривали, что, если почувствуем нехватку коммуникации или что-то еще пойдет не так, вернемся к исходному варианту. И в процессе внедрения изменений у нас была понятная метрика — время, которое люди тратят на митинги. По итогам все ощутили на себе, что оно значительно сократилось, но просадки в производительности не произошло. Также не возникло проблем с коммуникациями.
Рекомендую придерживаться этой идеологии — мягкий подход, понятные метрики, открытый фидбэк и возможность сделать шаг назад. Никаких методологий ради методологий. Никакого «через колено». Внедрение фреймворков только с пониманием того, какую проблему решаем и что на выходе хотим получить. И нет разницы, новая команда перед вами или уже существующая. В новой, возможно, сопротивление изменениям будет меньше, но это не значит, что надо поменять сразу и все.
0b010. Руководитель не растет в сложности проектов, останавливается на одном уровне, работает как на конвейере и увязает в рутине
Вообще, это не всегда плохо — например, в консалтинге задачи часто стараются сводить «к предыдущей». Но это особый случай.
В управлении IT-проектами, с моей точки зрения, сложность управления проектом зависит от уровня зрелости процессов, самой команды и ее окружения. Одним из показателей, которые можно использовать для измерения, являются накладные расходы, management overhead (время, которое уходит на все, кроме непосредственно разработки, — договоренности, обсуждения, наем и т. п.). Даже огромный проект для руководителя может оказаться простым, если все хорошо работает, а его внимание нужно в отдельных крайних случаях.
Личный совет
Если вам не нравится, что проекты однотипные, нужны новые вызовы и возможности, можно поговорить о доступных вариантах со своим руководителем (хороший руководитель может и сам подвести к такой беседе). Лично я начал бы с попытки понять, откуда вообще появилась мысль, что стало скучно. Конечно, бывает так, что ты все настроил и процессы в проекте отлично работают и в результате тебе, как руководителю, нечем заняться. Но вполне вероятна и другая ситуация — когда человек теряет связь с реальностью. Ему кажется, что он молодец, все работает, а на самом деле команда (иногда вместе с проектом) катится в бездну.
Если все действительно хорошо работает, в контексте руководства есть несколько путей. Обозначим два из них.
Первый — это тиражирование, когда свои удачные практики переносятся в соседние команды или команды более высокого уровня.
Второй — другой проект, который может стать новым вызовом. Можно поговорить с руководителем и выбрать сферу, где вы будете наиболее полезны (но, уходя, не забыть оставить за собой всю документацию и человека, который подхватит команду).
0b011. Руководитель не менторит свою команду или менторит ее недостаточно хорошо, не получает от нее обратную связь
Отчасти это зависит от компании и принятого в ней подхода, но менторинг, конечно, необходим. Это общеизвестная вещь — когда вы кого-то учите, вы прокачиваете собственные скиллы.
Когда только пришел в команду, мы с коллегами выстраивали не только технические процессы, но и коммуникации. Выделенные технологические лидеры учились подхватывать процессы работы с людьми (people management). И на этой стадии менторинг занимал процентов 70 моего времени, если не больше. Сейчас он занимает несколько меньшую долю.
Степень менторинга нужно чувствовать для каждого человека отдельно. Кому-то вопрос «как дела» покажется нормальной заинтересованностью положением дел, а кому-то — ненавистным микроменеджментом. Но в любом случае отличный способ узнать, хватает менторства или нет, да и в целом все ли идет хорошо, — разговаривать с людьми. Чтобы вовремя узнать о проблемах, в том числе о тех, которые вы и проблемами-то изначально не посчитали (а они на самом деле мешают работать). Плюс помогает давать фидбэк вовремя и честно.
Кстати, у нас в «Лаборатории Касперского» есть отдельное направление менторинга для самих руководителей. Помимо неформального общения с лидерами соседних отделов и теми, кто стоит на уровень выше, есть школа тимлидов, где в сжатом виде дается информация, которая будет полезна всем, кто претендует на управляющие должности. Мы стараемся, чтобы эту школу проходили все, кто уже руководит, а заодно и те, кому может быть интересен такой путь развития. Даже если потом эти люди не станут тимлидами, им это просто поможет лучше выстраивать коммуникации, работать с требованиями, зависимостями и сроками, понимать мотивацию свою и окружающих, а так же всесторонне развиваться.
Личный совет
Если говорить о конкретных советах для начинающих руководителей, то я рекомендую активно пользоваться календарем. Я заношу в Outlook все свои активности, включая «прочитать документ», «провести ревью кода» и т. п. Жестко бронирую слоты времени, когда их необходимо посвятить определенной работе, чтобы лишний раз не переключать контекст. В этот момент со мной не получится поговорить (за исключением каких-то действительно экстренных ситуаций, которые не могут ждать 30–60 минут).
В отношении команды стоит думать о capacity и планировании. Про это написана масса книг. Планы для двух-трех человек можно держать и на доске, понимая, где может быть отставание. А в команде из 50+ человек это невозможно. Необходимо более конкретное понимание, какие ресурсы доступны и что будет выталкиваться, если появляются незапланированные задачи. В идеале под них еще и буфер стоит оставлять.
А еще я уверен, что иметь один неидеальный процесс лучше, чем два-три очень классных. Чем больше подходов, тем сложнее с ними работать. Можно использовать любой удобный инструмент, но результат для обсуждения должен быть в таком виде, о каком изначально договорились.
0b100. Руководитель делает все вышеперечисленное, но не развивается за счет чужого опыта — не ходит на конференции или не выступает сам
Ходить на конференции полезно для вдохновения. Возможно, не каждый из докладов описывает что-то принципиально новое. Но там поднимаются темы, о которых вы могли раньше не думать, разбираются интересные паттерны. Впрочем, тут надо быть осторожным — классическая история, когда руководитель приезжает с конференции и начинает внедрять пять новых практик. Если возникнет такое желание, подумайте, какую проблему вы решаете и какими метриками будете контролировать качество решения.
На мой взгляд, на конференциях особенно полезны бизнес-игры, мастер-классы, воркшопы и неформальное общение. Обычно их не записывают, а там происходит интересное. Это интерактивные мероприятия, где больше общаешься с людьми, обсуждаешь или решаешь выдуманные или даже реальные кейсы.
А чтобы найти интересную тему для себя, стоит остановиться и разобраться, можно сделать 360-ревью, поговорить с руководителями и с коллегами по горизонтали, чтобы получить фидбэк и порефлексировать, в какую сторону стоит двигаться дальше.
Заключение
Надеюсь, мой опыт поможет вам решиться на эксперимент с руководящей позицией или же вовремя вывернуть, если вы идете «не туда». И главное, если процессы в компании построены правильно, вы всегда сможете сделать шаг назад. За примерами далеко ходить не надо — у нас в команде был случай, когда сотрудник начал руководить, но понял, что ему это не нравится, и с общего согласия он вернулся на линейную позицию. Или, например, кейс участника митапа тимлидов, о котором я говорил в самом начале: Евгений Мацюк даже написал целую статью о том, как не попасть в карьерную ловушку тимлида.
К такому повороту событий должны быть готовы и команда, и сам начинающий руководитель, и его руководитель тоже. Если обсудить все на старте, последствия ошибки можно нивелировать как для команды, так и для сотрудника. И в целом это помогает создать среду, где люди не боятся пробовать и совершать ошибки.
Надеюсь, со стереотипами о руководстве мы разобрались. Если вам было интересно, то загляните еще и сюда: здесь я и другие мои коллеги собрали свои взгляды на другие популярные мифы об IT.
P.S. Всем, кто даже не думает, раздумывает или уже решился встать на путь менеджера, рекомендую книгу Camille Fournier The Manager’s Path.
