#Google

Думал сегодня о том, как компании вроде Гугла поддерживают культуру, которая способна справляться с неопределённостью и невероятно сложными системами.

Ответ пришёл во время собеседования. Некоторые люди просто более заточены на работу в сложной (complex) среде и в условиях, когда всё неясно. Когда не то что нужно найти ответы, а нужно найти вопросы, потому что бывают моменты, что вообще ничего не понятно. Вокруг чернота и ты должен быть источником света.

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

Как сказал Бадма в последнем эпизода подкаста — «Старкрафт как шахматы, если умеешь играть, значит есть мозг. Если есть мозг, значит умеешь работать».

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

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

Это способность или данность? Можно ли это развить?

Думаю, что развить можно всё, что угодно, но у нас разные стартовые позиции. Хорошее сравнение — это навык эмпатии. Кто-то с самого детства супер эмпатичен и чувствует других людей. Кто-то нет. Вижу это по своим детям, которые сильно отличаются по этому признаку, хотя вышли из тех же ДНК и выросли в одной среде.

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

Как-то читал про роль таланта в успехе. Поинт статьи был в том, что талант даёт фору, но успехов достигает тот, кто много работает. При этом тот, у кого есть талант и кто много работает, конечно же, обладает значительно бОльшими шансами на успех.

Имхо, навык работы в неопределённости можно развить через проработку страхов и отпускание контроля, потому что именно от контроля идёт ориентация на процессы и тяга к структуризации. А контроль внешней среды — проявление внутреннего страха. Чтобы внутри было хорошо, надо чтобы вокруг всё было предсказуемым.

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

Способность быстро мыслить и ориентироваться на ходу тоже, думается мне, зависит от страхов. Когда ты теряешься, не можешь сообразить, наступает блок, не можешь придумать правильные вопросы — это закрытое сознание. А сознание закрыто, потому что подсознание боится. Вдруг скажу что-то не то и меня за это порешат? Лучше даже не буду думать, чтобы обезопасить себя от ошибки.

Как-то так.


Меня спросили как проходят перемещения между командами (внутренние трансферы) в Гугле.

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

С одной стороны поощрение внутренних перемещений ведёт к тому, что проекты могут замедляться или даже приостанавливаться, особенно, когда уходят ключевые участники или руководители. С другой — у топовых специалистов полно возможностей за пределами компании и попытки ограничить их перемещения могут привести к полной потере сотрудника для компании.

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

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

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

Вернусь к процессу.

Есть внутренний сайт с вакансиями, который описывает команду, проекты и т.п. Не замечал как в Гугле, но в Амазоне есть ещё и внутреннее описание должности, которое даёт конфиденциальную информацию о продукте и команде. На вакансии есть контакты менеджера и будущих коллег.

Первый шаг в процессе — всегда неформальный “кофе” с нанимающим менеджером, чтобы узнать друг друга получше. Если разговор прошёл хорошо и есть взаимный интерес, то менеджер коннектит тебя с другими важными для позиции людьми. Для продакт менеджеров — это другие ПМы и лиды в инжиниринге.

Когда я переходил в Google Maps, я разговаривал с другим ПМом, сениор руководителем разработки (менеджером менеджеров), руководителем дизайнеров, директором по продукту и директором разработки. Все разговоры были относительно неформальными, но, естественно, они собирали какую-то информацию обо мне, а я — о них.

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

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

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

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

Это Гугл. Мой опыт в Амазоне был немного другим.

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

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

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

Это твоя проблема как менеджера и избавляться от неё через то, чтобы “сплавить” сотрудника в другую команду — это неправильно и большой риск для твоей репутации внутри компании. Ты должен или вытащить человека на должный уровень перформанса или убрать его из компании. Но есть менеджеры, которые могут наговорить плохого о тебе новому руководителю. Таких мало, но они есть, и эти вопросы решаются через HR.


В гугле есть прикольная штука под названием “peer bonus”. Каждый квартал ты можешь дать трём коллегам такой бонус.

Пишешь, что они такого экстраординарного сделали для проекта, команды или тебя, указываешь кто ещё должен получить эту “открытку” (обычно указывают всю команду в копии) и нажимаешь ОК.

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

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

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

