Плохие советы о лидерстве.

Допустим, вы по какой-то причине посчитали, что хотите иметь, развивать или использовать лидерские качества. В таком случае мне хочется поделиться некоторыми советами, которые собраны из опыта.

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

1️⃣Обижаться.
Вы имеете дело с коллективом, кто-то может сказать или сделать что-то не так, испортить дело, доставить неприятности. Самое тупое, что можно сделать в такой ситуации - это обидеться на члена команды. Поругаться, выгнать из команды, проигнорировать, обсудить 1 на 1 - что угодно другое будет лучше. По сути что такое обида - это показное подчеркнутое эмоциональное недовольство чем-либо, с чем человек не может справиться. Это на биологическом уровне считывается как слабость и недостойное лидера поведение.

2️⃣Говорить людям "это не твое дело", "занимайся своей работой" и подобные вещи в ответ на вопросы или предложения.
Считывается как неуважение и/или страх/неуверенность в себе. Любому лидеру нужна вовлеченность людей в совместное достижение целей. Вовлеченный человек = любопытный человек. Интерес - это шанс увлечь и заработать лидерских очков, бить по рукам - способ их растерять.

3️⃣Дизморалить.
Унывать, говорить как "всё плохо", иными способами создавать тягостную и пессимистичную атмосферу. Конструктивный, решительный, бодрый или юмористический разнос негативных обстоятельств предпочтителен. В крайнем случае стоически/нейтрально.

Кстати, следствием этого пункта является часто другая крайность - токсичный позитив, оптимизм и грандиозность, распространенные среди лидеров. Это не в моем вкусе, но просто надо понимать, что работает всё что угодно, кроме дизморали.

4️⃣Выглядеть некомпетентным.
Если у вас о человеке мнение, что он не шарит в том, что он делает - ну маловероятно, что он вас на что-то сподвигнет ) Тут думаю понятно. Остается только нюанс в разнице между казаться или быть. Строго говоря, лидером может стать и тот, кто имитирует компетентность. Но лучше, конечно, шарить )

Советы разработке, часть 1

Команде разработки довольно часто дают советы. Сейчас это в основном призывы использовать ИИ, но и раньше было много всякого, начиная от того, что задачи надо делать быстрее, заканчивая предложениями работать по scrum (это мое любимое).

Вообще, разработкой обычно все недовольны, хотя и не показывают. И обычно это зависит не от качества и скорости разработки, кстати (в этом сложно разобраться), а от продаж. Если бизнес прет - обычно сойдет и сделанный из «говна и палок» продукт, и постоянные инциденты, и техдолг, и работающие по ставке сеньоров джуны из аутсорса. Если же не прет (а чаще всего он не прет, либо не так хорошо, как хочется) - тут обычно и начинается интерес к тому, а как же устроена разработка )

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

Помимо советов извне бывают еще советы изнутри команды. На моей практике ценными являются примерно 10% предложений извне и 80% изнутри. Вообще извне понять работу гораздо сложнее, чем находясь «на земле», это нормально.

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

И вот здесь есть пара моментов, на которые интересно обратить внимание:

Что делает непрофессиональный или недостаточно опытный менеджер, когда «большой начальник» вмешивается в его работу? Он бросает все и отдает максимальный приоритет тому, на что указано. Это на самом деле только усугубляет положение команды. Теперь со стороны это выглядит так, что «без меня ничего не делалось, а теперь начали». То есть вышестоящий руководитель лишь убеждается в необходимости своего вмешательства.

Вообще это интересный эффект, назовем его «эффект д’Артаньяна», когда люди думают, что без них не разберутся и их участие привносит какой-то невероятный прогресс в работу. Это искажение усугубляется тем, что, действительно, если топ-менеджер обращает внимание на какую-то задачу, чаще всего на нее бросают ресурсы. Снимая ресурсы с остальных задач, за которыми он не следит, и которые могут быть даже важнее. Поэтому, если далеко не думать, то ресурсы берутся как будто бы из «ниоткуда» и работа, которая стояла, начинает делаться ) Чтобы не падать жертвой этого эффекта, надо иметь некоторую фантазию и более стратегическое видение процессов.

