#13: Заметки из корпорации II
Вам переслали эту ссылку? Вы можете подписаться на рассылку и получать письма по пятницам. Или подписывайтесь на канал Meet Deadlines в Телеграм, если вы предпочитаете эту платформу
Это вторая часть историй из BigTech'a. Первая была в прошлом году, если пропустили - ссылка здесь.
В этой серии выпусков я описываю истории, с которыми сталкиваюсь, работая в большой корпорации, фиксирую то, как работает менеджмент команд и продуктов и как это сказывается на эффективности организации. Не смотря на то, что это наблюдения из одной компании, они применительны к любой подобной компании.
Исследование профессии
В сообществе Проектных менеджеров мы проводим большое исследование профессии Менеджер проектов. Это международное исследование, направленное на то, чтобы понять - кто такой Менеджер проектов сегодня? Где он работает? Как развивается? Какие инструменты использует? С Какими сложностями сталкивается на работе?
Пройти опрос: https://surveys.meet-deadlines.kz
Промежуточные результаты опубликованы здесь и здесь.
Просьба к вам:
- Если вы Менеджер проектов, Scrum Master, Delivery Manager, Program Manager, Стажер в профессии ... - пройдите опрос о профессии (40 минут в среднем на заполнение)
- Если у вас есть проектный отдел или проектные менеджеры в компании - перешлите опрос с просьбой заполнить его и поделиться текущим состоянием.
Текст для пересылки:
Сообщество проектных менеджеров описывает Портрет Менеджера проектов 24/25!
Мы хотим узнать какие инструменты использует Проектный менеджер сегодня, какие позиции занимает, какие проекты он выполняет, использует ли AI? Много вопросов, на которые ответы может дать каждый в этой профессии!
Пройди опрос и помоги сформировать портрет: https://surveys.meet-deadlines.kz/ru
Результаты исследования будут опубликованы в конце года здесь и в этой рассылке.
Гранулярность команд
Общался я с менеджером команды, который отвечает вот за этот кружок у имени. Этот кружок отражает "Статус" пользователя - он онлайн, на встрече, не в офисе, в отпуске и т.д.
Такая фича появилась в продуктах Microsoft кажется лет 17 назад. И вот, тут я общаюсь с менеджером, который отвечает за этот кружок. Звучит настолько несуразно, что сразу и не поверишь, что на этот кружок выделяется команда из 5-10 человек!
После общения с ним, выяснили детали:
- Кружок - это лишь UI-часть, видимая работы всей команды.
- Команда предоставляет сервис по "статусу" всем продуктам, которым он нужен: MS Teams, MS Office, MS Exchange Online, MS SharePoint и т.д. Статус пользователя действительно внедрен во многие продукты онлайн-пакета MS.
- У команды множество источников данных, которые они собирают (сигналы): встречи в календаре, статусы в MS Teams, подключен или нет к сети в данный момент, звонки на мобильный клиент MS Teams, звонок через Телефонию.
- Среди множества сигналов, которые могут быть абсолютно противоположны (пользователь пишет письмо в Outlook, он доступен, но параллельно ему позвонили через MS Teams для решения срочного вопроса - пользователь занят). Какой статус на текущий момент решающий? Сигнал из какой системы приоритетный на текущий момент? Все это усложняет систему, заставляет разрабатывать алгоритмы, писать сложные правила с большим количеством условий.
- А если человек сейчас на встрече, в комнате переговоров (не со своего устройства), но на телефона поставил статус "Online". Какой реальный сигнал выставить человеку?
- Сервис требует высокой доступности. На сервисы этой команды подписаны все крупные продукты компании!
- Есть еще on-premise решения, которые устанавливаются на сервера клиента, без подключения к облаку MS. И это отдельная логика, которую команда должна поддерживать и развивать, выпускать патчи.
В результате, сложность системы приводит к тому, что гранулярность команд повышается.
И в этом же и сложность самоопределения инженера. Насколько это будет адекватно, когда ты с коллегами или на собеседовании расскажешь, что твоя команда отвечает за сигнал статуса пользователя? В то время как твои друзья, коллеги запускают сервисы контейнеры в kubernetes, делают интернет-магазины, целые мобильные приложения, крипто-валюты и контракты разрабатывают. А ты кружочки рисуешь.
Менеджеры из книжки
Когда я читал книги по менеджменту, я смотрел на то, какие бесполезные менеджеры там проиллюстрированы. Как они не погружаются в вопросы команд и только делегируют / форвардят вопросы своей команде. То есть, занимают позицию роутера, не принося реальной пользы для команды / компании (хотя в большой компании, адресовать вопрос команде которая может решить это - уже ценность).
Забегая вперед скажу, что я не говорю, что это повсеместная история. Все-таки вокруг много вовлеченных менеджеров, которые знают отлично свою область и их потеря для продукта может сильно навредить. Но, все же, не могу рассказать об этом.
Случай 1
Переписка в общем чате, где находятся менеджеры разного уровня. Обсуждают дашборд, которые отображает данные. Менеджер (назовем его Менеджер А) выше по иерархии не смог получить доступ к отчету, поскольку отчет не был публичен. Менеджер рангом ниже (менеджер Б), попытался ему помочь, сказал что нужно сделать, но поскольку он не владелец дашборда - его помощь оказалась бесполезной. Он тегнул Менеджера В, который является автором отчета и попросил исправить ситуацию и написать детальную инструкцию на дашборде, чтобы таких ситуаций больше не повторял. Хороший совет. Вот только:
- Менеджер В не подчиняется Менеджеру Б.
- Менеджер Б сам в состояние написать инструкцию, после того как прояснилась ситуации и не нужно "делегировать" это другим, тем более равным тебе по иерархии.
- Менеджер Б навел много суеты, пользы от которой оказалось 0, но создал уже 1 задачу. Пользы от которой тоже не так много.
Менеджер Б - пример такого роутера, который на мой взгляд не приносит реальной ценности.
Случай 2
Моя команда владеет сервисом синхронизации. Сервис синхронизации помогает десятку команд синхронизировать задачи между ними, сопоставляя статусы, комментарии и при этом не заставляя их смотреть в разные экраны, а видеть все на одной экране.
Одной команде потребовалось улучшить алгоритмы синхронизации, они обсуждали в чате этот процесс, уже алгоритм расписали. Но я об этом не знаю, потому что меня нет в чате. Обсуждение длилось несколько дней, пока один из менеджеров не нашел меня (владельца сервиса) и не добавил в чат для прояснения ситуации. Я собрал все их хотелки, описал как это будет работать, все согласились. Я спрогнозировал срок и на этом разошлись
Моя команда сделала изменения, но мы не завершили работу и не опубликовали эти изменения, поскольку фокус команды сместился. Меня никто не трогал по этой доработке, я понял что она все же никому не нужна. Оставили незавершенной задачей и переключились на другие проекты.
Спустя 4 месяца, я случайно от одного менеджера слышу, что проблема все еще актуальна. Прошу подключить меня в переписку. Меня добавили в 3 параллельных чата (!!!), где несколько групп менеджеров обсуждали исходную проблему в течение нескольких месяцев, предложили несколько вариантов решения, обсуждали что нужно найти владельца сервиса и доработать сервис. До меня эта информация за 4 месяца не дошла ниразу.
Менеджеры потратили свое время на обсуждение проблемы, но не приблизились к ее решению. Еще один христоматийный пример менеджеров из книги, которые только и треплются в чате, а не решают проблемы.
Случай 3
Рекомендую послушать выпуск подкаста Бреслава и Ложечкина, про переговоры. Александр делится еще парой примеров таких ситуаций, где люди тратят время и усилия, но при этом не решают проблему или не находятся в контексте.
Формальность в управлении и иерархии
Она проявляется и в отношении к проектам, KPI (см. прошлый выпуск из этой серии) и во всех процессах.
Я недавно сменил команду. У меня новый skip-level (руководитель моего менеджера) менеджер и интересную картину я наблюдал в отношении ко мне (менеджеру одной из команд) после смены.
Ситуация до:
- Мой skip-level менеджер инициировал проведение 1:1 со мной (не так, как я вижу эти встречи :)), они проходили сначала 1 раз в месяц, потом 1 раз в 2 месяца. Но проходили.
- С моим прямым менеджером у меня были 1:1 на еженедельной основе.
За месяц до даты формальной смены команды, я уведомил моего менеджера. И за несколько дней до формального перехода у меня должен был состояться плановый 1:1 с моим skip-level менеджером (тот, что раз в 2 месяца). Мои ожидания, что на этой встрече меня спросят об обратной связи, о том, что можно было бы изменить или улучшить внутри подразделения. Но... Мой skip-level менеджер сам отменил эту встречу, без каких-либо комментариев. Мои ощущения ровно такие, как я их описываю тут — исключительно формальный смысл проведения 1:1, но реально они не очень нужны были моему skip-level менеджеру.
С моим прямым менеджером мы провели еще пару встреч, где я сказал, что несмотря на смену команды, я доведу в течение месяца проекты, которые должен был закончить. Мне сказали "ок" и отменили все следующие встречи, не дожидаясь выполнения моих обещаний.
Мои выводы?
- Менеджеры нанимают себе подобных (отлично описано в книге Не работайте с мудаками) и с себеподобными срабатываются.
- Формальное исполнение процессов, потому что "так надо" или "так все делают".
- Может я настолько негативный персонаж, что все рады, что я ушел? :)
Лучшие практики
Когда я делился опытом работы в крупной компании, меня спросили: "Какие бы процессы или лучшие практики я бы взял из компании?". И несмотря на определенную степень несогласия с реализацией, я считаю что в компании действительно применяются лучшие практики. Много умных людей, кто предлагает и внедряет эти инициативы. Но основная сложность в реализации всех этих процессов, как они работают и как к ним относятся. Несколько примеров.
Практика 1:1. Уже привел пример в этом выпуске, насколько формально подходят к исполнению этой практики.
Connects. Это процедура Performance review. Точнее Connects пришел на замену Performance review, но фактически остается им же, но структурирован.
NSAT. В части работы инженера, внутри MS собирают данные об отношении разработчиков к инструментам и процессам, в которые они вовлечены. Инженеры рандомно выбираются ежемесячно и проходят опрос, где они анонимно могут высказаться о том, что больше всего их радует или раздражает в работе. данные анализируются и автоматически структурируются. В результате для тех, кто занимается улучшением процессов разработки, даются готовые данные в динамике для анализа. The Pragmatic Engineer отлично рассказал об этом на примере LinkedIn
Пример анализа исследования эффективности работы инженера в компании
1ES. One Engineering System. Организация внутри MS, цель которой работать над улучшением продуктивности инженера. На мой взгляд, они одни из самых полезных внутри компании =). В блоге написано, что они сделали, я отдельно выделю Хранилище информации (CloudMine), которое содержит в себе выгрузку из репозиториев, все коммиты и код разработчиков - позволяет делать запросы к базе данных самостоятельно и находить инсайты. Я пользуюсь :)
Promotion. Упоминал не раз уже, но отмечу, что в исходном варианте систем заявляется, что мы анализируем влияет (impact) кандидата на компанию. Если Импакт значимый и соответствует следующему уровню - получаешь промоушн. Нет -- нужно еще время для роста. Но, на деле же решения принимают менеджеры, которые в соответствии с книгой "Не работайте с мудаками", не готовы получать в команде инженеров выше себя по уровню. Так, например, в одной из команд за последние 4 года, менеджер команды вырос на 2 уровня (дважды, то есть), а внутри его команды из 6 инженеров за это же время, вырос только 1 инженер на 1 позицию. Стоит отметить, что менеджер без команды не можем сделать многое -- результаты работы менеджера - результаты работы команды.
В поддержку этого топика, хочу еще раз порекомендовать послушать подкаст Бреслава и Ложечкина. В этом выпуске спикеры делятся о том, что такое грейды и промоушн, зачем он нужен корпорации. Рекомендую, поскольку во многом это согласуется с моим мнением.
Технологии. В частности, Microsoft, инвестирует в технологии, что неудивительно. И в ряде случаев умные инженеры делают лучшие решения для того, чтобы выпускать лучшие продукты (не только для зарабатывания денег, но и еще в соревновании с конкурентами). Например, Самая тихая комната в Мире, для оценки качества звука.
Самая тихая комната в Mире, YouTube
Централизация технологий. Во многом, я поддерживают, чтобы был централизованный подход к инженерным практикам. Это позволяет отдельным командам не тратить усилия на поддержание инфраструктуры. Например, платформенная команда, которая создает и поддерживает решение для запуска сервисов на клиентов, телеметрии, средств разработки. Они же, могут предоставить единый механизм для CI/CD процессов сервисов команд. 1ES – одна из таких команд. Но в случае с MS, реализация также страдает. Ввиду масштаба, центральные решения (пусть даже за 2000-4000 инженеров и миллионов пользователей) – становятся настолько тяжелыми, что у них появляются циклы разработки, команда поддержки разрастается в сотни человек и становится черной дырой. Все это идет в разрез с эффективностью (в смысле скорости онбоардинга нового сервиса и инженера и затрат команды на это). На мой взгляд, такой системой является COSMIC. Альтернатива – иметь большую гранулярность (Как писал выше). Одна инженерная команда на 500-700 человек, чтобы оставаться гибкими. Затраты будут соизмеримыми.
Альтернативный аккаунт и Zero Trust. Практики безопасности в компании – на высоте! Прочитайте про Zero Trust. Огромное количество сил, времени и ресурсов на защиту данных нужно вложить, чтобы построить такое. С точки зрения работы инженера это:
- Отдельная рабочая станция (SAW) для доступа к данным клиента и публичным сервисам;
- Необходим альтернативный аккаунт (не рабочий), чтобы получить доступ к боевой системе;
- Много-факторная аутентификация;
- Для доступа к корпоративным ресурсам требуется защищенное подключение;
- Сканирование антивирусом всего и вся (код, рабочие станции, телефоны);
- ...
Перечислять отличные практики можно бесконечно. Как и выше в вариантах выше – проблема в их реализации. Правительство США опубликовало отчет, в котором одной из причин утечки правительственных данных летом 2023 года была:
Throughout this review, the Board identified a series of Microsoft operational and strategic decisions that collectively point to a corporate culture that deprioritized both enterprise security investments and rigorous risk management
Поддержание иерархии коммуникацией
Мне нравится эта история. Порядок коммуникации подтверждает статус в организации и кто главнее. Это традиция и часть культуры, потому что я вижу проявление ее на всех уровнях организации.
Выглядит это так:
- Руководитель направления анонсирует изменения (поздравления).
- Следом, в соответсвии с иерархией подчинения следуют "поддерживающие" сообщения.
- Далее летят поздравления от смежных подразделений направлений, рандомных людей.
Ниже относительно недавний пример. Произошла реструктуризации подразделения (2000 чел). Часть подразделения (50 чел) ушла под управление нового менеджера. И случилась согласованная коммуникация между участниками. По размеру писем, я могу сказать, что их нельзя написать за 6 минут (посмотрите на время отправки сообщений). То есть, все письма были написаны заранее, согласованы, каждый договорился о том, какой месседж он несет и отправлены по расписание. С разницей ровно в 6 минут. В строгой последовательности.
Строгая и согласованная последовательность сообщений по иерархии
Giving Month
Это культура, которая распространена в компании - Give Month. Месяц пожертвований.
На картинке – скрин письма от моего коллеги. Я удивился, что за большой текст он написал, а это его подпись, которая автоматически добавляется к каждому письму :)
Пример письма про Giving Month
Таким образом он промоутит донаты. Да, пусть это делается 1 раз в месяц (как кампания), но многие коллеги помогают, спонсируют разные фонды, организации. Microsoft спонсирует 100% от суммы донатов плюсом к тому, что сотрудники задонатили.
Дополнительное пообщение спонсорства: - 3 волонтерских дня отпуска в течение года. Если вы волонтером выступаете в каком-либо общественном мероприятии - этот тот случай - Собраны большое количество фондов и способов быть волонтером / задонатить (животным, природа, исследовательские организации) - В офисе стоят коробки, куда можно принести то, что будет спонсируемо для приютов
Коробки для сбора донатов в офисе
И это отличная практика! Это же я заметил в Эстонии – это ящики с яблоками, которые стоят повсеместно в городе. Просто жители выставляют свои яблоки и любой прохожий может их взять (дети очень часто берут). Заходишь в магазин / кафе – чашка с яблоками тоже стоит.
Проявление культуры донатов в Эстонии
В этом есть позитивный эффект – когда вы что-то от себя отдаете – вы делаете себя немного счастливее. Даже эта рассылка – это уже про отдачу и позитивно сказывается на мне :)
Возвращаясь к письму от коллеги – это подпись в письме - потрясающий способ что-либо рекламировать среди коллег.
Promotion-driven culture
Я уже писал об этом, здесь я повторюсь скорее. Но у меня был показательный случай относительно этого.
Общался я с инженером относительно его задачи. И за долгим объяснением, почему у него что-то не получается, услышал следующее:
И в принципе, я не хочу делать эту задачу. Мне нужно делать задачи для моего promotion! А эта задача не имеет такого импакта, который поможет мне прыгнуть на следующий уровень!
В целом, инженер примерно прав, это задача рутинная, которую он должен делать по своим обязательствам. Но все гонятся за промоушеном. Потому что единственный вариант вырасти в зарплате сейчас.
Плюсом, прочитал выпуск рассылки Pragmatic Engineer, где рассказывается о том, что наметился тренд на выход людей из BigTech'a и причины, которые все еще позволяют подобным компаниям удерживать людей:
- Акции. Картинка ниже показывает как увеличилась стоимость акций инженера, если он пришел в компанию в 2022 году.
Рост стоимости акций инженера, который пришел в компанию 2 года назад
- Акции выпускаются в течение 4х лет (в среднем) с момента входа в компанию. Это удерживает людей как минимум на 1 год, а далее на 4 года, после чего вестинг (выпуск) акций прекращается. Если сотрудник не получил акций в течение 4х года, то его доход сильно проседает.
- Чем выше твоя позиция в компании – тем больше доля твоего дохода лежит в акциях, нежели в зарплат.
Распределение уровня дохода между акциями, бонусами и базовым доходом в зависимости от позиции? по версии levels.fyi
Но люди все равно уходят, потому что:
- Возможно вам не повезло и вы в компании, чьи акции упали (красные в таблице).
- Нет безопасности в работе. Сокращают тысячами в направлениях. Например, Microsoft объявил о закрытии HoloLens, поэтому это направление в скором времени тоже будет сокращено.
- Технологии и рост скиллов. Работая в BigTech - ты учишься работать только в BigTech. Выходишь из BigTech - инженерные скиллы теряют свою релевантность.
Wrap Up
Это следующие 7 историй, которые зацепили меня за последние несколько месяцев. Часть из этих историй вы могли прочитать в Телеграм-канале, часть – уникальны для рассылки.
Эти истории могут показаться негативными, но не воспринимайте их как базовое поведение людей в подобных компаниях. Я вижу, что многое зависит от конкретного руководителя и места в организации. Это лишь мои наблюдения (я вижу максимум 1% всей организации), которые я отметил. Вероятно, это не последняя часть, будет еще последующие истории из цикла "Заметки из корпорации".
Пользу для вас я вижу в том, что:
- Люди везде одинаковые. Мотивация схожая, независимо от сферы и страны работы.
- Многие не читают книг для своего развития :)
- Некоторые читают и следуют им в буквальном смысле
- Сложность системы порождает еще большее усложнение системы.
- Любую хорошую практику, может испортить ее реализация. Реализуют практики – люди, которые работают рядом с вами.
Спасибо, что вы читаете!
Успевайте в срок!
Станислав
Узнать подробнее обо мне можно здесь, об этой рассылке - в специальном разделе