Paolo Gallo | The Seven Games of Leadership | Talks at Google

Интересное видео из серии Talks at Google, в котором Paolo Gallo рассказывает про свою вышедшую месяц назад книгу "The Seven Games of Leadership: Navigating the Inner Journey of Leaders" и отвечает на вопросы аудитории. Сам Паоло когда-то был Chief Human Resources Officer в World Economic Forum in Geneva, was Chief Learning Officer at The World Bank in Washington, D.C., and Director of HR at the European Bank for Reconstruction and Development in London.

В самом видео автор начинает с рассказа о том, что он написал эту книгу для своей дочери-подростка, которая однажды его спросила "А чему ты научился папа за много лет своей карьеры". Дальше Паоло задумался и через неделю расска

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

Дальше он рассказывает про свою модель 7 игр лидера
1. Inner game - внутренняя игра, в которой человек пытается понять кто он такой, что его мотивирует, за что он выступает и в чем он хорош. Эти вопросы кажутся очевидными, но это совсем не так.
2. Better game - после того, как человек понял в чем он хорош, он начинает пытается это делать максимально хорошо. Это повышает авторитетность и мастерство в той игре, которую выбрал для себя человек. Тут важно, чтобы у человека была решимость продолжать совершенствоваться на протяжении жизни
3. Caring & outer game - на этом этапе этапе человек перестает думать только о себе и других людях (это часть про заботу) и дальше человек развивает контекстуальный интеллект и учится соединять точки и понимать как мегатренды влияют на его область деятельности (изменение в геополитике, климате, технологиях, демографии и так далее). Здесь происходит трансформация и расширение кругозора и понимание глубоких взаимосвязей
4. Crisis game - здесь наступает кризис, причем +/- у всех людей (обычно в районе между 40 и 50 годами). Здесь обычно возникает вопрос "А что я буду делать дальше" и для ответа на этот вопрос может потребоваться несколько лет. В общем, это игра в поисках нового смысла
5. Reinvent game - если смысл удается найти, то начинается игра с переизобретением того, что мотивирует человека
6. Revolution game - это изменения, от которых получат преимущества люди вокруг. Это такой альтруистический взгялд на вклад человека в улучшения, что принес человек в community, город, страну, ...
7. Let go game - иногда люди считают себя незаменимыми, но на этом этапе надо уметь отпустить это ощущение (или как говорил Людовик 14 "Государство — это я"). Здесь автор объясняет, что часто люди фиксируют момент, до которого они готовы двигаться, а потом нужно вовремя уйти. Это вопрос получения мудрости.

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

Мне эта модель понравилась своей краткостью и лаконичностью, а также тем, что она наводит на новые мысли в плане саморазвития. Мне даже захотелось купить книгу и прочесть ее целиком:)

#SelfDevelopment #Leadership #Management

Техно голос Tinkoff

Вчера у нас была очередная ежегодная раздача слонов от devrel направления, где я получил приз в номинации "Техно голос" за общий вклад в популяризацию нашего IT. С учетом прошлогодних призов "Адвокат бренда" в общем за активность и "Айти спешл" за "Code of Architecture" у меня теперь целых 3 стекляшки на подоконнике дома стоят:) Была еще номинация на премию Highload++, но там были другие победители:) В общем, прошлый год прошел хорошо, а в этом надо написать книгу и это будет уже успехом:)

P.S.
Отдельно отмечу, что мне стоит еще поработать над голосом и пройти курсы по постановке голоса и речи, если вы знаете крутые курсы, то напишите в комментах:)

#Devrel #Software

Модели консистентности (Consistency Models) от Jepsen

Продолжая серию постов про консистентность (CAP теорема, ее доказательство, PACELC) хочется порекомендовать ознакомиться с картинкой моделей консисетности от Jepsen, который проводит хардкорные тесты баз данных. На этой картинке видно две параллельные ветки serializable и linearizable, где первое вырастает из моделей изоляции транзакций RDBMS, а вторая из моделей чтения/записи атомарных значений. Прикольно, когда они встречаются на верхнем уровне strict serializable. Отдельно Jepsen дает ссылки на два whitepapers
- 2013 - Highly Available Transactions: Virtues and Limitations (Bailis, Davidson, Fekete et al)
- 2016 - Consistency in Non-Transactional Distributed Storage Systems (Viotti & Vukolic)