Наверное, встанет вопрос а не могут ли люди злоупотреблять этой системой, чтобы “заработать деньжат”?

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


Иногда просто нужно что-то изменить.

Прошлой весной я решил рубануть с плеча и перешёл из работы над чатботами и UX-платформами в продукт, для которого интерфейс вторичен. Последний год я погрузился в инструменты для разработчиков — успел поработать с Kubernetes, “бессерверными” технологиями (serverless), а также немного окунулся в особенности девяти языков программирования.

Это было интересно, но мысли всегда уходили куда-то ещё.

Они уходили в дизайн.

Несмотря на то, что по образованию я автоматизатор-разработчик, в душе дизайн всегда занимал место на одну ступеньку выше кодерства. С того самого момента, когда мне в руки в 1990х попала газета Computer Review, где в короткой статье был описан язык HTML. Когда я кое-как смог выждать одну ночь на даче, чтобы прибежать домой и попробовать наконец вбить в компьютер заветные <html><head><title> и увидеть страницу в браузере.

Это было просто вау. Несколько строк достаточно сохранить и они показываются в экране? Без компиляции? Это был взрыв мозга. Отвал башки.

Именно благодаря HTML я начал изучать фотошоп и заниматься дизайном. Дизайн всегда привлекал меня тем, что пользователь взаимодействует с продуктом именно через его интерфейс. Дизайн — передовая линия продукта, то, что и есть “экспириенс”, даже если 90% кода — на бэкэнде.

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

Всю жизнь я пытаюсь найти баланс между двумя парадоксами: во мне живёт любовь к дизайну без желания им заниматься и любовь к кодингу без желания кодить профессионально. Отчасти поэтому я всю карьеру мечусь между техническими и менее техническими продуктами. И вообще мечусь всю жизнь в поисках того, что же мне интересно. AWS Chatbot был таким продуктом и я занимался им 4 года, но хотелось чего-то другого…

Перейдя в Гугл, я отправился слишком далеко в технические дебри. В какой-то момент я перестал получать удовольствие от того, что делаю. Разбираясь с особенностями обратной совместимости Node.js и нюансами сетевых политик в Istio, я попросту засыпал. Знаете, когда, как на лекциях, нужно вставить в глаза спички, чтобы хоть как-то держать глаза открытыми. При этом моя работа приносила огромную ценность и была важной и для разработчиков, и для компании.

Но это было то, что англичане называют “not my cup of tea”. Люди могут быть универсалами и делать любую работу, какую им дают. Это вроде бы называется “профессионализмом”. Но я лично могу по-настоящему выстрелить и преуспеть только когда у меня горят глаза. Когда я не могу уснуть, размышляя над рабочей проблемой. Когда я могу выскочить из душа и записать идею, чтобы случайно не забыть.

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

Больше всего мне не хватало дизайна. Я люблю продукты, которые можно потрогать. Продукты, у которых есть интерфейс. Которые можно показать другому человеку на телефоне и объяснить, как они работают. Поэтому я не работаю в финансах, системах обработки данных и другой неосязаемой деятельности. То, что вижу, я понимаю на уровне ощущений. Мыслями без слов, образами. Я даже не могу это объяснить. То, что не вижу — понимаю интеллектуально, но этого недостаточно, чтобы зажечь внутренний огонь.

Поэтому я решил внести коррективы в карьеру. Сегодня я перехожу в Google Maps, где смогу совместить свою страсть к дизайну, понимание разработчиков и опыт построения платформ. Я буду отвечать за развитие Google Maps API, который позволяет разработчикам встраивать гугловские карты в свои приложения. В чём именно будет заключаться моя работа я пока ещё не знаю, но в неё точно будет входить работа над кастомизацией внешнего вида карт. Дизайн ☺️

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

Мета-поинт здесь в том, что найдёт только ищущий. Жизнь хоть и полна компромиссов с собой, но она у нас одна и её не стоит тратить на то, к чему не лежит душа.


Я писал про различия в культуре между Google и Amazon — интересно разбирать по кирпичиком, чем отличаются организации. Однако, фокусируясь на различиях, легко пропустить, что у них также много общего.