Тем не менее, все советы важно профессионально рассматривать. Здесь практический совет:

1️⃣Вам стоит иметь бэклог инициатив по улучшению работы, с приоритетами. Добавлять туда идеи и улучшения, расставлять приоритеты. У любой нормальной команды полно идей, что можно сделать лучше, но часто в формате «поговорили и забыли»
2️⃣Когда появляется новое предложение - надо соотнести его с имеющимся бэклогом и не бросаться выполнять, а вставить его на соответствующее место, объяснив очередность. Это будет профессионально.

Дополнительная польза - реализованным инициативам стоит вести учет и периодически о них рассказывать, улучшая имидж команды.

Следующим постом продолжу тему, и расскажу чуть больше про предложения изнутри команды.

Советы разработке, часть 2

Другая интерсная штука - предложения изнутри команды. Как я уже сказал, по моей оценке примерно 80% таких предложений, в отличие от предложений извне - ценные. Правда, ценность релевантных внутренних предложений обычно мельче и более тактическая.

Здесь тоже есть практический совет:

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

Это по соотношению пользы и затрат невероятно выгодное действие:

1️⃣Во-первых, само предложение может быть ценным, так как на местах многие вещи виднее
2️⃣Во-вторых, если принять предложение в позитивном ключе - у человека будет интерес и работать в такой обстановке, и что-то еще предложить в другой раз
3️⃣В-третьих, если не выслушать человека - он будет демотивирован
4️⃣В-четвертых, грамотная дискуссия и критика неподходящего предложения - хороший способ обеим сторонам научиться чему-то

Это очень выгодное действие, поэтому нет причин, кроме непрофессиональных, его не совершать. Но под влиянием своего эго и страха человек может:

🅰️Подумать, что предложения улучшить работу как бы свидетельствуют о его несовершенстве, являются критикой его работы, так как исходят не от него
🅱️Посчитать это подрывом его авторитета, атакой на его личность и т.п.

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

✔️Может быть человек сегодня сделал какое-то несущественное предложение, а потом сделает еще 10, из которых 2 будет реально стоящих. Отклонив первое, можно убить желание сделать 10 последующих
✔️Субъективно оценивая со стороны - я (как и большинство) скорее ошибусь в сторону недооценки эффекта, который будет иметь изменение. Поэтому опасно ориентироваться только на свой вкус в этом вопросе
✔️Излишняя придирчивость к предложениям, требования подробного обоснования и расчетов - реально пугают людей, отпугивают их от экспериментов и инноваций в работе
✔️Цена ошибки обычно низкая, и если что пойдет не так - всегда можно откатить назад, и в этом случае лучше дать человеку ошибиться и понять свою ошибку, чем вообще не дать ему действовать

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

1️⃣Все предложения внимательно выслуживаются и рассматриваются по существу
2️⃣Инициативы по улучшению работы собраны в очередь по приоритетам
3️⃣Эта очередь периодически (раз в месяц или квартал) пересматривается и приводится в актуальность
4️⃣Вы устраняете препятствия и пробиваете нужные ресурсы там, где это от вас зависит
5️⃣Результаты освещаются внутри команды и идут в зачет при оценке результатов работы
6️⃣Результаты освещаются за пределами команды

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

Вчера было важное, в том числе для этого канала событие - мой последний рабочий день после ровно 4 лет в компании)

Как-то так само собой получается, что проходит полтора-два года, и судьба подбрасывает новый поворот, не давая долго засидеться на одном месте, итого технически я сменил 4 места работы и 6 ролей (3 прогерские и 3 менеджерские) за 10,5 лет. Одновременно с этим так выходило, что каждая следующая роль была лучше и интереснее предыдущей. Думаю, мне везет.

Помимо прочего это означает несколько хороших вещей:

1️⃣По идее у меня в ближайшее время будет гораздо больше энергии на создание контента. С творчеством, конечно, сложно загадывать, но обычно это работает так.

