Привет, меня зовут Вадим Карасев, я — руководитель группы разработки в команде 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.
