Хабрахабр

Карьерные стероиды. Базовый алгоритм

Статья про быстрый карьерный рост внутри одной компании. Именно внутри одной, т.к. скачок при переходе — это другая методика, к ней нужно иначе готовиться (там больше комплект увольнения подходит).

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

Так же, как нет ничего плохого или хорошего в изучении ERP, ремонте своей квартиры или прохождении курса «100 отжиманий». В карьере нет ничего плохого или хорошего. Взамен он должен потратить больше ресурсов, чем расходовал до этого — времени, нервов, денег. Карьера — это проект с определенной целью, в который человек сознательно вступает, чтобы чего-то получить.

Если я им займусь, то эта информация может мне помочь. Мне кажется, будет здорово, если дальше вы будете читать именно с таким отношением: карьера — это такой проект.

Я тоже не планирую, например, никогда внедрять ERP, поэтому не читаю о нем статей. Если вы не планируете строить карьеру — не вопрос. Хотя мог бы читать и писать в комментах все, что я думаю о ERP и авторах статей о ней — только зачем?

Возвращаемся к карьере. Надеюсь, мы договорились.

на истину и «у меня правильнее» в этом вопросе претендовать бессмысленно — слишком уникальны ситуации в разных компаниях. Не скажу, что у меня прям сильно большой опыт, наверняка у кого-то он больше и интереснее — спорить не буду, т.к. Просто расскажу свой опыт и выводы, которые успел сделать, а вы сами для себя решите, что использовать, а что нет.

Как строится карьера

Мой опыт содержит в себе две прямо противоположные стратегии — сознательно строить карьеру и сознательно не строить карьеру, причем по количеству компаний стратегии соотносятся 50/50 — в половине компаний я старался продвинуться вперед и вверх, в половине хотел тишины, покоя и просто программировать.

Сразу назову самый главный вывод: если карьеру не строить, то она не построится.

Если ты сидишь и просто работаешь, то ты будешь сидеть и просто работать. Звучит банально, но я в этом убедился на личном опыте. И тут не особо важна должность — я проверял на должностях программиста и начальника ИТ-отдела, с пятью подчиненными.

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

Соответственно, второй вывод вытекает из первого: если хочешь карьеры, то придется ее строить.

Хорошее выполнение основных обязанностей, наверное, тоже может привести к карьерному росту, но это долго, нудно и подходящий момент нужен — например, повышение или увольнение вашего начальника. Строительство карьеры — это действия, которые надо предпринимать помимо основных обязанностей. Такой момент может и не наступить.

Руководство этих ребят вообще не знает, но на вопрос «кто будет начальником?» зачем-то отвечает «рассмотрим все варианты». Я такие ситуации часто видел, когда уходит руководитель, а из его подчиненных никто карьеру не строил. Их, естественно, бреют и берут со стороны очередного бездаря. И вот вылезают из своего подвала программисты, сисадмины и прочая нечисть и начинают рассказывать, что хотят быть начальниками.

Чем и продолжат заниматься. Ребят из подвала не берут, потому что они ничего не делали по проекту «карьера» — они просто работали.

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

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

Это не выдающиеся результаты в профессиональной или управленческой деятельности, не крутые процессы, не сплоченная команда, не авторитет среди сотрудников, это просто… стероиды. Эти действия – карьерные стероиды. Если вы наблюдали за корпоративными играми, то можете привести массу примеров карьерных стероидов. Искать внимания директора, что-нибудь говорить на совещаниях, когда все молчат, отдавать приоритет поручениям директора (настроить вайфай в айфоне) в ущерб реально полезным, красивый костюм, активно участвовать в корпоративах, дружить с секретаршей директора, чтобы знать о его настроениях и бежать впереди всех настраивать ему почту, помогать скачать песенки с торрента, и т.д.

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