Давайте посмотрим на то, что делает эти компании очень похожими друг на друга.

1) Информация универсально открыта всем сотрудникам

Весь код, история коммитов и code review, кроме новых супер-секретных проектов и тех, где есть серьёзная интеллектуальная собственность (IP), открыты всем сотрудникам. В Гугле моно-репозиторий, в Амазоне - тысячи отдельных, но ты можешь легко посмотреть, что делают другие команды и другие люди. Почти все задачи (issues, bugs) также в открытом доступе.

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

2) Внутренняя мобильность

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

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

3) Проактивность приветствуется.

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

Приведу пример.

В 2016 году в индустрии было много разговоров о чатботах. В Амазоне начали формироваться различные чатбот-проекты, в том числе, и мой AWS Chatbot, который был одним из первых и немногих, кто смог вывести успешный продукт на рынок. Я увидел активный интерес к чатботам в компании и организовал мини-конференцию для тех, кто работает над чатботами.

Я кинул клич в мейл-лист и мне на помощь пришло еще 4 волонтёра. В первый год мы организовали ивент на 100 человек, который помог создать помогающую друг другу комьюнити. Следующий ивент уже был на 400 человек с серьёзными гостями (автор Amir Shevat был главным спикером) и спонсорами. Я всё это сделал своими руками при помощи волонтёров, без спроса у менеджера.

Пришлось поработать адское количество часов, но вышло здорово. Я делал это для комьюнити, без задней мысли. Мне самому было интересно, кто над чем работает и я хотел собрать всех в одной аудитории. Однако, это создало мне внутреннюю репутацию как эксперта по ботам и следующие 4 года открыло возможности для консультирования разных команд Амазона по чатботам. Это помогло в том числе и моему промоушену на Principal.

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


В первом мета-эпизоде подкаста в гостях сам ведущий - Илья Безделев. В этом выпуске я отвечаю на вопросы о работе в Google и Amazon с уклоном в то как происходит найм, дизайн продуктов и как устроена культура этих компаний. Интервью проводил дизайнер Марат Достарбеков.

Место записи: Марат записывал в Алмате, а Илья - в пригороде Гонолулу на Гавайях.

Илья Безделев
Илья Безделев

Ссылки для скачивания

Ссылки на ресурсы

Таймлайн эпизода

0:44 - Илья рассказывает о себе.

1:40 - Об образовании.

3:36 - О системе высшего образования в США.

4:45 - Смотрят ли компании FAANG на образование?

6:20 - Кто собеседует кандидатов? HR vs рекрутеры.

6:54 - Как смотрят на образование у кандидатов с опытом?

7:50 - Разница между алгоритмами в крупных компаниях и маленьких проектах. Пример вопроса по системному дизайну.

8:45 - Важность кругозора и понимания бизнес-проблемы.

9:11 - Как рекрутируют дизайнеров?

9:43 - Процесс собеседования в Amazon.

16:20 - Программисты, PM и UX. Конфликт интересов

16:41 - Ответственность за зависимости (dependencies).

16:57 - Когда дизайнерам дают советы.

17:33 - Процесс создания продуктов от и до.

18:44 - Системы дизайна.

20:08 - Agile product development.

21:17 - Почему важно получать фидбек на дизайн от программистов.

22:44 - UI, UX и Visual дизайнеры.

23:39 - От чего зависит уровень дизайнера?

24:50 - Principal UX дизайнеры.

25:32 - Профессиональный карьерный рост vs. идти в менеджмент.

29:04 - Пример работы принципала в Amazon, информационная архитектура.

30:55 - Софт скиллы которыми должен обладать дизайнер чтобы войти в FAANG.

33:11 - Негламурная работа дизайнера.

33:50 - Экспериментирование, юзабилити ресерч.

35:28 - А/В тестирование.

36:07 - Когда начинается тестирование на живых людях?

37:58 - Догфудинг.

39:44 - Если портфолио под NDA? Как показать на собеседовании?

40:27 - Про работу из дома в локдауны.

41:12 - Почему продакту важен контекст.

42:50 - Коридорная культура Google, сложности удаленной работы и растянутые митинги.

45:19 - Важность Google Docs в митингах и открытость культуры Google.