2️⃣Канал ждет целый ворох новых историй, накопленных за 4 года, которые пойдут в тираж после небольшого, уместного в данном случае карантина. Кто-то из читателей с удовольствием узнает себя - с удовольствием, потому что антагонисты этих историй не читают такие каналы (да и вообще, наверно, редко читают), разве что им кто-то доложит ))

3️⃣Я становлюсь открыт для новых приключений, а значит, вы или ваши знакомые можете пригласить или порекомендовать меня, если где-то требуется организовать команду разработки или провести трансформацию размером ~20-100 человек и решить все обычно сопутствующие масштабированию проблемы на стыке разработки и бизнеса, или сколотить сильную распределенную команду с нуля. Приоритет на remote-first компании, но если будет что-то реально интересное, можно и on-site в любой точке мира, кроме опасных для здоровья ) Контакты: мой линкедин или личка тг, которая указана в описании канала.

Приоритет на full-time Head of Dev/Engineering Management/Delivery, но чисто из спортивного интереса, так как я люблю решать организационные паззлы, можно попробовать подружить с кем-то и в формате консалтинга/контракта, если нужно решить в сжатые сроки конкретные проблемы бизнеса.

4️⃣Ну и, наконец, в силу разных причин за последнее время у меня собрался довольно существенный (пара десятков) нетворк специалистов, которые могут быть открыты к интересным предложениям. И про которых я точно знаю, как они умеют работать и готов честно дать характеристику)
Любой, кто нанимал, знает, насколько сегодня это гигантское преимущество по сравнению с холодным наймом. Там есть разрабы, лиды, QA и ПМы, AI-энтузиаcты и консерваторы, эмигранты, номады и жители России, талантливые новички и люди с 10+ годами опыта. Если тут есть нанимающие менеджеры, скауты или рекрутеры - обращайтесь.

А еще - у меня есть еще три недели в Алматы (перед отлетом во Вьетнам) и это отличная возможность встретиться еще разок перед отлетом со всеми желающими, опять же, пишите в личку, организуем )

Психология разработки - отношение к проектированию.

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

Очень четко видно, как менеджеры с другим бэкграундом обычно совершенно не понимают отличие в психологии разработчика от каких-то других профессий, и руководствуются клише, своими ложными стереотипами или просто перекладывают психологию других профессий (сейлзов, саппорта) на разработку.

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

Как и многие другие человеческие характеристики, эта является градиентом - от полного отсутствия продумывания что и как кодить на одном полюсе, до вечной прокрастинации и бесконечного цикла проектирования на другом.

Здесь есть две противоборствующие фракции - одна хочет ни о чем не думать и спекулирует тем, что надо делать просто и «fail fast», а другая любит прокрастинировать и поэтому топит за DDD и глубокое продумывание архитектуры и бизнес-логики превентивно )

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

Иными словами:

1️⃣Некоторые задачи требуют более глубокого проектирования и продумывания наперед, другие - требуют максимально простого и решения

2️⃣Решая, как сделать, разработчик может выбрать более сложный или более простой подход, чем того требует ситуация

3️⃣Выбор будет зависеть от его субкультурного бэкграунда (среди каких разработчиков он рос, как там было принято делать, кого он слушал как авторитетное мнение)

4️⃣Выбор будет зависеть от психологии его поведения - склонен ли человек избегать лишнего размышления или же, наоборот, склонен переусложнять и уходить в это как в форму прокрастинации (оверинжиниринг)

5️⃣3 и 4 факторы зачастую имеют большее значение, чем обычная аналитическая ошибка в оценке ситуации

Причем тут ситуация такая, что и для "делать максимально просто и не переусложнять" и для "думать как следует, прежде чем делать" - есть хорошее теоретическое обоснование и свой набор "лучших практик". То есть каждый представитель соответствующей фракции радикалов, который хочет упороться в крайность - найдет необходимую базу объяснений для этого (вышеупомянутые fail fast, DDD и многое, многое другое).

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

Представьте здесь аналогию: сказать, что не стоит так перерабатывать и нужно следить за work/life balance трудоголику, который выгорает на глазах, или сказать то же самое человеку, который всеми силами минимизирует свою производительность - и интерпретация, и результат будут совершенно разными.

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

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