Несколько лет назад в моду даже в нашей стране вошло очередное корпоративное новообразование: Software Engineering Manager. Это даже на русский язык перевести сложно ― Инженер-Менеджер? Это как? Попытки объяснить это уже происходили в русскоязычном интернете, но без особых успехов. Чтобы не рассказывать своими словами удивительные взаимоисключающие истории о том, что, например, это такой узкоспециализированный тимлид, который должен досконально разбираться в своей области, но при этом вообще не писать код, но постоянно быть в курсе всех новинок, мы пошли другим путём.
Знакомьтесь, Карл Хьюс, бывший Software Engineering Manager. А нынче ― писатель. Неожиданный поворот в карьере, но нам очень на руку, ведь о своём бытии этим самым Software Engineering Manager он написал целую статью. А мы её перевели. Кстати, эту должность у них сокращают до engineering manager, а иногда и до просто SEM ― так что дальше в переводе мы будем звать его Сэмом. Далее ― от лица Сэма.
Все восемь лет моей работы Сэмом в разных компаниях я следил за тем, на что расходуется моё рабочее время и записывал результаты. Это было очень полезно для выполнения своих рабочих обязанностей, ведь таким образом я понимал, на что я трачу больше всего времени и на что, соответственно, нужно обратить больше внимания при планировании. Простой пример: я тратил примерно треть всего рабочего времени на помощь команде в решении технических проблем, поэтому оставлял пустые места в календаре на следующие недели специально, чтобы у команды было время обратиться ко мне за помощью. А если бы я не обращал на это внимание и забил весь календарь встречами и стратегическими планированиями, то вместо вместо движения вперёд мы бы застопорились, потому что вопросы, которые мне нужно было бы разобрать с командой, постоянно откладывались.
Но ещё это оказалось очень полезным сейчас, когда множество потенциальных Сэмов постоянно спрашивают меня, что это вообще за работа такая и чем на ней предстоит заниматься. Я просто собрал свои записи, систематизировал их и сейчас пишу эту статью о том, как тратит своё время Сэм. Конечно, разные компании делают всё немного по-разному, и я тоже работал не в одной компании всю жизнь, но оно и к лучшему ― можно будет на примерах продемонстрировать некоторую разницу в подходах и как это отражается на Сэме.
Моя команда постоянно росла. В первый раз в похожей роли я выступал в стартапе, где, кроме основателей, был единственным сотрудником. Сейчас у меня много людей в команде, и я занимаюсь высокоуровневыми процессами, так что переход от непосредственной работе с кодом к управлению смог отследить изнутри. Сейчас, как Сэм, я отвечаю за то, чтобы помогать моей команде отдавать заказчику тот софт, который он хотел, вовремя и в рамках бюджета.
Звучит отлично, но что значит «помогать»? Что конкретно делать-то надо? Писать код? Следить, чтобы остальные писали код? Ответ очень простой: зависит от ситуации.
С одной стороны, код должны писать разработчики, а не Сэм. С другой ― Сэм должен отлично разбираться в вопросе, потому что одна из их главных задач ― помогать «застрявшим» коллегам, будь то решение чисто технических вопросов или разрешение споров на рабочую тематику. Мало того ― он должен обучать сотрудников и оценивать кандидатов в сотрудники, и, хотя нынче модно говорить про софт скиллз, ценности компании и командный дух, кандидат ещё и работать должен уметь. А Сэм должен уметь это проверять.
Ну и, конечно же, как и любой другой менеджер, кроме разве что менеджера по клинингу, должен хорошо ладить с людьм и разбираться в них. Несколько расплывчатый критерий, не находите? В чём это измерять? Некоторые считают, что для этого просто нужно быть экстравертом, но это совершенно не так. Главное ― иметь развитую эмпатию, применять её к своей команде и помогать им как в технических, так и в личных вопросах. Вот только измерить это, конечно, невозможно. Ну и мало того ― Сэм должен взаимодействовать с вышестоящим руководством, защищать команду при необходимости, но если надо ― уволнять людей, которые тянут всю команду вниз.
И если это всё покажется вам сложным, не волнуйтесь, самое сложное ― не это. Самое сложное ― определять для себя, насколько ты полезен и эффективен. Процитирую Николаса Минса: «Время от времени я замечаю, что прошёл очередной день, заполненный совещаниями, последнее только что закончилось, а по ощущениям ― я не сделал за день ничего. Весь день я общался с людьми, читал документы, чекинился и синхронизировался, весь вымотался, а в результате ― ничего». Это вам не «обычная» работа. Когда я был простым инженером, всё было понятно ― тут продвинулся по очередной фиче, там сделал пуллреквест, а когда я стал менеджером, стало очень сложно понять, где мой непосредственный результат.
Поэтому-то я и начал отслеживать, сколько времени и на что я трачу. Конечно, нельзя сказать, что это очень уж точный способ измерять, сколько я именно сделал, но по крайней мере это помогает структурировать работу Сэма и понять, достаточно ли я делаю того, что действительно необходимо.
Итак, распределение времени Сэма выглядит примерно так:
Технические вопросы — 35%
Менеджмент — 35%
Рекрутинг — 15%
Операционка — 15%
Технические вопросы ― это как стандартные задачи, такие как непосредственное написание кода, ревью, поиск багов, парное программирование, так и поддержание себя в форме ― изучение лучших практик, обновлений… Ведь Сэм должен быть лидером команды, а для этого нужно достаточно хорошо разбираться в деталях, чтобы быть способным помочь с ними команде. А чем больше ваша команда, тем меньше вы делаете руками самостоятельно.
Менеджмент включает в себя как встречи с командой, непосредственное ею управление, планирование, составление правильного расписания и так далее и тому подобное, так и взаимодействие с вышестоящим руководством ― а при необходимости защищать команду и выступать «прокладкой» между ними и начальством. В конце концов, поддержание позитивного настроя в команде не менее важно, чем помощь в создании спецификаций. Причём, что интересно, ― даже когда я перешёл скорее на уровень стратегического планирования и общения напрямую с основателями в одной из компаний, распределение по времени осталось примерно таким же, а значит, моя теория работает.
Рекрутинг в нашей работе занимает не самый большой кусок времени, но он должен идти постоянно. Сюда я включаю всё, что с этим связано, от статей в блог и посещения конференций и до непосредственного общения с кандидатами. А так как самые лучшие кандидаты ― это как раз те, кто не находится в активном поиске работы и сами вряд ли вас найдут, приходится быть в этом вопросе проактивным.
Ну, а операционка ― без неё просто не обойтись. Помните, вы не просто инженер, вы Сэм, команда будет лучше работать над техническими вопросами, если операционку вы возьмёте на себя. Вот и берите её. Держите ваш инбокс прочитанным, а слак ― беленьким.
В завершение хотелось бы дать три важных совета. Не претендуя на истину в последней инстанции и не пытаясь объять необъятное, поделюсь с вами самыми базовыми вещами, выработанными за эти годы.
Во-первых, дайте вашей команде работать. Вы Сэм, а не инженер, не нужно заниматься микроменеджментом, ваша задача ― как и любого менеджера ― сделать так, чтобы люди сами достигали результатов. Да, ваши личные достижения будут выглядеть блекло и однажды сойдут на нет. Думайте о достижениях вашей команды. Они растут? Вы молодец.
Во-вторых, коммуницируйте. Вы менеджер, это одна из ваших главных задач. Особенно сейчас, когда команда зачастую и не видит друг друга. Нужно донести какую-то мысль? Вспомните теорию 7 касаний из маркетинга. Я не имею в виду, что нужно повторять каждую мысль по 7 раз, но попробуйте доносить её со всех сторон. На созвоне, в почте, походя в слаке, лично, коллективно… Никто не любит изменений, но они происходят всегда ― и лучший способ примирить с этим команду это постоянно обо всём рассказывать, чтобы они быстро привыкали ко всему.
И в-третьих, будьте источником спокойствия. Не устраивайте корпоративных интриг, не отделяйтесь вместе со своей командой от остальной компании, даже если эти гуманитарии ничего не понимают ни в чём и только штаны просиживают на совещаниях, и уж тем более не пытайтесь управлять вашей командой по принципу «разделяй и властвуй». Наоборот, задача настоящего лидера ― в любой ситуации создавать конкретные планы, напоминать людям про конкретные цели и давать уверенность в том, что все движутся к единой цели. Вот и будьте настоящим лидером, раз уж взялись. Удачи!