47:16 - Культура радикальной прозрачности и хаоса в Google.

49:10 - Как Amazon создает продукты.

50:24 - Процессы контроля качества создания и эксплуатации ПО в Amazon.

53:07 - Советы дизайнеру, чтобы стать хорошим кандидатом для FAANG?

55:43 - О курсах в Instagram.

56:12 - О важности английского языка.

Благодарности

Звукорежиссёру Михаилу Семашко - за редактирование аудио и создание иллюзии, что у меня идеальная речь без слов-паразитов. True story - мама послушала подкаст и восхищалась чистотой речи!

Автору подкаста Уехавшие Дмитрию Сидорову (телеграм-канал) - за вдохновение, советы и коннект с Михаилом.

Дизайнеру Марату Достарбекову - за то, что провёл со мной интервью и согласился сделать из него подкаст.


Работа в Amazon и Google сильно отличается и, по моим наблюдениям, фундаментальная разница в том, как они работают с неопределённостью.

Обе компании постоянно сталкиваются с неопределённостью, так как и Амазон, и Гугл создают новые технологии на глобальном масштабе. В этих проектах много рисков, связанных с самим продуктом (product-market fit), технологиями (создать что-то несуществующее бывает сложно, долго, дорого или вообще невозможно) и масштабом (системы должна работать для сотен миллионов пользователей по всему миру).

Гугл подходит к проблеме неопределённости с позиции “давайте начнём, а там разберёмся”. Можно сказать, что Гугл лавирует в потоках неопределённости и органически находит лучший путь сквозь тернии неизвестного.

Плюс этого подхода — инновации и скорость на старте. Минус — можно насоздавать продуктов, у которых “всего лишь” несколько миллионов пользователей и которые потом приходится убивать как неуспешные. Не каждый может так плавать в неопределённости месяцами, когда под ногами нет твёрдой почвы и многие обсуждения основаны на предположениях.

Амазон использует диаметрально противоположный подход. Он стремится искоренить неопределённость насколько это возможно. Процессы компании заставляют продакт менеджеров и тех лидов анализировать риски и различные сценарии развития событий и подкреплять это всё расчётами. Та неопределённость, которая всё же осталась неразрешённой, открыто признаётся и документируется как риски.

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

Где лучше?

Как говорил один мой русский коллега “to whom how”. Обе компании — супер успешные. Оба подхода работают. В неопределённости кому-то комфортнее плавать, а кому-то комфортнее искоренять. Иными словами, “кому как”.


Когда я пришёл в Google, синдром самозванца оставил меня примерно на 10-м месяце, а придя в Amazon пятью годами раньше я смог войти в струю и почувствовать себя уверенно за неделю. В чём была разница?

Предыдущие посты по теме: Синдром самозванца ч.2, Синдром самозванца в Google.

Я писал про три фактора, усложняющих смену работы: домен (область знаний и экспертизы), культура компании и позиция. Их и разберём на моём примере.

В Амазон я пришёл интерном Senior Product Manager на проект, связанный с рекламной платформой для amazon.com. Это был знакомый домен и у меня был весь необходимый набор скиллов в статистике, A/B тестировании, SQL, а также опыт с AdWords и AdSense, который был напрямую применим в работе.

Культура Амазона, основанная на документах, подошла мне идеально. Я люблю писать структурированные документы и скрупулёзно дорабатывать их через анализ и обратную связь до тех пор, пока не появится кристальная ясность. За неделю я освоился, стал “своим в доску” и успешно закончил проект, который принёс оффер на фулл-тайм позицию.

Придя в AWS (облачный бизнес Амазона) следующим летом, я освоился за пару дней и к концу первой недели уже написал первый черновик требований для нового проекта — платформы аналитики. Я опять попал в знакомый домен и, вдобавок, хорошо ориентировался в культуре. Через 4 года меня промотировали на уровень Principal, а ещё через год я перешёл в Google.

В Гугле система грейдинга немного другая, тут меньше названий, но больше уровней. Я называюсь Product Manager, но мой уровень эквивалентен амазоновскому принципалу. Таким образом, в Гугл я зашёл на более высокий уровень, чем когда начинал в Амазоне. Казалось бы, у меня есть весь опыт, необходимый для успешного начала работы, но начинать на более высоком уровне оказалось сложнее.

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

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

