Как строится репутация

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

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

Из этого получается следующая логика:

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

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

Никогда не используйте DISC

Менеджеры очень любят оперировать простыми моделями. Это желание понятно – реальность вокруг очень сложная, страшная и непредсказуемая, что делать – решительно непонятно. Особенно это относится к работе с людьми. Все мы сталкивались с конфликтами, возникшими практически на пустом месте, с увольнениями, которые никак нельзя было предсказать, и другими событиями, разрушающими выстроенную в голове реальность.

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

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

И ладно бы еще DISC был просто бесполезным, но он еще и вреден:

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

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

Давайте пообсуждаем пост про DISC тут. Обновленный спам-бот в чате типизирует себя как D по DISC, поэтому доминантно принял решение сам, и удалил комменты к прошлому посту.

Что определяет сильных инженеров

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

👉Вера в себя. Сложные проблемы всегда несут с собой огромное количество неопределенности. Вы не можете их оценить, вы не понимаете их технических деталей, вы не можете сходу сформулировать путь их решения. Для многих работа в такой обстановке невозможна. Вера в себя помогает не бояться таких проблем, браться за них. и постепенно эту неопределенность снимать.
👉Прагматичность. Для таких инженеров качество решения определяется не его элегантностью или какими-то другими критериями в вакууме, а тем, насколько эффективно оно решает изначальную проблему.
👉Скорость. Благодаря ей появляется возможность пробовать много разных подходов к решению задачи, и выбирать самый жффективный. Скорость важна и на длинном горизонте – чем больше разных идей инденер пробует, тем больше опыта он накапливает.
👉Технические скиллы. Здесь сложно выделить какой-то базовый уровень, но основная идея такая – хорошая техническая насмотренность помогает инженеру увидеть пути решения задачи, которые остальным будут не очевидны.

Баги – не проблема, а ее симптомы

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

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

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

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

Что посмотреть на выходных

Когда-то я очень сильно угорал по организации конференций. Началось все с небольших камерных митапов про iOS разработку, которые мы с командой собирали на мансарде Рамблера, продолжилось совместными с Онтико полноценными конфами AppsConf и ProductFest, а закончилось уже собственными онлайн-конференциями Podlodka Crew, когда мы в пике делали что-то около 40 мероприятий в год. Главная вещь, которую я за это время понял – конференции вообще непредсказуемы. Насколько успешно получится привлечь посетителей, с какими организационными проблемами предстоит столкнуться, какие спикеры исчезнут в самый последний момент – все эти вопросы будут не выходить из твоей головы до самого последнего момента.

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

👉Алексей Пименов про управление изменениями с помощью карт гипотез. Хороший системный подход к тому, как расставлять приоритеты в изменениях, и выстраивать стратегию, опирающуюся на логику, а не интуицию.
👉Сережа Попов про доверие. Как оно проникает в коммуникации и помогает строить отношения в команде.
👉Глеб Михеев про то, как перестать со всеми сраться, и начать договариваться. Это вообще моя любимая тема, с которой мы начали новый год в этом канале!
👉Андрей Смирнов про то, как извлечь пользу из хаоса в компании. Согласен с основным посылом про то, что работа в компании, проходящей через такой этап – отличная возможность прокачать свои навыки и найти неочевидные пути для карьерного роста.

Месяц с AI-джуном в команде

Весь прошлый год практически каждый день анонсировали какой-то новый прорывной продукт, использующий AI, а программирование хоронили еще чаще. Но даже на фоне всего этого информационного шума анонс Devin довольно сильно выделялся. В чем суть – это полноценный AI-агент, которому доступны все нужные разработчику инструменты: браузер, IDE, консоль. Все общение проходит через Slack, где вы просто просите решить какую-то задачу, а Devin асинхронно решает ее, приходит за уточнениями и рассказывает о статусе. Короче говоря, именно тот AI, которого мы все ждали!

На деле все оказалось, конечно, совсем не так весело. Команда, попробовавшая поработать с ним в течение месяца на реальных задачах, скорее разочарована:

👉Из 20 делегированных ему проектов он справился с 3, завалил 14, и в еще 3 случаях задачу хоть и решил, но лучше бы это сделал человек. Вот тут, кстати, есть поисание всех задач.
👉Лучше всего ему даются задачи с небольшим скоупом и очень хорошо сформулированные. При этом пользы от делегирования их AI не очень много, потому что времени они не отнимут и у обычного инженера, осоьенно вооруженного нормальным AI ассистентом.
👉Он подвержен той самой проблеме 70%, о которой сейчас модно рассуждать: первые видимые результаты можно получить очень быстро, но докрутить до продакшн-состояния занимает столько времени, что проще все было сделать самому.

Но я вообще AI-оптимист, и верю, что вот такие заметные провалы – необходимый шаг для того, чтобы получить реальный рабочий инструмент. Способности моделей продолжают быстро расти, UX вокруг взаимодействия с человеком, валидирующим результаты их работы, улучшается, они учатся использовать все больше и больше инструментов и опираться на все более сложный контекст. Еще год-два, и спокойно сможем делегировать агенту заполнение таймшитов в Jira и хождение на дейлики!

Что означают девятки в надежности сервисов

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