В общем, рекомендую почитать сайт Jepsen, полистать результаты его тестов разных баз данных, а потом еще и почитать два вышеупомянутых whitepaper. Это очень помогает при погружении в мир распределенных систем:)

#Software #Architecture #DistributedSystems #SystemDesign

AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

Продолжая вчерашнюю тему про модели консистентности, рекомендую посмотреть интересное выступление от ребят из AWS про значимый апгрейд их базы данных Aurora, которую мы как-то обсуждали в бонусном выпуске "Code of Architecture" и по которой есть whitepaper от 2017 года. Сейчас ребята добавили возможности масштабирования к этой базе данных. Причем тут фокус был на масштабировании write нагрузки, так как с read нагрузкой у этой базы уже было все хорошо. Если кратко описывать изменения, то смысл примерно такой

1) Добавляется семантика шардирования внутри самого Aurora - для этого у пользователей появляется возможности
- Пометить таблицы как шардированные и указать ключ шардирования - если транзакции попадают на один шард, то это максимально быстро, если нет, то используются распределенные транзакции двухфазный коммит. Для шардирования используется hash-range partitioning.
- Пометить часть таблиц как reference - такие таблички используются как справочники и они разложены на каждом шарде (их стоит использовать, если write нагрузки на эти таблички небольшие)
2) Шардированная база поддерживается семантику вида read commited и repetable read
3) Эта семантика работает внутри кластера Aurora, поэтому общие штуки типа дампа или point-in-time recovery работают как ожидается от кластера без шардов
4) Под капотом все это работает за счет добавление концепции shard group внутри aurora cluster, где есть роутеры для распределенных транзакций (здесь координируются распределенные транзакции и собирается общий результат) и шардов для доступа к данным (здесь выполняются локальные части запросов, работает локальный планировщик, используются индексы и так далее). Здесь тоже появляется дополнительный параметр compute redundancy, который позволяет compute частям шардов лучше переживать отказы
5) Для реализации repetable read ребята используют концепцию bounded clocks, которая похожа на концепт TrueTime из Spanner. Смысл этой концепции в том, чтобы использовать метки времени с разных устройств для упорядочивания транзакций. Проблема в том, что часы на разных машинка время может чуток отклоняться, поэтому приложению нужно несколько параметров: current time (approximate), earliest possible time, latest possible time. А дальше приложение должно подождать немного для того, чтобы точно не выставить транзакции метку времени из прошлого (иначе это может нарушить порядок транзакций в кластере). Эти параметры приложение получает из сервиса EC2 TimeSync с точностью порядка микросекунд. В самой презентации рассказывается как это работает для локальных и распределенных транзакций, а также для выполнения запросов с агрегатами.
6) В конце доклада авторы рассказывают про то, как взаимодействуют роутеры и шарды, а также как померить эффективность запросов, какие запросы получают максимальные бенефиты от параллелизации выполнения запросов на разных шардах (создание индексов, вакуум, агрегаты)
7) Пока эта limitless версия Aurora доступна через заявку на превью

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering #Databases

Аудиоподкаст "Code of Leadership"

Вчера я завел аудио версию подкаста и выложил первый эпизод на podster.fm, чуть позже он появится и на Яндекс Музыке. Так что теперь подкаст можно будет просто слушать, а не напрягаться и разглядывать иллюстрации из книг:) Кстати, за следующие пару недель планирую записать еще два эпизода:
- по книге Turn the Ship Around, про которую я уже упоминал раньше
- по книге "Как пасти котов", про которую я уже тоже рассказывал

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

#Management #Leadership #Podcast #Engineering #Software #SoftwareDevelopment