Самое важное в этом переходе — смена домена. Я перешёл из комфортной для себя области чатботов, веб-приложений и аналитики в облачную инфраструктуру. В самые дебри Kubernetes, Knative, Istio и других страшных названий. Что бы я ни делал, что бы ни читал, у меня всегда было ощущение, что я отстаю в понимании технических деталей. Мне приходилось звать с собой инженеров на разговоры с клиентами, потому что на каждом звонке меня заставали врасплох каким-нибудь техническим вопросом.

В какой-то момент поселился страх, что меня уволят раньше, чем я смогу распутать этот клубок знаний. Наверное, это было ощущение как у людей, которые заходят в айти из другой профессии — ты видишь перед собой гору непонятного и ХЗ с чего начать. Куда не сунься, везде нужны знания из смежных областей. Я прочитал 5 книг по технологиям, используемым в нашем продукте, но даже этого было мало. Мне не хватало практического опыта с подобными системами.

Ситуацию отягощало то, что многие мои вопросы были слишком мелкими, чтобы выдёргивать людей на митинг (они обычно 30-минутные и нужно договариваться заранее), но слишком сложными, чтобы я мог их нормально описать текстом в чате. Я много “варился в собственном соку”, как говорил один из моих первых руководителей много лет назад.

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

Появилась карта, из которой я начал составлять понимание системы в целом, её компонентов и их взаимосвязей. Я всё ещё многого не знаю, но уже могу комфортно вести разговоры, отвечать на вопросы пользователей или умело переводить их на правильных людей. В самом начале некоторые вопросы настолько вгоняли меня в тупик, что я даже не знал к какой части системы они относятся и кто за неё отвечает.

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

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

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

И, как говорят американцы — “fake it till you make it.” Это про меня, да и, наверное, про всех из вас, кто рискует и идёт в неизведанные для себя дебри.


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

Для начала надо отметить, что продакт менеджеры не работают на «проектах». Я отвечаю за развитие бизнеса, в основе которого лежит технологический продукт, и работа на нём бессрочна — она продолжается до тех пор, пока продукт существует. Результаты достигаются через запуски и другие проекты, для которых вместе разработчиками я задаю направление.

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

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

В какой-то момент начали складываться очертания того, куда я попал, и я начал документ под названием MVSR — Mission, Vision, Strategy, Roadmap. Миссия - это то, зачем мы существуем, высокая идея. Видение - цель на 3-5 лет. Стратегия - как мы достигаем видение и как это увязано со стратегией организации и Google Cloud. Roadmap - конкретные фичи, которые мы планируем сделать в ближайшее время.

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

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

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

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

Эти идеи пришли из трёх источников:

  • Физик Ричард Фейнман практиковал письмо всего, что он знает о предмете, чтобы увидеть границы своих знаний.
  • Мой бывший босс в Амазоне использовал документ MVSR, когда он пришёл в нашу организацию и наводил порядок.
  • Книга «Первые 90 дней» хорошо описывает баланс между техническими знаниями и организационным ориентированием на новом месте.

Итак, когда начинаешь работу в новой для себя сфере/команде/проекте:

  1. Максимально быстро получи общее представление о продукте, процессах, людях и технологиях через общение с людьми, чтение внутренних документов, просмотр видео и т.п.
  2. Начни писать то, что узнал. Это поможет как тебе, так и другим, потому что теперь «племенные» знания (tribal knowledge) становятся задокументированными знаниями и их легко передавать дальше.
  3. Возьми какой-нибудь проект, чтобы окунуться в детали. Погрузись туда с головой. Это поможет понять технические проблемы и ограничения, а также построить отношения с коллегами и пользователями.
  4. Пока у тебя свежий взгляд, подвергай текущие процессы сомнению, но не переусердствуй, так как ты ещё многого не знаешь. Просто задавай вопрос «почему» и изучай ответы. У тебя есть шанс изменить мышление команды к лучшему.
  5. Документируй всё. Повторяюсь, но это важно. Человек, который способен излагать свои мысли и синтезировать информацию письменно, сразу же приносит пользу любой команде. Люди это оценят.
  6. Поставь на паузу другие интеллектуальные задачи. Я на время перестал читать книги не по теме ибо мозг опух так, что я даже не мог нормально разговаривать после рабочего дня. Был перегруз от интенсива. Отдых важен.

