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

[little-elijah.livejournal.com]

Эээээ...
Ну ты меня понял. ;)

[hazan.livejournal.com]

Когда меня спрашивают, почему я так часто меняю работу - я отвечаю, что не хочу на себя взваливать чужой геморрой, становясь начальником. Люди не понимают, а я объяснить не мог. Зато теперь буду ссылаться на первоисточники ;-)

[alexaces.livejournal.com]

Само определение ситуации неправильное. Никто не будет в коммерческой неназываемой организации которая нанимает по 10-15 и больше человек в месяц "пытаться сделать менеджера" из нормального программиста если он четко открыто скажет что он этого не хочет.
Советы которые написаны сверху - они для тех "нормальных" программистов которые хотели (либо были не уверены что НЕ хотят) быть менеджерами и соотв были повышены до этой роли - с их гласного или молчаливого несогласия. Эти советы им - как попытаться реально трансформироваться в менеджера если уж решили что да, хотят. Можно конечно использовать эти советы как основу для решения, но думаю что есть более интересные материалы на тему "кем быть".
На тему карьерного продвижения - всего в хай-тек компании с моей точки зрения таких продвижений с моей точки зрения всего две, если оставаться в рамках engineering, а не переходить в сейлс/маркетинг/поддержку/трейнинг и т.п.
1. Individual contributor (тут в формальной иерархии high-tech максимальная должность для software инженера - если он конечно не настаивает на "программировать всю жизнь") - это либо Chief Architect, либо CTO (который может иметь маленькую группу, но реально просто идеолог, а не менеджер). Хорошая возможность если любишь вещи сделанные своими руками больше чем что-либо еще и/или получаешь удовольствие от самого процесса создания чего-то конкретного (соотв. в обоих случаях как правило имеешь очень большое ego ;) потому что думаешь что лучше тебя - никто. И действительно никто в твоей компании - потому что зачем второго такого брать если на задачи хватает одного?). Оптимальная роль для стартапа (где нужны "герои") или наоборот - для какого-нибудь весьма устоявшегося процесса где надо поддерживать статус-кво.
2. Manager. Тут собственно ограничений вверх нет. CEO - это много более 'менеджер' чем 'individual contributor', к примеру. Хорошая возможность если хочешь решать проблемы и удовольствие получаешь от результата, а вот в самом процессе готов про удовольствие забыть (поскольку менеджемент в более-менее не-рабской компании где люди свободно приходят и уходят - это всегда сплошные утрясания, договоры и компромиссы, ничем принципиально не отличающиеся от любой другой организацинной работы вовлекающей много людей - типа организации скажем вечеринки на 10 человек). Во вменяемой компании менеджер еще получает возможность (а хороший менеджер - передает её вниз) менять процессы так чтобы уменьшить будущие проблемы. У contributor такой возможности никогда нет, потому что он говорит все лишь от своего лица, и его мнение не много значит - его берут делать конкретную работу, а не улучшать процессы в компании.
Как любая формальная классификация, две категории наверху конечно же упрощены. Хороший менеджер будет всегда участвовать в работе группы индивидуально, потому что гораздо полезнее и нагляднее _показать_ что именно ты хочешь, а после этого объяснить как именно ты это сделал. Просто хороший менеджер определит границу между delegate, teach и do it yourself. И соотв построит баланс между временем которое нужно потратить на обучение тима с прицелом на то чтобы они могли делать больше сами в будущем vs. сделать-хорошо-самому-сейчас-и-заткнуть-дыру.

P.S. Советы кстати очень хорошие. Многие из них я в том или ином виде пытался тебе дать, в частности 5, 6, 8 и 10, плюс 3 в части Walking (в противоположность «sitting writing e-mails»).