Вакансия лида SRE команды в соцплатформу

В конце прошлого года я уже тизерил изменения внутри моего юнита "Клиентские интерфейсы, маркетинг и вовлечение". А сегодня я хотел рассказать про вакансию лида в одно из новообразованных управлений в рамках этих изменений. Это управление, в котором мы объединили все наши социальные сервисы и большую часть UGC (user generated content) в одно большое управление, туда вошли:
- Пульс - одна из крупнейших соцсетей для инвесторов;
- Лента новостей и профиль в мобильном приложении Тинькофф;
- Т—Ж (Тинькофф Журнал) - один из самых крупных медиапроектов про деньги и жизнь;
- Игры в приложениях Тинькофф - например, «5 букв» или «Ряд наград»;
- Видеоплатформа для сервисов Тинькофф.
Радует, что этим богатством сервисов пользуются несколько десятков миллионов человек и мы хотим, чтобы они получали сервис максимального качества. Для это мы хотим внедрить и масштабировать единые SRE-практики в рамках всего управления, которые помогут нам оперативнее реагировать на происходящие сбои и минимизировать их количество. Для этого Алексей Тарсов (@lexasoft123), технический директор этого управления, ищет к себе в команду лида SRE, который поможет с реализациями этих целей.

Формальные критерии есть в описании вакансии, но если кратко, то успешный кандидат
- Был лидом как минимум команды
- Имеет навыки работы с Linux и контейнерами, включая знания bash, а также понимает как работает сетевой стек
- Знает как работают CI/CD системы и имеет практический опыт с одной из них (желательно GitLab)
- Знает про принципы проектирования распределенных систем и умеет их готовить с использованием K8s
- Не чурается кода и может написать что-то на Python/Go (желательно хотя бы на уровне jun+/middle)
- Умеет готовить инфраструктуру не руками, а при помощи IaC подходов
- Умеет хорошо коммуницировать со смежными командами и находить общий язык с другими ролями: SDE, QA, Arch, менеджерами
- Разделяет принципы и философию обеспечения надежности сервисов (примерно как я описывал в докладе "Проектируем надежные системы")
- Плюсом будет опыт работы с video: ffmpeg и как работает передача видео в вебе

В общем, если вам нравится вакансия и вы считаете, что потянете, то пишите Леше (@lexasoft123) и он уже расскажет вам детали.

#Management #Vacancy #SRE

Сделано, чтобы прилипать. Почему одни идеи выживают, а другие умирают (Made to Stick. Why Some Ideas Survive and Others Die)

В этой книге авторы захватывающе рассказывают о том, как сделать ваши идеи "прилипчивыми". Это позволит вашим важным идеям пробивать себе дорогу. Авторы для начала рассказывают про свой акроним SUCCESs:
- Простота (simplicity) - для того, чтобы обнажить суть идеи, надо уметь отсеивать лишнее. Для этого надо уметь определять цели и приоритеты - идеи должны быть одновременно кратки и содержательны. Например, такими являются пословицы, которые мы с легкостью запоминаем и используем при случае.
- Неожиданность (unexpected) - для привлечения внимания важно удивить аудиторию кажущейся нелогичностью. Это близко к тезису Суворова "удивил - победил":) Но удивление не длится долго, поэтому важно кроме удивления возбудить интерес и любопытство аудитории.
- Конкретность (concrete) - абстрактные идеи запонимаются плохо, поэтому авторы рекомендуют добавлять конкретные образы, которые цепляют аудиторию.
- Достоверность (credentialed) - прилипчивые идеи должны сами по себе вызывать доверие и для этого можно использовать внешние авторитеты, статистику, визуализацию, тестирумые рекомендации (аля попробуй сам):)
- Эмоциональность (emotional) - здесь авторы предлагают использовать эмоции для подкрепления своих людей. Плюс люди испытывают эмоции к людям, а не к абстракциям, поэтому в миксе с конкретностью этот пункт позволяет благотворительным организациям успешно заниматься фандрайзингом
- Истории (story) - эта часть посвящена использованию историй, которые хорошо иллюстрируют идеи и в комбинации с другими факторами помогает не просто донести идею, но и провернуть что-то типа мысленной "репетиции", где аудитория проигрывает эту историю у себя в голове