1️⃣ С каждой следующей девяткой сложность инфраструктуры растет экспоненциально. Например, если для 99.9% надежности достаточно сервера в одном регионе, то 99.99% влечет за собой деплой сразу во много регионов, автоматический хелсчек и более сложные алгоритмы восстановления.
2️⃣ Такая оценка дает лишь очень приближенное представление о реальной надежности, так как скрывает много нюансов. Например, игнорирует частичный отказ сервисов, и предполагает равномерное распределение отказов по времени. Для пользователя картинка выглядит по-другому, и одно падение на час может быть существенно хуже, чем 200 минутных падений в течение года.
3️⃣ Не стоит стремиться к наибольшему количеству девяток, так как более высокая надежность влечет за собой кучу трейдоффов. Например, будут страдать скорость разработки и существенно расти косты на поддержку. Иногда придется даже жертвовать пользовательским опытом – упрощать фичи, чтобы архитектура системы была проще, или заменять синхронное действие сложными асинхронными распределенными транзакциями.

Хорошие вопросы, которые помогут понять, а что именно вам нужно в плане надежности:

👉Как влияют на бизнес разные типы инцидентов?
👉Где во всей системе мы можем иметь разные уровни стабильности?
👉Как надо обрабатывать случаи частичного отказа каких-то частей сервиса?
👉Как повышение надежности влияет на скорость разработки и возможность делать что-то новое?

Откуда берется бюрократия

👉Когда сотрудников становится больше, чем человек может удержать в голове, становится сложно понять, к кому конкретно надо прийти, чтобы обсудить свою проблему. Это ведет к усложнению структуры организации и коммуникаций, и вот она – бюрократия.
👉Люди боятся рисковать, даже если выгода перевешивает потери. В компании это усиливается. Представьте себе проект с одинаковым шансом потерять $1М и заработать $10М. Большинство линейных сотрудников не возьмут на себя такой риск, так как потеря статуса в случае неудачи несравнима с пользой, которую они получат от выигрыша. Бюрократия может появляться, чтобы компенсировать этот эффект.
👉Если вам нужно принять какое-то решение, чаще всего для этого достаточно 1-2 конкретных людей. Но при этом всегда есть кто-то, кто обидится, если его не позовут. Быть плохим и наживать себе врагов никто не хочет, поэтому размер групп раздувается до огромных комитетов и тяжеловесных процессов.
👉Вместо честного разговора о проблемах проще внедрить процесс, который распределяет ответственность на систему, а не на конкретного человека.
👉Культура компании притягивает тех, кто ей соответствует, и продвигает тех, кто хорошо в нее вписывается. Это особенно хорошо работает для бюрократии.

Новые выпуски подкастов про менеджмент

👉"Подлодка" про смену роли в IT. В этот раз мы не стали звать никаких гостей, и делились своим собственным опытом. Я, например, рассказывал и про переход из линейного разработчика в тимлиды, и из пипл-менеджмента в продакты. Если вас периодически посещают мысли, не попробовать ли что-то новое в сравнительно безопасных условиях – обязательно слушайте!
👉"Три тимлида заходят в бар" про managing up – как проактивно выстраивать отношения со своим руководителем и управлять его ожиданиями.
👉"Бреслав и Ложечкин" про то то, как выживать в мире позивной дискриминации, и то, насколько действительно имеет место гендерное неравенство.

Как организовать succession planning

Succession planning – это процесс, который помогает вам заранее продумать, кто займет ключевые роли в команде, если текущие сотрудники уйдут. Помимо очевидного менеджмента рисков, succession planning полезен тем, что помогает вести более осмысленные карьерные разговоры.

Вот как организовать процесс у себя:

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

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

Методологии разработки, о которых вы не слышали

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

1️⃣ShapeUp от BaseCamp

Весь цикл разработки делится на три фазы: Shaping, Betting, Building. На первой фазе команда исследует разные проблемы и экспериментирует с разными подходами к ее решению. На второй – стейкхолдеры выбирают, какие ставки сделать на основе предложенных решений. На третьей – в течение шести недель команда реализует MVP и доводит его до пользователей.

Выглядит похоже на стандартный Double Diamond, с небольшими локальными подкрутками.

2️⃣Plan > Build > Ship

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

3️⃣Get Shit Done

Внутренний процесс Shopify, который в основном крутится вокруг их внутреннего же инструмента трекинга. Вся работа бьется на отдельные проекты, задача которых – решить какую-то проблему пользователя. Работа бьется на три фазы, близкие к тому же ShapeUp: Think (исследуем проблему), Explore (исследуем область решений), Build (коммитимся на одном решении, разрабатываем и выпускаем его).

🌟Бонус для тех, кто дочитал: govno.works

Учимся финансовой грамотности

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

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

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

Моим проводником в вопросы разумного обращения с деньгами еще очень давно стал Павел Комаровский, которого многие из вас знают как автора канала RationalAnswer. Все началось с выпуска Подлодки про финансовую грамотность, продолжилось восхитительным докладом про личные финансы айтишников, а дальше – канал Паши всегда оставался у меня не под мьютом, и я постепенно набирался насмотренности.

Короче говоря, подписывайтесь на RationalAnswer. Вот посты, с которых можете начать:

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

Практикуем second-order thinking

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

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

👉"А что потом?". Думая о каком-то действии, задавайте себе этот вопрос несколько раз, пока не построите дерево возможных последствий ваших решений.
👉"10-10-10". Думайте о последствиях своих решений в трех временных горизонтах – 10 минут, 10 месяцев, 10 лет. Это поможет не фокусироваться на самых очевидных краткосрочных вещах.