Фундамента, на котором основывается правильное «ИТ-директорство», у него нет. Если человек стал, например, ИТ-директором благодаря стероидам, то для сохранения должности ему придется и дальше пользоваться этими стероидами. Он, конечно, выучит много умных слов, поездит на конференции, связи внутри компании выстроит, планы будет выполнять и проекты закрывать, но карьера будет и дальше стоять на скользком фундаменте – красивом костюме, комплиментах и настройке вай-фая директору и его гостям.

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

В таком случае не грех и вай-фай ему на айфоне настроить. Но стероиды – это не абсолютное зло, иногда они бывают полезны – когда у вас есть подходящая база для карьерного роста, но не хватает какой-то мелочи, вроде банального пересечения с директором, повода для встречи.

Эскалатор

Пока вы решаете, строить карьеру или нет, подолью еще масла в огонь.

Став, например, ИТ-директором, вы конкурируете уже не только с программистами, и даже не с другими ИТ-директорами, а со всеми менеджерами компании. Карьеру нельзя построить и забыть о ней, потому что чем выше должность, тем сильнее конкуренция и давление внешних сил.

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

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

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

Стал ИТ-директором, потом расслабился, в итоге оказался близок к увольнению. Я в своей жизни, не очень сознательно, проводил исследование на эту тему – катался вверх и вниз на одном и том же эскалаторе. Снова сделал рывок, поднялся уже почти до самого верха, снова расслабился и опять скатился. Снова предпринял усилия, вернул и даже превзошел прежние позиции, опять расслабился, опять скатился.

Как вариант, можно использовать рекомендации из клубка единомышленников. Увы, но на высоких должностях не существует статус-кво.

Ключевое преимущество

Первое, что надо решить — какую карьеру вы строите, какого типа, кем хотите стать в итоге, за что вам будут платить, в чем будет ваша уникальность, конкурентное преимущество.

Руководить — это тоже работа, и, независимо от того, кем вы собираетесь командовать, есть общие принципы и методики, которыми стоит овладеть. Мы говорим о карьерном, а не профессиональном росте, поэтому нас интересует, как правило, руководящая должность — ИТ-директор, тимлидер, или что-то в этом роде.

Изучив популярную литературу по менеджменту, вы станете обычным менеджером — таким же, как все остальные, конкурентных преимуществ у вас не будет. Есть куча книг по менеджменту, которые можно прочитать, но в них нет одного — вашего конкурентного преимущества. Таких, обычных менеджеров — еще больше, чем программистов.

Они пишут планы, ставят задачи, «дрючат» за их невыполнение в срок, контролируют все и вся, «принимают решения» и «несут за них ответственность». Обычные менеджеры скучны до безобразия. То, что лежит на поверхности. Но это все – видимая сторона.

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

Если в компании 10 руководителей, то у каждого одна уникальная особенность, которая называется одинаково – «я незаменим». Быть незаменимым – это традиционное ключевое преимущество, которое наращивают руководители, что весьма забавно. Название одно, а незаменимость разная.

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

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

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

Основной алгоритм

Если кратко, то нужно проактивно отличиться в чем-то, понятном и ценном для ЛПР — того человека, который принимает решение по нужной вам должности.

Похлопают, может даже по плечу, и на этом все кончится. Пение в хоре и танцы на корпоративе, наверное, тоже помогут отличиться, но я не припомню ЛПР, для которых пение и танцы имеют значение.

Посмотреть по истории, поспрашивать коллег, а самое лучшее — понаблюдать за происходящим внутри компании некоторое время. Чтобы понять систему ценностей ЛПР, надо, во-первых, его найти.

Обычно этот человек хочет быть избавленным от какой-то боли, а лучше — от всех сразу. Поняв систему ценностей ЛПР, вы убедитесь, что она совершенно нормальная. И это не зависит от его собственного уровня в иерархии компании: если он руководитель, то у него всегда полно болячек.

Их отличие в том, что болезни у них более настоящие, а не выдуманные, как у менеджеров. Немного другое дело — собственники. Поэтому, если ваш ЛПР — менеджер, посмотрите, от чего обычно горит его задница, и подумайте, как его от этого избавить. У собственника, например, нет потребности в прикрывании своей задницы, а у всех менеджеров — есть. Но если вы работаете с собственником, то не тратьте время на его задницу — ее надо от таких проблем прикрывать, какие программисту обычно не под силу.

Финдир хотел от меня быстрого перехода на 1С. Например, работал я на заводе, подчинялся финдиру. Я считал, что у меня два ЛПР, но работать надо с финдиром. Чего хотел гендир — не знаю, не думал об этом. Почему? Перешел на 1С за месяц, финдир был счастлив, но гендир воткнул выше меня какого-то левого парня, и назвал его ИТ-директором.

Во-первых, я неправильно определил ЛПР — не стоило ждать, что финдир пойдет за меня впрягаться.

Оказалось, что гендир не знает, что такое 1С, зачем куда-то переходить, а главная ценность ИТ для него — работающий лично у него интернет и вайфай по всему заводу. Во-вторых, я не знал систему ценностей гендира, и не пытался узнать, а просто сделал проекцию — как будто гендир хочет того же, чего и финдир — быстрого перехода на 1С. А я искренне считал вайфай второстепенной задачей, и не обращал на нее внимания.

В итоге ИТ-директором стал бывший сисадмин, которому было не в лом сбегать и самому перезагрузить роутер.

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

Как видите, чисто программистскими методами такие боли не снимаются. Болит обычно более комплексно и широко, и звучит как-то наподобие «бардак на складе», «продажи и закупки не могут договориться», «ужасная дисциплина, не добьешься исполнения задачи», «очень медленно разрабатывается новая продукция», «постоянно простаивает производство из-за дефицитов».

Услышать и понять эти боли несложно – достаточно начать слушать и наблюдать, а не говорить или ждать задачи.

Такого, чтобы прям сказали «наша боль – вот это вот», обычно нет. О том, что болит, обычно говорят часто, но урывками – о частных случаях проблем, косяках, потерях, неудачах и т.д. Поэтому надо научиться информацию сопоставлять самостоятельно, по обрывкам, группировать ее и составлять общее мнение.

Что важно – другие этого понимать не будут, потому что у них нет такой цели. Если не будете лениться, то понимание реальных болей войдет в привычку, и вы будете постоянно понимать, что не дает компании развиваться. Они будут концентрироваться на текущих задачах и проблемах, пожарных вопросах, требующих немедленного и, как правило, ручного вмешательства.

Умение решать системные проблемы – это голубой океан для карьеристов. Реального решения требуют системные проблемы, а не сиюминутные, но возиться с системными никому не хочется, потому что никто не умеет.

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

Как выбрать

Рассматриваю ситуацию, когда вы решаете системную проблему в первый раз.

Во-первых, вам никто не даст. Критерий номер одинне беритесь за самые важные и критичные проблемы. Во-вторых, высокая стоимость риска ошибки будет на вас постоянно давить, и страх не даст вам действовать хоть сколько-нибудь эффективно.

Это проблемы взаимодействия обычно. Критерий номер два, опциональный – лучше браться за кросс-функциональные проблемы – те, что находятся не внутри какого-то отдела, а на границе.

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

Граница между отделами почти всегда ничья, за нее никто не отвечает. Собственно, эти проблемы оттого и так актуальны, что за них никто не берется.

Когда станете сертифицированным бизнес-программистом, тогда вас начальник отдела сам позовет, а пока не лезьте. Ну и второе – если вызоветесь решать внутренние проблемы любого отдела, то с вероятностью 99% будете посланы вдаль его начальником. А кто хочет жить с таким диагнозом, известным всем окружающим? Мотивация у начальника простая – если какой-то хмырь пришел к тебе решать твои проблемы, то у тебя управленческая импотенция.

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

