Мышление письмом по пробному письму курса “Стать тимлидом”. Т.е. это нулевое письмо, скорее всего у него две цели: маркетинговая (продать курс) и ознакомительная (показать, что примерно будет внутри).
В разработке есть две равнозначные траектории роста — вертикальный (лидеры) и горизонтальный (хакеры).
Меня интересует это письмо, чтобы в очередной раз для себя покопать тему путей развития программиста. Сильно не буду придираться к выбранным названиям, это метафоры.
Быть лидером в команде — значит брать больше ответственности за результат, выстраивать коммуникацию между участниками, а вместо новых технологий изучать работу соседних отделов, чтобы приносить им больше пользы. Не писать код, а быть связующим звеном между бизнесом и разработкой.
Здесь идёт описание роли “лидер” и трактовка в каком-то айтишном варианте. Тут же у меня уже есть дребезг. Либо надо начинать вводить иерархию, какие бывают лиды(техлиды, тимлиды, руководители группы разработки и т.д.). Либо не верить. Потому что по-моему опыту и осведомленности классические (ближайшие к разработчикам) лиды не могут не писать код и забить совсем на свою техническую экспертизу. Т.е. когда мы вот так пишем, что мол пойду я в тимлиды и стану-ка чистым менеджером (автоматически), это неправда. Это можно было бы назвать траекторией. Но в таком виде она сразу же несёт риски.
Обычно лидеры растут в СТО или других управленцев, а обратно в хакеры переходят, только если выгорают из-за неправильного выбора мотива на старте (поговорим об этом ниже).
Как раз это один из рисков. От неправильного понимания роли. И отсутствующего ролевого мастерства.
Быть хакером — значит прокачивать хард-скилы: писать код и разбираться в десятках технологий. Обычно хакеры растут в техлидов или архитекторов, но бывают и другие варианты.
Вот некая иерархия проявилась. Хотя и тут закопан топор войны. Я в соседней ветке специализаций видела обсуждение, что в архитекторы растут из системных аналитиков. И всё чаще встречаются истории, когда некие сугубо технические должности занимают люди не имеющие хардового опыта именно разработчика. Если взять вот эту история со становлением СА архитектором, то может оказаться, что до этого он был тестировщиком. А может и вовсе человеком с улицы, который прицельно выучился именно на СА. Разработчикам такое очень не нравится. Так же как и менеджер, который теперь их начальник, но хардовой мощности в прошлом у него нет. Он почти сразу воспринимается, как очередная говорящая голова. Которой нужно вчера и неважно, что это нереалистичное требование, а магии не существует.
Хакер принимает технологические решения, следит за трендами и закрывает задачи своими руками. Ему не нужно налаживать процессы в команде и гораздо меньше приходится общаться со стейкхолдерами.
В этом описании тоже есть закодированный перекос. Харды, руки только свои, “общаться не умеет”. Но это тоже достаточно давно неправда. И потому что мы работаем командами (разного размера) и потому что часто ни от кого из аналитиков не допросишься внятного описания. А значит надо идти и общаться “с бизнесом”. И да, общаться всё ещё надо на птичьем языке. Иначе мы не поймём друг друга и будет “всё сделано по ТЗ, не работает”.
Но всё же самое главное отличие лидеров от хакеров — в эмоциональной нагрузке.
Результат лидера — это всегда результат всей команды. Результат хакера — чаще всего его личный результат. Из-за этого амплитуда эмоциональных колебаний у лидера гораздо выше.
Я соглашусь, что основная нагрузка коммуникативная. А с учётом среднего уровня собранности в команде и отсутсвия пройденного курса по онтологике. Общаться сложно, дорого, долго и неэффективно. При этом у лидера с проседанием собранности весь коллектив будет стремиться отжать всё доступное время на коммуникации. Что он при этом может налаживать и как это может хорошо влиять на результат всей команды, большой вопрос. Как раз из-за этого вопроса и создаются подобные курсы. “Как не сдохнуть в новой менеджерской роли, когда я инженер”.
Разработчикам-хакерам проще получать вознаграждение за свою работу: закрыл таску — увидел в burndown-чарте, закрыли спринт — похвалили друг друга на ретроспективе, предложил, как упростить код, — коллеги сказали «спасибо».
И да, и нет. Конечно горизонт получения неких рабочих продуктов у разработчика “в среднем” по больнице меньше, чем у тех, от кого ждут релиз. Но здесь очень сильно зависит от агентности конкретного разработчика и того, как его учили работать. В наших нынешних системах, где всё со всем связано и чтобы дотащить до прода одну небольшую задачку нужны слаженные действия 5ти команд. Стало сильно сложнее получить вот это состояние “я закрыл задачу”. Только если не считать выложенный в репозиторий код - окончательным этапом своей деятельности. Но уже даже без ШСМ многие слышали, что код в репозитории и работающая программа это разные вещи. И польза есть от работающей правильно у заказчика программы, а от кода в репе - пользы нет. Это просто описание.
При этом я всё чаще чувствую, что ответственность на лиде она более размазанная. Так же как и на всех остальных, спускающих нам запросы на задачи. Релиз не доехал в срок. Кто виноват? Или чья ответственность? Всей команды. Хотя опять же когда на проде чего-то нет или что-то работает не так, как ожидалось, кто виноват? Разработка. Кто делает, то и не прав. Как будто. Т.е. лид всё-таки отвечат за весь процесс поставки в конкретной команде или что у него является оргзвеном. И если процесс плохой (может он и до него был плохой), а он пытается его улучшить, то в моменте все фейлы мимо него. У нас же “время изменений”. А магии всё ещё нет. Хотя некоторые заказчики постоянно смотрят на разработку, как магический чёрный ящик. И раз он желание не исполняет, значит плохой джин. Надо купить нового или надо больше джинов.
Руководителям сложнее: никто не похвалит за изменения в процессах, потому что раньше было лучше, никто не обрадуется новым требования к коду и уж тем более не будет рад увольнению. В работе руководителя весь полезный выхлоп отложен во времени.
Про время сказали. Про измеримый выхлоп интересный поинт. Если ваших изменений не видно, значит надо их сделать прозрачными. Это как раз вполне себе выглядит как задача, а не проблема. Что угодно можно мерить, раньше у нас 3 человека в два месяца увольнялось, а теперь 3 в год. Раньше программисты каждый день ругались в чате, что какие-то проблемы с инфраструктурой и они не могут работать. А теперь одно сообщение в месяц. Я бы за такое хвалила и вроде хвалю. Стендов добавили, спасибо.
У хакера есть суперинструмент, чтобы увеличить вознаграждение: можно побольше поработать, чтобы закрыть побольше задач (мы ни в коем случае не призываем так делать).
Хаха. Есть суперинструмент, работать меньше за те же деньги. Собранность называется. Второй суперинструмент уволиться и найти, где платят больше за ту же квалификацию.
Лидер так не может — вознаграждение зависит от потраченного времени далеко не линейно: вряд ли команда станет лучше писать код, если вы недельку позадерживаетесь на работе, чтобы разгрести бэклог технического долга или описать изменения в процессах.
Это тоже про собранноть. И эта зависимость общая для всех. Продуктивность вообще от времени очень мало зависит.
Компании заботятся о том, чтобы хакерам было комфортно работать: ограничивают количество задач в спринтах, изолируют рабочие места от шума, упорядочивают коммуникацию, добавляют поддерживающих ритуальчиков.
Ещё раз хаха. В какой-то параллельной вселенной бизнесу есть дело, до того, чтобы разработка не перетруждалась.
Если хакер не умеет управлять собственным временем — добрый менеджер всегда потыкает палкой.
Плохой, хороший, злой. Готов тыкать палочкой два раза в час.
У лидеров рабочие места менее стандартизованы: никто не задумается о вашем состоянии, когда будет присылать вам приглашение на седьмую встречу за день, никто не предложит отключить уведомления из слака, если увидит, что вы не можете даже на минуту сосредоточиться на важных задачах.
Вот это общие проблемы. Да, у разработчика поток входящих в пару раз меньше, чем у лида. Но проблемы те самые.
Нужно много рефлексировать и самому вылавливать проблемы, которые пожирают внимание и ломают продуктивность.
Моделирование и Собранность всем!
Чтобы хорошо выполнять работу, лидер должен быть энергичным. Перекладывать JSON и шлёпать формы теоретически можно и лёжа на диване в полусне, а вот принимать острые эмоциональные решения вроде увольнения людей, смены стратегии или отказа от требований бизнеса можно только находясь в трезвом уме и здоровой форме.
Все должны быть в хорошей формы. К сожалению или счастью просто перекладывать JSON’ы уже давно не достаточно.
Лидер — это атлет. Важно всё: как лидер ест, как спит, с кем говорит — всё это влияет на то, насколько лидер спокоен и уравновешен.
Меняем “лидер” на “агент-человек”.
Есть такой стереотипный сценарий: хороший программист писал код и, чтобы заработать денег, получить больше свободы и сделать жизнь интереснее, уходит в управленцы — и не тянет. Такие ребята обычно несчастливы: они достигают плохих результатов как управленцы и часто сваливаются в то, чтобы писать код за подчинённых. Первое время это нормально — управленческие навыки пока не выросли. Но если вы продолжаете так управлять через год, то пора остановиться и подумать, как это можно делать иначе. Скорее всего, проблема в долгосрочной мотивации.
Скорее всего проблема в том, что роль изменилась. А паттерны работы остались старые. И конечно “больше свободы” и управление это примерно, как “я выгорел, как лид, пойду в тестировщики отдохну”. Ага, тестировщики ж ни капли не бутылочное горлышко и бездельничают большую часть времени. Это тоже интересный шаблон: я устал, я вместо того, чтобы полноценно отдыхать, меняю один источник неприятных ощущений, на другой.
Патрик Ленсиони в книге «Мотив» говорит, что на фундаментальном уровне есть две причины, побуждающие людей становиться лидерами: вознаграждение и ответственность.
Вознаграждение. Лидерство — награда за многолетний тяжёлый хакерский труд, поэтому теперь работа должна стать приятной, давать возможность выбирать занятие и избегать рутины и дискомфорта.
Ответственность. Лидерство — это ответственность, руководство может быть трудным и сложным.
Здесь какие-то мутные выводы. В каком месте лидерство может быть отдыхом и избеганием дискомфорта непонятно. Т.е. я единственное могу предположить, что это сказка про предпринимателя. Сидит себе парень в офисе 7 дней в неделю, задачи ему выдают, ему не очень интересно, часть денег отжимают капиталисты. И он такой: всё я решил, стану свободным человеком, открою своё дело. Буду работать на себя! Если ему тут сложность не видна, а видны только “перспективы” самому выбирать на что тратить время. То я ему сочувствую. Даже переход на удалёнку показал банальные вещи: все неочень крутые ништяки офиса, которые тебе давала контора, гораздо сложнее и затратней организовывать себе самому дома. Особенно если заметить, что очень много вещей было скрыто от твоего внимания. А тут вдруг, оп и оно само не работает.
В какое-то просто стремление к ответственности я тоже не очень верю. Мы тут в клубе говорим о том, что “сложность - кайф” потому что у тебя есть возможность сделать что-то более масштабное. И только поэтому ты готов грызть сложность, учиться разным ролям и т.д. Сама по себе большая ответственность не является мотивацией. Разве что это какой-то вариант радоваться тому что “вот теперь я большой начальник”. Но там же работать надо, а эта радость очень эферное чувство. И выглядит не очень, как “я начальник, ты дурак”.
Последний вопрос: можно ли совмещать оба пути?
Можно качать оба направления одновременно, но это сложный и дорогой путь. Чтобы стать многоруким Шивой, скорее всего, придётся пожертвовать какой-то другой областью: семьёй, здоровьем или хобби. Поэтому мы советуем не усаживаться на оба стула одновременно, а сначала стать классным в чём-то одном.
Третий путь пойти качать трансдисциплины интеллект-стека)
Выводов не будет. Я понимаю, что не понимаю менеджмент. Поэтому лезть туда до прохождения 3х семестров не зачем. Собственно история про я попробовал и подгорел, у меня уже есть. История про стать таки крутым спецом (где там эта контора, которая заботится о хакерах) пока очень больно бьётся об процессы. А совсем выключить агентность и работать от ТЗ до обеда я не могу. Мне дискомфортно и без результатов, и без смысла.
