Статья про быстрый карьерный рост внутри одной компании. Именно внутри одной, т.к. скачок при переходе — это другая методика, к ней нужно иначе готовиться (там больше комплект увольнения подходит).
Сразу скажу: я не считаю, что строить карьеру — это правильно, без этого никак и кто не строит — валенок. При этом я и не считаю, что не строить карьеру — правильно.
В карьере нет ничего плохого или хорошего. Так же, как нет ничего плохого или хорошего в изучении ERP, ремонте своей квартиры или прохождении курса «100 отжиманий». Карьера — это проект с определенной целью, в который человек сознательно вступает, чтобы чего-то получить. Взамен он должен потратить больше ресурсов, чем расходовал до этого — времени, нервов, денег.
Мне кажется, будет здорово, если дальше вы будете читать именно с таким отношением: карьера — это такой проект. Если я им займусь, то эта информация может мне помочь.
Если вы не планируете строить карьеру — не вопрос. Я тоже не планирую, например, никогда внедрять ERP, поэтому не читаю о нем статей. Хотя мог бы читать и писать в комментах все, что я думаю о ERP и авторах статей о ней — только зачем?
Надеюсь, мы договорились. Возвращаемся к карьере.
Не скажу, что у меня прям сильно большой опыт, наверняка у кого-то он больше и интереснее — спорить не буду, т.к. на истину и «у меня правильнее» в этом вопросе претендовать бессмысленно — слишком уникальны ситуации в разных компаниях. Просто расскажу свой опыт и выводы, которые успел сделать, а вы сами для себя решите, что использовать, а что нет.
Как строится карьера
Мой опыт содержит в себе две прямо противоположные стратегии — сознательно строить карьеру и сознательно не строить карьеру, причем по количеству компаний стратегии соотносятся 50/50 — в половине компаний я старался продвинуться вперед и вверх, в половине хотел тишины, покоя и просто программировать.
Сразу назову самый главный вывод: если карьеру не строить, то она не построится.
Звучит банально, но я в этом убедился на личном опыте. Если ты сидишь и просто работаешь, то ты будешь сидеть и просто работать. И тут не особо важна должность — я проверял на должностях программиста и начальника ИТ-отдела, с пятью подчиненными.
Как специалист расти будешь, проекты будут интересные попадаться, но карьерного роста не будет. Причина простая — пока вы сидите и просто работаете, кто-то строит карьеру. Возможно, кто-то из сидящих рядом с вами.
Соответственно, второй вывод вытекает из первого: если хочешь карьеры, то придется ее строить.
Строительство карьеры — это действия, которые надо предпринимать помимо основных обязанностей. Хорошее выполнение основных обязанностей, наверное, тоже может привести к карьерному росту, но это долго, нудно и подходящий момент нужен — например, повышение или увольнение вашего начальника. Такой момент может и не наступить.
Я такие ситуации часто видел, когда уходит руководитель, а из его подчиненных никто карьеру не строил. Руководство этих ребят вообще не знает, но на вопрос «кто будет начальником?» зачем-то отвечает «рассмотрим все варианты». И вот вылезают из своего подвала программисты, сисадмины и прочая нечисть и начинают рассказывать, что хотят быть начальниками. Их, естественно, бреют и берут со стороны очередного бездаря.
Ребят из подвала не берут, потому что они ничего не делали по проекту «карьера» — они просто работали. Чем и продолжат заниматься.
Причина того, что для построения карьеры надо шевелиться, проста – всегда есть кто-то кроме вас. Если вы будете сидеть и программировать, даже лучше всех программировать, найдется один человек, который пойдет обходным путем – путем карьериста. И обойдет вас, даже если вы программируете лучше него. У меня такое было, в одной из компаний, где я решил отсидеться после бурной карьеры в предыдущей компании.
Я программировал больше, и лучше, и более серьезные системы, а начальником стал он, потому что предпринял простые и понятные действия, не связанные с программированием.
Эти действия – карьерные стероиды. Это не выдающиеся результаты в профессиональной или управленческой деятельности, не крутые процессы, не сплоченная команда, не авторитет среди сотрудников, это просто… стероиды. Искать внимания директора, что-нибудь говорить на совещаниях, когда все молчат, отдавать приоритет поручениям директора (настроить вайфай в айфоне) в ущерб реально полезным, красивый костюм, активно участвовать в корпоративах, дружить с секретаршей директора, чтобы знать о его настроениях и бежать впереди всех настраивать ему почту, помогать скачать песенки с торрента, и т.д. Если вы наблюдали за корпоративными играми, то можете привести массу примеров карьерных стероидов.
Почему это стероиды? Потому что ускоряют достижение результата, но плохо сказываются на здоровье и создают зависимость от себя.
Если человек стал, например, ИТ-директором благодаря стероидам, то для сохранения должности ему придется и дальше пользоваться этими стероидами. Фундамента, на котором основывается правильное «ИТ-директорство», у него нет. Он, конечно, выучит много умных слов, поездит на конференции, связи внутри компании выстроит, планы будет выполнять и проекты закрывать, но карьера будет и дальше стоять на скользком фундаменте – красивом костюме, комплиментах и настройке вай-фая директору и его гостям.
Главное для такого человека – неизменность окружающей среды. Если сменится директор, или даже кто-то из горизонтальных руководителей, карьера может пойти прахом. Стероиды, которые подходили предыдущему директору, могут не подойти новому. Окажется, что он сам умеет настраивать вайфай, ходит в футболке, сам смотрит цифры в системе и любит общаться с людьми, а не с их руководителями. ИТ-директору просто некуда будет вколоть свои стероиды.
Но стероиды – это не абсолютное зло, иногда они бывают полезны – когда у вас есть подходящая база для карьерного роста, но не хватает какой-то мелочи, вроде банального пересечения с директором, повода для встречи. В таком случае не грех и вай-фай ему на айфоне настроить.
Эскалатор
Пока вы решаете, строить карьеру или нет, подолью еще масла в огонь.
Карьеру нельзя построить и забыть о ней, потому что чем выше должность, тем сильнее конкуренция и давление внешних сил. Став, например, ИТ-директором, вы конкурируете уже не только с программистами, и даже не с другими ИТ-директорами, а со всеми менеджерами компании.
Вы как Блэйд, наполовину человек, наполовину вампир. Только вы — помесь программиста и менеджера. Вас не любят ни те, ни другие, и вы это знаете. Программисты хотят на ваше место, менеджеры хотят, чтобы вы со своего места свалили (если это не так, то вы — плохой ИТ-директор).
Лучше всех это состояние сформулировала Алиса из Зазеркалья: "— У нас, когда долго бежишь, непременно попадаешь в другое место. — Ну, а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее."
Чем выше стоишь, тем менее устойчива почва под ногами, и требуются постоянные усилия, чтобы не свалиться вниз. И усилия эти — примерно те же по своей сути, что и при строительстве карьеры, и так же выходят за рамки основной работы.
Я в своей жизни, не очень сознательно, проводил исследование на эту тему – катался вверх и вниз на одном и том же эскалаторе. Стал ИТ-директором, потом расслабился, в итоге оказался близок к увольнению. Снова предпринял усилия, вернул и даже превзошел прежние позиции, опять расслабился, опять скатился. Снова сделал рывок, поднялся уже почти до самого верха, снова расслабился и опять скатился.
Увы, но на высоких должностях не существует статус-кво. Как вариант, можно использовать рекомендации из клубка единомышленников.
Ключевое преимущество
Первое, что надо решить — какую карьеру вы строите, какого типа, кем хотите стать в итоге, за что вам будут платить, в чем будет ваша уникальность, конкурентное преимущество.
Мы говорим о карьерном, а не профессиональном росте, поэтому нас интересует, как правило, руководящая должность — ИТ-директор, тимлидер, или что-то в этом роде. Руководить — это тоже работа, и, независимо от того, кем вы собираетесь командовать, есть общие принципы и методики, которыми стоит овладеть.
Есть куча книг по менеджменту, которые можно прочитать, но в них нет одного — вашего конкурентного преимущества. Изучив популярную литературу по менеджменту, вы станете обычным менеджером — таким же, как все остальные, конкурентных преимуществ у вас не будет. Таких, обычных менеджеров — еще больше, чем программистов.
Обычные менеджеры скучны до безобразия. Они пишут планы, ставят задачи, «дрючат» за их невыполнение в срок, контролируют все и вся, «принимают решения» и «несут за них ответственность». Но это все – видимая сторона. То, что лежит на поверхности.
Внутри всего этого лежит одно – желание стать незаменимым, чтобы система жила и работала только при наличии внутри этого самого руководителя. Это хорошо видно во время отпуска руководителя – он не может выключить телефон и расслабиться, т.к. сам искусственно создал ситуацию своей незаменимости. Даже заменяющий руководителя человек не может не может сам справиться со всеми делами, а особенно – с принятием решений, этим великим таинством, которое доступно лишь избранным.
Быть незаменимым – это традиционное ключевое преимущество, которое наращивают руководители, что весьма забавно. Если в компании 10 руководителей, то у каждого одна уникальная особенность, которая называется одинаково – «я незаменим». Название одно, а незаменимость разная.
Такой подход – создание своей незаменимости – тоже можно отнести к стероидам, хотя она несколько лучше, ведь работоспособность процесса обычно обеспечивается. Даже иногда работа над эффективностью проводится, но с непременным условием – система должна работать, только пока руководитель внутри.
По сути, никакого конкурентного преимущества такой подход не создает, т.к. все конкуренты действуют одинаково. Получается только конкуренция между «система с этим менеджером» и «система без этого менеджера». Второй вариант приведет к временным системным сбоям, поэтому к нему стараются не прибегать – придется ждать, пока новый менеджер перестроит систему под себя.
Для компаний такие подходы менеджеров давно привычны, и на них уже давно не обращают внимания, просто интуитивно стараются не менять менеджеров слишком часто. Даже исследования проводят, как дорого менять менеджеров. Это действительно дорого, т.к. меняется не только менеджер, а вся система, которую он собой олицетворял.
Основной алгоритм
Если кратко, то нужно проактивно отличиться в чем-то, понятном и ценном для ЛПР — того человека, который принимает решение по нужной вам должности.
Пение в хоре и танцы на корпоративе, наверное, тоже помогут отличиться, но я не припомню ЛПР, для которых пение и танцы имеют значение. Похлопают, может даже по плечу, и на этом все кончится.
Чтобы понять систему ценностей ЛПР, надо, во-первых, его найти. Посмотреть по истории, поспрашивать коллег, а самое лучшее — понаблюдать за происходящим внутри компании некоторое время.
Поняв систему ценностей ЛПР, вы убедитесь, что она совершенно нормальная. Обычно этот человек хочет быть избавленным от какой-то боли, а лучше — от всех сразу. И это не зависит от его собственного уровня в иерархии компании: если он руководитель, то у него всегда полно болячек.
Немного другое дело — собственники. Их отличие в том, что болезни у них более настоящие, а не выдуманные, как у менеджеров. У собственника, например, нет потребности в прикрывании своей задницы, а у всех менеджеров — есть. Поэтому, если ваш ЛПР — менеджер, посмотрите, от чего обычно горит его задница, и подумайте, как его от этого избавить. Но если вы работаете с собственником, то не тратьте время на его задницу — ее надо от таких проблем прикрывать, какие программисту обычно не под силу.
Например, работал я на заводе, подчинялся финдиру. Финдир хотел от меня быстрого перехода на 1С. Чего хотел гендир — не знаю, не думал об этом. Я считал, что у меня два ЛПР, но работать надо с финдиром. Перешел на 1С за месяц, финдир был счастлив, но гендир воткнул выше меня какого-то левого парня, и назвал его ИТ-директором. Почему?
Во-первых, я неправильно определил ЛПР — не стоило ждать, что финдир пойдет за меня впрягаться.
Во-вторых, я не знал систему ценностей гендира, и не пытался узнать, а просто сделал проекцию — как будто гендир хочет того же, чего и финдир — быстрого перехода на 1С. Оказалось, что гендир не знает, что такое 1С, зачем куда-то переходить, а главная ценность ИТ для него — работающий лично у него интернет и вайфай по всему заводу. А я искренне считал вайфай второстепенной задачей, и не обращал на нее внимания.
В итоге ИТ-директором стал бывший сисадмин, которому было не в лом сбегать и самому перезагрузить роутер.
Как вы сами теперь понимаете, у ЛПР редко болит что-нибудь уровня документа, отчета или даже подсистемы, поэтому такими способами наверх не доедешь. Маловероятно сделать карьеру, занимаясь исключительно программированием — никакой серьезной боли этим не вылечишь.
Болит обычно более комплексно и широко, и звучит как-то наподобие «бардак на складе», «продажи и закупки не могут договориться», «ужасная дисциплина, не добьешься исполнения задачи», «очень медленно разрабатывается новая продукция», «постоянно простаивает производство из-за дефицитов». Как видите, чисто программистскими методами такие боли не снимаются.
Услышать и понять эти боли несложно – достаточно начать слушать и наблюдать, а не говорить или ждать задачи.
О том, что болит, обычно говорят часто, но урывками – о частных случаях проблем, косяках, потерях, неудачах и т.д. Такого, чтобы прям сказали «наша боль – вот это вот», обычно нет. Поэтому надо научиться информацию сопоставлять самостоятельно, по обрывкам, группировать ее и составлять общее мнение.
Если не будете лениться, то понимание реальных болей войдет в привычку, и вы будете постоянно понимать, что не дает компании развиваться. Что важно – другие этого понимать не будут, потому что у них нет такой цели. Они будут концентрироваться на текущих задачах и проблемах, пожарных вопросах, требующих немедленного и, как правило, ручного вмешательства.
Реального решения требуют системные проблемы, а не сиюминутные, но возиться с системными никому не хочется, потому что никто не умеет. Умение решать системные проблемы – это голубой океан для карьеристов.
Когда боли будут вам ясны, останется выбрать, с какой начать и попробовать ее решить.
Как выбрать
Рассматриваю ситуацию, когда вы решаете системную проблему в первый раз.
Критерий номер один – не беритесь за самые важные и критичные проблемы. Во-первых, вам никто не даст. Во-вторых, высокая стоимость риска ошибки будет на вас постоянно давить, и страх не даст вам действовать хоть сколько-нибудь эффективно.
Критерий номер два, опциональный – лучше браться за кросс-функциональные проблемы – те, что находятся не внутри какого-то отдела, а на границе. Это проблемы взаимодействия обычно.
Фишка в том, что проблемы взаимодействия обычно некому решать. Теоретически, этим должны заниматься всякие бизнес-аналитики, директора по организационному развитию и прочая нечисть, но в большинстве компаний их тупо нет, а в меньшинстве они ничего не умеют делать.
Собственно, эти проблемы оттого и так актуальны, что за них никто не берется. Граница между отделами почти всегда ничья, за нее никто не отвечает.
Ну и второе – если вызоветесь решать внутренние проблемы любого отдела, то с вероятностью 99% будете посланы вдаль его начальником. Когда станете сертифицированным бизнес-программистом, тогда вас начальник отдела сам позовет, а пока не лезьте. Мотивация у начальника простая – если какой-то хмырь пришел к тебе решать твои проблемы, то у тебя управленческая импотенция. А кто хочет жить с таким диагнозом, известным всем окружающим?
Критерий номер три – берите то, что никто другой брать не хочет. Вам не нужна конкуренция на начальном этапе, т.к. она будет отвлекать силы и время.
Критерий номер четыре – берите то, за что уже кто-то брался, но не победил. Если у вас получится, то вы покажете себя в сравнении. Если те, кто не справился – менеджеры, то вы автоматически становитесь в чем-то лучше их.
Ну и последний, пятый критерий – не беритесь за внешние проблемы предприятия, ваша цель – внутренние, системные противоречия.
Большинство менеджеров думают, что для развития и роста предприятия ключевое значение имеют продажи, рынки, маркетинг и тому подобная лабуда. Если поймете, признаете и согласитесь, что ключевые проблемы лежат внутри бизнес-системы, а потом научитесь их решать, то у вас почти не останется конкурентов.
Внешние проблемы кажутся заманчивыми, но давно превратились из задач в отмазки типа «оптимизация бизнес-процессов – это все херня, главное – чтобы клиентов много было». А т.к. привести много клиентов никто не умеет, то ситуация остается без изменений. Обвинить в том, что клиентов мало, особо-то и некого – все отмажутся, что это внешняя среда, там нет приемов и методов, там мэджик какой-то нужно знать, таинство продаж, нужен гуру или магистр Йода, и тому подобная чушь.
Самый простой способ убедиться в этом – зафиксировать внимание на ситуации, когда спрос начинает превышать предложение, а такое бывает почти у всех. Вот они, клиенты, на отсутствие которых все кивали, когда не хотели заниматься системными проблемами. Чего тогда продажи не растут? Почему клиенты, которых привели, отказываются с нами работать? Почему сроки поставок срываются? Качество продукции не выдерживает конкуренции? Себестоимость выше, чем у конкурентов?
Тут и начинают менеджеры решать реальные проблемы, а клиенты начинают разбегаться. Еще ничего не успели придумать и изменить в бизнес-системе, как уже снова пожар – клиентов не хватает, тут уж не до оптимизации. Так и бегают, как собака за своим хвостом.
Как реализовать
Когда выбрали, надо делать. Тут, увы, единого рецепта нет – нужно знать и применять множество методов бизнес-программирования.
Вообще, бизнес-программирование – не для того, чтобы карьеру руководителя строить, я вообще против руководителей, как таковых. Но сам я строил карьеру именно бизнес-программированием и точно знаю, что это очень простой и кайфовый путь. Никакие стероиды с ним не сравнятся.
Запасной путь
Если неохота возиться с проблемами других подразделений, а карьеру построить хочется, то у вас всегда есть запасной путь – бизнес-программирование внутри ИТ-отдела. Я этой возможностью часто пользовался.
В ИТ-отделе всегда полно проблем, не связанных с программированием. Организация работ, мотивация, эффективность, стоимость, взаимодействие с заказчиками и пользователями, проектное управление, закуп, сервисные услуги, даже какое никакое управление запасами есть. Можно сказать, что ИТ-отдел – это вся компания в миниатюре.
Но главное – вы уже внутри. Просто выбирайте и улучшайте.
Помните лишь об одном – ваша работа должна звучать, как абстрактный менеджмент. Как будто вы не программист, а бизнес-программист, или не привязанный к функциональной специфике менеджер или консультант, которого пригласили для решения проблемы ИТ-отдела. Такое ведь и в жизни встречается, согласитесь? Когда зовут чмыря со стороны, чтобы он вашу работу улучшил. Зачем же ждать этого чмыря, если можно самому попробовать?
Кайф в том, что нет препятствий и конкуренции, не надо ни с кем договариваться и спорить, оценивать риски и заниматься челночной дипломатией. Просто берете и делаете, помня, что вам этот результат надо будет продать, как менеджерский.
Например, сделайте так, чтобы задачи пользователей решались быстрее, допустим вдвое. Сразу поставьте систему замеров – тупо от даты подачи или принятия в работу до даты согласования результата заказчиком. И начинайте работать над снижением этого времени.
Когда достигнете устойчивого снижения, продавайте свой результат. Напишите письмо, или несколько, разным людям – например, руководителям подразделений. Или ЛПР, если нашли такового. Директору, собственнику. Часто бывает какая-нибудь штука вроде отдельного ящика для вопросов директору – и туда запулите. Кратко, емко, с цифрами в графиках и описанием основных менеджерских приемов. Сарафанное радио используйте – в курилке, столовой, маршрутке – рассказывайте о том, что сделали. Без хвастовства, не настойчиво, просто как интересный факт. Обязательно найдутся люди, которые это запомнят, а среди них – те, кто сделает «репост», и оно дойдет до гендира.
У меня так было с внедрением Scrum. Внедрил, ускорил вдвое, написал письмо. С гендиром отношения были на тот момент натянутые, он не отреагировал. Потом он сам где-то в менеджерских источниках услышал про Scrum, прочитал книгу, впечатлился, захотел узнать побольше и… вспомнил про меня. Пришел внезапно, посмотрел на доску, задал несколько вопросов, увидел что все – реально, и наши отношения резко стали позитивными – я стал одной из его опорных точек в изменениях.
Автор: Иван Белокаменцев
