Как хорошему разработчику не стать плохим менеджером

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

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

Автор открыт для диалога – это большой плюс данной книги и данного автора.

Многие идеи будут интересны не только менеджерам, и не только IT-специалистам.

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

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

Наверное, опытным менеджерам многие мысли покажутся очевидными. Но о них почему-то не пишут.

К прочтению рекомендую разработчикам и другим it-специалистам, которые подумывают, не перейти ли в менеджмент, а так же начинающим и продолжающим менеджерам.

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

Читается книга легко. Отдельное спасибо автору за то, что не во всех историях есть очевидные выводы. В таких историях автор оставляет место «для подумать».

Очень понравились главы про мотивацию, финансы и становление менеджером. Наверное, потому что это самые животрепещущие и актуальные для начинающего руководителя темы.

Автору большое спасибо за его труд и творческих успехов!

Одной из лучших прочитанных мною книг в прошлом году стала относительно небольшая книга Константина Борисова по проведению интервью — “Брать или не брать? или Как собеседовать разработчика”. Теперь я её рекомендую всем, кто либо сам проводит интервью, либо готовиться проходить — так ты лучше понимаешь, что из себя представляет потенциальный работодатель, и стоит ли его рассматривать.

Но Константин Борисов написал также и другую книгу — «Как хорошему разработчику не стать плохим менеджером». Тема, на самом деле, не такая странная, какой может показаться по названию. В IT широко известно, что сильных специалистов часто повышают, поскольку они хорошо справляются со своими задачами. Сегодня ты прекрасный программист, а завтра тебе дают в обучение парочку стажёров, послезавтра делают ведущим программистом, затем дают в подчинение команду, и вот ты уже менеджер.

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

Но хотя у меня это было осознанное решение, не все приходят в менеджмент таким путём. Многие — как я описал выше. Однако перед всеми встаёт одна и та же задача: ты был неплохим разработчиком, но теперь тебе надо стать неплохим менеджером. А лучше — отличным.

Книга «Как хорошему разработчику не стать плохим менеджером» — очередной очень концентрированный сборник великолепных советов, собранных воедино. Я помечал по ходу чтения множество фрагментов, а подписаться готов чуть ли не под каждым абзацем. До многого из описанного я доходил собственным умом, что-то пришлось выучить на собственных же грубых ошибках. Но если бы все менеджеры в IT следовали описанным Константином Борисовым подходам, я бы брал их к себе в команду не задумываясь. Да чего говорить, это главные критерии, по которым я оценивал руководителей в собственные команды. Да, не все были просты в работе, но практически с каждым я находил общий язык и ту сильную сторону, за счёт которой проекты двигались вперёд.

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

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

Но если уж решение принято, то надо действовать корректно и разумно.

Как в и прошлой книге, Константин Борисов разбивает повествование по разделам:

* Поначалу он рассуждает об управлении вообще, и чем управление в сфере IT отличается от классического. Из интересных отличий тут я бы выделил: --- Очень широкое применение делегирования полномочий --- Крайне своевольные исполнители, требующие «очень аккуратного управления». «При том, что сами они ведут себя часто очень агрессивно» --- Все проекты высокорисковые * В следующем разделе (кажется, самом крупном в книге) он рассуждает о мотивации и ответственности. Вот уж где я маркером наотмечал почти каждую страницу! * Третий раздел полностью посвящён вопросам финансовой мотивации, он так и называется — «Бабло». Основные вопросы тут — когда и почему стоит повышать оплату труда, а когда это не имеет смысла. Как премии могут работать против бизнеса, а то и привести к увольнению. И так далее. Ибо деньги — часто слишком переоцененный инструмент удержания сотрудников * В четвёртом разделе автор рассуждает про подходы контроля проектов, разные модели (Time Material или Fixed Price), а также насколько Scrum как методология относится к менеджменту и помогает ему * А заканчивает, что интересно, Константин Борисов небольшим разделом про становление молодого менеджера. Тут и набор типовых «подводных камней», и несколько примеров из жизни, и распространённые ошибки начинающего управленца.

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

По словам автора, тут важно многое, но я выделил следующие цитаты:

* При проблемах в командах нельзя остановиться и перезапустить работу «с чистого листа». «…Люди слишком ценный ресурс и найти 20-30 незанятых человек просто невозможно. К тому же в “кризисных” проектах знания распределены по ключевым людям и без них нельзя продолжить работу. Да и заказчик не может терпеть задержку из-за “перезапуска” проектов«. * «…Начать работу с мотивацией надо с того, чтобы исключить демотивацию. Дело в том, что мотивация – это очень хрупкий объект. Чтобы человек думал о всеобщем благе, стремился к самосовершенствованию и делал больше, чем необходимо, надо, чтобы у него было всё хорошо. Демотивация же, обычно, наоборот штука грубая, больно “бьющая” по человеку и оставляющая след надолго. Если менеджер один раз вспылит, обзовёт разработчика бесполезным и пригрозит увольнением, то потом может расслабиться и больше не тратить время на мотивацию этого разработчика. Такой менеджер уже всё сломал и чтобы вывести мотивацию хотя бы в ноль, надо обладать специальными навыками и продуманно приложить значительные усилия«. * Уметь признавать ошибки и брать ответственность за проблемы. Команда понимает, что так не ищут козла отпущения, благодарна и фокусируется на поиске решения вместо того, чтобы становиться в защитную позицию. Но тут важно ещё так взять ответственность на себя, чтобы показать, какие именно моменты «якобы вы» могли сделать лучше. Это даст правильный сигнал команде

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

Отдельно также выделю одну цитату про доверие, поскольку для меня доверие — такой же важный навык руководителя, как и продуктивность. Без доверия нет партнёрских отношений.

Так как вопрос доверия является ключевым и часто сложным для усвоения я хотел бы конспективно перечислить ключевые моменты:

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

Короче, я могу ещё много цитировать эту книгу, но она и так довольно короткая. Лучше её просто прочитать. Тем более, что, как и первая, эта книга раздаётся на Литресе бесплатно!

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

Что понравилось:

– Все описано, как часто на самом деле и происходит.

– Можно поспорить с автором (мысленно), авторитет не давлеет . И спорить приходилось частенько.

– Читается легко и быстро

– Бесплатно

Что не понравилось:

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

– структура слабая

– большая часть историй основана на опыте в аутсорсе

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

Больше всего меня, в положительном плане, цепанула история про доверие:

"Разделять вопросы доверия и квалификации критически важно…

– Менеджер не должен работать с теми людьми, которых он считает недостойными доверия;

– Менеджер не должен путать доверие и гарантию от ошибок. Каждый может ошибиться;"

Прямо очень хорошо!

История от которой я в ступоре: «История про ненужные сложности». Интересно, удалось ли в итоге уволить Сергея?

Есть пара интересных историй, однако в целом похоже на сборник ИТ-рассказов из опыта автора. Не мешало бы сделать саммари. Читается легко, твёрдая тройка.