Российский издатель (МИФ) приводит следующий список причин для прочтения книги

— После прочтения этой книги — увлекательной и провокационной — вы станете иначе доносить свои идеи до мира
— Чек-лист, который поможет превратить обычную идею — в «прилипчивую»
— В книге есть Лаборатория идей, где можно отточить теорию на практике: представить, как улучшить чужие истории, и подумать, какие бы фишки добавить
— Бестселлер: почти тысяча отзывов на Амазоне и высокий рейтинг
— 6 принципов, миллион примеров, полезные кейсы и 256 страниц, которые вдохновят на креативные мыслительные подвиги

P.S.
Мне книга понравилась. Написали ее ученые и преподаватели в крутых универах
- Чип Хиз преподает в Высшей школе бизнеса при Стэнфордском университете
- Дэн Хиз работает ведущим специалистом в Центре развития социального предпринимательства Университета Дюка.
Это не просто булшит книжка, в ней много отсылок к конкретным психологическим экспериментам, плюс есть примеры из истории маркетинга:)

#Writing #PublicSpeaking #Leadership #SelfDevelopment #ProductManagement

Michael Gervais | The First Rule of Mastery | Talks at Google

В этом интервью Michael Gervais рассказывает про свою книгу "The First Rule of Mastery", в подзаголовке которой приводится основная мысль "stop worrying about what people think of you". Michael Gervais имеет PhD по психологии и работает со спортсменами-рекордсменами и призерами олимпиад, музыкантами, CEO крупных компаний. В своей книге он дает руководство по преодолению наших страхов перед мнением других людей (fear of people’s opinions) или сокращенно FOPO. Эти страхи могут ограничивать наш потенциал и мы встречаемся с ними практически повсюду. Когда мы позволяем FOPO взять на себя управление, мы действуем очень осторожно, потому что боимся того, что встретим критику. Когда нам бросают вызов, мы отказываемся от своей точки зрения. Мы обмениваем подлинность на одобрение. Мы гонимся за мечтами других, а не за своими.

В своей книге Майкл Жерве показывает нам, что ключ к продуктивной жизни — это перенаправить наше внимание с мира снаружи на мир внутри нас. Он раскрывает навыки и методы, которые нам нужны, чтобы преодолеть FOPO — те же навыки, которые он преподавал лучшим спортсменам в мире, в том числе MVP в спорте, всемирно известным артистам и музыкантам, а также лидерам и командам из списка Fortune 100. Как это принято в современной литературе по психологии и бизнесу, основные идеи излагаются через истории из мира спорта и бизнеса. Ну а в этом выступлении Майкл рассказывает основные идеи из этой книги.

P.S.
Прикольно, что у меня в очереди на прочтение есть уже книга Ричарда Фейнмана с названием пересекающимся с темой этого интервью "Какое тебе дело до того, что думают другие?". Она является продолжением "Вы, конечно, шутите, мистер Фейнман!", про которую я уже рассказывал.

#Management #Leadership #SelfDevelopment #Psychology #PopularScience

The Joy of Building Large Scale Systems • Suhail Patel • YOW! 2023