Если у вас получится, то вы покажете себя в сравнении. Критерий номер четыреберите то, за что уже кто-то брался, но не победил. Если те, кто не справился – менеджеры, то вы автоматически становитесь в чем-то лучше их.

Ну и последний, пятый критерийне беритесь за внешние проблемы предприятия, ваша цель – внутренние, системные противоречия.

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

А т.к. Внешние проблемы кажутся заманчивыми, но давно превратились из задач в отмазки типа «оптимизация бизнес-процессов – это все херня, главное – чтобы клиентов много было». Обвинить в том, что клиентов мало, особо-то и некого – все отмажутся, что это внешняя среда, там нет приемов и методов, там мэджик какой-то нужно знать, таинство продаж, нужен гуру или магистр Йода, и тому подобная чушь. привести много клиентов никто не умеет, то ситуация остается без изменений.

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

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

Как реализовать

Когда выбрали, надо делать. Тут, увы, единого рецепта нет – нужно знать и применять множество методов бизнес-программирования.

Но сам я строил карьеру именно бизнес-программированием и точно знаю, что это очень простой и кайфовый путь. Вообще, бизнес-программирование – не для того, чтобы карьеру руководителя строить, я вообще против руководителей, как таковых. Никакие стероиды с ним не сравнятся.

Запасной путь

Если неохота возиться с проблемами других подразделений, а карьеру построить хочется, то у вас всегда есть запасной путьбизнес-программирование внутри ИТ-отдела. Я этой возможностью часто пользовался.

Организация работ, мотивация, эффективность, стоимость, взаимодействие с заказчиками и пользователями, проектное управление, закуп, сервисные услуги, даже какое никакое управление запасами есть. В ИТ-отделе всегда полно проблем, не связанных с программированием. Можно сказать, что ИТ-отдел – это вся компания в миниатюре.

Просто выбирайте и улучшайте. Но главное – вы уже внутри.

Как будто вы не программист, а бизнес-программист, или не привязанный к функциональной специфике менеджер или консультант, которого пригласили для решения проблемы ИТ-отдела. Помните лишь об одном – ваша работа должна звучать, как абстрактный менеджмент. Когда зовут чмыря со стороны, чтобы он вашу работу улучшил. Такое ведь и в жизни встречается, согласитесь? Зачем же ждать этого чмыря, если можно самому попробовать?

Просто берете и делаете, помня, что вам этот результат надо будет продать, как менеджерский. Кайф в том, что нет препятствий и конкуренции, не надо ни с кем договариваться и спорить, оценивать риски и заниматься челночной дипломатией.

Сразу поставьте систему замеров – тупо от даты подачи или принятия в работу до даты согласования результата заказчиком. Например, сделайте так, чтобы задачи пользователей решались быстрее, допустим вдвое. И начинайте работать над снижением этого времени.

Напишите письмо, или несколько, разным людям – например, руководителям подразделений. Когда достигнете устойчивого снижения, продавайте свой результат. Директору, собственнику. Или ЛПР, если нашли такового. Кратко, емко, с цифрами в графиках и описанием основных менеджерских приемов. Часто бывает какая-нибудь штука вроде отдельного ящика для вопросов директору – и туда запулите. Без хвастовства, не настойчиво, просто как интересный факт. Сарафанное радио используйте – в курилке, столовой, маршрутке – рассказывайте о том, что сделали. Обязательно найдутся люди, которые это запомнят, а среди них – те, кто сделает «репост», и оно дойдет до гендира.

Внедрил, ускорил вдвое, написал письмо. У меня так было с внедрением Scrum. Потом он сам где-то в менеджерских источниках услышал про Scrum, прочитал книгу, впечатлился, захотел узнать побольше и… вспомнил про меня. С гендиром отношения были на тот момент натянутые, он не отреагировал. Пришел внезапно, посмотрел на доску, задал несколько вопросов, увидел что все – реально, и наши отношения резко стали позитивными – я стал одной из его опорных точек в изменениях.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть