Роли principal инженеров

Инженеры уровня principal почти такие же снежинки, как и тимлиды – они очень сильно отличаются друг от друга, и могут выполнять очень разные роли. Благодаря тому, что в Amazon инженерная команда бесконечного размера, принципалов тоже скопилось достаточно много, чтобы выделить самые частые и полезные роли, которые они могут выполнять:

👉Спонсор – лидер проекта, который разрабатывается несколькими командами. Отвечает за то, чтобы проект двигался вперед, проблемы, встающие перед командами, быстро решались, а решения вовремя принимались. Такую роль может выполнять и менеджер, но в случае принципала люди ему напрямую не подчиняются.
👉Гид. Доменный эксперт, глубоко вовлечен в техническую часть, в отличие от спонсора не занимается проектным менеджментом или организационными задачами. Часто драйвит архитектуру, но при этом не становится главным архитектором, вместо этого активно вовлекая всю команду. Продакшн код не пишет. Гид работает с целой командой, а не менторит отдельных людей.
👉Катализатор. Проводит проект от очень сырой идеи до момента официального запуска: пилит прототипы, готовит все нужные документы, получает buy-in от нужных стейкхолдеров. Как только проект запущен, катализатор либо меняет свою роль на гида или спонсора, либо берется за следующую идею.
👉Tie Breaker (помогите найти аналог на русском). Подключается к принятию очень важных решений, в которых нет очевидного правильного ответа, и которые команда не может принять сама. Он глубоко погружается в проблему, разбирает все точки зрения, принимает финальное решение и документирует его. Это временная роль, в отличие от всех предыдущих.
👉Ловец. Подхватывает проект, столкнувшийся с проблемами и сошедший с трека, и приводит его в порядок. Его основная задача – провести независимый анализ, выявить проблемы, придумать и осуществить план их решения.
👉Участник. Если принципал не занимает одну из перечисленных выше ролей, он работает как обычный член одной или нескольких команд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🔥Как повысить эффективность, минимизировать хаос и удержать команду, превращая проблемы в четко управляемые процессы?

⚡️22 января в 20.00 мск. приглашаем на открытый вебинар “Как построить процессы, а не проблемы?”, на котором:

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

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

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

❗️Разберем практические кейсы участников и ответим на вопросы

👉Не пропустите! Регистрация по ссылке https://otus.pw/Cyyg/

Открытый урок приурочен к старту курса "CTO/Технический директор". 5 месяцев обучения. Преподаватели-практики из ведущих отраслевых компаний. Выпускной проект - детальный план развития технического подразделения на один год, на три года и на пять лет.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

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

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

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

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

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

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

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

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

Авито нанимает 30 продуктовых менеджеров с помощью конкурса

Станьте продакт-менеджером в одной из лучших IT-компаний России, решив кейс и пройдя отбор.

Что такое Avito Product Bootcamp?

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

С 13 января по 2 февраля 2025 г. пройдёт регистрация. Отборочные этапы на платформе Карьерного Цеха.

Кому подойдёт? 

- Джунам с опытом работы в продукте, желающим ускорить карьеру в продуктовом менеджменте;
- Мидлам, желающим вырасти и укрепить навыки управления продуктом;
- Соискателям без продуктового опыта, но с пониманием работы продакта и мотивацией развиваться в продуктовом менеджменте

Почему Авито?

Авито — один из сильнейших продуктовых брендов в России, занимает 3 место среди дорогих интернет-компаний страны. Здесь выстроены здоровые процессы, команды автономны и ставят цели самостоятельно.

Отличный шанс прокачать навыки управления продуктом в классной компании ❤️
Регистрируйтесь сейчас и не теряйте время! 😉

Подробнее о мероприятии и условиях участия можно узнать: https://start.avito.ru/product-bootcamp

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

Когда-то я очень сильно угорал по организации конференций. Началось все с небольших камерных митапов про 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 полезен тем, что помогает вести более осмысленные карьерные разговоры.

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

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

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