Это очень интересное выступление Suhail Patel, Senior Staff Engineer at Monzo. Оно посвящено тому, как поменялись latency numbers (смотри "Latency Numbers Every Programmer Should Know") и производительность в общем за последние годы. Важно, что эти изменения напрямую влияют на проектирование и эксплуатацию масштабных и нагруженных систем. Автор очень подробно идет по куче тем и
- Рассказывает про работу b-tree+ в базах данных (интересно, что он не говорит про LSM и SSTables)
- Показывает как поменялась скорость дисков: HDD (200 mbps), SDD (550 mbps), NVMe (3000 mbps)
- Упоминает про изменения в CPU (да закон Мура уже не про рост мощности одного ядра, а про увеличение количества ядер) + появление ARM процессоров, что выдают больше мощности на стоимость по сравнению с x86-64
- Говорит про рост пропускной способности сети (c 1Gbps до десятков Gbps) и появление кастомных чипов типа TPU от Google (tensor processor unit)
- Вспоминает давнишние предсказания о том, что несмотря на увеличение мощности компьютеров software всегда найдет куда утилизировать эти мощности (обычно в дополнительные уровни абстракций поверх уровня железа)
- Разбирает подход с работой вида thread per core (сравнение shared everything arch vs shared nothing arch на уровне процессора, его ядер и доступа к памяти), тут же рассказ про выделение одного ядра на работу с сетью и как это помогает с tail latency, про Seastar, что используется в Scylla (конкурент Cassandra, но только на C++, а не Java), про io_uring, который заехал и в libuv
- Рекламирует Rust как инструмент для системного программирования и показывает как его легко использовать с Python (пример с парсингом дат в промышленном масштабе)
- Рассказывает про новые трюки с garbace collection, начиная с Java 17, дальше про eBPF (я рассказывал про интересную документалку об этом проекте)
- Говорит про простое ускорение работы с парсингом JSON, оптимизацию загрузки весов с llama и подобные вещи при помощи понимания низкоуровневых концепций
И заканчивает на высокой ноте, призывая лучше разбираться с тем, как работет железо под нашим софтом

Many of the systems (apps, services, databases, caches, queues) that we build/rely on are grounded on quite poor assumptions for the hardware of today

Software can keep pace, but there’s some work needed to yield huge results, power new kinds of systems and reduce compute costs

#Software #Architecture #DistributedSystems #SystemEngineering #SystemDesign #Engineering #Devops #SRE

Разверните ваш корабль (Turn the Ship Around!)

Прочитал за пару дней эту интересную книгу, посвященную лидерству. Вся книга представляет собой историю капитанства Дэвида Марке, который рассказывает про свой подход, с помощью которого он превратил подводную лодку Santa Fe из худшей в лучшую всего за несколько лет. Дэвид описывает свой подход как переход от модели "leader - followers" к модели "leader - leaders". Для этого он выделяет три ключевые темы
- Control - принятие решений и контроль за их реализацией Дэвид предлагает передавать на тот уровень, где эффективнее всего это можно сделать. Чем-то это напоминает OKR (objectives and key results), в котором сверху приходят цели, а на местах люди уже придумывают как их достигнуть и какие ключевые результаты удастся получить. В итоге, у Дэвида в модели лидерства капитан не является человеком, который рассказывает что сделать и принимает за всех решения. У него офицеры и старшины могут принимать решения в своей зоне ответственности и нести за них ответственность (понятно, что несмотря на это за все происходящее на подводной лодке все равно accountable капитан)
- Competency - передача принятия решений и контроля без наличия нужных компетенций - это выстрел себе в ногу. Поэтому другой основой подхода Дэвида является повышение уровня компетенций команды. Его подход к инцидентам и работе с ними напоминает подходы SRE (site reliability engineers) и конкретно postmortems. Интересно, что Дэвид переключает команду с режима избегания ошибок на достижение операционного совершенства (operational excellence). Это фокусирует людей на непрерывном улучшении и обучении в процессе работы, вместо попыток просто "не облажаться"
- Clarity - в модели "leader - leaders" очень важно, чтобы люди, принимающие решения на местах, понимали общую цель организации. Часто в бизнесе при этом говорят про vision, mission, strategy и так далее. В книге Дэвид описывает как это выглядело для сотрудников на подводной лодке:)

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

P.S.
При чтении книги можно собрать очень хороший список вопросов для размышлений, которые автор приводит в конце каждой главы. Это позволит вам оценить насколько хорошо дела идут на вашей подводной лодке:)

#Management #Leadership #SelfDevelopment #Psychology #ForParents #SystemThinking #ProjectManagement

