Два типа IT-менеджеров

Два типа IT-менеджеров

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

Самообман

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

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

Хорошо ли быть из «своих»?

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

О чем тогда этот пост?

Вполне, обоснованно, спросите вы. Если все зависит от ситуации, то и в классификации нет никакого смысла, ведь так?

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

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

Проиллюстрирую такой ситуацией. Допустим, тимлид сидит и пишет код в офисе допозна, работает в выходные, проводит код-ревью в нерабочее время, коммитит вообще круглые сутки. Какой вывод сделает программист в его команде? "У нас ахтунг и аврал, раз мой тимлид сидит и пилит фичи без сна и отдыха, нужно включиться и ему помогать". Или такой: "хочу стать тимлидом — нужно коммитить круглосуточно". Или даже: "чтобы стать технически крутым, как наш тимлид, нужно работать без выходных".

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

А что с регламентами и инструкциями?

Тут — наоборот. Допустим, пишет проджект-менеджер регламент приемки релиза. Упрощенно, что-то вроде: "такой-то должен чекнуть, QA должны поставить галочку в джире, два аппрува реквесту и полетели". Если там все разумно, то вывод простой — надо, так надо.

А если такой же регламент пишет CTO, который раз в квартал коммитит сам по необходимости и именно он писал CI/CD. Очевидно же, что тут важнее не как он на бумажке написал, а как он будет делать сам.

Вместо вывода

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