Немного деталей о моей работе продакт менеджером в Google Cloud и её технической составляющей. Если вам скажут, что продакту необязательно быть технически подкованным, скажите, что это зависит от индустрии, и перешлите этот пост.

Речь пойдёт о знаниях, которые нужны мне, чтобы быть успешным на моём конкретном продукте. В других продуктах требования будут отличаться, но везде нужна глубина в основных технологиях. Знать специфику технологий на старте как правило не требуется — от кандидата ожидают сильную техническую базу, благодаря которой он(а) сможет наверстать недостающие знания на месте.

Один из моих продуктов - Google Cloud Run for Anthos. Разберём пошагово, что он делает, и заодно посмотрим на требования к знаниям.

  1. Всё начинается с кода, который клиенты запускают на облачной платформе Google Cloud. Мой продукт помогает разработчикам быть более эффективными. Чтобы понимать пользователей, мне нужно разбираться в процессах создания ПО в локальной среде: кодинг, управление зависимостями, сборка, отладка, git.

  2. По старинке код заливают на сервер, но это вчерашний день. Последние годы в тренде “бессерверные” технологии (разработчикам не нужно управлять инфраструктурой) и контейнеризация (код упаковывается в “контейнер” со всеми зависимостями). Мой продукт объединяет обе технологии и, чтобы разработчикам не нужно было думать об инфраструктуре, он берёт на себя задачу “упрощения” технологий. Мне нужно немного разбираться в контейнерах.

  3. Продукт построен на опен-сорс платформе Kubernetes, которую создали внутри Гугла. Тут начинается самое сложное. Kubernetes даёт много свободы администраторам (они - моя вторая категория пользователей), но чересчур сложный для разработчиков. Задача нашего продукта - дать админам гибкость в настройке, но скрыть всё это от кодеров. Мне приходится разбираться в деталях Kubernetes.

  4. Чтобы упростить жизнь разработчикам и создать иллюзию “бессерверности”, моя команда создала опен-сорс проект Knative. Скажу лишь, что он сложный и пока ещё не достиг версии 1.0, поэтому там много подвижных частей. Он - ядро продукта и его мне нужно понимать достаточно глубоко.

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

    Для сети (network layer) используется гугловский опен-сорс проект Istio, который добавляет к контейнерам в Kubernetes так называемые “sidecars” - дополнительные контейнеры, которые работают рядом с пользовательскими и отвечают за регулировку трафика, мониторинг и соблюдение политики безопасности внутри системы. Нужно разбираться в сетевых протоколах, DNS и информационной безопасности в целом.

  6. Нашим пользователям нужно мониторить свои приложения при помощи метрик, логов и трейсинга, что можно назвать общим словом observability. Этот функционал предоставляется другими продуктами Гугла, а также партнёрами вроде Datadog. Нужно самому уметь всем этим пользоваться, чтобы понимать пользователей.

  7. Интерфейсы продукта: командная строка, графический UI и платформа автоматизации инфраструктуры Terraform. Нужно разбираться в UX дизайне и как он помогает пользователям достигать их целей (UX - это не только то, что можно кликать, а всё, с чем взаимодействует пользователь). Также нужно понимать основы DevOps (infrastructure as code, CI/CD, GitOps).

  8. И напоследок - приложениям пользователей нужно делать запросы к другим продуктам Google Cloud. Эта задача не всегда тривиальная, потому что между приложением и API этих сервисов стоит Kubernetes. Нужно разбираться в платформе Google Cloud и авторизации запросов из Кубернетиса.

Когда я пришёл в Google, я не разбирался в контейнерах и всём, что связано с Kubernetes, Knative и Istio. Мне также не хватало знаний по сетевым протоколам. Чтобы почувствовать себя относительно уверенно, ушло полгода, но мне далеко до комфорта, который я испытываю в области, где у меня есть глубокая экспертиза. Идеальный кандидат на такую работу был бы разработчиком из Гугла, перешедший в продакт менеджмент. Такие есть, но их мало.