Programmer’s Apprentice Season 2: Future Directions in AI-assisted Coding • Erik Meijer • YOW! 2023

Интересное выступление про будущее разработки, в котором Erik Meijer, Director of Engineering at Facebook, делает утверждение, что мы - последнее поколение, что будет писать код руками:) И это не печалит автора доклада, скорее он рад и вдохновлен этой возможностью. Для начала автор вспоминает про то, как развивались языки программирования и про 5th generation, а потом как он ушел в создание языков программирования, а в районе 2017 года на фоне развития neural networks перешел в AI (вовремя переобулся). Дальше он говорит про
- Non-monothonic logic (как ранний подход к AI)
- Virtuous cycle между железом и программным обеспечением (отсылка к закону Мура)
- Vicious cycle между бизнесом и программным обеспечением, где сложность бизнеса приводит к усложнению софта (что может съедать весь прирост от virtuous cycle). Для этого обычно разрабатываются software engineering tools. Но автор предлагает заменить software + software engineering tools на AI:)
- Дальше автор рассказывает про whitepaper 2021 года "AI in Software Engineering at Facebook", где он выступал в качестве соавтора. Где авторы говорили про: code search using natural language, но это не очень понравилось пользователям. Дальше автор говорит про code recommendations, automated bug fixes. Для 2021 года это была крутая статья, но в 2022 году с приходом к власти LLMs она мгновенно устарела и автор показывает как эти сценарии легко выполняются с chatGPT
- Дальше автор переходит к описанию того, как можно автоматизировать самих себя:
-- AI-powerd typing (copilot)
-- AI-powered search (chatGPT)
-- AI-powered "workflows" (autoGPT)
- И дальше Eric показывает как это может выглядеть для написания программ в виде взаимодействия агентов: testrun agent, bugfix agent, refactor agent. Плюс дальше идет prompt engineering
- Дальше автор иронизирует над фреймворком React для фронта, а дальше рассказывает про новый React, который приведен в whitepaper "ReAct: Synergizing Reasoning and Acting in Language Models" и дальше автор вспоминает свою whitepaper из 20 века "Client-side Web Scripting with HaskellScript"
- Ну и под конец автор рассказывает про видение LLM как scripting client
- Финальным слайдом идет утверждение, что llm-based software is very powerful, but error-prone, brittle, insecure, hard to write, impossible to debug, expensive, privacy sensitive
- И это все стоит поправить для того, чтобы перейти в новый светлый мир (где код писать будут LLMs), а для этого надо еще будет поработать инженерам:)

#Management #Software #SoftwareDevelopment #LLM #AI #ML #Engineering #SystemEngineering #Architecture

Java Weekend Offer @ Tinkoff

Мы в Тинькофф периодически проводим мероприятия, на которых устроиться на работу к нам можно за выходные. Очередное такое мероприятие пройдет в эти выходные (3-4 февраля) и 17-18 февраля. В рамках таких мероприятий обычно несколько команд приносят свои вакансии и преимущественно проводят интервью. В этот раз там есть ребята из моего юнита, что развивают Маркетинговую платформу. Эта платформа представляет из себя набор продуктов, с помощью которых мы связываемся с клиентами по множеству маркетинговых каналов. Каждый клиент банка — наш пользователь. Платформа работает по сценариям, которые создают контент-менеджеры. Она совершает более 100 млн действий ежедневно: рассылает пользователям пуш-уведомления и СМС, начисляет бонусы, запускает многоходовые маркетинговые акции и геймификацию.

Для того, чтобы дойти до фит-интервью с командами (и выбрать вакансию маркетинговой платформы) надо пройти 3 секции интервью
- Языковая секция, где будет обсуждаться платформа, фреймворки, с которыми вы работали, и теоретические вопросы, а также будет ревью кода
- Алгоритмы и структуры данных, где будет пара алгоритмических задач, чтобы оценить навык написания кода (эти навыки можно тренировать на leetcode, который и я использую, чтобы поддерживать себя в форме)
- System Design (для уровня senior), где надо будет спроектировать распределенную систему (вот мой пост про это интервью)

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

