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]

Само определение ситуации неправильное. Никто не будет в коммерческой неназываемой организации которая нанимает по 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»).

[recoder]

Никто не будет в коммерческой организации [...] "пытаться сделать менеджера" из нормального программиста если он четко открыто скажет что он этого не хочет.
Увы, сплошь и рядом убер-менеджментом делается такой вывод: "$PERSON - хороший программист в области $AREA, поэтому из него выйдет отличный менджер в той же области $AREA". При этом почему-то редко вспоминают, что у этих довольно разных профессий очень разные требования к навыкам. Ситуация усугубляется тем, что иногда за счёт типичных для хорошего программиста логического мышления, настойчивости и аккуратности он таки-вытягивает новые обязанности на приемлемом уровне. И это укрепляет вышеописанное заблуждение.
А приводит это к вымыванию хороших программистов из R&D и, как следствие, общему ухудшению качества софтверных продуктов. В результате мы имеем то что имеем, начиная с баек 'если бы строители строили, так как программисты программируют'...

[alexaces.livejournal.com]

А вот с этим соглашусь целиком и полностью в контексте неназываемой компании. Не хватает - катастрофически - опытных людей на проектах и в отделе продаж, а потому сколько-нибудь проявивший себя в какой-нибудь $AREA человек немедленно выдергивается туда и соотвественно ему нужна замена на которую тащат человека с более низкого уровня.
Тем не менее это совершенно не отменяет моего тезиса, который надо читать целиком, до слов "если он четко и открыто скажет что он этого не хочет". У нас люди соглашаются с принципом "надо для блага компании", просто хотят попробовать себя или элементарно боятся последствий отказа (которые реально заключаются всего лишь в том что больше уже не спросят и будут смотреть - неизбежно - как на менее ценного сотрудника) - отсюда и идет вымывание. Переформулируя - если человек прямо откажется - во всех случаях когда ему предложили - быть менеджером, его "тащить" никто долго туда не будет - потому что это пустая трата времени которого и так не хватает.

[recoder]

Переход в сейлс/маркетинг/etc. - это на мой взгляд смена профессии, а не карьерное продвижение! Рост - это всё же более эффективное применение накапливаемого профессионального опыта, такое как движение в сторону Chief Architect.

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

[alexaces.livejournal.com]

"Но ценность их для программиста" - поправка. Ценность их для программиста "КОТОРЫЙ НЕ ХОЧЕТ БЫТЬ МЕНЕДЖЕРОМ".

Ты не в армии. Ты даже не в комсомоле/партии. Не хочешь быть менеджером - не будь им ;) Но не обобщай это на всёх програмистов-то. Может кто-то хочет (я десяток знаю точно, хотя половину бы я в менеджемент не пустил ;) ). Вот им-то подобные советы очень полезны - а тебе просто нужны другие советы. Например либо "как захотеть стать менеджером за 48 часов". Либо - еще лучше - "отвожу порчу, сглаз и предложения стать менеджером. Дорого. Надежно" ;)

[recoder]

"Но ценность их для программиста" - поправка. Ценность их для программиста "КОТОРЫЙ НЕ ХОЧЕТ БЫТЬ МЕНЕДЖЕРОМ".

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

[alexaces.livejournal.com]

Тут я вижу две вещи вытекающие одна из другой.
1. Если "менеджер программистов" это другая профессия, а не просто следующий этап развития программиста, то по той же логике все другие пути развития программиста когда он реально сам код уже не пишет (те же architects, к примеру) - тоже смена профессии.
2. Отсюда (да собственно, не только отсюда, а просто-таки by design) следуюет что "программист, который остается программистом" - ему не стоит смотреть советы ни для чего кроме "как программировать на <язык тут>". И если после того как он несколько раз гласно отказался от того чтобы быть менеджером или - это вытекает из "остается программистом" - architect, - то ему безусловно надо менять компанию. Причем с моей т.з. - приготовится к тому что компании придется менять часто (исключение - гос-служба, желательно - армия, где технологии стоят на месте), потому что очень скоро таких компаний где его опыт/знания и связанная с этим высокая зарплата будут предподчтительнее чем какая-нибудь свежевыпущенная молодежь с красными дипломами - практически не будет. Хороший пример подобного самоограничения - спецы по ЕС ЭВМ. Профессионалы - да. Требуются - да. Всё меньше и меньше - тоже ДА.
Я - это моё личное мнение - считаю что само-ограничение в том что "делал дольше всего/лучше всего разбираешься" - это преждевременная профессиональная смерть, причем много более быстрая в high-tech как очень неразвитой/быстро меняющейся индустрии чем в каком-нибудь plumbing. Как и со всеми остальными своими личными мнениями, я его никому не навязываю, люди должны думать своей головой, я только излагаю почему именно так думаю именно я.

[hazan.livejournal.com]

На самом деле вы как то зря концентрируетесь на программистской судьбе. Картина совершенно одинаковая во всех областях. И "проект" как программный продукт - слишком узкое трактование. Просто в других областях народ по прежнему на визитках пишет "начальник" или "руководитель", выполняя тот же самый набор функций и ритуальных танцев. Любое дело, имеющее более-менее четко очерченные границы, уже по сути является проектом, сроки которого могут быть как четко очерчены, так и быть бесконечными. А суть одна - основной работой становится не производство продукта, а налаживание процесса производства. А как следствие - поиск компетентных исполнителей, контроль сроков и качества, решение проблем и собирание геморроя. Потому и перспективы не только СЕО, СТО - а просто СхО. Ну разумеется, при старте из какой то конкретной области круг потенциальных цеелй сужается, но все пути могут вывести наверх.

[alexaces.livejournal.com]

Ну, по пунктам.
1. Программистская судьба по определению есть фокус данной дискуссии потому некий г. РеКодер - программист ;)
2. Соответственно я старался писать только с т.з. инженерной/IT организации которая выходит на CIO (или в кривых конторах - на CTO).
3. Под определением что есть "проекта" и его сути (налаживание процесса производства) подпишусь, но не вижу где именно "проект" я или другие участники дискусии трактовали как продукт, а поэтому не понимаю третьей фразы вообще.
4. Опять-таки, менеджер может подняться реально до какого угодно CxO, речь шла об ограниченности роста человека который хочет быть individual contributor и ничего/кого не менеджить. В engineering/IT - это c моей т.з. Chief Architect. А чтобы было совсем уж точно, перефразируем так - конечно, Chief Architect имеет вероятность вырасти в CxО. Но эта вероятность очень мала, потому что человек чтобы вырасти до CA шел по не-меджерской дорожке и соотв развивал не-менеджерские навыки. Но исключения бывают везде - это жизнь, а не компьютерная программа (I hope and believe that is true ;) )).
5. Вообщем-то мой фокус был на том чтобы РеКодеру объяснить его ближайшие перспективы, а всё что сверху это уже "общечеловеческие" рассуждения, так что на тему предлагаю забить ;)

[hazan.livejournal.com]

Ну, смысл тертьей фразы был в том, что менеджер чего-угодно перестает заниматся работой в принципе, и после этого уже становится все менее и менее важно, какой у него был технический бекграунд. Главное - его организационные способности, которые очень редко связаны с родом работы, которую человек выполнял до этого.
Это я просто пытаюсь объяснить сказанное ранее, без попытки что то оспаривать.

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

Кстати, на счет сложности построенных человеком устройств - государство покруче будет ;-)

[alexaces.livejournal.com]

А, теперь понял.

На тему сложности и государства - это правда, потому я и вписал не только "компании", но и "организации" в "самые сложные устройства". Государство с моей точки зрения - это организация.