Большинство продакт менеджеров в Google Cloud, что я знаю лично — бывшие разработчики, которых тянуло к бизнесу, стратегии и более масштабному мышлению. Если кто-то из вас разработчик, задумывающийся о переходе в продакт менеджмент, вас оторвут с руками на продукты с технической пользовательской базой при наличии сильных продуктовых скиллов. Дерзайте!


В марте прошлого года американские компании закрыли офисы. Всё началось с технологических гигантов в Сиэтле: Google, Amazon и Facebook были первыми, кто отправил сотрудников домой. Мы думали посидим пару недель дома и вернёмся обратно в офис, но прошёл уже год.

За этот год я перешёл на работу в Google Cloud в надежде на бесплатный хавчик, эспрессо и массаж, но в офисе я до сих пор ни разу не был. Мне прислали бэдж, но я даже не знаю куда его прислонять. Несколько человек в моей команде тоже перешли в Гугл после начала локдаунов. В отличие от остальных членов команды, мы не знакомы ни с кем лично. Это, пожалуй, самое сложное в смене работы на удалёнке.

Я — “коридорный” человек и обычно около часа моего ежедневного офисного времени уходило на общение с людьми на кухне, в коридорах, в лифтах и у входов в туалет. Я люблю перекинуться парой слов, собрать сплетни, ненавязчиво узнать статус проектов, задать вопрос, выслушать личные проблемы. Благодаря этому я держал руку на пульсе, двигал проекты вперёд и предотвращал кризисы.

Такое общение помогало мне на протяжении всей карьеры — я строил отношения с людьми неформально и я везде был “своим в доску”. За всю карьеру я могу пересчитать по пальцам конфликты с другими людьми, так как сложно конфликтовать с человеком, с которым ты на одной волне. А я ловил в коридорах самые разные волны. Интуитивно, без усилий.

А потом всё изменилось — коридоров не стало. Чтобы с кем-то поговорить, нужно запланировать звонок, но тогда важно кого-то не забыть и вот у тебя в митинге уже пять человек. Чтобы что-то быстро спросить, нужно это или напечатать (занимает время и требует усилий), или запланировать звонок. День стал разбит на отрезки времени в календаре, часть спонтанного общения 1:1 заменилась групповым с задержками связи, перебиванием друг друга и излишней вежливостью.

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

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

Локдауны подкосили эту культуру. Люди адаптировались и работают по-новому, но насколько они эффективны? Мне сложно судить, так как я не работал в “настоящем” до-ковидном Гугле. И возможно уже никогда не поработаю, потому что когда всё вернётся на свои места через 2-3 года, культура уже не будет прежней. Она будет травмирована беспощадной разбивкой рабочего дня на получасовые отрезки.

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

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

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

Забавно, как люди иногда оказываются не того роста, как ты их представлял, или другой комплекции. И вообще забавно, что они — живые люди, а не просто двигающиеся аватарки на фоне из бегающих детей и кошек.

У меня всё 🐈


В Google любят говорить о синдроме самозванца. С первого дня на тренингах опытные “Гуглеры” уверяли нас, что это распространённое чувство не только среди новеньких, но и среди давно работающих в компании.

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

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

С другой стороны, особо впечатлительные перфекционисты могут начать чувствовать себя менее уверенно, потому что постоянные разговоры о самозванстве могут вызвать вопросы из серии “А действительно ли я хорош для работы тут? Может я тоже самозванец, как и они, просто чего-то не вижу?”

Я поднял эту тему с коллегой, который пришёл в Google одновременно со мной, и рассказал ему, что я не чувствую себя самозванцем, но вокруг как будто есть давление, что надо бы. У него отозвались эти же ощущения.

Я читал, что много лет назад культура Google отличалась “интеллектуальной заносчивостью”, что особенно ярко проявлялось на собеседованиях, когда кандидату иногда давали понять, что он разговаривает с “кагбы очень умными людьми и должен знать своё место”. Это уже в прошлом и мой опыт собеседования и работы тут показывает, что люди очень приятные и скромные. Никто не хвастается своими достижениями и способностями.

Однако, мне кажется, Гуглу есть ещё над чем работать, ибо истории о самозванцах — это ничто иное как фольклорное восхваление интеллектуального уровня сотрудников, но в мягкой и неагрессивной форме. А, возможно, они всё делают правильно…

Вы бы стали чувствовать себя менее уверенно, если бы вокруг часто говорили о том, как чувствовать себя самозванцем это норма?


Когда готовился к интервью в Google, я узнал про систему планирования OKR, которую Гугл использует по рекомендации венчурного капиталиста Джона Дорра практически со становления компании. Система была изобретена в компании Intel, где Дорр работал в начале карьеры.

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

OKR расшифровывается как Objectives and Key Results и диктует форму записей целей для организаций и сотрудников. Objectives (цели) определяют то, чего мы хотим достигнуть. KR (ключевые результаты) определяют, каких результатов нужно достичь, чтобы цель была выполнена. KR обычно 3-4 на каждую O и прописываются они так, чтобы их достижение однозначно приводило к достижению цели.

Например, OKR может быть записан вот так:

O: Увеличить прибыльность на 20%.

  • KR1: Увеличить продажу дополнительных услуг на X%.
  • KR2: Сократить затраты на отправку посылок на Y%.
  • KR3: Увеличить эффективность сотрудников на Z%.

Компания создаёт OKR на самом высоком уровне и каждый KR становится O для следующего уровня иерархии. Например, увеличение продаж дополнительных услуг становится Objective для продуктового отдела роста, который разбивает её на более детальные KR и спускает ниже по иерархии.

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

Понимая куда мы идём всем продуктом, я сам выставляю свои OKR и договариваюсь с разработкой и другими отделами, чтобы они взяли себе такие же KR и мы все вместе могли достичь продуктовых целей.

Все OKR в Google публичные. Любой сотрудник может посмотреть OKR любого другого сотрудника. Я писал про прозрачность культуры и OKR - это один из механизмов обеспечения прозрачности.

Каждые три месяца наша организация (около 100 человек) в большом митинге публично разбирает уровень достижений по OKR предыдущего квартала и ставит им оценки от 0 до 1 как показатель, насколько каждый KR и О в целом были достигнуты. Потом ставятся OKR на следующий квартал и цикл начинается по новой. На моём коротком опыте в Гугле, O обычно остаются стабильными в течение года, а KR меняются каждый квартал.

Я описал процесс вкратце. Его ключевые аспекты - это иерархичность в сочетании с креативом, обеспечение общности целей и прозрачность. Если интересна тема, советую почитать книгу Джона Дорра “Измеряйте самое важное", в оригинале “Measure What Matters” by John Doerr.


Большинство кандидатов на работу в Google получают отказ. Я не знаю официальной статистики, но коллега говорил, что прособеседовал около ста кандидатов и из них наняли только пару человек.

Безусловно, Гугл и другие топовые компании нанимают людей с серьёзным интеллектуальным потенциалом, навыками и умением решать сложные задачи. Но есть две черты, которые не купишь за деньги и не воспитаешь контролем. Без них не удастся получить работу и удержаться в компании даже если ты очень крутой специалист.

Первое, что отличает всех сотрудников Google — это драйв и приверженность профессии. Гугловцы любят решать сложные задачи, которые до этого никто не решал. Людям реально важно и интересно то, над чем они работают, и они готовы свернуть интеллектуальные и бюрократические горы. Деньги имеют значение, но Гугл платит достаточно много, чтобы сотрудники не думали о деньгах.

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

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

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

В следующих постах — система постановки целей OKR и как компании проводят собеседования на неосязаемые качества вроде драйва и лидерства.


Самое необычное, что я заметил в Google — это то, насколько твоя работа прозрачна для других людей.

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

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

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

Люди открыто делятся рабочими документами с другими командами. Исключение составляют документы, где обсуждаются финансовые результаты бизнеса в целом (туда доступ только у тех, кому нужно знать эту информацию), и источники данных с информацией о пользователях. Получить информацию о пользователях ОЧЕНЬ сложно, в большинстве случаев практически невозможно, Google охраняет её как зеницу ока. Я стал больше доверять продуктам Гугла, когда сам начал тут работать.

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

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