#SoftwareDevelopment #Software #Vacancy #Engineering

Профсообщества в больших компаниях

Появилась запись встречи канала "безвотэтоговсего" про профессиональные сообщества в Росбанке, где я дискутировал на прошлой неделе. Во встрече помимо меня участвовали следующие замечательные люди:
- Сергей Щербинин, автор канала "безвотэтоговсего" и организатор встречи
- Паша Соломин, лидер разработки и сопровождения СБОЛ
- Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых сервисов Росбанка
- Макс Морозов, СЕО Астон

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

Если суммировать мою точку зрения на основе опыта Тинькофф, то у нас проффсообщества логично называются профессиями и выстроены примерно так
- У профессий есть свои лидеры, что исполняют эту роль, совмещая с участием в продуктах/проектах
- Професии являются точкой синхронизации людей, объединенных вокруг чего-то общего: профессии (продакт менеджер, системный аналитик, qa-инженер, разработчик), языка разработки в случае разработчиков(golang, kotlin/java/.net, etc), функции (архитектура, процессы разработки) и так далее
- У каждой профессии есть ее лидеры, которые ее развивают как во всей организации, так и внутри крупных подразделений
- Лидеры профессий помогают определять ожидания от специалистов, которые входят в определенную профессию - это так называемые матрицы компетенций
- Лидеры профессий участвуют в рассмотрении заявок на повышение, что идут через наш процесс Т-Рост, про который я рассказывал в своей статье
- Лидеры профессий помогают улучшать найм сотрудников в рамках своей профессии (это наши стримы найма, например я когда-то курировал и рассказывал про system design и troubleshooting)
- В рамках профессии вырабатываются стандарты и часто реализовывается общий инструментарий, который помогает всем в рамках профессии быть эффективным
- Также лидеры профессий часто ведут публичную деятельность по освещению своей профессии как внутри, так и снаружи компании (aka devrel)

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

Но тогда возникает вопрос, а зачем ему это делать?
Ответ в том, что это улучшает карму сотрудника и повышает вероятность успешного повышения в рамках процесса Т-Рост, причем для высоких грейдов это становится необходимым, но недостаточным критерием:)

#Management #Leadership #Engineering #Staff #Software #Devrel

Leetcode - прогресс за первый месяц

Я уже рассказывал как купил себе Premium подписку на LeetCode на день рождения (3 января ) и парочку курсов оттуда ("Data Structures and Algorithms" и "System Design for Interviews and Beyond"). А теперь пришло время отчитаться за этот месяц:
- Оказалось, что руки забыли примерно одинаково как писать на всех языках, поэтому я решил вспоминать Python для алгоритмических задач
- После того, как я вспомнил синтаксис python и чуток набил руку, то easy задачки я стал решать где-то за 5-10 минут, а вот задачки уровня medium идут у меня с переменным успехом (и пока они скорее побеждают)
- У нас в компании есть чатик любителей leetcode, которые решают Daily Challenge вместе и обсуждают задачки - я туда тоже записался, но отрешал только около половины ежедневных задачек
- Зато SQL у меня как будто не забывался - тут в среднем easy задачки идут за пару минут, medium обычно минут 5 и даже hard задачки решаются относительно просто (правда, сегодня ночью решал порядка часа последнюю hard задачку из набора "Advanced SQL 50")

В общем, leetcode пока мне нравится - я системно им занимаюсь каждый день утром как проснусь и вечером перед сном и кажется, что руки и голова потихоньку вспоминает про алгоритмы:) Теперь я могу не только про них рассказывать, но и даже что-то написать:) Ну и для иллюстрации добавлю скриншот с визуализацией из своего личного кабинета, по которому я оцениваю свой прогресс.

P.S.
Купленные курсы я пока не прошел (и даже особо не начинал), но планирую в феврале их заботать. Особенно интересно будет изучить system design курс.

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment