The craftsman-to-manager paradox

[recoder]

По наводке urbansheep прочитал заметку "The craftsman-to-manager paradox", где товарищ Dave Gray описывает прямо-таки мою ситуацию, когда из нормального программиста пытаются делать менеджера.

Как правильно пишет 'аффтар', ситуация довольно типичная: успешного программиста повышают до менеджера в соответствии с Принципом Питера. Однако успешным программер был потому что руководствовался принципами 'Делать всё надо сразу правильно' и 'Хочешь чтобы что-то было сделано - сделай это сам'. А новая позиция предполагает диаметрально противоположный подход.

И вот что предлагается предпринимать:

1. Make your expectations crystal clear.
   Leave no room for interpretation. WHO will do WHAT by WHEN?
2. Listen actively.
   What is the person saying? What is their tone of voice saying? What is their body language saying? Pay attention.
3. Be observant and proactive. Watch what’s going on around you. MBWA (Manage by walking around). Learn to anticipate problems and address them before they are problems.
4. Master the art of asking.
   Good questions help you diagnose root causes and understand underlying dynamics, so you can solve the problem instead of trying to fix a symptom.
5. Teach.
   Every mistake is a learning opportunity. In fact, nearly every interaction you have with your team is a learning opportunity
6. Delegate.
   Anything you do yourself is a wasted opportunity for someone on your team to learn something. Stay close to help if necessary, but only if they ask for it.
7. Coach.
   Spend quality time with your high performers, making them better. It’s easy to forget this one and waste lots of time on the underperformers.
8. Don’t avoid difficult conversations.
   As a manager it’s your job to initiate them when necessary. And never have difficult conversations by email; always do them face to face if possible, by phone if necessary.
9. Learn how to be tough.
   If you’re going to set expectations, there need to be consequences if they are not met. Face it: If you’re going to be a manager you will have to fire someone sooner or later. It’s a true communication challenge and the toughest part of being a manager. When the time comes, just do it.
10. Develop your farm teams.
    You’ll need a stable of people on deck, ready to come on board should you need them. Ongoing and proactive communication is key. Keep them warm.

То есть предлагается забить на все свои достижения как программиста, и вырабатывать в себе совершенно другие качества. Практически, это выглядит как смена рода работы, поэтому от себя добавлю альтернативу: положить на такое карьерное продвижение и поискать другую работу, в привычном качестве программиста.

Буду продолжать медитировать над всеми этими мыслями...

Comments

[alexaces.livejournal.com]

Я вижу что тут некоторая путаница в понятии менеджер наблюдается. Скорее всего потому что в неназываемой компании их - менеджеров - дефицит, а потому люди "сидят на множестве стульев".
Менеджер проекта - это действительно как правило фигура эпическая, по определению того что он стоит между клиентом, проектной командой (как правило - собираемой под проект, замечу, так что это совсем не обезательно и даже скорее редко когда "его люди")и отделом продаж которые как правило всегда продают больше чем можно сделать. Т.е. конфликт в его позицию заложен изначально, потому что его контроль за сроками, людьми и требованиями не очень-то и велик.
Вот только менеджерами проектов не ограничевается понятие "менеджер" (это даже не вспоминая не-менеджерских менеджеров типа product manager, etc), и более того, довольно редко менеджер проектов - бывший программист. По крайней мере в нашей компании и у системных интеграторов с которыми мы сталкивались (включая всех больших - Accenture, Bearing Point, etc, etc).

[recoder]

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

Впрочем, отдельно написаную образовательную лекцию по таксономии менеджеров с удовольствием прочитаю, и думаю, не только я один.

[alexaces.livejournal.com]

Не претендуя на академичность, полноту или всеобщую применимость, вкратце моё понимание различных типов менеджеров:

Менеджеры как руководители могут быть грубо поделены на менеджеров людей и задач, обычно в какой-то комбинации этих двух, редко когда 100-0.
1. Менеджеры людей имеют в подчинении постоянные группы, они участвуют/руководят наймом/увольнением людей в этих группах, их зарплатами, отпусками, рабочими местами и т.п. Их фокус люди и группы людей, а не решение конкретных тактических задач - как правило. Руководство групп, отделов и направлений - это менеджеры людей.
2. Менеджеры задач занимаются конкретными тактическими задачами, определяя требуемые ресурсы, время, график и контролируя то как идет процесс решения задачи. Они могут не иметь вообще людей в постоянном подчинении и набирать команду из других групп под конкретную задачу. Руководство проектов и бидов - то менеджеры задач.

Еще есть тонна людей которые реально не попадают ни в одну из категорий, но называются менеджерами. Хороший пример для софтверной компании- это Менеджер продукта. Product Manager - роль которая соостоит в координации сбора, приведении в порядок и выдачи в качестве product roadmap улучшений и добавлений для следующих версий продуктов. Реально Product Manager не имеет в подчинении людей, а работает над координацией запросов разных отделов - sales, marketing, engineering, support, etc. Он реально - менеджер задач/фич. То же самое - менее распространенная должность - marketing manager, account manager (это sales), human resources менеджер (отдел кадров) и т.д.

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