![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The craftsman-to-manager paradox
По наводке ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
urbansheep прочитал заметку "The craftsman-to-manager paradox", где товарищ Dave Gray описывает прямо-таки мою ситуацию, когда из нормального программиста пытаются делать менеджера.
Как правильно пишет 'аффтар', ситуация довольно типичная: успешного программиста повышают до менеджера в соответствии с Принципом Питера. Однако успешным программер был потому что руководствовался принципами 'Делать всё надо сразу правильно' и 'Хочешь чтобы что-то было сделано - сделай это сам'. А новая позиция предполагает диаметрально противоположный подход.
И вот что предлагается предпринимать:
- Make your expectations crystal clear.
Leave no room for interpretation. WHO will do WHAT by WHEN? - Listen actively.
What is the person saying? What is their tone of voice saying? What is their body language saying? Pay attention. - 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.
- 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. - Teach.
Every mistake is a learning opportunity. In fact, nearly every interaction you have with your team is a learning opportunity - 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. - 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. - 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. - 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. - 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.
То есть предлагается забить на все свои достижения как программиста, и вырабатывать в себе совершенно другие качества. Практически, это выглядит как смена рода работы, поэтому от себя добавлю альтернативу: положить на такое карьерное продвижение и поискать другую работу, в привычном качестве программиста.
Буду продолжать медитировать над всеми этими мыслями...
no subject
Ну ты меня понял. ;)
no subject
no subject
Другое дело, что этому не хочется учиться...
no subject
Само понятие "слава" - уже ментальность начальника (или individual contributor). Слава менеджера - это его команда/процессы им построенные и рост его зарплаты/ответственности. Если хочется славы, лучше вообще работать в одиночку.
no subject
Слава менеджера - это его команда/процессы им построенные
Кстати - это пожалуй и есть основная моя проблема. Что главное достижение менеджера - есть не качественный продукт, а отлаженый процесс. А из второго первое совершенно не следует.
no subject
Потому что если мы обсуждаем реальность, то утверждения что PHB "совершенно типичен для Штатов" и что более того PHB "становятся 90% всего начальства" (замечу - опять НАЧАЛЬСТВА, а не менеджемента, что хорошо подтверждает мою точку зрения, ессно на ассоциативном уровне) - без доказательств НЕ принимаются. Даже как-то обидеться хочется, как менеджеру группы, на такие сравнения.
Мой личный опыт и наблюдения не подтверждают подобную точку зрения. Более того, PHB для меня - это менеджер приведенный сверху и не имеющий никакого опыта в той сфере которой он руководит (и не хотящий этот опыт получить). Мы вроде бы обсуждали менеджера который был выдвинут снизу, да причем еще был _выдвинут_, а не _выдвинулся сам_, а следовательно он по определению знаком с предметной областью и с большой вероятностью - не карьерист.
// Кстати - это пожалуй и есть основная моя проблема. Что главное достижение менеджера - есть не качественный продукт, а отлаженый процесс. А из второго первое совершенно не следует.
Следует, если не терять сочетание команда/процессы - которое я не просто так использовал. Потому что не только "отлаженный процесс", а и КОМАНДА строится менеджером, и является его заслугой. Одно без другого качественного продукта не даст, оба - всегда дадут. А славу за продукт должна у приличного менеджера получать команда, иначе какая у ней-команды - мотивация что-то делать хорошо?
no subject
Пф! Ну сходи на любой техно-гиковский форум типа SlashDot и почитай бесчисленые рассказы о Death March'ах и прочих «радостях» устраиваемых местными PHB.
Мы вроде бы обсуждали менеджера который был выдвинут снизу
А это ничего не меняет. Если у свежеиспечённого менеджера есть мотивация|желание|умение менеджить правильно - он станет таким менеджером, как описываешь ты. Иначе же он скатывается в к этому самому PHB, что по-моему происходит очень часто.
Даже как-то обидеться хочется, как менеджеру
Предлагаю на личности не переходить. :) Не рассматривать конкретных лиц или компаний, а обсуждать среднестатистические ситуации.
no subject
Т.е. каждый человек в индустрии немедленно бежит писать в SlashDot если у него менеджер "ну так, ну обычный менеджер, ну что-то там делает, особо сильно не достает, и не полный идиот"? ;)
Так что аргумент со слэш-дотом не принимается - тенденциозная, непроверяемая и соотв нерепрезентативная выборка. Принимается - например - опрос друзей и знакомых, насколько можно всеобъемлющий, который дает картину 90% PHB-менеджеров на удаленни 1-2 человека от тебя. Это будет настолько приближенно к среднестатической организации насколько мы можем получить.
Абсолютно так же логика применима к выдвиженцам снизу которые скатились в PHB - хочу статистику. Лично не знаю такого ни одного.
no subject
no subject
no subject
А можно попросить точно разделить термины 'начальник' и 'менеджер'? А то по твоим постам проскальзывает настроение "начальник - это такой плохой менеджер". FYI, у нас в словариках написано так:
no subject
Всё ниженаписанное не претендует на полноту и осознает то что в современном русском языке понятия используются часто как взаимозаменяемые, не в последнюю очередь потому что механически были взяты иерархии советского времени и модернизация свелась к переименованию начальников в менеджеры. если взять тот же лингво и посмотреть перевод, то видно что в переводе "начальник" нет ни одного варианта с "менеджер" и наоборот.
Я использовал термины в следующем смысле.
1. Начальник - человек получивший власть над определенным числом людей выбранным по признаку организационной иерархии. Как правило назначен сверху, часто член бюрократической машины, перебрасываемый с одного места на другое (бессмертное "бросить на производство" из Ильфа/Петрова). Мандат начальника -как правило - "руководить" (а не решать какие-то задачи отдела/продвигать "миссию компании" или даже выполнять волю собственников компании). Ключевое слово для "начальника" - власть. Не зря все варианты перевода на том же лингво тяготеют к "начальник тюрьмы, полиции" и т.п. - одного аналогичного слова просто в английском нет. Самое к примеру близкое к начальник отдела - это Director of XXX Deparment. А все managers - они уже под Director сидят, или вообще в отдельной иерархии (PMO->project managers). Для начальника чтобы хорошо жить - надо быть в хороших отношениях с его начальником, не обязательно из-за результатов. Как правило начальник назначается через голову его непосредственного начальника, а потому и уволен может быть через головую
2. Менеджер - наемный работник, нанятый для решения определенных задач (а не для просто руководства существующей группой людей). Часто приводит своих людей, увольняет или убирает на вторые существующих и т.п. - для того чтобы решить задачу. Полномочия как правило ему нужно выбивать, а не получать, причем чаще всего они временные (а у начальника - они постоянные пока он на этой должности). Причем как правило менеджер отвечает напрямую людям которые его наняли и соотв могут его уволить, а потому у него есть прямой стимул работать на результат.
Хорошее summary пост-советских типов руководителей есть вот здесь -
http://www.cfin.ru/management/people/denisov-08.shtml
Начальники там это значительный процент из тех кто "Советская школа".
Надеюсь что более понятно стала разница. Если нет, могу по возможности еще расширить.
no subject
Настоящий менеджер проекта - это такая эпическая фигура с кнутом в правой руке, пряником в левой и оголенным навазелиненным задом. Кнутом он погоняет нерадивых программистов, в зад его имеет клиент, а пряник он жрет сам.
no subject
no subject
Менеджер проекта - это действительно как правило фигура эпическая, по определению того что он стоит между клиентом, проектной командой (как правило - собираемой под проект, замечу, так что это совсем не обезательно и даже скорее редко когда "его люди")и отделом продаж которые как правило всегда продают больше чем можно сделать. Т.е. конфликт в его позицию заложен изначально, потому что его контроль за сроками, людьми и требованиями не очень-то и велик.
Вот только менеджерами проектов не ограничевается понятие "менеджер" (это даже не вспоминая не-менеджерских менеджеров типа product manager, etc), и более того, довольно редко менеджер проектов - бывший программист. По крайней мере в нашей компании и у системных интеграторов с которыми мы сталкивались (включая всех больших - Accenture, Bearing Point, etc, etc).
no subject
Впрочем, отдельно написаную образовательную лекцию по таксономии менеджеров с удовольствием прочитаю, и думаю, не только я один.
no subject
Менеджеры как руководители могут быть грубо поделены на менеджеров людей и задач, обычно в какой-то комбинации этих двух, редко когда 100-0.
1. Менеджеры людей имеют в подчинении постоянные группы, они участвуют/руководят наймом/увольнением людей в этих группах, их зарплатами, отпусками, рабочими местами и т.п. Их фокус люди и группы людей, а не решение конкретных тактических задач - как правило. Руководство групп, отделов и направлений - это менеджеры людей.
2. Менеджеры задач занимаются конкретными тактическими задачами, определяя требуемые ресурсы, время, график и контролируя то как идет процесс решения задачи. Они могут не иметь вообще людей в постоянном подчинении и набирать команду из других групп под конкретную задачу. Руководство проектов и бидов - то менеджеры задач.
Еще есть тонна людей которые реально не попадают ни в одну из категорий, но называются менеджерами. Хороший пример для софтверной компании- это Менеджер продукта. Product Manager - роль которая соостоит в координации сбора, приведении в порядок и выдачи в качестве product roadmap улучшений и добавлений для следующих версий продуктов. Реально Product Manager не имеет в подчинении людей, а работает над координацией запросов разных отделов - sales, marketing, engineering, support, etc. Он реально - менеджер задач/фич. То же самое - менее распространенная должность - marketing manager, account manager (это sales), human resources менеджер (отдел кадров) и т.д.
P.S. И это не буквоедство с моей т.з., а попытка внести некоторую структуру в модель обсуждаемого мира. Всё-таки большие компании/организации - одно из самых сложных устройств построенных человечеством, и структура там тоже сложна. Без какого-то четкого разделения по ролям критика менеджеров _вообще_ выливается просто в выпуск пара и поиск врага.
no subject
Советы которые написаны сверху - они для тех "нормальных" программистов которые хотели (либо были не уверены что НЕ хотят) быть менеджерами и соотв были повышены до этой роли - с их гласного или молчаливого несогласия. Эти советы им - как попытаться реально трансформироваться в менеджера если уж решили что да, хотят. Можно конечно использовать эти советы как основу для решения, но думаю что есть более интересные материалы на тему "кем быть".
На тему карьерного продвижения - всего в хай-тек компании с моей точки зрения таких продвижений с моей точки зрения всего две, если оставаться в рамках 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»).
no subject
Увы, сплошь и рядом убер-менеджментом делается такой вывод: "$PERSON - хороший программист в области $AREA, поэтому из него выйдет отличный менджер в той же области $AREA". При этом почему-то редко вспоминают, что у этих довольно разных профессий очень разные требования к навыкам. Ситуация усугубляется тем, что иногда за счёт типичных для хорошего программиста логического мышления, настойчивости и аккуратности он таки-вытягивает новые обязанности на приемлемом уровне. И это укрепляет вышеописанное заблуждение.
А приводит это к вымыванию хороших программистов из R&D и, как следствие, общему ухудшению качества софтверных продуктов. В результате мы имеем то что имеем, начиная с баек 'если бы строители строили, так как программисты программируют'...
no subject
Тем не менее это совершенно не отменяет моего тезиса, который надо читать целиком, до слов "если он четко и открыто скажет что он этого не хочет". У нас люди соглашаются с принципом "надо для блага компании", просто хотят попробовать себя или элементарно боятся последствий отказа (которые реально заключаются всего лишь в том что больше уже не спросят и будут смотреть - неизбежно - как на менее ценного сотрудника) - отсюда и идет вымывание. Переформулируя - если человек прямо откажется - во всех случаях когда ему предложили - быть менеджером, его "тащить" никто долго туда не будет - потому что это пустая трата времени которого и так не хватает.
no subject
И - да, советы хорошие для желающих стать хорошими менеджерами. Но ценность их для программиста такая же как у советов "Если вы захотели торговать марихуаной, то во-первых, найдите себе подходящую крышу...".
no subject
Ты не в армии. Ты даже не в комсомоле/партии. Не хочешь быть менеджером - не будь им ;) Но не обобщай это на всёх програмистов-то. Может кто-то хочет (я десяток знаю точно, хотя половину бы я в менеджемент не пустил ;) ). Вот им-то подобные советы очень полезны - а тебе просто нужны другие советы. Например либо "как захотеть стать менеджером за 48 часов". Либо - еще лучше - "отвожу порчу, сглаз и предложения стать менеджером. Дорого. Надежно" ;)
no subject
Именно это я и имел в виду. Я же уже несколько раз акцентировал внимание на том, что считаю менеджмент другой профессией. Поэтому да, моё "для программиста" надо читать как "для программиста, который остаётся программистом".
no subject
1. Если "менеджер программистов" это другая профессия, а не просто следующий этап развития программиста, то по той же логике все другие пути развития программиста когда он реально сам код уже не пишет (те же architects, к примеру) - тоже смена профессии.
2. Отсюда (да собственно, не только отсюда, а просто-таки by design) следуюет что "программист, который остается программистом" - ему не стоит смотреть советы ни для чего кроме "как программировать на <язык тут>". И если после того как он несколько раз гласно отказался от того чтобы быть менеджером или - это вытекает из "остается программистом" - architect, - то ему безусловно надо менять компанию. Причем с моей т.з. - приготовится к тому что компании придется менять часто (исключение - гос-служба, желательно - армия, где технологии стоят на месте), потому что очень скоро таких компаний где его опыт/знания и связанная с этим высокая зарплата будут предподчтительнее чем какая-нибудь свежевыпущенная молодежь с красными дипломами - практически не будет. Хороший пример подобного самоограничения - спецы по ЕС ЭВМ. Профессионалы - да. Требуются - да. Всё меньше и меньше - тоже ДА.
Я - это моё личное мнение - считаю что само-ограничение в том что "делал дольше всего/лучше всего разбираешься" - это преждевременная профессиональная смерть, причем много более быстрая в high-tech как очень неразвитой/быстро меняющейся индустрии чем в каком-нибудь plumbing. Как и со всеми остальными своими личными мнениями, я его никому не навязываю, люди должны думать своей головой, я только излагаю почему именно так думаю именно я.
no subject
no subject
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. Вообщем-то мой фокус был на том чтобы РеКодеру объяснить его ближайшие перспективы, а всё что сверху это уже "общечеловеческие" рассуждения, так что на тему предлагаю забить ;)
no subject
Это я просто пытаюсь объяснить сказанное ранее, без попытки что то оспаривать.
А в целом конечно да. Все, думаю, уяснили для себя местами безрадостные перспектитвы карьерного роста.
Кстати, на счет сложности построенных человеком устройств - государство покруче будет ;-)
no subject
На тему сложности и государства - это правда, потому я и вписал не только "компании", но и "организации" в "самые сложные устройства". Государство с моей точки зрения - это организация.