«Что будет, если...», или Курс молодого тимлида

Всем привет. Меня зовут Роман, и я технический директор в Calltouch. Опыт на аналогичных позициях более пяти лет, в данной компании работаю последние полтора года. До этого был разработчиком, архитектором, руководил небольшими группами.

Сегодня поговорим о том, стоит ли идти в руководители или тимлиды. Я часто сталкиваюсь с этим вопросом: слышу его от коллег, встречаю на профильных форумах, да и что греха таить, сам когда-то им задавался.

Эта статья будет полезна, в первую очередь, молодым специалистам, которые планируют карьеру и встали на распутье, столкнувшись с подобным вопросом. Людям, перешагнувшим этот порог, я Америку не открою: вещи, о которых пойдет речь, очевидны и просты. Но не все и не всегда принимают их во внимание. Кто-то, вероятно, будет со мной не согласен — это нормально и даже хорошо. В спорах рождается истина.

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

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

Я бы хотел затронуть три основные проблемы, с которыми вы точно столкнетесь практически сразу.

Уйти (,) нельзя (,) остаться: трудный выбор коллектива

Вы доросли до того момента, когда приняли решение двигаться дальше, и устроились на новое место с повышением. Другая ситуация: руководство на текущем месте отметило ваши заслуги и решило вверить вам подразделение. В назначенный день вас представляют всем сотрудникам и торжественно произносят: «У вас новый руководитель, просим любить и жаловать». Страшно?

Тут возможны две кардинально противоположные ситуации:

• вы приходите в незнакомый коллектив;
• остаетесь в своем любимом, но знакомом до боли коллективе, просто теперь вы начальник.

У обеих ситуаций есть свои плюсы и минусы. Если есть выбор, я бы рекомендовал идти в новый коллектив. Это очень страшно и сложно, но если пройти этот путь — вы получите мощный левел-ап. Можно «потренироваться» на текущем месте и потом уйти в другое, но все равно все «грабли» придется собрать. Я не буду заострять внимание на этом варианте — он достоин отдельной истории. Кратко дам советы. Читайте литературу по психологии, управлению, менеджменту. Пробуйте, ошибайтесь и пытайтесь вновь. Главное — оставаться человеком в любой ситуации, это вернется. Это как учиться плавать: если на середину пруда выплыл — отлично, умеешь.

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

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

Кто, если не я?

Вы на должности, все круто. Что делать дальше? Очевидно, налаживать процесс во вверенном подразделении. Сюжет широко известной книги «Как пасти котов»: вот они пасутся тут такие, будем направлять их на путь истинный (сарказм, конечно).

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

Как обычно рассуждает такой человек? «Сейчас я всех научу делать так же круто, как я. Всем расскажу, объясню и, конечно, помогу. Я теперь руководитель, знаю все и могу донести до сотрудников». К сожалению, реальность вносит коррективы.

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

Что происходит в такой ситуации? Руководитель остается главным разработчиком, при этом у него добавляются еще и административные обязанности — ведь мы рассматриваем полноценного руководителя, а не тимлида с командой из двух-трех человек. С ростом подразделения количество времени, которое вы проводите на работе, увеличивается. Вы начинаете уставать и быстро перегорать. Если пытаетесь сохранять прежние рамки рабочего времени, что-то не успеваете.

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

Совет: забудьте. Это больше не ваш код и не ваше детище. У вас теперь другие функции.

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

Бизнес и разработка: найти точки соприкосновения и выжить

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

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

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

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

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

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

Пример утрированный, но это и есть бизнес. В наиболее короткие сроки вывести на рынок новое решение или продукт и урвать новую пачку клиентов, пока конкуренты думают.

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

П: «Что вы сделали за прошедшую неделю?»

Р: «Ну, мы внедрили суперподсистему отладки в нашу систему».

П: «И зачем? Чем нам это поможет?»

Р: «Как же, мы теперь в три раза быстрее сможем расследовать инциденты и чинить баги!»

П: «Это все круто. Вы, безусловно, молодцы, но как и, главное, кому мы это сможем продать?»

Знакомая ситуация? Скорее всего, да. А слово «рефакторинг» либо вызывает улыбку, либо сеет панику. Проблема? Еще какая.

Тут тоже есть две кардинально разные позиции.

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

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

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

Второй подход, достаточно распространенный, характеризуется крылатой фразой «хренакс-хренакс — и в продакшн».

Все равно как, кто — это нужно вчера. Даешь костыли и говнокод! Это действительно работающий подход, нередко сочетающийся с диктаторским управлением. Можно делать какие-то вещи в три, в пять раз быстрее. И они даже будут неплохо работать. Бизнес доволен, клиенты тоже, все круто.

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

разработчики еще в середине такого пути покидали компании. Их можно понять — такой подход как ком в горле.

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

Я не сторонник черного и белого — всегда стараюсь найти золотую середину. Качеством продукта ни в коем случае нельзя пренебрегать. Но и понять потребности бизнеса тоже важно.

Выход: лавировать, искать решения.

Выводы

Я постарался акцентировать внимание на трех важных, на мой взгляд, проблемах. Есть много других «граблей», с которыми придется столкнуться. Это и мотивационные подходы, и психологические моменты, и варианты стилей управления — куча всего, о чем достаточно литературы.

Отвечаю на поставленный вопрос — стоит ли идти в руководство?

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

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

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

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

Роман Хохлов

Технический директор

Calltouch